项目管理中的经验教训：指南与示例

项目管理中的经验教训是什么？

经验教训 是在项目中获得的、经过记录的知识，涉及哪些进展顺利、哪些进展不顺、原因是什么，以及未来应该采取哪些不同做法。一条好的经验教训应足够具体，让没有参与该项目的人也能据此采取行动，并以明确的建议作结。

经验教训可以是正面的，也可以是负面的，两者都很重要：

• 正面经验教训 记录值得重复的做法，例如及早发现缺陷的供应商审查流程。
• 负面经验教训 记录问题及其根本原因，以及如何预防。
• 建议 将每条经验教训转化为针对当前项目、未来项目或组织方法的行动。

有一个重要的区别：经验教训被 识别 与经验教训被 吸取。在电子表格中写下“测试开始得太晚”只是识别了一条经验教训。只有当后续项目因此以不同方式规划测试时，它才算被吸取。本指南所描述的大部分工作，都是为了弥合这一差距。

为什么经验教训很重要

• 更准确的估算： 过去项目的实际工期和成本可以改进未来的 成本估算 和进度安排。
• 减少重复出现的问题： 已知风险可以直接纳入下一个项目的 风险登记册.
• 可复制的成功： 良好实践得以推广到发现它们的团队之外。
• 更快的入职上手： 新项目经理可以借鉴组织的历史经验，而不必从零开始。
• 改进的方法： a PMO 可以根据实际依据更新模板、检查清单和标准。
• 更强的团队文化： 一次组织良好的复盘表明提出问题是受欢迎的，从而使今后的汇报更加坦诚。

经验教训还为以下方面提供支持： 项目治理：决策日志及从中总结出的经验教训，为发起人和委员会批准类似项目提供了依据。

经验教训登记册、知识库、日志和报告

不同方法对这些文档的命名各不相同。下表展示了它们之间的对应关系。

在 PMBOK 指南 第六版中，经验教训在整个项目期间记录在登记册中，并在阶段或项目收尾时转入知识库。 PRINCE2 将“从经验中学习”作为其七项原则之一，这意味着在项目开始时就要查找经验教训，同时记录新的经验教训。无论使用哪种术语，模式都是相同的：在项目期间收集，在结束时分享，在下一个项目开始时复用。

经验教训流程

1. 识别： 在评审会、状态会议和回顾会中，以及每个阶段结束时，随时发现经验教训。
2. 记录： 趁细节尚且清晰，将每条经验教训连同其背景、影响和证据记录在登记册中。
3. 分析： 找出根本原因，而不只是表面症状。 鱼骨图 或 5 Why 分析法会有所帮助。
4. 建议： 写出具体的行动并指定负责人，并确定它适用于当前项目、未来项目还是组织的标准。
5. 分享与存储： 将经过验证的经验教训按统一的类别和标签转入组织的知识库，以便检索。
6. 应用与检查： 启动新项目时审阅相关的经验教训，并在之后检查各项建议是否真正得到落实。

步骤 1 到 4 由项目团队负责。步骤 5 和 6 通常需要 PMO 或项目之外的其他负责人承担，因为届时项目团队已经转向其他工作。

何时收集经验教训

如何召开经验教训会议

1. 准备证据： 收集计划和基准、 状态报告、 问题日志、RAID 日志和变更日志。
2. 提前收集意见： 发送一份简短的调查问卷或共享文档，让较为内向的人以及无法参会的人也能贡献意见。
3. 邀请合适的人员： 核心团队、关键相关方、相关的供应商，最好还有发起人。将范围控制在能够坦诚交流的群体内。
4. 选择引导者： 如果项目困难重重或存在争议，请选择一位中立人士，而不是项目经理。
5. 制定基本规则： 聚焦于流程和决策，而不是个人；假定每个人都在当时所知道的情况下尽了最大努力。
6. 回顾时间线： 按顺序回顾主要事件、决策和转折点。
7. 讨论哪些进展顺利、哪些需要改进， 然后将相似的要点归纳为主题。
8. 找出根本原因 （针对排名前几位的主题），而不是试图分析所有内容。
9. 商定建议 ，并为每项指定负责人和目标日期。
10. 记录并分享 将结果记入登记册，并在几天内向与会者和 PMO 发送简短的总结。

90 分钟议程示例

使用我们的 会议议程模板 ，提前发送议程。

引导形式

• 行动后复盘（After Action Review）： 一种源自美国陆军的简短结构化复盘。提出以下问题：原本应该发生什么？实际发生了什么？为什么存在差异？下次应该怎么做？
• 开始、停止、继续： 开展起来很快，适合产生行动项。
• 进展顺利 / 有待改进 / 想法： 一块简单的三栏看板，线下或线上都适用。
• 带高低点的时间线： 团队将事件标在时间线上并标注当时的感受，从而揭示人们原本可能不会提出的问题。
• 回顾会游戏： 帆船或 4L 等形式也适用于项目复盘；参见 冲刺回顾会游戏.

经验教训应提出的问题

选择适合您项目的问题，而不必逐一过完所有问题。

规划与范围

• 目标和成功标准从一开始就清晰吗？
• 需求在工作开始前是否完整且已达成一致？
• 我们对范围变更的控制效果如何？

进度、成本和估算

• 哪些估算与实际偏差最大，原因是什么？
• 延误从哪里开始？在我们的报告中是否很早就能看出来？
• 应急储备的规模是否合适？是否用在了该用的地方？

风险和问题

• 哪些问题我们事先已经识别为风险？
• 哪些问题让我们措手不及？我们本可以预见到吗？
• 上报是否足够迅速地送达了合适的人？

团队、相关方和沟通

• 人们是否具备所需的技能、时间和权限？
• 相关方是否在正确的时间获得了正确的信息？
• 决策是否迅速做出并被记录？

供应商、质量和收尾

• 供应商的表现如何？是什么使合作关系顺利或不顺利？
• 质量检查是否足够早地发现了缺陷？
• 向运营部门的交接是否顺利？我们会做哪些改变？
• 如果明天重新开始这个项目，我们会采取哪些不同的做法？

如何写好一条经验教训

一条有用的经验教训遵循一个简单的模式： 发生了什么、影响、根本原因，以及一条指定了负责人的具体建议。 避免含糊其辞和追究责任。

经验教训登记册模板

登记册可以是一张电子表格、项目工具中的一个列表，或者共享 Wiki 中的一个页面。以下各列适用于大多数项目：

我们的免费 经验教训模板 已备好这些列，可直接在 Google Sheets、Excel 或 PDF 中使用，并为影响和状态提供下拉菜单。如需深入分析单个问题，请使用 根本原因分析模板.

经验教训示例

以下条目来自一个虚构的为期八个月的 CRM 实施项目和一次虚构的办公室搬迁。它们展示了应达到的详细程度。

经验教训报告大纲

在阶段或项目结束时，将登记册汇总成一份简短的报告，提交给发起人和 PMO。

报告应保持简短：通常两三页就足够了。它通常包含在收尾报告中；请参阅我们关于 项目收尾.

经验教训、回顾会与事后复盘对比

它们的目的相同：学习和改进。一种务实的做法是，将回顾会视为团队层面的习惯，而将经验教训作为把最有用的发现传递给其他团队的方式。

如何让经验教训落地生根

最常见的失败是经验教训被收集起来后从未被使用。以下习惯有助于弥合这一差距：

• 将审阅过往经验教训作为启动阶段的一个步骤。 将“审阅相关经验教训”加入 项目章程 检查清单或第一个阶段关口。
• 将经验教训存放在一个可检索的地方 ，采用统一的类别和标签，并由 PMO 或知识负责人管理。
• 将反复出现的经验教训转化为标准。 如果同一条经验教训在三个项目中出现，请更新模板、检查清单或估算指南，而不是第四次记录它。
• 像跟踪其他行动一样跟踪建议， 指定负责人和截止日期，并报告有多少建议得到了落实。
• 分享简短的故事，而不是冗长的电子表格。 在实践社区会议上用五分钟分享，比一份没人打开的文档能触达更多人。
• 将经验教训与风险关联起来。 将相关经验教训直接纳入新项目的 RAID 日志.

常见错误

• 等到项目结束才收集，那时人们已经忘记细节或已转向其他工作。
• 把会议变成追究责任的场合，导致人们不再坦诚。
• 记录症状（“测试太晚”）而不是根本原因。
• 写出没有负责人的含糊建议。
• 只记录问题，忽视值得重复的成功经验。
• 将经验教训存放在没人查看的地方，例如已关闭的项目文件夹中。
• 跳过已取消项目的经验教训，而这些项目往往最有借鉴价值。

用现成的结构开始您的下一次复盘：下载免费的 经验教训模板 或面向敏捷团队的 冲刺回顾会模板 。

本主题的免费模板

浏览所有模板

常见问题