经验教训总结模板：项目经验教训怎么总结（附填写示例）

项目终于交付了。大家松了一口气，也累得够呛，人已经被分去做下一件事了。有人约了一场 1 小时的收尾会，团队聊了几段“踩坑经历”，记录员填了一份之后再没人打开的文档。半年后，下一个项目又在同一个地方栽了跟头。

一份好的经验教训模板，就是用来打破这个循环的。它不是那种开完会大家感觉不错、到周五就忘光的总结，而是一份结构化的记录：哪些做法有效，哪些无效，原因是什么。要写到让一个从没参加过会议的人也能看懂，并避开同样的坑。两者的差别，主要就在结构：一份好用的经验教训模板只需要 6 个字段，即发生了什么、结果好坏、根本原因、改进建议、负责人和类别。下面是我们实际在用的模板、一份可以直接复制的填写示例，以及让总结会说真话、而不是说客套话的主持技巧。

经验教训文档是什么

经验教训文档是指一个项目留下来、能长期保存的知识。美国项目管理协会（Project Management Institute，PMI）把它定义为：把知识记录下来，以便复用。关键就在“复用”这两个字。回顾会议改善的是你接下来两周的工作，经验教训记录则要比项目本身、比参与项目的人留存得更久。

总结经验教训有三个好时机，而大多数团队只用了第一个，还用得不好。项目收尾时：趁团队还没解散就开总结会，因为大家一旦投入新工作，细节很快就模糊了。重大里程碑或阶段关口：项目做到一半就总结，这样能在同一个项目里及时纠偏，而不只是给下一个项目提个醒。重大事件之后：几天之内就写下来，趁时间线还清楚，能如实还原。

PMI 自己的建议是：在收尾阶段召开总结研讨会，邀请各部门的代表参加，而不只是项目经理，并由一位中立的主持人来主持。最后这一点比听起来重要得多，后面还会讲到。

经验教训总结、回顾会议和复盘有什么区别

这三个词经常被混着用，团队也因此常常开错了会。它们有重叠，但各自的角度不同。

回顾会议（retrospective）是团队的例行会议。每个迭代都开，不管有没有出问题，关注的是团队内部：我们这个团队，下一个迭代怎样合作得更好？它是主动的，按固定节奏开。复盘（post-mortem）则是被动的，范围也窄。它在某次具体的失败之后才开，比如一次搞砸的上线或一次故障，通过还原时间线找出那个根本原因，让它不再发生。它是一次调查。

经验教训文档的范围比这两者都广。它覆盖整个项目，成功和失败同样重要，而且是写给没参加过会议的人看的。回顾会议改进团队，复盘剖析事件，经验教训则为下一个项目和组织的记忆提供养分。一个不顺利、还出过事故的迭代结束后，你完全可以三样都做，成熟的团队也确实这样做，但它们不是同一种产出，不该混成一份。

提示：会议叫什么，要名副其实。 如果你把它叫作“回顾会”，实际上却是想给明年的项目留一份记录，大家就会忙着吐槽，而不是认真记录。一开始就告诉所有人：“这份记录会放进项目档案，下一个团队会看。”就这一句话，能明显提高大家发言的质量。

经验教训模板的 6 个字段

网上流传的模板很多都有 10 到 12 栏，大部分根本用不上。实际用了一段时间后会发现，真正起作用的是 6 个字段，少了任何一个，这份文档就会悄悄失去价值。

1. 观察：发生了什么

对事件或规律的具体描述。“沟通不畅”毫无用处；“设计稿交付时没有验收标准，QA 只能靠猜来写测试用例”才是一条经验教训。

2. 结果：做得好还是不好

简单标记正面或负面。做得好的也要记下来，因为重复有效的做法占了一半的价值，而这恰恰是大多数团队忘了记录的部分。

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

写底层的系统原因，而不是表面症状。别停在第一个答案上。“我们延期了”不是原因；“估算时按全员到岗计算，而实际上有两个人还要轮值支持”才是。

4. 改进建议：下次怎么做

一项具体、可执行的改变。不是“加强沟通”，而是“每张工单进入迭代前，必须写好验收标准”。

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

写具体的人名，绝不能写团队。PMI 在这一点上说得很直白：每条建议都要有一位负责人，负责落实，或者在做不到时向上说明原因。“团队会解决的”意思就是没人会解决。

6. 类别：方便以后查找

按领域给每条经验打标签：范围、进度、成本、质量、风险、资源、干系人或沟通。有了类别，下一位项目经理就能在档案里直接搜“关于范围的所有经验”，而不用翻 40 份文档。

经验教训模板（可直接复制）

下面就是模板本身。把它放进文档、Wiki 或电子表格里，每条经验教训占一行。表头就是整个模板，空行留给你来填。

在表格上方加几行背景信息：项目名称、起止日期、参会人员和主持人。以后的读者需要知道这是谁的项目、大概在什么时候，才能判断当时的条件对自己还有多少参考价值。

经验教训总结示例

光看空模板总是不够直观，下面用同一份模板，填一个虚构的项目：客户门户重建，最终晚了两周交付，但范围没有缩水。注意，4 行里有 2 行是做得好的。一份全是抱怨的文档读起来就像追责记录，下次大家就不会再说实话了。

就 4 行。每一行都具体到可以直接行动，每一行都写了负责人的名字，每一行都打了标签，下一位项目经理一搜就能找到。这就是标准。20 行含糊的内容，不如 4 行一针见血的。

怎样开一场说真话、不追责的总结会

模板是最容易的部分。难的是在领导也在场的会议室里，让大家把真话说出来。下面几个做法很管用。

请一位中立的主持人，最好是跟项目表现好坏没有利害关系的人。负责这个项目的项目经理不适合主持对它的“审查”，因为他太在意结论了。每个问题都围绕流程而不是个人来谈。把根本原因写成“没有就绪定义的把关”，而不是“Priya 忘了写验收标准”，大家就会放松下来，问题也会诊断得更准。从做得好的地方谈起，而且要真心谈，不是当作吐槽前的热身，因为这能定下建设性的基调，也能把值得保留的做法找出来。

另外，在会议之前先收集几条观察，能匿名就匿名。会上最安静的那个人，往往掌握着最重要的经验，而坏消息在现场讨论中传得最慢。一份简单的会前问卷，就能收集到那些没人愿意第一个当众说出来的事。

提示：记录和主持要分开。 主持人没法一边引导好讨论，一边准确地做记录，总有一样会打折扣，通常是记录。要么安排一位专门的记录员，要么把会议录下来，让主持人能全身心投入，事后再核对措辞。

总结得好不好，取决于记录得好不好

有一种失败没人愿意承认：会开得很好，讨论也很坦诚，最后产出的文档却很单薄。有人边打字边听，只听进去一半；一条建议被转述得含含糊糊；有两项的负责人压根没写下来。讨论的内容是金子，留下来的记录却只有一张便利贴。

这正是 AI 会议记录工具的用武之地。Laxis 这类工具会录制并转写整场会议，在大家说出待办事项、决策和负责人的同时就自动提取出来。这样，模板里的“改进建议”和“负责人”两栏，填的是大家实际承诺的内容，而不是一个疲惫的记录员一小时后凭记忆拼凑的版本。它支持 Zoom、Google Meet 和 Microsoft Teams，支持 100 多种语言，这对分布式团队很重要；还有免费版，可以在下一次收尾会上试试。主持人专心主持，记录依然准确。

自动记下每一条改进建议和负责人

让 Laxis 录下你的经验教训总结会，自动提取待办事项、决策和负责人，你只管专心讨论。

免费试用 Laxis

总结

检验一份经验教训文档的，不是你有没有写，而是下一个项目开始前有没有人打开它。所以，要把这些改进建议当成待办列表（backlog），而不是档案：在项目启动会上，把上个项目还没落实的事项拿出来，在第一个迭代开始前分配下去。一条没人落实的经验教训，只是一种代价高昂的感慨。

常见问题

经验教训模板应该包括哪些内容？

一份实用的经验教训模板有 6 栏：发生了什么（观察）、结果好还是不好、背后的根本原因、具体的改进建议、具体到人名的负责人，以及类别，比如范围、进度、成本、质量、风险或沟通。正是负责人和类别这两栏，让一堆笔记变成了下一个团队真正能执行、能检索的资料。

什么时候开经验教训总结会？

有三个时间点：项目收尾时，趁团队还没解散、记忆还没模糊；重大里程碑或阶段结束时，以便在项目中途纠偏；重大事件发生后几天内，趁细节还清楚。PMI 建议在收尾阶段召开总结研讨会，并邀请各部门的代表参加，而不只是项目经理。

经验教训文档和回顾会议有什么区别？

回顾会议是以团队为中心的例行会议，每个迭代开一次，目的是改进团队之后的协作方式。经验教训文档则是一份长期保存、可以检索的记录，供以后的项目和从没参加过会议的人复用。回顾会议改进的是接下来两周，经验教训改进的是下一个项目。

经验教训文档和复盘有什么区别？

复盘（post-mortem）范围窄，只针对具体事件：深挖一次失败，还原时间线，找出根本原因，让它不再发生。经验教训文档的范围更广，记录的是整个项目的成功和失败，包括值得重复的做法，而不只是出了问题的地方。

怎样让经验教训总结会不追责、说真话？

请一位跟结果没有利害关系的中立主持人，每个问题都围绕流程而不是个人来谈，根本原因写成系统层面的状况，而不是人名。会前匿名收集几条观察，让不爱发言的人和坏消息都能浮出水面；会上先从做得好的地方谈起，定下建设性的基调。