1. hindsight 这词准确戳中了技术人的两块心病Hindsight——事后之明回望。英文里老有人说 hindsight is 20/20意思是回头看一切都清清楚楚。这话搁在技术项目里既在说一种认知偏差也在说一项我们缺了很久的能力。我这些年做过不少从零到一、从有到优的项目也经历过半夜线上事故、上线三天回滚、重构了一半推倒重来的场面。每次事后复盘时都有一种相似的感觉出事之后一切都那么明显可在当时为什么就是没人站起来说一句这方案有问题这个问题困扰了我很久。后来我发现症结不在于团队里没有聪明人而在于我们把 hindsight 这件事只用对了一半。我们用事后之明来评判谁对谁错却很少用事后之明去理解系统为什么会允许这个错误发生。这篇文章想聊的就是把 hindsight 从一个被误解的词变成一个真正能帮团队进步的实践。适合正在带项目、做技术管理、或者被复盘会议折磨过的同学读也适合刚入行想搞懂复盘到底在复什么的新人。我不是理论派下面所有内容都来自实际项目中踩过的坑和试过有效的方法。我会先从认知层面讲清楚为什么复盘经常无效再给一套可以直接拿去用的执行框架。2. 复盘没用的真正原因后见之明偏差在捣乱2.1 我早就知道了是一种错觉先做一个自我测试。一年前的今天你能准确回忆起当时对某件事的判断吗大部分人做不到。但有趣的是当事情结果出来后我们都会坚信自己当时隐约感觉到了。心理学把这个称为后见之明偏差hindsight bias。它的机制是我们的大脑会无意识地把已知结果倒推回去重写当时的记忆让一切显得顺理成章。放到项目里这个偏差的破坏性是巨大的。我印象特别深的一次团队给核心交易系统做底层数据库切换前期压测数据不好看但当时大家统一认为换个时间窗口、再优化一下参数就行。结果上线后出现慢查询拖垮了接口花了十几个小时才恢复。事后复盘会上几乎所有参与决策的人都说其实当时我就觉得数据不好看会有问题甚至有人拿出聊天记录证明自己提过疑虑——但翻记录一看他当时的原话是数据不好看但问题不大先上吧。这就是典型的事后之明在改写记忆。如果复盘会上只依赖大家凭印象还原当时的情况那得出的所有结论都会被这种偏差污染。你以为是总结经验其实是在给一个已经被改写的剧本找合理性。2.2 幸存者偏差只复盘失败不复盘侥幸成功很多团队的复盘有一个默认前提出事了才复盘。这本身没问题但它会带来一个被忽视的盲区——那些没有出事、但同样存在严重隐患的决策你永远不会去审视它。举个我自己的例子。有一年我们上线了一个新的缓存策略实现上其实有明显短板缓存失效时会出现瞬时高负载。上线之后连续三个月都在业务低谷期高负载被低流量掩盖了一直没出乱子。直到大促前的一次压测问题才暴露出来。当时压测工程师说还好测了一下可我心里清楚不是还好测了而是我们错把三个月的平静当成了方案正确的证明。成功让人放松警惕。复盘不仅要做事故后的也要定期对运转正常但原因不明的系统做一次审视是我们设计对了还是只是运气好这个问题在复盘里很少被问但它往往是下一次事故的伏笔。2.3 叙事谬误复盘会变成了编故事会人类的大脑天生喜欢连贯的故事。事后复盘时我们很容易把一堆杂乱的事实串成一条因为A所以B所以C的完美因果链。问题是这个链条往往是我们自己脑补出来的。真实情况里事故通常是多条线并行、各种巧合叠加的结果。我见过一份复盘报告把一次线上事故完整归因成了某工程师凌晨错误操作导致配置变更。但深入查下去才发现变更审批流程里没有环境区分、监控阈值设置得过高报警形同虚设、操作手册里的命令和实际环境不符、当天值班的人同时要看三个群。这个工程师只是整个链条里最后被触发的那一环。如果复盘停留在有人操作失误这个叙事上前面所有系统性的问题就全被掩盖了。后见之明偏差、幸存者偏差、叙事谬误这三样东西叠加在一起会让复盘会变成一场集体确认既有判断的活动而不是一次真正的学习。所以接下来的问题是怎么才能绕开它们3. 无过错复盘把矛头从人身上移开才能真正找到根因3.1 先立规矩说什么都不追究我刚开始带项目的时候复盘会经常开成批斗会。某个模块出问题参会的负责人第一反应是这个不是我负责的当时我就说过要加监控的。讨论还没开始防御就铺满了。这种氛围下复盘只能得出一个结论某个人不够细心。后来我看了很多关于高可靠性组织的资料发现普遍有一个共同点采用无过错复盘blameless post-mortem。核心原则只有一条——复盘会上探讨的所有内容不得用于追责。这样做不是包庇错误而是因为绝大部分事故的根源都不在个人而在系统流程设计不合理、工具不好用、信息不透明、压力过大、疲劳加班。只要追责机制还在这些信息就永远不会有人说出来。定这个规矩不是发一个通知那么简单。我自己的做法是复盘会开场第一句话永远是今天我们只看事实和系统不聊谁对谁错。聊完之后除非涉及违法或恶意行为所有人说的话都不进绩效、不进档案。这句话要固定不变每次都讲讲到团队成员真的信了为止。安全感的建立需要时间但一旦建立复盘的信息质量会翻倍提升。3.2 先还原时间线再谈观点人都是带着观点走进复盘会的。为了避免一上来就吵我会要求所有参会者在开会前先共同完成一件不涉及判断的事还原时间线。时间线从哪里来日志、监控截图、发版记录、IM聊天记录、工单、值班交接记录全都可以。列成一张表几点几分发生了什么、谁做了什么、系统当时的指标是什么。只列事实不写解释。举个例子有一次服务出现间歇性超时大家在会上争论了二十分钟到底是不是缓存问题。我让大家先停一停把从故障发生前两小时到恢复后的每一条关键事件列出来。结果一列就发现了一个之前没人注意到的细节故障前三十五分钟恰好有另一套系统的定时任务在跑把同一批数据库连接池占满了。如果一开始就带着缓存有问题的预设去复盘这个事实很晚才会浮出水面。先事实、后观点这六个字能解决大半的无效争论。3.3 五问法为什么经常被用歪提到根因分析很多人会想到五问法5 Whys连续问五个为什么挖到最底层。这个方法本身没错但实操中有一个很常见的歪法——问到最后总停在一个人类员工不够谨慎的结论上。举个例子为什么服务挂了因为缓存节点全部失效。为什么缓存节点全部失效因为有人改了配置。为什么改了配置因为人手滑了。然后呢很多人就停在这里结论变成下次要小心一点。但真正的五问法应该继续往下为什么配置变更没有环境隔离为什么变更没有自动校验为什么生产环境的告警阈值高到形同虚设为什么一个低级变更不需要评审就直接生效挖到这里你才会碰到值得改进的东西——流程、工具、规范而不是人的记忆和心情。我把五问法的边界定义为凡是回答落在某人不够小心上就说明还没问到底。继续问下去你总能找到那个在同样条件下换任何一个人都可能踩进去的机制性缺陷。找到机制性缺陷才是复盘真正有产出的开始。4. 一套可落地的复盘执行框架含文档模板4.1 什么时候复盘别让记忆冷掉经验法则是故障恢复后的72小时内必须完成首次复盘最好在24小时内。原因很简单人的记忆衰减速度远超我们的想象隔了一周再来回顾很多细节就已经被大脑自动美化过了。如果事故比较大现场情况复杂可以先做一次快速复盘锁定核心事实和紧急行动项两周后再做一次深度复盘补上系统性分析。对于没有出事的项目我的习惯是每个里程碑结束后安排一次一小时的结构化回望问四个问题我们做对了什么我们做错了什么我们学到了什么下次必须改变什么不需要每次都写长文档但要留下结论哪怕只有三五行。4.2 复盘文档的骨架很多人把复盘文档写成一本流水账没人愿意看。我建议的骨架是这样的概述Impact Summary这次事件的影响范围、持续时间、损失级别的简明描述。一段话能说清楚。时间线Timeline按时间排列的关键事件纯事实。这部分在会前完成不要在会后补。根因分析Root Cause用五问法或其他方法得出的直接原因和系统性原因明确区分什么触发了事故和什么允许事故发生。促成因素Contributing Factors那些没有直接导致事故但放大了影响的背景因素比如监控缺失、文档过时、排班过紧。行动项Action Items每个行动项必须有负责人、截止日期、验收标准。没有日期的行动项等于没有行动项。经验教训Lessons Learned三条以内、可供后续项目直接引用的结论。附录Appendix相关日志、PR链接、监控截图等供未来查询。这个骨架的逻辑是从发生了什么到为什么会发生再到我们怎么避免每一步都有对应的输入。写文档的时间建议控制在两小时内重点放在讨论和行动上不要花几天雕琢措辞。4.3 行动项怎么定才不会被遗忘复盘报告写完最怕的就是挂在文档里吃灰。我踩过这个坑无数次后来摸索出两个能提高行动项落地率的做法。第一行动项要绑定到具体的工作流里而不是只贴一个待办标签。比如结论是要把配置变更加上自动校验那就直接拆成在下周五前给配置中心加一条校验规则并给相关人发变更公告。抽象结论只会被无限推迟落到具体日程里的任务才可能被执行。第二下次复盘开场先花五分钟过一遍上次的行动项完成情况。没完成的说明当初评估工作量时过于乐观或者优先级设置有问题要做的是调整资源而不是再发一封催促邮件。这个环节能让复盘之后真的会做事形成肌肉记忆团队对复盘的态度也会认真起来。5. 让复盘结论变成下一次决策的输入5.1 从记录教训升级为建立约束有一次我和一个做运维的朋友聊天他提到他们团队的一个做法每一条复盘出来的有效教训都必须变成一道约束——要么是自动化的检查比如CI里加一条规则要么是流程上的卡点比如发版前必须过某个审批要么是工具里的硬限制。如果一条教训只能靠大家以后注意那它就不算一条真正的教训。我很认同这个思路。人是最不可靠的执行器系统才是。复盘结论如果想真正起作用就要把它翻译成让人想犯错都难的机制。比如复盘发现手工操作容易出错那下一阶段的硬任务是给操作加一个人工确认步骤复盘发现新人容易踩坑那就把踩坑记录写成一份带检查清单的文档放进新人的必读材料里。教训一旦沉淀成机制就不再依赖任何人的记性了。5.2 用指标验证复盘到底有没有效果复盘的产出如果永远只是一个文档那它对组织的改进作用是无法量化的。我给自己的团队定了三个可观察的指标一是同一类事故的复发率这个最硬核二是行动项按时完成率这个反映闭环程度三是平均故障发现时间这个反映监控和告警体系的改进效果。这三个指标之间也是互相牵制的。行动项完成率高通常会带来故障发现时间缩短故障发现时间缩短事故影响范围就会变小事故影响范围变小团队的复盘压力也会小一些形成正向循环。我会在季度总结里专门看一眼这些数字而不是只看这个季度复了几次盘。5.3 主动把经验注入下一个项目走过这么多项目我发现最高级的复盘应用场景不是在自己项目里反复翻旧账而是在下一个项目还没开始之前。具体做法很简单新项目立项的时候把最近半年最有价值的三条复盘结论放在需求文档的首页作为设计时的约束条件。举个例子我们团队有一次在复盘里沉淀了一条教训凡是涉及数据迁移的操作必须先做灰度禁止全量一步到位。这个结论写进了后续所有涉及迁移任务的设计评审清单里。后来另一个项目做存储迁移时评审会上的第一句话就是这条灰度的要求满足了吗——大家讨论的不是要不要做灰度而是灰度怎么做。这就是把 hindsight 提前到了 foresight从被动回望变成了主动预防。6. 关于 hindsight我最后想说的几句实在话写了这么多其实核心就一句话hindsight 本身没有价值围绕它建立起来的诚实地回望、系统地归因、认真地行动这个循环才有价值。回头看人人都能做到但看的时候带没带偏见、归因归到机制还是归到个人、看完有没有行动决定了这个团队是会越走越稳还是在同一个坑里反复掉进去。我个人实际操作中最受益的反而是两个不起眼的小习惯。一个是复盘会前的五分钟静默阅读所有人先花五分钟独自看完时间线和材料再开始发言。这能最大程度减少第一个发言者的观点污染整场讨论。另一个是我自己会定期把过去几年的复盘结论翻出来重读一遍。很多时候会发现当时觉得特别重大的教训放到今天看已经成了常识而那些被匆忙归档的细节反而在新的环境下重新变得危险。历史不会重复但历史的注释会——这句话我一直觉得很有道理。希望这篇基于实际经验写的复盘方法论能帮你把事后诸葛亮变成事前诸葛亮。下次项目出问题时别忘了先给所有人倒杯水再说一句我们不追责只追因。
1. hindsight 这词准确戳中了技术人的两块心病Hindsight——事后之明回望。英文里老有人说 hindsight is 20/20意思是回头看一切都清清楚楚。这话搁在技术项目里既在说一种认知偏差也在说一项我们缺了很久的能力。我这些年做过不少从零到一、从有到优的项目也经历过半夜线上事故、上线三天回滚、重构了一半推倒重来的场面。每次事后复盘时都有一种相似的感觉出事之后一切都那么明显可在当时为什么就是没人站起来说一句这方案有问题这个问题困扰了我很久。后来我发现症结不在于团队里没有聪明人而在于我们把 hindsight 这件事只用对了一半。我们用事后之明来评判谁对谁错却很少用事后之明去理解系统为什么会允许这个错误发生。这篇文章想聊的就是把 hindsight 从一个被误解的词变成一个真正能帮团队进步的实践。适合正在带项目、做技术管理、或者被复盘会议折磨过的同学读也适合刚入行想搞懂复盘到底在复什么的新人。我不是理论派下面所有内容都来自实际项目中踩过的坑和试过有效的方法。我会先从认知层面讲清楚为什么复盘经常无效再给一套可以直接拿去用的执行框架。2. 复盘没用的真正原因后见之明偏差在捣乱2.1 我早就知道了是一种错觉先做一个自我测试。一年前的今天你能准确回忆起当时对某件事的判断吗大部分人做不到。但有趣的是当事情结果出来后我们都会坚信自己当时隐约感觉到了。心理学把这个称为后见之明偏差hindsight bias。它的机制是我们的大脑会无意识地把已知结果倒推回去重写当时的记忆让一切显得顺理成章。放到项目里这个偏差的破坏性是巨大的。我印象特别深的一次团队给核心交易系统做底层数据库切换前期压测数据不好看但当时大家统一认为换个时间窗口、再优化一下参数就行。结果上线后出现慢查询拖垮了接口花了十几个小时才恢复。事后复盘会上几乎所有参与决策的人都说其实当时我就觉得数据不好看会有问题甚至有人拿出聊天记录证明自己提过疑虑——但翻记录一看他当时的原话是数据不好看但问题不大先上吧。这就是典型的事后之明在改写记忆。如果复盘会上只依赖大家凭印象还原当时的情况那得出的所有结论都会被这种偏差污染。你以为是总结经验其实是在给一个已经被改写的剧本找合理性。2.2 幸存者偏差只复盘失败不复盘侥幸成功很多团队的复盘有一个默认前提出事了才复盘。这本身没问题但它会带来一个被忽视的盲区——那些没有出事、但同样存在严重隐患的决策你永远不会去审视它。举个我自己的例子。有一年我们上线了一个新的缓存策略实现上其实有明显短板缓存失效时会出现瞬时高负载。上线之后连续三个月都在业务低谷期高负载被低流量掩盖了一直没出乱子。直到大促前的一次压测问题才暴露出来。当时压测工程师说还好测了一下可我心里清楚不是还好测了而是我们错把三个月的平静当成了方案正确的证明。成功让人放松警惕。复盘不仅要做事故后的也要定期对运转正常但原因不明的系统做一次审视是我们设计对了还是只是运气好这个问题在复盘里很少被问但它往往是下一次事故的伏笔。2.3 叙事谬误复盘会变成了编故事会人类的大脑天生喜欢连贯的故事。事后复盘时我们很容易把一堆杂乱的事实串成一条因为A所以B所以C的完美因果链。问题是这个链条往往是我们自己脑补出来的。真实情况里事故通常是多条线并行、各种巧合叠加的结果。我见过一份复盘报告把一次线上事故完整归因成了某工程师凌晨错误操作导致配置变更。但深入查下去才发现变更审批流程里没有环境区分、监控阈值设置得过高报警形同虚设、操作手册里的命令和实际环境不符、当天值班的人同时要看三个群。这个工程师只是整个链条里最后被触发的那一环。如果复盘停留在有人操作失误这个叙事上前面所有系统性的问题就全被掩盖了。后见之明偏差、幸存者偏差、叙事谬误这三样东西叠加在一起会让复盘会变成一场集体确认既有判断的活动而不是一次真正的学习。所以接下来的问题是怎么才能绕开它们3. 无过错复盘把矛头从人身上移开才能真正找到根因3.1 先立规矩说什么都不追究我刚开始带项目的时候复盘会经常开成批斗会。某个模块出问题参会的负责人第一反应是这个不是我负责的当时我就说过要加监控的。讨论还没开始防御就铺满了。这种氛围下复盘只能得出一个结论某个人不够细心。后来我看了很多关于高可靠性组织的资料发现普遍有一个共同点采用无过错复盘blameless post-mortem。核心原则只有一条——复盘会上探讨的所有内容不得用于追责。这样做不是包庇错误而是因为绝大部分事故的根源都不在个人而在系统流程设计不合理、工具不好用、信息不透明、压力过大、疲劳加班。只要追责机制还在这些信息就永远不会有人说出来。定这个规矩不是发一个通知那么简单。我自己的做法是复盘会开场第一句话永远是今天我们只看事实和系统不聊谁对谁错。聊完之后除非涉及违法或恶意行为所有人说的话都不进绩效、不进档案。这句话要固定不变每次都讲讲到团队成员真的信了为止。安全感的建立需要时间但一旦建立复盘的信息质量会翻倍提升。3.2 先还原时间线再谈观点人都是带着观点走进复盘会的。为了避免一上来就吵我会要求所有参会者在开会前先共同完成一件不涉及判断的事还原时间线。时间线从哪里来日志、监控截图、发版记录、IM聊天记录、工单、值班交接记录全都可以。列成一张表几点几分发生了什么、谁做了什么、系统当时的指标是什么。只列事实不写解释。举个例子有一次服务出现间歇性超时大家在会上争论了二十分钟到底是不是缓存问题。我让大家先停一停把从故障发生前两小时到恢复后的每一条关键事件列出来。结果一列就发现了一个之前没人注意到的细节故障前三十五分钟恰好有另一套系统的定时任务在跑把同一批数据库连接池占满了。如果一开始就带着缓存有问题的预设去复盘这个事实很晚才会浮出水面。先事实、后观点这六个字能解决大半的无效争论。3.3 五问法为什么经常被用歪提到根因分析很多人会想到五问法5 Whys连续问五个为什么挖到最底层。这个方法本身没错但实操中有一个很常见的歪法——问到最后总停在一个人类员工不够谨慎的结论上。举个例子为什么服务挂了因为缓存节点全部失效。为什么缓存节点全部失效因为有人改了配置。为什么改了配置因为人手滑了。然后呢很多人就停在这里结论变成下次要小心一点。但真正的五问法应该继续往下为什么配置变更没有环境隔离为什么变更没有自动校验为什么生产环境的告警阈值高到形同虚设为什么一个低级变更不需要评审就直接生效挖到这里你才会碰到值得改进的东西——流程、工具、规范而不是人的记忆和心情。我把五问法的边界定义为凡是回答落在某人不够小心上就说明还没问到底。继续问下去你总能找到那个在同样条件下换任何一个人都可能踩进去的机制性缺陷。找到机制性缺陷才是复盘真正有产出的开始。4. 一套可落地的复盘执行框架含文档模板4.1 什么时候复盘别让记忆冷掉经验法则是故障恢复后的72小时内必须完成首次复盘最好在24小时内。原因很简单人的记忆衰减速度远超我们的想象隔了一周再来回顾很多细节就已经被大脑自动美化过了。如果事故比较大现场情况复杂可以先做一次快速复盘锁定核心事实和紧急行动项两周后再做一次深度复盘补上系统性分析。对于没有出事的项目我的习惯是每个里程碑结束后安排一次一小时的结构化回望问四个问题我们做对了什么我们做错了什么我们学到了什么下次必须改变什么不需要每次都写长文档但要留下结论哪怕只有三五行。4.2 复盘文档的骨架很多人把复盘文档写成一本流水账没人愿意看。我建议的骨架是这样的概述Impact Summary这次事件的影响范围、持续时间、损失级别的简明描述。一段话能说清楚。时间线Timeline按时间排列的关键事件纯事实。这部分在会前完成不要在会后补。根因分析Root Cause用五问法或其他方法得出的直接原因和系统性原因明确区分什么触发了事故和什么允许事故发生。促成因素Contributing Factors那些没有直接导致事故但放大了影响的背景因素比如监控缺失、文档过时、排班过紧。行动项Action Items每个行动项必须有负责人、截止日期、验收标准。没有日期的行动项等于没有行动项。经验教训Lessons Learned三条以内、可供后续项目直接引用的结论。附录Appendix相关日志、PR链接、监控截图等供未来查询。这个骨架的逻辑是从发生了什么到为什么会发生再到我们怎么避免每一步都有对应的输入。写文档的时间建议控制在两小时内重点放在讨论和行动上不要花几天雕琢措辞。4.3 行动项怎么定才不会被遗忘复盘报告写完最怕的就是挂在文档里吃灰。我踩过这个坑无数次后来摸索出两个能提高行动项落地率的做法。第一行动项要绑定到具体的工作流里而不是只贴一个待办标签。比如结论是要把配置变更加上自动校验那就直接拆成在下周五前给配置中心加一条校验规则并给相关人发变更公告。抽象结论只会被无限推迟落到具体日程里的任务才可能被执行。第二下次复盘开场先花五分钟过一遍上次的行动项完成情况。没完成的说明当初评估工作量时过于乐观或者优先级设置有问题要做的是调整资源而不是再发一封催促邮件。这个环节能让复盘之后真的会做事形成肌肉记忆团队对复盘的态度也会认真起来。5. 让复盘结论变成下一次决策的输入5.1 从记录教训升级为建立约束有一次我和一个做运维的朋友聊天他提到他们团队的一个做法每一条复盘出来的有效教训都必须变成一道约束——要么是自动化的检查比如CI里加一条规则要么是流程上的卡点比如发版前必须过某个审批要么是工具里的硬限制。如果一条教训只能靠大家以后注意那它就不算一条真正的教训。我很认同这个思路。人是最不可靠的执行器系统才是。复盘结论如果想真正起作用就要把它翻译成让人想犯错都难的机制。比如复盘发现手工操作容易出错那下一阶段的硬任务是给操作加一个人工确认步骤复盘发现新人容易踩坑那就把踩坑记录写成一份带检查清单的文档放进新人的必读材料里。教训一旦沉淀成机制就不再依赖任何人的记性了。5.2 用指标验证复盘到底有没有效果复盘的产出如果永远只是一个文档那它对组织的改进作用是无法量化的。我给自己的团队定了三个可观察的指标一是同一类事故的复发率这个最硬核二是行动项按时完成率这个反映闭环程度三是平均故障发现时间这个反映监控和告警体系的改进效果。这三个指标之间也是互相牵制的。行动项完成率高通常会带来故障发现时间缩短故障发现时间缩短事故影响范围就会变小事故影响范围变小团队的复盘压力也会小一些形成正向循环。我会在季度总结里专门看一眼这些数字而不是只看这个季度复了几次盘。5.3 主动把经验注入下一个项目走过这么多项目我发现最高级的复盘应用场景不是在自己项目里反复翻旧账而是在下一个项目还没开始之前。具体做法很简单新项目立项的时候把最近半年最有价值的三条复盘结论放在需求文档的首页作为设计时的约束条件。举个例子我们团队有一次在复盘里沉淀了一条教训凡是涉及数据迁移的操作必须先做灰度禁止全量一步到位。这个结论写进了后续所有涉及迁移任务的设计评审清单里。后来另一个项目做存储迁移时评审会上的第一句话就是这条灰度的要求满足了吗——大家讨论的不是要不要做灰度而是灰度怎么做。这就是把 hindsight 提前到了 foresight从被动回望变成了主动预防。6. 关于 hindsight我最后想说的几句实在话写了这么多其实核心就一句话hindsight 本身没有价值围绕它建立起来的诚实地回望、系统地归因、认真地行动这个循环才有价值。回头看人人都能做到但看的时候带没带偏见、归因归到机制还是归到个人、看完有没有行动决定了这个团队是会越走越稳还是在同一个坑里反复掉进去。我个人实际操作中最受益的反而是两个不起眼的小习惯。一个是复盘会前的五分钟静默阅读所有人先花五分钟独自看完时间线和材料再开始发言。这能最大程度减少第一个发言者的观点污染整场讨论。另一个是我自己会定期把过去几年的复盘结论翻出来重读一遍。很多时候会发现当时觉得特别重大的教训放到今天看已经成了常识而那些被匆忙归档的细节反而在新的环境下重新变得危险。历史不会重复但历史的注释会——这句话我一直觉得很有道理。希望这篇基于实际经验写的复盘方法论能帮你把事后诸葛亮变成事前诸葛亮。下次项目出问题时别忘了先给所有人倒杯水再说一句我们不追责只追因。
核心思想与竞赛应用解析)
