如何做一次能改善下一次发布的复盘

还原发布前已经知道什么

收集最初目标、假设、范围、时间与决策记录，保留结果出现之前的版本。看到结果后重新解释原目标，会让团队很难从当时的选择中学习。

把准备检查、变更、沟通、事故和客户反应按时间排列。尽量使用有日期的记录；只能依靠回忆的部分，也应明确标识，而不是当成同等强度证据。

分别检查是否触达目标人群、是否交付承诺体验、是否出现预期客户反应。前一个阶段出问题，可能使后面的假设根本没有得到公平测试。

例如付款流程故障的发布，不能证明客户拒绝了价格。应先记录技术故障，再说明哪些需求问题仍然没有答案，不要用一个结果解释所有环节。

寻找故障类型或协作挑战相近的案例，用来提出关于顺序、责任和预防措施的问题，而不是把别人公司的原因直接套到自己的结果上。

比较不同解释的证据，区分已经支持、合理但未证实、仍需测试的判断。也要记录这次做对的部分，避免改进时不小心删除有效实践。

每项行动都需要负责人、完成条件，以及在下一次发布流程中的具体位置。“加强沟通”过于模糊；有明确输入和责任人的准备检查，才便于验收。

之后复查改动是否落实、是否减少了目标问题。行动数量应控制在真正能执行的范围内；教训如果只留在演示文档里，复盘就还没有完成。

复制到自己的笔记里填写。空白代表尚待验证，不需要用猜测把它填满。

原始目标与假设：
发布前证据：
时间线：
交付故障：
尚未测试的需求问题：
竞争解释：
保留的实践：
行动、负责人和完成条件：
下次发布验证：

选一个支持案例，再找一个结果不同的反例。阅读正文及其来源，检查与你的情境是否可比。

可用于练习的英文案例（请自行核查原始来源）：

在 App 中搜索公司和主题，阅读案例，再用追问比较不同做法。