变革项目管理的项目复盘经验萃取方法

聊变革项目的复盘这个话题，我得先说几句心里话。我在项目管理这个行当摸爬滚打这么多年，见过太多企业搞变革，有的折腾半天最后悄无声息地没了下文，有的倒是硬着头皮做完了，但过程中踩过的坑、积累的经验，全都烂在参与者的肚子里，下次遇到类似问题还得从头再来。这种情况看多了，我就一直在想：那些真正从变革项目里杀出来的团队，他们到底做对了什么？

后来我发现，答案可能没那么复杂——就在于他们会不会做复盘，更准确地说，在于他们会不会从复盘里真正萃取出有价值的东西来。这篇文章，我想用一种比较实在的方式，跟大家聊聊变革项目管理中的经验萃取到底该怎么做。之所以强调变革项目，是因为它跟普通项目真的很不一样，里面的门道值得单独拎出来说。

一、变革项目复盘为什么总爱"走过场"

先说个现象，不知道大家有没有共鸣。很多公司的项目复盘，开场倒是挺正式，PPT做得漂漂亮亮，时间地点参与人列得一清二楚，签到表也没少发。但开着开着，味道就变了——要么变成了一场大型甩锅现场，大家小心翼翼地绕开责任问题，专挑好听的说；要么成了领导一个人的独角戏，其他人负责点头和鼓掌；要么干脆变成了诉苦大会，诉完苦该干嘛干嘛，下个项目照样踩同样的坑。

我曾经跟一个制造业的朋友聊过，他们公司前年搞过一个流程再造项目，折腾了七八个月，投入了不少资源。按理说这种项目复盘应该有很多东西可聊，结果复盘会上大家你看看我我看看你，最后就总结出三句话：领导支持力度不够、跨部门协调太难、供应商配合不到位。然后呢？没有然后了。下次遇到类似项目，这三条"经验"又被原封不动地搬出来用了一遍。

问题出在哪？我觉得根本原因在于，很多人把复盘理解成了"总结"，以为复盘的目的就是给项目画上个句号，大家坐下来意思意思，流程走完就完事了。但实际上，复盘真正的价值在于萃取经验，而经验萃取是个技术活。它需要有方法、有工具、有适合的语境，更重要的是，参与的人得愿意说真话、敢暴露问题。

二、变革项目的复盘有什么不同

在说方法之前，我觉得有必要先把变革项目的特殊性讲清楚。因为如果你不理解变革项目跟普通项目的区别，用普通的方法去做复盘，效果肯定好不到哪去。

变革项目最突出的特点，就是它不是单纯地"做事"，而是要改变人。你想啊，不管是组织架构调整、业务流程重构，还是管理系统升级，归根结底都要落实到具体的人身上——得有人改变自己的工作方式，有人放弃既得利益，有人接受新的考核标准。这个过程中，涉及到的利益关系、情感冲突、心理阻力，比单纯做个信息系统上线要复杂得多。

我见过一个很典型的例子。有家服务型企业想推行客户关系管理系统的规范化，按理说这是个技术项目，但因为涉及到销售团队要改变多年来的"自由发挥"习惯，结果引发了一场不大不小的抵触。销售们表面上配合，私下里还是用自己那套老办法，项目推进了三个月，几乎没什么实质进展。后来项目组意识到问题所在，专门花了力气做变革管理方面的沟通和辅导，才慢慢把局面扭转过来。

所以你看，变革项目的复盘，你不能只盯着"事"来复，还要盯着"人"来复，盯着"关系"来复。哪些沟通方式起到了作用？哪些阻力是之前没预料到的？不同利益相关方的诉求有没有被妥善照顾到？这些维度，在普通项目的复盘里可能不是重点，但在变革项目里，恰恰是最关键的部分。

另一个特点是不确定性高。变革项目往往没有多少先例可循，情况在不断变化，计划赶不上变化是常态。这就更要求团队具备快速学习和调整的能力，而复盘就是这种能力的重要来源。如果每次变化之后团队不能及时总结经验教训，那下一次变化来临时还是会手忙脚乱。

三、经验萃取到底"萃"的是什么

很多人把经验萃取想得太玄乎，其实说白了，它就是把埋在项目过程里的"宝贝"挖出来的过程。那这些"宝贝"具体长什么样呢？

我个人的经验是，有效的经验萃取至少要覆盖这几个层面：

• 方法论层面的经验：这个项目用了哪些方法？哪些方法被证明是有效的？哪些方法在特定情境下不适用？比如前面提到的变革项目，如果发现"先试点后推广"的策略在降低变革阻力方面效果不错，那就应该把这个方法总结出来，下次遇到类似情况可以直接复用。
• 流程层面的经验：项目执行过程中，哪些环节的流程是需要优化的？有没有哪个环节因为流程不清晰而导致返工或者延误？这类经验对于提升未来项目的执行效率特别有价值。
• 人际层面的经验：团队协作、跨部门沟通、与外部供应商的合作等方面，有哪些经验教训？变革项目中尤其要关注利益相关方管理的经验，因为这方面出问题往往会导致项目全盘皆输。
• 认知层面的经验：通过这个项目，团队对业务、对组织、对用户有了哪些新的认识？这些认知层面的提升，虽然不如方法和流程那么具象，但往往是最有长远价值的。

举个例子。薄云在服务客户的过程中发现，很多企业的变革项目之所以失败，倒不是因为方向不对或者资源不够，而是低估了变革推进中的沟通成本。有的项目组花了大量时间在做方案、搭系统，却忽视了跟关键利益相关方的充分沟通，结果方案做得再完美，没有人愿意用，最后只能推倒重来。这个经验教训，就是典型的认知层面经验——它改变的是团队对"什么是变革项目重点"这件事的判断。

四、复盘会议前的准备工作

准备工作做得好不好，直接决定复盘会议的质量。这话一点不夸张。我见过很多复盘会开得稀里糊涂，其实问题不是出在会议本身，而是出在会前根本没做该做的事。

第一件事：把数据资料收集齐

复盘不是凭印象说话，而是要靠数据说话。但这数据不是说最后的结果报表就够了你得把项目过程中产生的各种资料都收集起来：变更记录、问题清单、会议纪要、往来邮件、阶段性的评估报告等等。这些资料是复盘讨论的素材，没有它们，复盘很容易变成各执一词的扯皮会。

第二件事：分层次邀请参与人

变革项目的复盘，参与人的选择很有讲究。核心团队成员肯定要在，但仅仅有他们还不够。你需要邀请不同层级、不同角色的人参与：高层决策者可以帮你理解战略意图，中层执行者可以补充很多一线细节，基层实施者可以反映最真实的使用体验。如果只叫核心团队复盘，很容易陷入"自己人互相认同"的盲区。

第三件事：做好心理铺垫

这点可能是最容易被忽视的。很多人一提到复盘就紧张，担心被追责，担心说错话，这种心理状态下，复盘很难开诚布公。所以会前需要做一些铺垫，比如明确复盘的目的是"为了把以后的事情做得更好"，而不是"这次谁没做好要追究责任"。管理层带头营造安全的讨论氛围，这点非常重要。

五、经验萃取的实操方法

准备工作做完，接下来进入正题——复盘会议到底怎么开？我给大家介绍一个我用过觉得比较好用的框架，我叫它"四步萃取法"。

第一步：还原目标与结果

这一pa看起来简单，但很多人做得不到位。什么叫还原目标？就是把项目最初设定的目标原原本本地摆出来，包括那些写在纸面上的目标，也包括当时没说出口但大家默认的期望。然后，再把最终的结果摆出来。注意，这一步只需要客观描述，不需要评价对错。

为什么要这么做？因为只有在目标和结果的对比中，我们才能发现问题。很多时候，团队对项目成败的判断不一致，其实是因为大家各自心里的"目标"本来就不一样。先把目标谈清楚，后面的讨论才有共同的出发点。

第二步：差距归因

目标有了，结果有了，接下来要问一个问题：哪些地方达到预期了？哪些地方没达到？对于没达到的地方，原因是什么？

归因这个环节，特别考验功力。我常用的方法是分层追问。比如，跨部门协调不顺畅，这是一个现象，那追问一层：为什么跨部门协调不顺畅？是因为职责不清吗？还是因为沟通机制有问题？再追问一层：职责不清的背后，是不是因为项目启动时没有把各方的责任边界划清楚？如果是这样，那根因就找到了。