一个完整的项目复盘到底要怎么做？

笔者阐述了完整的项目复盘流程，以及其中涉及的问题，对于项目复盘具有指导性意义。

 

 

复盘，是运营必不可少的能力，小到一次买菜的经历，大到百亿千亿的投资项目，都可以通过复盘来总结规律、提升水平。

 

简单说来，复盘可以达到的效果有两条：

 

优化弱项，强化强项

 

明确自己的价值，明确工作的价值

 

那么，复盘到底该怎么做呢？或者说，做好复盘有比较高效、实用的方法吗？有的。

 

以下内容来源于我工作中的思考，同时参考了柳传志的关于复盘的方法论，力图展现一个完整的、可实践的项目复盘流程。

 

一、复盘的底层逻辑

复盘首先是要做的是事实陈述，一个有效的AAR(After Action Review)必须建立在“铁的事实”的基础上，如果现实难以陈述清楚，并取得一致，将导致复盘进展缓慢或无法深入下去。

 

一旦事实确定下来了，就开始诊断、分析存在差异的原因，找出导致成功或失败的根本原因后进行规律总结。明白为什么会成功、哪些关键行为起了作用、这些行为有没有适用条件，对于提高后续行动的成功率有没有价值。

 

因此，一个完整的复盘就出现了，包括如下四个步骤：目标回顾、结果陈述、过程分析、规律总结。

 

1. 目标回顾

当初行动的意图或目的是什么？

 

事件/行动想要达到的目标是什么？

 

我们计划怎么做？

 

预先制订的计划是什么？

 

事先设想要发生的事情是什么？

 

2. 结果陈述

实际上发生了什么事？

 

在什么情况下？是怎么发生的？

 

与目标相比，哪些地方做得好？哪些未达预期？

 

3. 过程分析

实际状况与预期有无差异？

 

如果有，为什么会发生这些差异？是哪些因素造成了我们没有达到预期目标？

 

失败的根本原因是什么？

 

如果没有失败，成功的关键因素是什么？

 

4. 规律总结

从过程中学到了什么新东西？

 

如果有人要进行同样的行动，我会给他什么建议？

 

接下来我们该做些什么？

 

哪些是我们可直接行动的？

 

二、项目复盘的阶段流程

一个项目，基本都会包含几个核心阶段：目标、需求、设计、开发、测试、上线，把每个阶段中的具体工作进行分解，才能分析出每一项工作的进展是否顺利，问题点在哪、以及如何更好的优化。

 

这里分享一个项目复盘的小技巧：按照项目执行的时间线记工作日记。

 

不一定要每天都写，但一定要在各个重要的时间节点留下工作记录，这样才会对整个活动过程了如指掌。复盘的时候，只需要重新去翻这部分日记，列出一个实际工作的时间表，对比策划书中的计划时间表，哪部分工作提前，哪部分工作延后，哪部分工作是临时加进去，完成度怎么样。

 

比如第一步是项目目标回顾，优质的项目往往都伴随着明确的预设目标，目标本身要是不合理的话，复盘得出的结论也很难有说服力。所以在复盘的时也有从目标设定合理性开始复盘，当初是基于怎样的条件设定的目标。

 

如果项目整体目标较大，建议进行目标分解，确定项目实施里程碑，形成子目标或阶段性目标，便于目标的衡量与跟进。以电商类活动策划为例为例，影响交易额的子目标包含：流量、转化率、客单价、复购率。

 

后续步骤也是这样，通过不断分解，对整个项目流程做出完整的、可量化的梳理，从而对项目指标的实际情况和预期对比做到了解。

 

三、如何做产品项目复盘？

复盘最重要的两个环节：过往演绎和复盘优化，明确产生偏差的原因，并提出针对性意见。

 

1. 项目目标复盘

1.1 项目进度复盘

 

是否按照原计划交付时间交付？

 

原计划的需求点实现了多少？哪些需求点没有按计划实现？

 

每一个需求点延后原因分别是什么？

 

哪些里程碑有延迟，延迟原因是什么？

 

1.2 项目结果复盘

 

项目中出现了哪些意外？为什么会出现这些意外？

 

用户对新增功能点的接受程度和项目规划中的是否一致？

 

2. 需求阶段复盘

是否提供完整的需求输出?包括：原型、MRD、PRD、UML等

 

设计师、交互师、开发人员分别对需求是否明确？如果出现需求不明确的情况，将会严重影响项目的进度和质量。

 

是否对典型用户和使用场景有清晰的描述？

 

3. 设计阶段复盘

是否确定视觉设计的最终审核人？

 

UI设计产出是否符合统一标准？

 

设计工作是否影响开发工作的进度？影响原因是什么？

 

产品设计工作在什么时候，由谁来完成的？

 

4. 开发阶段复盘

4.1 工期评估复盘

 

开发实施前，是否有充分的时间做工期预估？工期评估一方面是让项目成员能够对项目的整体进度有所准备，也是对项目需求进行详细梳理的过程。

 

工期预估与实际开发时间是否有差异，及差异原因分析。

 

4.2 开发文档复盘

 

是否有撰写开发文档？

 

开发文档是否符合规范?

 

4.3 突发状况复盘

 

是否出现需求无法实现的状况？原因是什么？

 

是否出现团队成员变动情况？如何应对成员变动？后期如何避免？

 

是否出现功能模块与需求不符的情况？出现原因是什么？

 

5. 测试阶段复盘

5.1 测试计划复盘

 

是否有完整、准确的测试用例？

 

是否有一个测试计划？这样的计划是否有效？

 

团队是如何测试并跟踪产品开发效果的？

 

5.2 测试工具复盘

 

使用了哪些测试工具来帮助测试？是否可以持续使用？

 

测试的时间、人力和软件/硬件资源是否足够?

 

5.3 测试结果复盘

 

哪个功能模块产生的Bug最多，为什么？

 

哪些BUG出现回滚，原因是什么（回滚：即程序版本回退。出现较大bug，程序从1.1回退到1.0，迭代之后全是bug，修复成本高）？

 

6. 上线阶段复盘

6.1 验收复盘

 

是否进行了正式的上线验收？

 

在正式发布的过程中是否有出现状况？后续如何避免？

 

上线前是否和运营、文案进行充分的沟通？

 

是否检查了数据埋点，数据埋点是否满足运营要求？

 

6.2 上线后效果复盘

 

在上线之后是否出现重大bug? 为什么测试阶段没有发现？

 

产品上线后的问题反馈渠道是否流程？

 

产品上线后收集到哪些问题反馈？都是什么类型？如何改进？

 

每次的项目复盘，都是对自己的一次拷问和锤炼，迭代型产品每逢3个版本进行一次复盘。一般情况下，发版的节奏是一个月一个版本，因此可以按照3个月的节奏进行复盘。

 

在复盘结束后，最短时间开复盘会议，这样很多活动执行细节和用户反馈都历历在目，做复盘的可靠性比较高。

 

彼此坦诚剖析，既不推卸责任，也不妄自菲薄，而是尽可能地呈现一个完整真实的项目流程。每个参与者都有平等的发言权，都能真实地表达想法。

 

要有专人控制时间和记录要点，开会最忌讳的就是不着边际地开得又臭又长，控制每个部分的时间很重要，另外记录要点也是一种会议成果的输出，有利于总结经验并开展下一步行动。