项目管理第四招：做好项目复盘_it项目复盘汇

项目结束不是真正的结束

​ 经过千辛万苦，产品上线了。项目组成员们往办公椅上一趟，长出一口气说终于结束了，项目组成员们都琢磨着去哪里吃上一顿大餐犒劳一下自己。但是这样真的已经结束了么？没有，恰恰相反，项目过程中的一个重要环节才刚刚开始，那就是：复盘，或者说总结。

复盘的重要性

​ 有句话说得好：“失败是成功之母”，但是这句话应该还有半句话没说出来。那就是，不是每次失败都会是成功之母，而只有总结了经验教训之后的失败才能成为成功之母，才能说让自己不在同一个坑跌倒两次。

如何复盘

​ 如何复盘的文章网上已经有一大把，我这里就不重复的引用，就基于基本的复盘步骤来聊一聊从程序员出身的项目经理的角度来看，怎么去做好这四个步骤。

回顾目标

​ 这里再一次体现了目标的重要性。如果没有目标，复盘也无从说起，因为你都不知道什么是好，什么是坏。这也再一次强调了目标需要用SMART原则去衡量的重要性。因为如果目标不是可衡量的，在复盘的时候就无法对目标进行偏差的评估。

基于事实评估结果

​ 每个人都会有情绪，每个人都会选择自己的需要的内容去进行记忆。所以基于事实去评估结果我认为是复盘中最关键也是最难做的部分。

​ 每个人在讲述过程的时候，都会选择对自己有利的角度去进行讲述，将对自己不利的部分忽略或者淡化。这是人之本性。因此，在项目过程中如实的记录就变得非常的关键。我认为项目过程中的记录可以在下面几个地方注意。

• 日报。很多程序员会认为这是一个非常浪费时间和精力的事情。但是如果你通篇看下来，看到这里时，你是不是也会认为日报会是一个非常有用的工具。
  • 首先，我认为日报不是一个浪费时间的事情。而是一个梳理自己当日工作内容，识别当前问题和风险，并为第二天的工作做好安排的利器。
  • 第二，上面这一点药实现的话有一个前提，就是项目总目标，阶段目标，阶段字母表拆分的非常明确。过程计划非常清晰的基础上，这样每个人才会有清楚的工作计划。如果工作无整体安排，工作就会和踩着西瓜皮一样，溜到哪算哪，工作日报自然也无从谈起，反而变成一个多余的事情。
  • 写日报不是目的，而是工具。不要用的太死板，因为有些预研或者研究性的工作，可以适当的把时间间隔拉长，比如双日报之类。
  • 最重要的，日报是在做项目复盘时，最好的事实记录基础。
  • 最后，个人认为，一份好的日报。完成的事情不会超过5件。太多了的话要不就是扯淡，要不就是在打杂。
• 会议纪要。会议是一个很好的工具，但是用好不容易。网上也有很多开好会议的指导，新的项目经理很有必要去研读一下。我这里提到的就是一个会议结束之后，必须要有成文的纪要。
  • 一是会议讨论往往都是比较发散的，将其中的重点抽取出来形成文字便于保存，所谓的“好记性不如烂笔头”。
  • 二是便于传播。都是信息时代了，会议的决议和精神不可能通过口口相传来进行传播，这样效率又低，又非常容易造成信息丢失。
  • 三是便于执行。会议上的决定都是停留在口头上，只有执行了才会变成现实。会议纪要就是督促会议参与人员和周边人员按照会议结论进行执行。
  • 回到我们的这个小主题上，会议纪要也是重要的过程事实。和日报记载日常工作和进展不一样，会议纪要记录了项目过程中的重要决策，决策的背景和原因等等。

​ 从上面的一些过程中发现了事实之后，我们就可以根据结果与目标之间的差距，参考过程中发生的事实，来分析成功和失败的原因了。

分析原因

​ 有了目标与结果的差距和事实依据之后，我们就可以来开始分析原因了。

• 分析两种原因：
  • 成功的原因，这样可以指导我们碰上相同的情况可以根据这些经验来指导我们的决策，这我们称作知识沉淀。
  • 失败的原因，这样就是让我们“吃一堑长一智”。

​ 一般来说我们能比较好的做好的经验的总结，而不太愿意做失败原因的总结，或者逃避，或者浅尝辄止。从我自己的经验来看，我们不愿意做教训的总结有下面几个原因：

• 都是一个公司的，低头不见抬头见，不好讲太多不好的东西，多不好意思。
• 分析错误原因就是在秋后算帐，为了不影响自己或朋友的利益，少说为妙。
• 不说别人的不对，下次别人也不会说我的。
• 不愿意面对自己的失败。

​ 所以说，我觉得做原因分析这个动作之前，有一些准备性的工作需要做，而且其中一些还是一些长期性的工作，为的就是一个目标：不让原因分析变成针对某个人或者某个团队的集中批判大会。

1. 我自己的经验是，我会准备一个ppt，在这个ppt的第一页就写上几个大字：“我们相信项目组成员做的每个决策都是当时最合适的决策”。为什么这么写呢，因为在分析原因时，很多人都会以一种**“事后诸葛亮”的态度去看待，你当时为什么不这么做，你当时这么做就好了。要知道，在做出决策的当时，并没有现在坐在办公室时有那么多的信息可供决策。我们是去集思广益地发现决策的不足，而不是去批判这个决策到底对不对**。
2. 营造一种积极面对错误的风气，不停的主张：“我们是要发现问题并解决，而不是发现问题并丢到某人身上”。
3. 设计相对合理与灵活的考核制度，这个可能一般不在项目经理的职责范围之内，所以就不细讲了。
4. 基于事实的描述。另外避免**“你应该”，“你必须”等词语。而尽量使用“我们应该”，“我们必须”**这样的称呼，在语境上营造大家是一个团队的氛围。

如何做原因分析

​ 做原因分析的过程基本上是以问题来推进，其实就是多问几个为什么。直到暴露出最关键的问题。那么什么时候是停止继续问为什么呢？我个人的经验是这个问题的回答已经设计到某个人的某个具体动作。这样，我们才可以针对某个具体问题进行改进。

​ 举个例子：

​ 场景一：

​ Q：版本为什么发布失败了？

​ A：因为我们的本地和现场的配置文件不一致。

​ 改进措施：下次我们一定要保证本地和现场的配置文件一致。

​ 如果我们这样去做原因分析的话，那么下一次大概率会再次出现这个问题。因为这个改进措施完全是一句口号，没有具体的措施，动作和责任人。在复盘会议之后就会成为一纸空文。

​ 场景二：

​ Q：版本为什么发布失败了？

​ A：因为我们的本地和现场的配置文件不一致。

​ Q：什么原因造成不一致？

​ A：测试人员发布没有比对，部署人员现场部署时也没有比对。

​ Q：怎么比对？技术上是否可以实现？流程上如何保证？

​ A：产品发布上增加比对节点，测试输出操作指导，配置文件版本好和改动范围作为节点输入。部署人员拿到操作指导后进行发布包和现场环境比对。配置文件可以采用beyond compare软件人工比对。后续可以考虑使用脚本自动比对发布。

​ Q：脚本工具是否谁负责开发，什么时候可以完成？

​ A：xxx在xx日前可以完成。

​ Q：流程节点如何保证宣贯到位？

​ A：xx负责在团队内部宣讲。xxxxx等步骤。

​ 如果按照这样来分析的话，最起码可以保证我们针对这次的问题做出了具体的分析，并制定了改进计划。

​ 具体来说，我们一般可以从下面几个维度上来分析原因：

• 客观因素，比如上面的例子，可能是因为时间，部署条件限制等原因无法比对。
• 主观因素，如测试和部署没有意识去比对，忘记去比对。这就要通过流程或者技术手段来保证。

​ 还可以另外一种分法：

• 技术因素，技术的失败的原因是什么。
• 管理因素，在管理流程上是否存在漏洞。

​ 还可以有其他的分法，只有针对一个现象按不同的维度进行了分析之后，才会得到详细的改进计划。

改进计划

​ 改进计划就两个重点：

1. 明确时间，责任人
2. 从会后开始按照改进计划执行，毕竟只有动起来才是有效的改进。