编辑导语：在项目完结时，我们经常需要进行项目复盘。那么一个好的项目复盘是怎样的？作者以自己的工作项目为例，进行了一次复盘总结，供你学习参考。

最近所负责的项目顺利完结，如期上线，完成初期制定的项目目标。 回顾整个项目历程，发现问题和不足的同时，也不断成长。因此，趁正好时间充足，回顾及记录整个项目历程。

首先整体回顾总结一下项目复盘会，将结合实际场景和项目需求，从会议前期准备，会议进行中，项目经验总结三个维度进行描述。其中，项目经验总结是关于项目过程中遇到的问题以及对应的应对方案，希望可以供大家借鉴和讨论。

一、项目背景介绍

本次所负责的项目主要实现公司自建商城的中台化改造，在项目开展之前，前端业务的承载主要依托已经搭建的各个小后台系统，存在如下问题：

• 前端业务急速发展，快速变动，现系统无法快速响应变动需求
• 在各大类型活动中，因系统维护成本高，容易引发各类型风险
• 数据分散在各个系统，无法形成统一的标准，进而无法有效发挥数据的价值

因此，基于以上问题，在完成各核心功能的中台化搭建后，组织立项进行系统的整体迁移，通过中台化的方式，满足前后端的发展需求。整体项目具备如下特点：

• 项目范围大：应用端涉及安卓，IOS，Web，小程序；管理端涉及商品管理，营销管理，订单管理。
• 外部系统多：同步需对接包含财务，物调，内部支撑工具，大数据报表等外部系统。
• 影响范围大：涉及售后，售前，客户维护，财务，运营，运维等部门。
• 项目难度高：在同步兼容历史功能及数据的同时，还需响应当前业务需求。
• 项目周期长：项目时间跨度接近3个月。

二、会议前期准备

复盘时间点：项目上线一周后，上线遗留问题基本解决，系统稳定运行。

参会人员：项目成员，项目团队直接上级，适当邀请公司高层。

内容前期收集：共享文件形式，模板如下：

• 问题描述：以叙述的方式描述项目过程中，遇到的问题或收获，可以从项目各阶段里程碑划分，例如，上线部署时，测试验证时间比较长而且覆盖面不够全。
• 预期结果：基于问题或收获，抛开实际结果，理想化的分析目标期望达到的最完美结果。
• 实际结果：实事求是，记录基于问题描述，实际达到的结果。
• 原因分析：通过对比实际结果和预期结果的不足或超额完成点，分析导致两者差距的原因。
• 经验总结：从原因出发，剔除项目因素，总结可适用于后续项目的经验规律。

讨论点：关于模板是否需要添加【提出人】。

个人觉得需要根据团队的氛围围综合评估，以个人经验来说，添加【提出人】有如下的优缺点。

• 优点：可直接定位到提出人，会议期间，在冷场的情况下，可直接cue到对应的提出者。
• 缺点：团队成员可能担心中伤到其他成员，或害怕会议上被cue到，导致不会按照实际情况如实填写。

我的方案：在模板上先不添加【提出人】字段，会议期间同步添加【分析人】字段，主要考虑一般复盘会议，会尽量邀请各团队成员的直属或隔级上级，需要给团队成员一个展示的机会，特别是在隔级上级的面前（作为产品/项目人员，有义务让与我们一起奋斗的小伙伴得到成长和展示）。

小tips：如项目允许，尽量邀请各端对应的上级领导同步参加，一来可以给项目成员一次露脸的机会，二来可以有效提升项目成员的参与积极性。

三、会议进行中

整体流程：团队成员可以一起按照问题收集表核对，分析，总结，需注意的点如下：

• 问题收集表提前发出，会议前期敦促相关成员积极填写
• 作为主持人，需熟悉登记的问题，排查重复项
• 前期需初步熟悉问题/收获所指向的团队或成员，在会议冷场时，可直接引导对应的人进行回答
• 收集表中，问题描述，预期结果，实际结果要求前期必填，原因分析和经验总结可依据实际情况填写，会议期间重点关注原因分析和经验总结
• 把控整体会议节奏，防止讨论蔓延
• 前置安排人协助，包含协助投影，协助记录，主持人重点关注整个会议流程及问题分析
• 把发言权交项目成员。

1. 复盘会议基本原则

• 对事不对人，基于事情讨论不针对到对应的人。
• 要求团队成员，在整体会议期间，不允许出现项目成员人员，最多能接受出现对应工作端，例如前端，移动端，后台，产品。
• 每个端，每个人都要求发言（需结合团队具体情况）。

小提示：虽然明确说明可以添加收获和亮点，但一般开发成员不会添加，此时，作为产品/项目负责人，可以适当的添加上，可指向具体的团队，也可指向具体的开发成员，作为对项目工作的肯定，提高对应成员的积极性。

2. 项目经验总结

本文由 @老鬼 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议