指南 › 指南

经验教训模板

大多数经验教训文档只写一次，精心归档，再也没人打开。这份模板的目的，是让下一个项目里真的有些东西发生改变。

为什么大多数教训从未被吸取

只有当有人做了不一样的事，一条教训才算被吸取。一段“沟通本可以更好”的话改变不了任何事，因为没人负责，也没人能判断是否奏效。

所以下面的模板要求每条教训都有证据、原因和有人负责的行动。回答不了这些，那只是抱怨，不是教训。

模板：可复制的列

用一张简单的表，每条教训一行。措辞保持事实性，不追究个人。

• 编号及项目阶段（启动、规划、交付、收尾）。
• 类别：范围、进度、成本、人员、供应商、治理、技术或沟通。
• 发生了什么，用一两句事实性的话。
• 影响：损失的天数、增加的成本或受影响的效益（如果知道的话）。
• 根本原因：原因背后的原因，而不是表面症状。
• 建议、行动负责人，以及适用的团队或流程。

如何开好这场会

趁记忆还新鲜时召开，最好在上线后几周内，邀请实际干活的人，也邀请发起人。条件允许的话，请交付团队之外的人来主持，因为项目经理对自己的项目很少是中立的。

用三个问题展开，每个问题先静默书写十分钟再讨论，免得嗓门最大的人定下议程。

• 哪些做得好，值得重复？
• 哪些没做好，根本原因是什么？
• 我们会怎么做得不同，谁来推动落实？
• 针对最大的两三个问题，连问五次“为什么”。
• 事先约定一条规矩：我们讨论流程和决策，不讨论人。

把教训变成改变

把成果分成可以行动的教训和仅仅有趣的教训。可行动的要有负责人和日期，并放到人们还会再看到的地方，例如 PMO 手册、项目启动清单，或下一个项目的风险登记册模板。

• 把反复出现的问题加入新项目的标准风险清单。
• 当周就更新模板和清单，不要“以后再说”。
• 把最重要的五条教训发给 PMO，并点名发给下一位项目经理。
• 每个新项目启动会开始时回顾这份记录。

边做边记录教训

最好的教训记录从项目启动的那一周就开始。每次出问题就补一行，比结束时靠英雄式的回忆强得多。在 Senshin 中，您可以把它与 RAID 日志放在一起，等复盘时，已关闭的问题和决策早已在那里等着了。

它在 Senshin 中的位置

常见问题

更多指南

最后更新: 2026-10-22