147 lines
11 KiB
Markdown
147 lines
11 KiB
Markdown
|
# 39 | 项目总结：做好项目复盘，把经验变成能力
|
|||
|
|
|
|||
|
|
你好，我是宝玉。相信大家都有这种体验，经历了无数个“996”加班，项目终于成功上线了，也进入了稳定运行阶段，你终于可以松一口气，准备迎接下一个项目的挑战了。
|
|||
|
|
|
|||
|
|
然而，这时还有一件事不要忘记了，那就是对项目复盘，全面总结一下项目过程中的得与失。
|
|||
|
|
|
|||
|
|
## 什么是项目复盘？
|
|||
|
|
|
|||
|
|
“复盘”本来是围棋术语，表示对弈之后，棋手把下棋的过程重演一遍，看看哪些地方下的好，哪些地方下的不好，有哪些更好的走法。把下棋的过程还原，并且分析、讨论的过程就是复盘。
|
|||
|
|
|
|||
|
|
软件项目中的复盘，也是通过分析、讨论开发中出现的问题，进而总结成功经验，吸取失败教训，提升团队能力。
|
|||
|
|
|
|||
|
|
一次项目过程，自然会有一些做的好的地方，也会犯一些错误，复盘就是要分辨出哪些是好的实践，继续保持；哪些是做的不够好的，找出原因，针对性改进，避免再犯同样的错误。
|
|||
|
|
|
|||
|
|
如果没有这样的项目复盘，那下一次做项目，你还会是用同样的方式来做事情，那恐怕踩过的坑可能还得再踩一遍。
|
|||
|
|
|
|||
|
|
也许你会认为，你们团队也开过项目复盘总结会议，但是似乎没有什么效果，是不是项目复盘并没那么有价值？
|
|||
|
|
|
|||
|
|
并不是项目复盘没有价值，多数情况下，是因为没有做好项目的复盘，反而相当于浪费了一次学习提升的机会。比如说一些常见的存在问题的项目复盘情形：
|
|||
|
|
|
|||
|
|
* 总结不出来有效的结论
|
|||
|
|
|
|||
|
|
有些团队流水账的回顾了一遍项目过程，感觉似乎有做的不好的地方，但说不上是什么地方做不好，所以也无法进一步的总结。
|
|||
|
|
|
|||
|
|
* 没做好是客观原因导致的
|
|||
|
|
|
|||
|
|
有些团队在复盘后，将结论归结为是客观原因导致的，比如说：“虽然这次做的不好，只是客户不靠谱，但是下一次遇到一个好客户肯定能做的更好！”，这相当于没有想清楚：是哪里做的不好？为什么做的不好？下一次遇到这样的客户怎么才能做的更好？
|
|||
|
|
|
|||
|
|
* 知道什么原因，但不知道该怎么办
|
|||
|
|
|
|||
|
|
有些经过分析总结，能找到原因，但不知道如何应对。比如说发现主要原因是客户老变需求导致项目延迟，但是不知道如何应对需求变更。
|
|||
|
|
|
|||
|
|
类似于这样的项目复盘，确实达不到好的总结效果，也难有提升。那么怎么样才能做好项目复盘呢？
|
|||
|
|
|
|||
|
|
## 如何做好项目复盘？
|
|||
|
|
|
|||
|
|
项目复盘，首先就是知道项目中哪些是做的好的地方，哪些是做的不好的地方，这样才能把做的好的地方继续发扬光大，做的不好的地方进行改进修正。
|
|||
|
|
|
|||
|
|
那怎么样才能知道哪些地方做的好，哪些地方做的不好呢？
|
|||
|
|
|
|||
|
|
只要对比一下你当初制定的项目目标和最终的项目结果，就可以发现差异，通过这些差异，就可以清楚地知道哪些地方是变好了、哪些地方变糟了，比如说项目延期了，功能被砍了，软件质量相比以前的项目质量提升了。
|
|||
|
|
|
|||
|
|
但光知道差异还不够，需要思考背后的原因，比如说为什么会导致项目延期？做了什么事情让软件质量提升了？也就是说，要从这些事情中能总结出来规律，从而知道哪些做法是真正有效的，值得继承或者推广？哪些做法是无效的？
|
|||
|
|
|
|||
|
|
这里就需要结合软件工程的知识来分析，把实践经验概括为普适的理论或者原则。
|
|||
|
|
|
|||
|
|
最后就是要用这些从经验中学到的理论或原则，指导后续的项目开发，决定要停止做什么，开始做出怎样的改变，以及继续做哪些事。
|
|||
|
|
|
|||
|
|
联想公司对于项目的复盘总结了四个步骤，同样适用于软件项目，我们可以借鉴它的做法，采用四个基本的步骤来进行：
|
|||
|
|
|
|||
|
|
1. 回顾项目目标；
|
|||
|
|
2. 评估项目结果；
|
|||
|
|
3. 分析原因；
|
|||
|
|
4. 总结规律，落实行动。
|
|||
|
|
|
|||
|
|
接下来我就这四个步骤来分别讲一下，如何对项目进行复盘。
|
|||
|
|
|
|||
|
|
**第一步：回顾项目目标**
|
|||
|
|
|
|||
|
|
每个项目在最开始的时候都会确定项目的目标，所以复盘的第一步，就是要回顾最初的项目目标，方便对最终结果进行评估。
|
|||
|
|
|
|||
|
|
在这个环节，需要你描述清楚当初定的项目目标是什么？项目计划中制定的里程碑是什么？其中的关键就在于，对目标的描述要尽可能准确和客观。
|
|||
|
|
|
|||
|
|
**因为只有做到准确和客观，在后续你才能对目标的完成情况进行准确地评估。**
|
|||
|
|
|
|||
|
|
比如说：“我们的目标是做一款伟大的产品”，就不算是准确客观，因为“伟大”是一个根据主观评判的形容词，每个人对伟大的理解是不同的。
|
|||
|
|
|
|||
|
|
你需要将这类形容词换成具体可考核的检查项，比如，可以总结出类似于这样的目标：“三个月时间完成一款在线学习网站产品，包括登录、在线学习、留言等主要功能模块，上线后的Bug比例低于上一款产品。”
|
|||
|
|
|
|||
|
|
最后再加上最初定的里程碑，比如说：“两个月开始内部测试，三个月正式上线。”这样，大家就可以对目标的完成情况有清晰地认识。
|
|||
|
|
|
|||
|
|
**第二步：评估项目结果**
|
|||
|
|
|
|||
|
|
在对项目的目标进行回顾后，就可以来看看项目的实际结果和当初的目标有多少差异了。这里需要列出两方面的差异：好的差异和坏的差异。
|
|||
|
|
|
|||
|
|
比如说项目的结果是：我们花了四个月时间完成整体项目，三个月才开始内部测试。原有功能作出了调整，学生留言老师回复的功能改成了类似于讨论版，大家一起讨论的功能，上线后质量稳定，Bug比例低于上一款产品。
|
|||
|
|
|
|||
|
|
好的差异：
|
|||
|
|
|
|||
|
|
* 上线后质量很稳定，严重Bug很少；
|
|||
|
|
* 没有出现需求遗漏，开发和测试能及时同步需求的变更。
|
|||
|
|
|
|||
|
|
坏的差异：
|
|||
|
|
|
|||
|
|
* 功能发生了变化，中间有比较多的需求变更；
|
|||
|
|
* 项目发生了延期。
|
|||
|
|
|
|||
|
|
可以鼓励团队成员一起列出项目中好的差异和坏的差异。需要注意的是，在这一步，只需要客观描述结果就好了，不需要去分析原因，不然大家很容易思维发散，过早陷入对细节的讨论。
|
|||
|
|
|
|||
|
|
**第三步：分析原因**
|
|||
|
|
|
|||
|
|
在结果评估完了后，就可以来分析原因了，分析的时候也可以主要从两方面着手：是什么原因导致了好的差异，什么原因导致了坏的差异。
|
|||
|
|
|
|||
|
|
比如说，导致好的差异的原因：
|
|||
|
|
|
|||
|
|
* 增加了自动化测试代码的比例，改进了开发流程，代码合并之前有代码审核，并且要通过自动化测试；
|
|||
|
|
* 增加了工具的使用，比如持续集成系统的搭建，每次提交后可以清楚的看到测试结果；
|
|||
|
|
* 改进了项目流程，对于所有的需求细分后，都创建成了Ticket，基于任务跟踪系统记录了起来，这样可以及时了解任务进程，有需求变更的情况，相关人员也能及时了解。
|
|||
|
|
|
|||
|
|
比如说，导致坏的差异的原因：
|
|||
|
|
|
|||
|
|
* 老板对于产品干预过多，导致需求变更频繁；
|
|||
|
|
* 项目周期过长，难以响应需求的变化；
|
|||
|
|
* 设计时没有考虑到需求的变更，导致需求变更发生后，很多设计需要修改，最终导致延期。
|
|||
|
|
|
|||
|
|
在分析的时候，可以营造一个宽松的氛围，让团队成员能畅所欲言，讨论时要做到对事不对人，尽可能客观地分析清楚成功和失败的原因。**只有分析清楚原因，才能总结出规律。**
|
|||
|
|
|
|||
|
|
**第四步：总结规律，落实行动**
|
|||
|
|
|
|||
|
|
分析出原因后还不够，最重要的是，还需要去总结背后的规律，才能真正把成功或失败的经验变成个人和团队的能力。这里也可以充分运用你在《软件工程之美》专栏中学习到的知识，去帮助你总结规律。
|
|||
|
|
|
|||
|
|
比如说，接着上面的案例你可以继续总结规律：
|
|||
|
|
|
|||
|
|
* 需求变更是导致项目延期的主要源头，需要在后续项目中控制好需求的变更；
|
|||
|
|
* 自动化测试加上代码审查，再配合持续集成工具，可以有效提升产品质量；
|
|||
|
|
* 任务跟踪系统可以方便地跟踪需求的执行情况，也能保证项目成员能及时同步需求的变更。
|
|||
|
|
|
|||
|
|
总结出来规律后，还需要落实成行动，才能真正做出有效的改变，帮助你在以后的项目中做的更好。落实行动的关键就是：对于好的实践，继续保持；对于不好的实践，停止并寻求改变。
|
|||
|
|
|
|||
|
|
就上面的案例来说，针对上面总结出来的规律，你可以继续整理出需要在后续项目中落实成行动的事项：
|
|||
|
|
|
|||
|
|
* 参考专栏文章《[20 | 如何应对让人头疼的需求变更问题？](http://time.geekbang.org/column/article/89848)》中的解决方案，针对需求变更，我们将缩短项目周期，采用快速迭代的开发模式，及时响应需求变更，同时在一个迭代中，没有特殊情况，不做需求上的变更，有变更放到下一个迭代中；
|
|||
|
|
* 继续增加自动化测试代码的比例，代码在合并前要对代码进行审查，用好持续集成工具；
|
|||
|
|
* 继续使用任务跟踪系统，对需求任务进行跟踪，并且可以尝试对于一些临时性的任务也用任务跟踪系统跟踪起来。
|
|||
|
|
|
|||
|
|
通过分析目标、评估结果、分析原因和总结规律这四个步骤对项目复盘，能有效帮助你发现项目中做的好的地方和做的不好的地方，找出背后的原因，最终总结出来规律，落实成行动，做出积极的改变，把经验变成个人和团队的能力。
|
|||
|
|
|
|||
|
|
## 总结
|
|||
|
|
|
|||
|
|
项目复盘，可以帮助你从刚刚经历过的软件项目中，总结成功经验，吸取失败教训。为什么在同样的工作时间内，有的人就是成长的比较快，收获更多的经验能力？其实他们就像优秀的棋手，通过不断地对做过的事情进行总结复盘，来快速提升自己的能力。
|
|||
|
|
|
|||
|
|
项目复盘主要通过四个步骤进行：回顾项目目标、评估项目结果、分析原因、总结规律落实行动。
|
|||
|
|
|
|||
|
|
另外你需要注意的是，对于项目的复盘，并不是说只有项目快结束了才要去做，日常项目中遇到一些特殊的事情，比如线上故障，也可以及时总结复盘，预防类似的事情再次发生；在每一个迭代结束之后，都可以阶段性的复盘，比如说敏捷开发中每个Sprint的项目回顾会议；在整个项目结束的时候进行全面的项目复盘。
|
|||
|
|
|
|||
|
|
在项目复盘的形式上，可以通过团队会议的形式来进行，但是要想做到会议有效率，还需要在会议之前就做好准备工作，事先收集内容；会议进行中要有人组织引导大家积极发言讨论，避免陷入细节的争吵中，更要避免互相甩锅、人身攻击等极端情况发生；会议后，要落实到行动。
|
|||
|
|
|
|||
|
|
关于项目复盘会议，我觉得阿里的这篇文章写的非常好：《[开会=浪费时间？阿里技术团队这样开项目复盘会](http://yq.aliyun.com/articles/675302)》，你可以作为参考。
|
|||
|
|
|
|||
|
|
希望你也可以不断地对做过的事、参与的项目进行总结复盘，把经验变成能力。
|
|||
|
|
|
|||
|
|
## 课后思考
|
|||
|
|
|
|||
|
|
你平时都是如何对项目进行复盘总结的？你觉得哪些地方可以做的更好？你有哪些好的经验可以和大家一起分享讨论的？欢迎在留言区与我分享讨论。
|
|||
|
|
|
|||
|
|
感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。
|
|||
|
|
|