game-postmortem

AlterLab GameForge -- 事后复盘分析工作流

每款发布的游戏背后都有一段故事，其价值甚至超过游戏本身。事后复盘就是提取、梳理这段故事，并将其转化为可复用知识的过程。如果没有事后复盘，团队就会在下一个项目中重蹈覆辙——这并非因为他们能力不足，而是因为记忆具有选择性，缺乏结构的反思往往会偏向叙事，而非规律。

GDC Vault 收录了大量来自工作室的事后复盘，这些工作室都曾为此付出过代价。Supergiant 以结构化回顾记录了每个 Hades 开发周期，这些机构知识直接为 Hades II 的制作流程提供了参考。Obsidian 对 Fallout: New Vegas 的事后复盘发现了“18 个月死亡行军”这一反模式，因此他们在制作 The Outer Worlds 时刻意避开了它。ConcernedApe 对 Stardew Valley 的事后复盘表明，这位独立开发者面临的最大风险并非技术问题，而是 3.5 年间缺乏外部反馈循环。

好的事后复盘不是追责会，也不是庆功会，而是一套结构化的数据提取流程，能为下一个项目、下一个冲刺或下一个团队产出可执行的知识。

目的与触发时机

在以下情况使用此工作流：

• 项目发布后，团队希望总结所学
• 重要里程碑完成时（垂直切片、Alpha、Beta、发布）
• 一个冲刺周期结束，团队希望进行比回顾更深入的分析
• 项目取消后，团队需要提取仍有价值的经验教训
• 新团队成员问“上次出了什么问题？”

它可以解决的问题：

• 在不同项目中重复相同的制作错误
• 幸存者偏差，只有成功经验会被记住
• 以追责为导向的文化，导致失败被掩盖而非分析
• 团队成员离开时，机构知识随之流失
• “经验教训”清单过于笼统，无法据此采取行动

与 game-retrospective 的关系

game-retrospective 技能用于冲刺级和里程碑级的复盘——时间较短、重点更集中，并为下一个冲刺提供可立即执行的成果。事后复盘的范围更广、分析更深入：它会分析整个项目或一个重要阶段，寻找系统性规律，而非特定冲刺中的问题。

在以下情况下使用 game-retrospective：“下一个冲刺我们应该做出哪些改变？” 在以下情况下使用 game-postmortem：“下一个项目我们应该做出哪些改变？”

如果有之前冲刺的回顾数据，事后复盘会将其作为模式分析的输入数据（参见第 3 阶段）。

项目数据（自动填充）

这些值通过 shell 预处理自动注入。它们提供量化的项目数据，让复盘以事实为依据，而非凭感觉。

• 提交总数：!git rev-list --count HEAD 2>/dev/null || echo "No git history"
• 项目周期：!echo "First commit: $(git log --reverse --format='%ai' 2>/dev/null | head -1 || echo 'unknown') / Latest commit: $(git log -1 --format='%ai' 2>/dev/null || echo 'unknown')"
• 提交频率（最近 12 周）：!git log --since="12 weeks ago" --format="%aW" 2>/dev/null | sort | uniq -c | sort -rn | head -12 || echo "No recent history"
• 贡献者：!git shortlog -sn --no-merges 2>/dev/null || echo "No contributor data"
• 文件变更频次（变更最多的文件）：!git log --pretty=format: --name-only 2>/dev/null | sort | uniq -c | sort -rn | head -15 || echo "No file history"
• 标签/里程碑历史：!git tag -l --sort=-creatordate --format='%(refname:short) %(creatordate:short)' 2>/dev/null | head -10 || echo "No tags"
• 未解决的问题：!gh issue list --limit 20 --state open 2>/dev/null || echo "No GitHub issues accessible"
• 已关闭的问题：!gh issue list --limit 20 --state closed 2>/dev/null || echo "No GitHub issues accessible"
• 复盘记录：!ls production/sprints/*retro* production/sprints/*retrospective* 2>/dev/null || echo "No retrospective files found"
• Sprint 数据：!ls production/session-state/last-sprint.json production/session-state/velocity.json 2>/dev/null || echo "No sprint state data"

关键规则

1. 不追责，只看模式。 将个人归咎为失败原因的复盘，永远无法做到坦诚。应将问题归因于流程、决策和系统性条件，而不是个人。“渲染管线没有代码审查关卡”是可采取行动的结论。“Dave 写的着色器很差”则有害且毫无用处。

2. 先看数据，再谈感受。 先从量化数据（提交历史、速度趋势、缺陷数量）开始，再进行主观反思。数字能为讨论提供依据，避免事后改写记忆。上方自动填充的数据是起点，而非装饰。

3. 成功与失败同等重视。 只分析失败的团队会逐渐习得无助；只庆祝成功的团队则会形成盲点。复盘会为两者都安排结构化的讨论时间。

4. 具体胜于抽象。 “我们应该加强沟通”不是经验教训。“我们应该在每个 Sprint 开始时进行 15 分钟的同步，协调美术和代码的优先级”才是经验教训。每项发现都必须形成具体且可落实的行动项。

5. 归档成果。 复盘文档存放在 production/milestones/ 或 design/postmortems/，并在未来的项目设置中引用。复盘如果被放在文件夹里后便再也无人阅读，就毫无价值。

工作流

复盘分为五个阶段。每个阶段都有具体的输入、活动和输出。这些阶段相互衔接，不要跳过或调换顺序。

---

阶段 1：数据收集

收集项目或里程碑周期的定量和定性数据。

定量数据（来自自动填充字段和手动收集）：

• 开发总时长（从首次提交到发布/里程碑）
• 提交频率模式（是否存在赶工期？停滞期？）
• 文件变更频次分析（哪些文件变更最多？它们是复杂度热点）
• 缺陷趋势（缺陷数量随时间呈上升还是下降趋势？）
• Sprint 速度历史（如果 production/session-state/velocity.json 中有记录）
• 范围变更（初始计划后增加的功能、删减的功能） 定性数据（从团队或个人开发者的反思中收集）：
• 最初的愿景是什么？最终发布的产品与之相比如何？
• 声明的设计支柱是什么？是否遵循了这些原则？
• 哪些决策当时感觉正确，后来却证明是错误的？
• 哪些外部因素影响了开发（市场变化、个人因素、工具）？
• 团队的士气在整个项目期间如何变化？

对于个人开发者，定性数据来自自我反思。开发者应 查看自己的提交消息、TODO 注释以及个人开发日志。

---

阶段 2：团队反思

使用具体且可回答的问题进行结构化反思。这些问题旨在 从噪声中提取有效信息。

哪些方面进展顺利（保留并加强）：

1. 哪个单一决策对项目产生了最积极的影响？
2. 哪种工具、流程或实践是你肯定会再次采用的？
3. 不同专业领域之间最出色的一次协作是什么？
4. 哪个功能的交付结果比预期更接近最初的愿景？为什么？
5. 团队及早识别并成功缓解了哪项风险？

哪些方面出了问题（理解并改进）：

1. 哪个单一决策导致了最多的返工或时间浪费？
2. 哪个问题早期就已显现，却拖到很晚才处理？
3. 不同专业领域或团队成员之间的沟通在哪里出现了问题？
4. 哪个功能偏离最初设计最远？是什么导致了这种偏离？
5. 团队有意积累了哪些技术债？这种权衡值得吗？

哪些方面出乎意料（从意外中学习）：

1. 哪项任务花费的时间远超（或远少于）预估？为什么？
2. 哪条玩家或测试人员的反馈最出乎意料？
3. 哪种工具或技术的表现与预期不同（更好或更差）？
4. 哪个外部事件对项目时间表或范围的影响最大？
5. 哪个假设被证明是错误的？

对每个回答，都要追问：“下次可以采取什么具体改变来解决这个问题？” 含糊的回答要继续追问，直到得出具体行动。

---

阶段 3：模式分析

将阶段 1 的数据与阶段 2 的反思进行交叉对照，以识别 系统性模式。个别事件只是症状，模式才是病因。

需要留意的模式类别：

估算模式：

• 任务是否一直被低估？低估了多少？
• 某些专业领域的估算能力是否比其他领域更差？
• 估算准确度在项目期间有所提高，还是始终不变？
• 如果有冲刺速度数据，进行比较：团队的估算偏差是否稳定？

依赖关系模式：

• 哪些跨专业交接造成的延误最多？
• 是否存在反复出现的瓶颈（总是在等美术资源，总是在等代码审查）？
• 团队是及早识别依赖关系，还是到了冲刺中途才发现？

范围模式：

• 发生了多少功能范围蔓延？追踪最初锁定范围后新增的功能。
• 功能删减是主动进行的（在压力出现前），还是被动进行的（在压力下）？
• 被删减的功能是否一直保持删减状态，还是后来又重新加入？

质量模式：

• 缺陷是什么时候引入的，又是什么时候发现的？两者之间相隔多久？
• 某些系统是否一直有更多缺陷？为什么？（复杂度高？规格不明确？采用了新技术？）
• 质量关卡（代码审查、试玩、QA）是否发现了问题，还是问题流向了玩家？

沟通模式：

• 决策是有文档记录，还是通过口头传达？
• 决策被重新审视或推翻的频率如何？
• 所有团队成员是否都掌握了所需背景信息，还是存在信息孤岛？

如果存在以前冲刺的回顾记录（来自自动填充的数据），请阅读 并留意反复出现的主题。在连续三次冲刺回顾中都出现、却始终未解决的问题， 属于系统性失效，而不是冲刺层面的问题。

---

阶段 4：提炼经验教训

将模式转化为经验教训。每条经验教训都采用特定格式：

LESSON FORMAT
---------------------------------------------------------------
Pattern observed: [what happened, with supporting data]
Root cause: [why it happened, traced to a process or decision]
Impact: [what it cost in time, quality, morale, or scope]
Lesson: [one sentence statement of what was learned]
Action item: [specific, implementable change for next project]
Owner: [who is responsible for implementing the change]
Verification: [how to check if the change was implemented]
---------------------------------------------------------------

目标是产出 5–10 条高质量经验，而不是 20 条浅层经验。每条经验都应当能让团队在六个月后指出，并说：“我们根据这次复盘做出了改变，这是后续结果。”

按领域对经验分类：

• 流程经验（团队如何协作）
• 技术经验（架构、工具、引擎选择）
• 设计经验（机制、内容、玩家体验）
• 制作经验（范围、排期、资源分配）
• 沟通经验（交接、文档、决策）

---

阶段 5：行动项与归档

将经验转化为具体行动计划，并归档复盘报告。

行动项格式：

ACTION ITEM
---------------------------------------------------------------
ID: PM-[project]-[number]
Lesson: [reference to lesson from Phase 4]
Action: [specific change to implement]
Owner: [responsible person or role]
Deadline: [when this should be in place — ideally before next project]
Status: [ ] Not started / [ ] In progress / [ ] Complete
Verification: [how to confirm it was done]
---------------------------------------------------------------

归档：

• 将已完成的复盘报告存储在 production/milestones/postmortem-[name].md
• 参考 @templates/post-mortem.md 获取输出模板
• 在项目的 README 或设计文档索引中添加摘要条目
• 如果经验会影响共享流程，请相应更新 @docs/collaboration-protocol.md 或 @docs/coordination-rules.md

输出格式

此工作流将生成一份复盘报告，结构如下。完整模板请参考 @templates/post-mortem.md。

# Post-Mortem Report: [Project/Milestone Name]

**Date:** [date]
**Period covered:** [start date] to [end date]
**Team size:** [number]
**Project duration:** [weeks/months]
**Scope:** [project | milestone: name]

## Executive Summary
[3-5 sentences: what was built, whether it met its goals, and the top 3 lessons]

## Quantitative Overview
| Metric | Planned | Actual | Delta |
|--------|---------|--------|-------|
| Duration | [weeks] | [weeks] | [+/- weeks] |
| Features | [count] | [count] | [+/- count] |
| Bugs at ship | [target] | [actual] | [+/- count] |
| Sprint velocity avg | [planned] | [actual] | [+/- %] |

## What Went Well
1. [Finding with supporting evidence]
2. [Finding with supporting evidence]
3. [Finding with supporting evidence]

## What Went Wrong
1. [Finding with root cause analysis]
2. [Finding with root cause analysis]
3. [Finding with root cause analysis]

## Surprises
1. [Unexpected finding and what it revealed]
2. [Unexpected finding and what it revealed]

## Pattern Analysis
### Estimation Accuracy
[Analysis with data]

### Dependency Bottlenecks
[Analysis with data]

### Scope Management
[Analysis with data]

### Quality Trajectory
[Analysis with data]

## Lessons Learned
### Lesson 1: [Title]
- **Pattern:** [what happened]
- **Root cause:** [why]
- **Impact:** [cost]
- **Action:** [what to change]

### Lesson 2: [Title]
[repeat format]

## Action Items
| ID | Action | Owner | Deadline | Status |
|----|--------|-------|----------|--------|
| PM-001 | [action] | [owner] | [date] | Not started |

## Appendix
- Sprint retrospective summaries (if available)
- Commit frequency charts
- File churn analysis
- Bug trajectory data

质量标准

成功的复盘报告应满足以下所有要求：

• 包含定量数据，并以此支撑定性分析
• 至少包含 3 条“进展顺利”和 3 条“出现问题”的发现，且有证据支撑
• 至少找出 2 个系统性模式（而非孤立事件）
• 每条经验都对应一项具体、可执行且有负责人的行动项
• 不使用针对个人的责备措辞
• 文档已归档在易于查找的位置
• 行动项设有截止日期和验证标准
• 如实说明哪些情况出乎意料或令人不适

使用示例

1. “我们刚发布了游戏。来做一次复盘吧。” 完整的 5 阶段工作流。纳入所有可用的 Git 数据、冲刺历史记录和回顾笔记。产出全面的项目级复盘报告，总结可用于指导下一个项目启动的经验。

2. “我们的 Alpha 里程碑已经完成。我们学到了什么？” 以里程碑为范围进行复盘。将数据收集范围限定为项目启动至 Alpha 阶段。将 Alpha 交付成果与最初的 Alpha 目标进行比较。提取可在 Beta 阶段前应用的经验。

3. “这个项目取消了。还有什么值得保留吗？” 取消项目复盘。重点加强阶段 3（模式分析），以了解项目失败的原因。行动项聚焦于下一个项目中需要做出的改变，以避免重蹈覆辙。坦诚务实地分析问题。

4. “我是独立开发者，刚做完我的第一款游戏。我应该做哪些不同的尝试？” 独立开发者复盘。阶段 2 转为自我反思。提交频率模式可以反映工作习惯（是否有赶工？是否出现倦怠导致的工作间断？）。跨任务的估算准确度可以揭示个人偏差模式。行动项则是个人流程改进。

5. “我们即将启动一个新项目。上个项目的复盘报告有什么结论？” 检索并应用复盘结论。阅读归档的复盘报告，审查行动项，确认哪些已落实，并标出尚未落实的项目。将未处理的经验纳入新项目的 game-start 工作流。

Agentic 协议

• 加载 @docs/collaboration-protocol.md，了解交互规范
• 加载 @docs/coordination-rules.md，了解升级处理路径
• 参考 @templates/post-mortem.md 获取输出模板
• 将已完成的复盘报告存储在 production/milestones/postmortem-[name].md
• 如果有冲刺回顾数据，请在阶段 3 中纳入分析
• 如果有速度数据，请将其纳入定量概览
• 如果在 game-retrospective 之后运行，请将回顾输出作为阶段 2 的输入

属于 AlterLab GameForge——独立游戏开发技能套件。