极客时间已完结课程限时免费阅读

39 | 项目总结:做好项目复盘,把经验变成能力

39 | 项目总结:做好项目复盘,把经验变成能力-极客时间

39 | 项目总结:做好项目复盘,把经验变成能力

讲述:宝玉

时长12:53大小11.81M

你好,我是宝玉。相信大家都有这种体验,经历了无数个“996”加班,项目终于成功上线了,也进入了稳定运行阶段,你终于可以松一口气,准备迎接下一个项目的挑战了。
然而,这时还有一件事不要忘记了,那就是对项目复盘,全面总结一下项目过程中的得与失。

什么是项目复盘?

“复盘”本来是围棋术语,表示对弈之后,棋手把下棋的过程重演一遍,看看哪些地方下的好,哪些地方下的不好,有哪些更好的走法。把下棋的过程还原,并且分析、讨论的过程就是复盘。
软件项目中的复盘,也是通过分析、讨论开发中出现的问题,进而总结成功经验,吸取失败教训,提升团队能力。
一次项目过程,自然会有一些做的好的地方,也会犯一些错误,复盘就是要分辨出哪些是好的实践,继续保持;哪些是做的不够好的,找出原因,针对性改进,避免再犯同样的错误。
如果没有这样的项目复盘,那下一次做项目,你还会是用同样的方式来做事情,那恐怕踩过的坑可能还得再踩一遍。
也许你会认为,你们团队也开过项目复盘总结会议,但是似乎没有什么效果,是不是项目复盘并没那么有价值?
并不是项目复盘没有价值,多数情况下,是因为没有做好项目的复盘,反而相当于浪费了一次学习提升的机会。比如说一些常见的存在问题的项目复盘情形:
总结不出来有效的结论
有些团队流水账的回顾了一遍项目过程,感觉似乎有做的不好的地方,但说不上是什么地方做不好,所以也无法进一步的总结。
没做好是客观原因导致的
有些团队在复盘后,将结论归结为是客观原因导致的,比如说:“虽然这次做的不好,只是客户不靠谱,但是下一次遇到一个好客户肯定能做的更好!”,这相当于没有想清楚:是哪里做的不好?为什么做的不好?下一次遇到这样的客户怎么才能做的更好?
知道什么原因,但不知道该怎么办
有些经过分析总结,能找到原因,但不知道如何应对。比如说发现主要原因是客户老变需求导致项目延迟,但是不知道如何应对需求变更。
类似于这样的项目复盘,确实达不到好的总结效果,也难有提升。那么怎么样才能做好项目复盘呢?

如何做好项目复盘?

项目复盘,首先就是知道项目中哪些是做的好的地方,哪些是做的不好的地方,这样才能把做的好的地方继续发扬光大,做的不好的地方进行改进修正。
那怎么样才能知道哪些地方做的好,哪些地方做的不好呢?
只要对比一下你当初制定的项目目标和最终的项目结果,就可以发现差异,通过这些差异,就可以清楚地知道哪些地方是变好了、哪些地方变糟了,比如说项目延期了,功能被砍了,软件质量相比以前的项目质量提升了。
但光知道差异还不够,需要思考背后的原因,比如说为什么会导致项目延期?做了什么事情让软件质量提升了?也就是说,要从这些事情中能总结出来规律,从而知道哪些做法是真正有效的,值得继承或者推广?哪些做法是无效的?
这里就需要结合软件工程的知识来分析,把实践经验概括为普适的理论或者原则。
最后就是要用这些从经验中学到的理论或原则,指导后续的项目开发,决定要停止做什么,开始做出怎样的改变,以及继续做哪些事。
联想公司对于项目的复盘总结了四个步骤,同样适用于软件项目,我们可以借鉴它的做法,采用四个基本的步骤来进行:
回顾项目目标;
评估项目结果;
分析原因;
总结规律,落实行动。
接下来我就这四个步骤来分别讲一下,如何对项目进行复盘。
第一步:回顾项目目标
每个项目在最开始的时候都会确定项目的目标,所以复盘的第一步,就是要回顾最初的项目目标,方便对最终结果进行评估。
在这个环节,需要你描述清楚当初定的项目目标是什么?项目计划中制定的里程碑是什么?其中的关键就在于,对目标的描述要尽可能准确和客观。
因为只有做到准确和客观,在后续你才能对目标的完成情况进行准确地评估。
比如说:“我们的目标是做一款伟大的产品”,就不算是准确客观,因为“伟大”是一个根据主观评判的形容词,每个人对伟大的理解是不同的。
你需要将这类形容词换成具体可考核的检查项,比如,可以总结出类似于这样的目标:“三个月时间完成一款在线学习网站产品,包括登录、在线学习、留言等主要功能模块,上线后的 Bug 比例低于上一款产品。”
最后再加上最初定的里程碑,比如说:“两个月开始内部测试,三个月正式上线。”这样,大家就可以对目标的完成情况有清晰地认识。
第二步:评估项目结果
在对项目的目标进行回顾后,就可以来看看项目的实际结果和当初的目标有多少差异了。这里需要列出两方面的差异:好的差异和坏的差异。
比如说项目的结果是:我们花了四个月时间完成整体项目,三个月才开始内部测试。原有功能作出了调整,学生留言老师回复的功能改成了类似于讨论版,大家一起讨论的功能,上线后质量稳定,Bug 比例低于上一款产品。
好的差异:
上线后质量很稳定,严重 Bug 很少;
没有出现需求遗漏,开发和测试能及时同步需求的变更。
坏的差异:
功能发生了变化,中间有比较多的需求变更;
项目发生了延期。
可以鼓励团队成员一起列出项目中好的差异和坏的差异。需要注意的是,在这一步,只需要客观描述结果就好了,不需要去分析原因,不然大家很容易思维发散,过早陷入对细节的讨论。
第三步:分析原因
在结果评估完了后,就可以来分析原因了,分析的时候也可以主要从两方面着手:是什么原因导致了好的差异,什么原因导致了坏的差异。
比如说,导致好的差异的原因:
增加了自动化测试代码的比例,改进了开发流程,代码合并之前有代码审核,并且要通过自动化测试;
增加了工具的使用,比如持续集成系统的搭建,每次提交后可以清楚的看到测试结果;
改进了项目流程,对于所有的需求细分后,都创建成了 Ticket,基于任务跟踪系统记录了起来,这样可以及时了解任务进程,有需求变更的情况,相关人员也能及时了解。
比如说,导致坏的差异的原因:
老板对于产品干预过多,导致需求变更频繁;
项目周期过长,难以响应需求的变化;
设计时没有考虑到需求的变更,导致需求变更发生后,很多设计需要修改,最终导致延期。
在分析的时候,可以营造一个宽松的氛围,让团队成员能畅所欲言,讨论时要做到对事不对人,尽可能客观地分析清楚成功和失败的原因。只有分析清楚原因,才能总结出规律。
第四步:总结规律,落实行动
分析出原因后还不够,最重要的是,还需要去总结背后的规律,才能真正把成功或失败的经验变成个人和团队的能力。这里也可以充分运用你在《软件工程之美》专栏中学习到的知识,去帮助你总结规律。
比如说,接着上面的案例你可以继续总结规律:
需求变更是导致项目延期的主要源头,需要在后续项目中控制好需求的变更;
自动化测试加上代码审查,再配合持续集成工具,可以有效提升产品质量;
任务跟踪系统可以方便地跟踪需求的执行情况,也能保证项目成员能及时同步需求的变更。
总结出来规律后,还需要落实成行动,才能真正做出有效的改变,帮助你在以后的项目中做的更好。落实行动的关键就是:对于好的实践,继续保持;对于不好的实践,停止并寻求改变。
就上面的案例来说,针对上面总结出来的规律,你可以继续整理出需要在后续项目中落实成行动的事项:
参考专栏文章《20 | 如何应对让人头疼的需求变更问题?》中的解决方案,针对需求变更,我们将缩短项目周期,采用快速迭代的开发模式,及时响应需求变更,同时在一个迭代中,没有特殊情况,不做需求上的变更,有变更放到下一个迭代中;
继续增加自动化测试代码的比例,代码在合并前要对代码进行审查,用好持续集成工具;
继续使用任务跟踪系统,对需求任务进行跟踪,并且可以尝试对于一些临时性的任务也用任务跟踪系统跟踪起来。
通过分析目标、评估结果、分析原因和总结规律这四个步骤对项目复盘,能有效帮助你发现项目中做的好的地方和做的不好的地方,找出背后的原因,最终总结出来规律,落实成行动,做出积极的改变,把经验变成个人和团队的能力。

总结

项目复盘,可以帮助你从刚刚经历过的软件项目中,总结成功经验,吸取失败教训。为什么在同样的工作时间内,有的人就是成长的比较快,收获更多的经验能力?其实他们就像优秀的棋手,通过不断地对做过的事情进行总结复盘,来快速提升自己的能力。
项目复盘主要通过四个步骤进行:回顾项目目标、评估项目结果、分析原因、总结规律落实行动。
另外你需要注意的是,对于项目的复盘,并不是说只有项目快结束了才要去做,日常项目中遇到一些特殊的事情,比如线上故障,也可以及时总结复盘,预防类似的事情再次发生;在每一个迭代结束之后,都可以阶段性的复盘,比如说敏捷开发中每个 Sprint 的项目回顾会议;在整个项目结束的时候进行全面的项目复盘。
在项目复盘的形式上,可以通过团队会议的形式来进行,但是要想做到会议有效率,还需要在会议之前就做好准备工作,事先收集内容;会议进行中要有人组织引导大家积极发言讨论,避免陷入细节的争吵中,更要避免互相甩锅、人身攻击等极端情况发生;会议后,要落实到行动。
关于项目复盘会议,我觉得阿里的这篇文章写的非常好:《开会 = 浪费时间?阿里技术团队这样开项目复盘会》,你可以作为参考。
希望你也可以不断地对做过的事、参与的项目进行总结复盘,把经验变成能力。

课后思考

你平时都是如何对项目进行复盘总结的?你觉得哪些地方可以做的更好?你有哪些好的经验可以和大家一起分享讨论的?欢迎在留言区与我分享讨论。
感谢阅读,如果你觉得这篇文章对你有一些启发,也欢迎把它分享给你的朋友。
分享给需要的人,Ta购买本课程,你将得18
生成海报并分享

赞 6

提建议

上一篇
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
下一篇
“一问一答”第4期 | 14个软件开发常见问题解决策略
 写留言

精选留言(11)

  • 拉欧
    2019-05-30
    我部门的项目复盘就是击鼓传锅大会

    作者回复: 😂好形象生动的比喻

    26
  • 易林林
    2019-05-30
    项目复盘是整个项目实施过程中或项目结束后很重要的一环,它可以帮助项目团队成员站在全局的视角上提升发现问题-分析问题-解决问题的能力,更能帮助具有管理才能的技术人才提高统筹规划和执行能力。与此同时,我们还可以根据每个团队成员在项目实施过程中的经典设计和典型错误,判断出他们各自的擅长领域和技术上的短板,在遇到相似或相关问题的时候进行针对性的沟通和交流,从而减少问题重复发生所带来的影响。

    作者回复: 🙏谢谢补充分享! 建议对于团队成员,日常就可以做这样的沟通和指正,不必等到项目复盘的时候。比如说定期可以有一对一的会议。

    共 2 条评论
    6
  • 陈丹
    2019-09-09
    有时候总结出是领导的问题,但是毕竟领导组织的,也没人敢说他的问题,每次领导说你们啥啥啥一堆问题,其实大家都觉得他是主要源头,但是就是不知道如何表达,让他意识到他的问题,又不会显得下属太直接。。

    作者回复: 说实话,这个问题我帮不了太多,多转发一点软件工程文章让他看到也许是个委婉的方式🤦‍♂️

    5
  • 纯洁的憎恶
    2019-06-02
    回顾目标。客观准确。 评估结果。在目标与结果的差异中发现做的好的地方和不足的地方。客观不发散。 分析好与不足的原因。畅所欲言,就事论事。 总结规律。归纳出可以继承的经验或极力避免的坑,凝练出流程与规范。
    展开

    作者回复: 👍谢谢总结分享

    4
  • hua168
    2019-06-08
    好的地方比原来做得差的意思是上一个项目复盘知道优缺点,比如bug变少了,是开发和测试花大量时间共同努力的结果,原因项目规定时间,其它方面少了,比如代码比较乱,注释少,文档没有…… 如果在bug方便控制,下个项目bug比之前多,其它方面有所改善,反正是这个弄好了,那个又变差了,小公司开发他们也不想着怎么改进,如果加入强制控制他们反感,本来时间就紧,还搞其它…
    展开

    作者回复: 如果是解决一个问题又导致了新的问题,按下葫芦起了瓢这种情况,需要多在整体思考一下原因,尤其是项目的整体流程和开发计划方面。 推广开发流程导致反感,觉得时间紧还搞其他这个问题,需要两方面入手: 1. 首先要反省项目计划,如果只是加要求而不给相应时间计划,比如说要求写自动化测试,而不留出写自动化测试时间,那当然会抵触。 所以相应的要制定出更好的项目计划,避免为了砍时间而砍时间,给开发留出时间去设计去写测试代码,不然就算你制定一个很紧的计划,还是要花很多时间修Bug,最终花的其实时间差不多。 2. 提升大家的认识,不仅是团队内部,还包括团队外部,你的老板和业务部门,获得他们的支持。让大家知道磨刀不误砍柴工:前期投入时间在开发质量上面,后期会节约大量修改Bug的时间。

    3
  • javaadu
    2019-11-09
    之前在有赞的时候,使用一些复盘的工具来进行项目复盘: (1)KISS(keep、improve、stop、start),分别讨论出在下一个项目中需要保持、提升、停止、开始的行动,感觉非常有效; (2)心情曲线,可以从另一个侧面考察项目组成员在项目过程中的参与感和非理性的感觉,有助于在后面的项目中改善项目组沟通 老师在这篇文章中介绍了最基本的步骤:(1)回顾项目目标;(2)评估项目结果;(3)分析原因;(4)总结规律,落实行动。对于第四步来说,就可以使用KISS这个工具。
    展开

    作者回复: 👍谢谢分享

    2
  • 冰糕不冰
    2019-06-12
    第二次阅读这篇文章,真的是大获启发!项目复盘会议组织过多次,但是没想到以前做的这么差劲,没想到复盘会议还可以这么玩儿,真的学到了很多。再次感谢宝哥!

    作者回复: 谢谢支持:)

    2
  • hua168
    2019-06-01
    如果复盘,好的是花不少精力上去了,如果要改进坏的,那么好的地方就会比原来的做得差,这种情况怎搞?是不是想办法提高效率之类? 另外我想问下宝哥,你哪章是讲代码质量,项目质量的呀?我看标题找不到,尴尬了^_^|||

    作者回复: 你说的“好的地方会比原来的做的差”,能举一个具体的例子吗? 你说的代码质量和项目质量是来自《31 | 软件测试要为产品质量负责吗?》

    2
  • alva_xu
    2019-05-30
    我觉得scrum方法中提到的两个会,可以作为项目复盘会内容的参考。Sprint评审会议(Sprint Review Meeting)和Sprint回顾会议(Sprint Retrospective Meeting)。Sprint 评审会议在 Sprint 快结束时举行 ,用以检视所交付的产品增量并按需调整产品待办列表,是对工作成果的评审。Sprint 回顾会议是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。是对方法论的回顾和提高。项目复盘会也应该从这两个角度去做总结提高。

    作者回复: 🙏谢谢补充! Sprint评审会议可以帮助发现做的好的和做的不好的; Sprint回顾会议可以帮助找出原因和总结规律

    2
  • 邢爱明
    2019-05-30
    回想一下,项目复盘想要效果好,需要做一些准备工作: 1. 复盘会前,要求项目组核心人员对项目的情况先自己进行总结,包括做得好和做的不好的方面,有书面文件输出。先要有思考,复盘会上大家才有可讨论的内容,否则会议上大家可能就是随便说说,复盘会成了走形势。 2. 复盘会的会议主持人,需要有比较强的会议主导能力,尤其是参加会议的人来自多个部门的时候。因为大家总结项目中做的不好的地方,难免会涉及到多个部门或团队配合的情况,且每个人的描述也不可能做到百分之百的客观和公正。如果有人认为总结的内容有问责的含义或需要自己承担责任,复盘会就很容易变成了甩锅会。这时候就需要会议主持人正面介入和引导,让大家讨论解决方案和改进措施,确保按照预定的议程开复盘会议。
    展开

    作者回复: 🙏谢谢补充! 会议前的准备蛮重要,要有一些基础的可以讨论的素材 会议时要有人组织控制

    1
  • ifelse
    2022-07-07
    项目复盘主要通过四个步骤进行:回顾项目目标、评估项目结果、分析原因、总结规律落实行动。--记下来