经验教训登记册是什么
经验教训登记册把项目收尾、故障复盘、审计发现与验收问题沉淀成结构化条目：背景、做法、结果、适用条件与建议。它和复盘行动项的分工不同——行动项改当下的问题，登记册供未来项目启动时检索同类经验。失效方式有两种：收尾时才补，细节已经遗忘，记录只剩一句结论；以及只登记不使用，新项目重复踩同一类坑，登记册变成纯粹的存档义务。
基本信息
| 来源 | 项目收尾、故障复盘、审计发现、验收问题 |
|---|---|
| 内容 | 背景 / 做法 / 结果 / 适用条件 / 建议 |
| 使用 | 新项目启动时检索同类经验 |
| 检索 | 条目带场景与领域标签，否则无法复用 |
| 责任人 | 登记册有 owner，负责归档与季度整理 |
典型使用场景
- 项目立项时检索同类项目做过的取舍与代价
- 新团队接手历史系统，需要了解当年的坑
- 审计与认证要求提供改进沉淀的证据
- 同类事故在不同团队重复发生，需要横向传播结论
- 年度回顾时要说明组织层面的经验是否被复用
条目示例
条目示例
背景：系统迁移窗口只有 4 小时 # 写清约束条件，否则建议无法复用
做法：预先校验 + 演练两次 + 分段切换 # 做法要具体到可以照做
结果：实际中断 35 分钟 # 结果要有数字，用来判断效果
代价：两次演练占用约 6 人日 # 记录成本，帮助他人做取舍
建议：同类迁移预留双倍演练时间 # 建议指向可执行动作
适用条件：数据量在 TB 级以内、可分批切换 # 写明适用边界，避免被无条件套用字段与写法
| 字段 | 要写什么 | 常见问题 |
|---|---|---|
| 背景 | 当时的约束、目标与规模 | 只写项目名称，后来者无法判断是否可比 |
| 做法 | 具体步骤与关键决策 | 写成结论式口号，无法照做 |
| 结果 | 可量化的效果与代价 | 只有定性描述，无法判断收益 |
| 适用条件 | 在什么前提下有效 | 缺少边界，被错误套用到不同场景 |
| 建议 | 下一次该怎么做 | 建议指向不明确的责任方，无人执行 |
登记册的价值在使用端：新项目启动会上先检索同类经验，比项目结束后再总结便宜得多；条目要挂场景与领域标签，否则再多条目也无人翻阅。