经验教训模板：让项目洞察真正留存下来

项目交付了。每个人都松了一口气，有点筋疲力尽，又已经被半推半就地分到了下一件事上。有人安排了一个一小时的收尾会，团队聊了几个"战场故事"，记录员填好一份再没人打开的文档，半年后下一个项目又在同一个坑上栽了跟头。

正是这种循环，才需要一份好的经验教训模板来打破。它不是那种到周五就烟消云散的自我感觉良好的复盘，而是一份关于哪些有效、哪些无效以及原因的结构化记录，写得让一个从未在场的人也能读懂、理解，并避开同一个坑洼。两者的区别，主要就在于结构。下面就是我实际使用的模板、一个你可以直接复制的填写示例，以及那些能让会议保持诚实而非客套的引导技巧。

经验教训文档究竟是什么

经验教训文档是一个项目留下的可持续知识。项目管理协会（Project Management Institute）将其定义为捕捉知识以便复用，而复用这个词，正是全部意义所在。复盘改善的是你接下来的两周；而经验教训记录的使命，是要比项目本身、比项目中的人活得更久。

捕捉经验教训有三个好时机，而大多数团队只是把第一个用得很糟。在项目收尾时，趁团队尚未解散就开会，因为一旦大家投入新工作，细节很快就会模糊。在重大里程碑或阶段关口，在项目进行途中捕捉经验教训，这样你就能在同一个项目上真正纠偏，而不只是给下一个项目提个醒。而在重大事件之后，要在几天之内写下来，趁时间线还足够清晰，能诚实地复原出来。

PMI 自己的指导意见是：在收尾阶段召开研讨会，并邀请跨职能的代表，而不只是项目经理，由一位中立的引导者来主持会场。这最后一点比听上去更重要，我们稍后会再讲到。

它与复盘和事后回顾有何不同

这三者经常被混用，而团队往往就是因此用错了方法。它们有重叠，但每一个的切入角度各不相同。

复盘是一种周期性的团队仪式。它在每个迭代都会发生，无论是否出了岔子，并且着眼于内部：我们这个团队，如何在下一次迭代中更好地协作？它是主动的、由节奏驱动的。事后回顾则是被动且狭窄的。你在某次具体失败之后才进行——一次搞砸的发布或一次故障——并构建一条时间线，去找出那个唯一的根本原因，好让它永不复发。它是一次调查。

经验教训文档比这两者覆盖得更广。它涵盖整个项目，胜利与失败同等重要，并且是写给那些不在场的读者看的。复盘改善团队，事后回顾剖析事件，经验教训则滋养下一个项目和组织的记忆。在一个既糟糕又夹带事件的迭代之后，你完全可以三者都做，成熟的团队也确实如此，但它们不是同一份产物，不应被混为一谈。

小贴士：诚实地为会议命名。 如果你把它叫作"复盘"，实际上却是想为明年的项目留下一份记录，人们就会为发牢骚而优化，而不是为记录文档而优化。一开始就告诉在场的人："这会进入项目档案，下一个团队会读它。"就这一句话，能改变人们贡献内容的质量。

让经验教训模板奏效的六个字段

到处流传着带十个甚至十二个栏目的模板，大多数都用不上。在用了一段时间之后，真正承担重量的是六个字段，缺了任何一个，都会悄悄地葬送这份文档的价值。

1. 观察——发生了什么

对事件或模式的具体、明确的描述。"沟通很糟"毫无用处；"设计交接没有附带验收标准，于是 QA 凭猜测来编写测试用例"才是一条经验。

2. 结果——做得好还是没做好

一个简单的正面/负面标记。你也需要把胜利记录下来，因为重复有效的做法贡献了一半的价值，而这恰恰是大多数团队忘记捕捉的部分。

3. 根本原因——为什么会发生

是底层的系统性状况，而非表面症状。要往第一个答案之外深挖。"我们晚了"不是原因；"估算时假设了满员配置，而当时有两个人还在轮值支持"才是。

4. 建议——下次该怎么做

一项具体、可执行的改变。不是"沟通得更好"，而是"要求每张工单在进入迭代之前都附带验收标准"。

5. 负责人——谁来推动落实

一个具名的人，绝不能是一个团队。PMI 对此直言不讳：每条建议都需要一位负责人来负责实施，或上报说明为什么无法做到。"团队会修复这个"意味着没人会去做。

6. 类别——以便日后可被检索

按领域为每条经验打标签：范围、进度、成本、质量、风险、资源、干系人或沟通。正是这些类别，让下一位项目经理能在档案里搜索"我们关于范围学到的一切"，而不必去读四十份文档。

可复制粘贴的经验教训模板

这就是模板本身。把它放进一份文档、一个 wiki 或一张电子表格，每条经验加一行。表头那一行就是整个模板；空行留给你来填。

在表格上方加一个简短的表头区块以提供背景：项目名称、日期、在场人员和引导者。未来的读者需要知道这是谁的项目、大致在什么时候，这样他们才能判断当时的条件在多大程度上仍适用于自己。

一个填写好的示例

抽象的模板总让人抓不住要领，所以这里把同一个模板填进了一个虚构的项目——一次客户门户的重建，它延期两周交付，但守住了范围。注意，四行里有两行是胜利。一份全是抱怨的文档读起来像一本追责记录，于是人们在下一份里就不再诚实了。

四行。每一行都具体到足以付诸行动，每一行都点名了一个人，每一行都打了标签，好让下一位项目经理能找到它。这就是标准。二十行含糊的内容，不如四行犀利的内容值钱。

召开一场诚实、不追责的会议

模板是简单的部分。难的部分，是在一个有经理在场的房间里，让人们把真话说出来。有几条做法能扭转局面。

使用一位中立的引导者，最好是对项目看起来如何毫无利害关系的人。运行项目的那位项目经理，不该来主持它的"庭审"；他们对结论太投入了。把每个问题都围绕流程，而非个人来表述。当你把根本原因写成"当时不存在'就绪定义'关卡"，而不是"Priya 忘了验收标准"时，人们就会放松下来，诊断也会更加犀利。从做得好的地方开始，要真心实意，而不是把它当作通往抱怨环节的热身，因为它能奠定建设性的基调，并浮现出那些值得保留的做法。

并且在会议之前收集几条观察，如果可以的话匿名收集。房间里最安静的那个人，往往掌握着最重要的那条经验，而坏消息在现场群体中传得最慢。一份简单的会前阅读表，能帮你拿到那些没人愿意第一个当众说出口的东西。

小贴士：把记录与引导分开。 引导者无法同时既带动一场好的对话，又记下准确的笔记；两者中总有一个会受损，而通常受损的是笔记。要么指派一位专职的记录员，要么录下整场会议，好让引导者能全身心在场，事后再核实措辞。

洞察的好坏，只取决于记录的好坏

这里有一个没人愿意承认的失败模式：会议很棒，讨论很诚实，可从中产出的文档却很单薄。有人一边打字一边只听了一半，一条建议被转述成了一团浆糊，有两个负责人压根没被写下来。对话本是金子，记录却成了一张便利贴。

这正是 AI 记录工具发挥价值的地方。像 Laxis 这样的工具，会对会议进行录音和转写，并在动作项、决策和负责人被说出口的当下就自动抽取出来，于是你模板里的"建议"和"负责人"两栏，就由人们实际承诺的内容填写，而不是一个小时后由疲惫的记录员重构出来的版本。它能在 Zoom、Meet 和 Teams 上使用，并支持 40 多种语言，这对分布式团队很重要，而且还有免费方案，可以在你下一次收尾会上试用。引导者保持在场，记录保持准确。

自动捕捉每一条建议和负责人

让 Laxis 录下你的经验教训会议，并在你专注于对话时抽取出动作项、决策和负责人。

免费试用 Laxis

结论

经验教训文档真正的考验，不在于你是否写了它，而在于是否有人会在下一个项目开始之前打开它。所以，把那些建议当作待办事项清单，而不是档案：在启动会上把上一个项目的未决项拉进来，并在第一个迭代之前就分配好。一条没人去落实的经验，不过是一种昂贵的感受罢了。

常见问题

一份经验教训模板应该包含什么？

一份实用的经验教训模板有六栏：发生了什么（观察）、做得好还是不好、背后的根本原因、一条具体的建议、一位具名的负责人，以及一个类别，比如范围、进度、成本、质量、风险或沟通。正是负责人和类别这两个字段，把一份笔记清单变成了下一个团队真正能付诸行动并可检索的东西。

什么时候应该召开经验教训会议？

在项目收尾时召开一次，趁团队还未解散、记忆还未褪色；在重大里程碑或阶段结束时召开，好让你能在途中纠偏；并在重大事件发生后的几天之内召开，趁细节还新鲜。PMI 建议在收尾阶段召开研讨会，并邀请跨职能代表，而不只是项目经理。

经验教训文档与复盘有何不同？

复盘是一种周期性的、以团队为中心的仪式，每个迭代都进行，以改善团队今后如何协作。经验教训文档则是一份可持续、可检索的记录，旨在供未来的项目和那些从未在场的人复用。复盘改善接下来的两周；经验教训改善下一个项目。

经验教训文档与事后回顾有何不同？

事后回顾狭窄且针对具体事件。它深挖一次失败，构建一条时间线，找出根本原因，好让它永不再发生。经验教训文档则更宽泛。它捕捉整个项目中的胜利与失败，包括那些值得重复的做法，而不只是那些出了问题的事情。

怎样让一场经验教训会议保持不追责且诚实？

使用一位对结果毫无利害关系的中立引导者，把每个问题都围绕流程而非个人来表述，并把根本原因写成系统性状况而非人名。在会议之前匿名收集几条观察，好让较安静的声音和坏消息浮现出来，并从做得好的地方开始，以奠定建设性的基调。