project-retrospective

项目复盘撰写指南

创建 LESSONS.md 文件，记录组织经验，尤其是失败教训。像记者报道自己的项目一样思考：具体、诚实，并指出实际犯下的错误。

设定复盘视角：关注责任，而非一味避免责备

事故分析写作领域在 2024–2026 年形成的共识（PagerDuty、J. Paul Reed、Lorin Hochstein）认为，彻底不责备在神经生物学层面并不现实，人类会本能地归咎于某方。更健康的做法是：承认归咎偏见确实存在，并有意识地加以纠正。来源：https://postmortems.pagerduty.com/culture/blameless/

需要明确纠正的认知偏差：

• 基本归因错误：系统允许了某种失败，却将责任归咎于个人
• 确认偏误：只寻找能够证实预设叙事的证据
• 后见之明偏误：用当时并不可得的信息评判过去的决策
• 负面偏误：过度关注出错之处，而忽视奏效之处

叙述原则不是「不责备」，而是「指出是什么系统允许了人的行为，而不只是描述行为本身」。

摒弃单一根因的框架

Allspaw 的经典批评（在 2024–2026 年仍是主流观点）称，五问法／单一根因分析「诱人、令人信服地简单，却并不真实」。它会让分析人员陷入线性的因果链，并以归咎个人收尾。来源：https://www.kitchensoap.com/2014/11/14/the-infinite-hows-or-the-dangers-of-the-five-whys/

改用「如何」叙事，围绕以下四个问题收集信息：

• 线索：当时有哪些信号？谁在什么时候看到了这些信号？
• 解读：人们如何理解这些信号？
• 目标：人们当时想要达成什么？
• 采取行动：他们做了什么？预期会发生什么？

复盘的任务是找出促成事件的因素，而非宣布一个根因。

何时开展复盘

事先定义触发条件，而不是等到事故发生后才定义。Google SRE 指定了以下标准：用户可见的停机时间超过阈值、发生任何数据丢失、值班人员回滚、监控失效且需人工发现、利益相关方提出要求。来源：https://sre.google/sre-book/postmortem-culture/

转化为新闻行业的情境：

触发条件	示例
直播事件故障	选举之夜实时报道页面停机、突发新闻嵌入内容损坏、深度调查期间付费墙回归故障
编辑流程故障	错过更正时限、来源管理违规、绕过事实核查流程
影响订阅用户的工具故障	CMS 迁移导致回归故障、付费墙逻辑影响超过 X% 的读者
利益相关方提出要求	编辑／出版商／消息来源明确询问「发生了什么？」

预先定义触发条件，可以避免对日常工作走形式地复盘，并确保真正的失败事件得到复盘。

时间安排：尽量在一周内完成

Google 对优劣复盘的比较中，将「四个月后」的案例列为质量问题，因为参与者的记忆已经衰退。来源：https://sre.google/workbook/postmortem-culture/

建议的时间安排：

项目类型	目标时限
直播事件复盘（选举之夜、突发新闻）	当天总结，48 小时内完成书面记录
工具／CMS 事故	一周内
调查或发布上线	项目结束后一个月内
持续推进项目的年度回顾	每年一次，聚焦具体决策节点

实证上的底线是「参与者记忆犹新」。超过一周后，叙事就会变成重构，而非回忆。

对于事件类型的复盘，使用 AAR 结构

美国陆军的事后复盘（After Action Review，FM 7-0 附录 K）专为主持式事后总结而设计，比项目收尾模板更适合实时新闻的实际情况。来源：https://www.first.army.mil/Portals/102/FM%207-0%20Appendix%20K.pdf

四个提示问题：

1. 原本应该发生什么？
2. 实际发生了什么？
3. 两者之间的差异，哪些地方做对了，哪些地方做错了？
4. 下次怎样才能达到标准？

事件结束后立即开展 AAR，让所有参与者都参加，包括选举夜新闻编辑部团队、实时博客执行人员和突发新闻编辑台。对此使用 event.md 模板；项目收尾模板不适用于实时事件复盘。

关键部分：“真正的问题”

这是任何复盘中最有价值的部分。它回答的是：

“我们以为自己要构建什么？实际需要的又是什么？”

有力示例：

我们为编辑构建了一个管理仪表盘，但他们实际需要的是一个 Slack 机器人。他们日常都在 Slack 里，非要他们打开 Web 应用会造成他们无法接受的阻力。这个仪表盘每月活跃用户只有 2 人；而我们一天内构建的 Slack 机器人原型有 47 人使用。

无力示例：

我们认识到了用户研究的重要性。

模板结构

# LESSONS.md

## Project
- **Name:** [Project name]
- **Dates:** [Start - End]
- **Status:** [Completed / Abandoned / Ongoing]
- **Author:** [Your name]
- **Retrospective written:** [Date, should be within timing window above]

## Summary
[One paragraph: what it did, what impact it had, why it matters]

## What worked

### Technical wins
- [Specific decision and WHY it worked]
- [Tool/pattern that saved time]

### Process wins
- [Methodology that helped]
- [Communication pattern that worked]

## What didn't work

For each item below, separate the system layer from the people layer.
"What did the system permit or require?" comes before "What did the
people inside that system do?"

### Critical failures
- **System:** [What the architecture / process / tooling permitted]
- **People:** [What humans did inside that constraint]
- **Cost:** [Quantified impact: hours, subscribers affected, money]

### Technical debt
- [Shortcut that hurt later, and why it was the rational choice at the time]
- [Complexity that wasn't needed]

### External factors
- [Things outside your control that impacted the project]

## The real problem

What we thought: [Initial assumption]
What was actually needed: [Reality]
The gap cost us: [Time / effort / money wasted]

## Action items

Each item must have an owner, a deadline, a tracker URL, and a priority.
"Postmortems without subsequent action are indistinguishable from no postmortem."
- Google SRE

| # | Action | Owner | Deadline | Tracker | Priority |
|---|--------|-------|----------|---------|----------|
| 1 | [Specific change] | [Name] | [Date] | [Issue URL] | P0 / P1 / P2 |
| 2 | [Specific change] | [Name] | [Date] | [Issue URL] | P0 / P1 / P2 |

Failure modes to avoid:
- Ambiguous wording ("make automation better")
- Equal priority across all items (defeats the purpose of priority)
- No tracker bug or issue URL (action items vanish)
- Fixes targeting human behavior instead of system redesign ("be more careful")

Add a 30/60/90-day check-in note: who reviews progress on these, and when.

## Reusable artifacts

| Component | Why it's valuable |
|-----------|-------------------|
| [Name] | [Specific reuse potential] |
| [Name] | [Why someone else should use this] |

## Questions for next time
- [Unanswered questions worth investigating]
- [Things you'd research before starting]

表达风格指南

• 诚实、具体，略带自嘲
• 像是在向朋友解释项目为什么耗时是原计划的两倍
• 先说明系统允许了什么，再说明人们在系统中做了什么
• 指出具体错误，不要含糊地说“挑战”
• 使用主动语态；避免使用“错误发生了”这类隐藏决策者身份的被动表达

来源决策复盘（新闻业原生）

经典的 SRE / AAR / Allspaw 框架并未涵盖调查报道所需的编辑判断复盘。research-project.md 模板新增了“重新审视来源决策”部分：

• 我们信任了哪些来源，为什么？
• 我们拒绝了哪些来源，为什么？
• 编辑处理逻辑是什么？经得起检验吗？
• 如果重新开展这项调查，我们会重新考虑什么？
• 哪些经验模式应该延续到下一项调查？

新闻编辑部工程博客（NYT Open、ProPublica News Apps、WaPo Engineering）会发布项目介绍，但很少介绍复盘方法，因此我们将其视为该系统的新闻业原生扩展，而非借鉴既有做法。

应包含与排除的内容

包含	排除
带有量化背景的具体失败	含糊的“经验教训”
错误造成的实际时间 / 成本	对个人的指责
系统允许了什么（以及之后人们做了什么）	“错误发生了”这类被动表达
按名称指出起到帮助或阻碍作用的工具	泛泛而谈的最佳实践
如果现在再做，你会推翻哪些决定，以及原因	显而易见的陈述
意外发现	其他文档中已有的信息

具体性检验

对于“哪些地方不顺利”中的每一项，都要问：

• 我能否说出具体的决定？
• 我能否量化其影响？
• 我是否区分了系统允许的行为与人们实际做出的行为？
• 这能否帮助别人避免同样的错误？

只要有一项答案是否定的 → 就要写得更具体。

写作中的危险信号

如果你发现自己写了以下内容，请停下来，写得更具体：

• “沟通至关重要”
• “我们认识到了……的重要性”
• “今后我们应该……”
• “挑战包括……”
• “……方面存在一些问题”
• “错误发生了”（谁犯的？在什么系统中？）

这些只是对真实洞见的占位描述。请替换成真实内容。

好条目与差条目示例

差：过于含糊：

• 沟通本可以做得更好
• 我们低估了复杂性
• 测试不充分

好：具体且可采取行动：

• CI 中禁用了数据导入脚本的架构验证步骤（系统），而导入新条目的自由撰稿人并不知道该步骤已被禁用（人员）。代价：花了 3 小时调试一个拼写错误，该错误导致 12 篇已发布报道悄无声息地出错。
• 我们开发了自定义日期选择器，而浏览器原生输入控件就能满足需求。跟踪编号：ENG-1247。负责人：K. Park。浪费了 2 天。

新闻业专用模板

模板位于 templates/ 目录中：

模板	用途
research-project.md	调查报道、数据新闻项目（包含信源选择复盘）
event.md	会议、工作坊、宣传活动（采用 AAR 结构）
publication.md	新闻简报、播客、持续更新的内容
editorial-tool.md	新闻编辑部软件、AI 工具

模板选择

What kind of project?
├── Investigation/analysis → research-project.md
├── Conference/workshop/election night → event.md (use AAR)
├── Newsletter/podcast → publication.md
└── Newsroom tool → editorial-tool.md

最近一次时效性核查

2026-05-09。已核实的来源：kitchensoap.com（Allspaw 的“Infinite Hows”）、postmortems.pagerduty.com、sre.google/sre-book 和 /workbook、first.army.mil FM 7-0 Appendix K、adaptivecapacitylabs.com。

---

最好的复盘由那些吃过苦头、希望帮助他人避免重蹈覆辙的人撰写。