“吾日三省吾身：
为人谋而不忠乎？
与朋友交而不信乎？
传不习乎？”
《论语·学而》
复盘会上的“狼人杀”
会议室里静悄悄的，人们围坐在方桌前，大家一言不发。
除了摆放在面前苹果电脑之外，会议室里的这群人还分享着另一个共同点——他们的表情都异常凝重，凝重到他们头顶的空气都要凝固了。
在一个互联网公司里，出现这样的场面并不奇怪，毕竟现在他们开的是一个故障复盘会——或者，你也可以把它叫做互联网人的修罗场。
实际上，这次会议要复盘的故障，早在前一周就已经发生、发现并且解决了。但是，因为最近一段时间故障实在是太多了，大家实在分身乏术，所以对这个故障的复盘和定责迟迟没有完成。
只要故障定责没有完成，对于某些人来说，悬在心头的那块巨石就不会落地。因为一旦背上故障，这一年就约定于白干了。所以，虽然现在大家现在都一言不发，但是大家心里很清楚，此次会议的结论事关重大。
毕竟，没有那个打工人愿意白干一年，或是一年白干。
在展开这个故事之前，不妨让我们看看都有哪些人在参加这个会议。
首先，那个看上去神情疲惫、眼圈深陷的家伙，当然就是这次故障的当事人了。
事实上，在故障发生到现在的这段时间里，当事人一直都在惶恐中组织应急，连一个整觉都没有睡过。甚至，就连现在投在电视上的故障复盘报告里的绝大多数内容，都是他昨天熬夜写的——写这份报告本应该是复盘组织者——故障管理小组的职责，但是最近发生的故障实在太多了，故障管理小组的同事已经忙不过来了，于是他们把这个苦差事借着当事人的愧疚之情推给了他。
墙倒众人推，不管从哪个方面来看，故障当事人已经把自己送上了绝路——这一年他可能要白干了。
实际上，这次捅出这么个天大的篓子，当事人从一开始就已经放弃了治疗，能够坚持到现在把故障处理完，凭的是他已经残存不多的职业道德。至于之后怎么样？是一年白干？还是以后都不用干了？这件事情他不是不想思考，而是压根就没有时间思考——他已经被榨干了。
在故障当事人身旁正襟危坐的那个人，便是当事人的老板。
虽然表情同样凝重，但在当事人老板的眼神中却丝毫看不出一点慌乱，甚至在他那凝重的脸上反而透露着一丝的不耐烦——好像他早就知道结果所以不想在这里浪费时间了似的。
当事人的老板，少说也有七八年了的工龄了。他不是第一次参加此类故障复盘会议，对这种会议里的的各种明规则和潜规则早已经烂熟于心。
关于本次的这个故障，虽然当事人是自己团队的人，但是他一点都不可怜当事人，因为他早就想把这个做事毛手毛脚的当事人给汰换掉了。但是从团队的角度出发，他知道背上这么一个严重的故障对他和他的团队意味着什么——很可能让大家一年都白干了——而这，绝对是他无法接受的。
所以，就在复盘会议的前两天，他就已经早早动手了——他私下找各方老板沟通了一遍。也许他早就拿到了自己想要的结果——要么把故障等级降低，要么干脆把故障甩给别人。也许他已经找到了战略同盟，一会儿为了定责开撕的时候，不至于让自己落单成为众矢之的——反正，完全背这个故障，在他的列表里没有、也不可能有这个选项。
再往当事人老板的旁边看，便是产品经理。
就在刚才，在产品经理收到他同事的消息的时候，他那满脸的愁容就已经一扫而光了。消息上说：“我们的没问题，我们的prd（产品文档设计）上描述得很清楚。”
从设计文档、测试文档、产品文档、业务文档等各种文档中找寻证据，证明自己与这个故障没有关系，是故障定责时的惯用招数。现在产品经理知道自己手握关键证据。有这么一张大牌，这个故障的责任怎么着也不会落到他的头上。
产品经理抬头环视会议室里的其他人，看到的是千篇一律的凝重表情。真是幽默啊，他在心中窃喜。是的，目前整个会议室里没有谁能比他更轻松了，他把眼前的苹果电脑一合，把椅子往后一推，身体展开舒服地斜躺在椅子里。
下一秒，这个产品经理已经变成了与世无争的吃瓜群众。
和产品经理形成巨大反差的，是坐在产品经理旁的测试妹子和她的老板。
从来没有见过这样的阵仗，刚刚毕业的测试妹子被吓到了，她连大气都不敢出，连头也不敢抬。
测试妹子连做梦也没有想到，自己入职的第一个重大项目，竟是以线上故障的方式收场的，而导致那个故障的问题，现在看来实在是太低级、太不应该了，但是当时她确实没有测试出来。
现在她即懊恼又害怕。
懊恼，是因为自己的大意、明明是可以测出来的，她在心里埋怨自己。
害怕，则是因为在入职培训的时候，她知道公司对线上故障的零容忍态度——学生时代分数思维未脱的她，怕自己在年终拿到一个不好的绩效，然后被赶走。
老实说，她真的很喜欢这份工作。
反观她的老板，虽然此时一样脸色凝重，但在他的头脑里，正盘算着着一个完全不同的抉择——他正在为今年的最差绩效的人选而发愁。
现在机会来了，要不要抓住呢？要不要让测试妹子“一年都白干了”呢？
善恶交织的念想让刚成为小组长不久的他纠结不已。公允来说，测试妹子的能力和潜力并不算差，让她背锅她可能真的就离职了，着实有点可惜和不公。但是，他又怕后面不再有这样顺理成章的机会了——要知道一个团队的绩效可不是那么好打的，这几年他可听了不少因为绩效反目成仇的故事。另外，如果他主动把这个故障揽下来，今年团队的故障指标就会用掉一个，后面如果再来一个故障的话可不好受……
to be or not to be，这一直都是一个问题。
就这样，互联网公司里一次典型的故障复盘会，就在这样近乎同床异梦的情况下展开了。
如果你没有参加过大厂的故障复盘会，那么很可能你会怀疑这个故事的真实性。
这真的大可不必，我会告诉你艺术源于生活。
而且，根据我长期观察，故障复盘可以说是大家最讨厌同时又最喜欢的一种会议形式。
换言之，故障复盘会不单单是一个修罗场，有时候它还是一个秀场。
甚至，当两拨人撕到上头的地方，会让实际搞出故障的那个人产生一种“你们吵得这么嗨，这故障好像和我没什么关系”的错觉。
在曾经的几次故障复盘会上，看着大家撕来撕去，我不禁感叹，这个复盘过程本身就需要来一次复盘。
对了，我想你一定很好奇故事里这个故障的责任最后定给了谁。
这里姑且先让我卖个关子，在揭晓谜底之前，不妨让我们先看一下到底什么是复盘？
什么是复盘？
复盘，首先是一个围棋概念。在围棋中，复盘也称 “复局”。
指对局完毕后，棋手复演这盘棋的记录，以检查对局中双方招法的优劣与得失关键。
用人话来说，就是在复盘的过程中，棋手需要分析关键步骤。此时他们需要会站在旁观者的视角提问：“我为什么要这样走？有没有更好的走法？对手为什么要那样走？有没有更好的走法？”。
通过这种方式，棋手可以加深对这局对弈的印象，找出双方攻守的漏洞，提高自己的博弈水平。
在工作和生活中，我们常说的复盘，就是把已经发生的事情，同当事人一起重新梳理和推演，找到事情何以至此的原因，并在未来予以优化或者避免。
用更概括的语言来说，复盘的过程，是把自己从当局者变成旁观者，从整体上检视并反思已经发生的事件，并对未来提供指导的过程。
例子：公司里的故障复盘会
现实中，我们的故障复盘流程是这样的：
会议前
主持人向故障当事人收集材料，编写故障复盘报告。故障复盘报告的内容组织一般按照故障发生的时间线的方式展开。
会议中
1 主持人以时间线的方式介绍整个故障的过程，包含但不限于：
-
故障的时间：这个故障是什么时候引入的，什么时候发现的，什么时候恢复的
-
故障的原因：引起故障的原因，一般有技术原因和管理原因
-
人的因素：谁在什么时候做了什么决策，谁又去执行了什么操作，执行结果是什么？
2 分析故障的根因
以时间线展开，分析在每个关键节点上，我们的决策和执行是否正确？是否有更好的解决方？这个环节需要研发、测试、产品等各方的共同参与，以便不同的视角对问题进行分析，力求全面和细致。
3 提出避免相同故障再次出现的解决方案
更具不同的角度，一般会有多个可以落地执行的action，并指定执行人和action的完成时间。
4 故障定责
这一步，简单来说是为了杀一儆百。在技术层面来看，这一步可能是最不重要的。但在政治层面一旦涉及到谁要白干一年，就是另一个回事儿了。从过往的经验来看，在故障非常重大、各方没有达成一致的时候，这一步反而是最花时间的。
会议后
通报故障结果，跟踪和执行action。
在一个好的复盘里，action一定要落地执行到位，这个我后面也会提到。
受限于篇幅，这里只能对公司里的故障复盘流程做简单介绍。虽然每个公司的复盘流程都不尽相同，但是实施复盘的原则永远都是一样的：
既然已经说到了实操的原则，那么你可能会疑惑：为什么要复盘？
为什么要复盘？
曾子说：“吾日三省吾身：为人谋而不忠乎？与朋友交而不信乎？传不习乎？”
从曾子的角度来看，他认为每天复盘的原因，是为了做更好的自己。
从现代工程师的角度来看，我想需要复盘的原因有如下三点：
第一，复盘可以避免未来的失败
在脑海中失败的越多，才能减少在现实中的失败。
如前文中描述的故障复盘，其实就是从线上故障中寻找原因和解法，进而避免未来再次出现相同的故障。
这种思想在各行各业都是适用的，所谓吃一堑长一智，这几乎是动物的本能。
第二，复盘是成功的催化剂
避免了失败，不代表我们一定会成功。如果想要成功，我们更要时时复盘那些成功案例。从中找出能够让我们走向成功的主要原因，并且想方设法加强这个主要原因。
比如，我们对自己的能力进行分析、找到自己的优势，或者在商业上我们会对公司的优势进行分析，这个时候，我们就需要复盘自己的过去，找到促使自己成功的主要原因，然后设法放大这个主要原因。
第三，复盘产生新知，新知可以传承
复盘要求我们从全局视角去重新审视已经发生的事件。
在切换视角之后，即便是同一件事情也可以从中看到不同的内容，所以说复盘是一个重新学习（relearn）的过程。
在这个过程中，我们会从未知走向已知（这句话未来我可能会反复提起很多遍，就和下面的图一样），发现自己之前不曾关注的信息、知识甚至规律，梳理出更加体系化的知识和智慧。
在一个具体的领域中，这些知识和智慧就是这个领域当中的经验。而知识和智慧可以传承，无论对于个人还是组织，都是一笔无形的财富。
比如，我们曾经处理过金额单位转换错误（比如，把100分当成100元），引发的线上资损问题。
复盘下来我们才意识到——原来有些国家货币的最小单位是元而不是分，如日元，越南盾等等。进一步分析，我们发现就算是同一种币种的金额，其单位在不同系统的接口上的定义也是不同的。另外，不同国家的币种之间也会因为汇率转换而出现舍入误差。最后，作为整个复盘的结果，我们产出了一套标准的金额处理方法在团队里推广，这就避免了相同的问题在未来再次出现。
可以看到，这样体系化的知识，如果不跳出自己的固定视角去分析，在事后予以梳理和重新学习，在当时是很难发现的——这就是所谓的“当局者迷，旁观者清”。
而且，在故障复盘之后，我们会保存复盘报告，这既是一种归档，也是一种知识的传承，方便后来者查阅学习、避免重复犯错。
值得一提的是，我们常说那些的歇后语，本质上就是前人在复盘之后的智慧传承。
既然复盘这么重要，那么怎么复盘才是正确的姿势呢？
如何复盘？
首先，从复盘材料的来源看，复盘有两种方式。
-
第一种，复盘自己的经历。
-
第二种，复盘别人的经历。
第一种方式-复盘自己的经历。概括下来，就是“我当时为何要这样做？做对了还是做错了？如果重来一遍，有无更好的做法？”
复盘自己的经历，好处是自己是当事人，体验了切肤之痛之后，可以做到尽可能的场景还原，而且复盘过程相对私人化，更能对症下药。当然，自我复盘的坏处也很明显——自己复盘自己的经历，可能结果会非常主观，也有可能“不识庐山真面目”。
第二种方式-复盘别人的经历。概括下来，就是“他当时为何要那样做？做对了还是做错了？如果重来一遍，有无更好的做法？”
复盘别人的经历，则可能只能看到表面的部分，很难完全还原当时的场景，更难感同身受，这样的复盘收获只能作为一种参考。但是，无论如何我们都要感谢那些乐于分享自己经历的人。从某种意义上来说，他们是人类智慧的传承者（所以看完本文应该做什么呢？）。
其次，关于复盘的内容，可以是成功的经历，也可以是失败的经历。
复盘的目的无非有二：学习成功者如何成功，学习失败者如何失败。
比如，前文故事中的故障复盘，其实就是在复盘失败的经历，避免下次出现同样的错误。而阅读成功者的传记，则是在复盘别人成功的经历，希望能够学习成功者的处事方式。
再次，从复盘的过程来看，信息的全面性、客观性非常重要。
为了能够对整个事件有全面的把握，我们要把事件的始末梳理清楚，我们要尽可能地还原出每个人在事件中的所思所想和行动。
当然，聪明的你肯定想到了，在人性使然下众人必然各执一词，所以绝对的客观绝对不是一件简单的事情，但是再难也得想办法去接近真相。
比如，在故障复盘中，我们需要把故障的前因后果分析清楚，把故障中每个人的关键动作记录在案，几乎是以福尔摩斯的抽丝剥茧，产出故障报告。
这样，在实际复盘的时候，我们才能确保不同角色的人对故障的过程理解一致，才能知道如何改进，不会因为信息不完整而做出错误的判断。
此外，复盘人数可以是一个人也可以是多人。
一个人复盘不难理解，毕竟有些事情只能一个人在心里慢慢复盘。
但是多人复盘却能够避免盲区，集思广益。
当然，无论一人复盘还是多人复盘，都要强迫自己从当局者变成旁观者，唯其如此，才能看到问题的本质。
最后，复盘一定要有指导未来的结果。
复盘不是空想和空谈，不能因为盘过了就抛之脑后，浪费了大量的时间，还不如不盘。
复盘之后，一定要有可以执行的动作，一定要有改进措施，最重要的是把这些措施执行下去。
只有把复盘得到知识用于实践，我们才不会被同一个石头绊倒两次。
何时复盘？
对于重大事件，比如故事中故障复盘，最好的复盘时间是故障发生后的一周之内，此时人们对事件的记忆还比较清晰，复盘效果最好。
对于日常生活来说，每天复盘实在过于频繁，我们能够做到一周一次小复盘，一个月一次大复盘即可。
另外，个人复盘的内容，可以通过日记或者周记保存，便于后续查阅。
复盘的关键点
无论复盘的具体形式是怎样的，都必须遵循如下四个关键点：
第一，复盘最怕肤浅
既然是复盘，那就要想方设法弄清楚所复盘事件的前后因果，找到驱动整个事件的“底层逻辑”，要有一定的思考深度。
如果复盘只是简单的走个过场，流于表面，把复盘报告（日记）拿出来照着念一遍，那还不如不复盘，不要浪费大家的时间。
第二，复盘不是追责
复盘盘的是事情的始末源委，盘事情的目的是为了未来把事情做好，而不是为了给哪个人定责。
如果抱着追责的心态去复盘，那复盘的过程就成了走过场，复盘场也就变成了修罗场。
最可怕的是，在对立情绪之下，复盘的结果必然也是扭曲的，那还不如不复盘。
如果要做复盘，请把“自我”抽离出去，谦虚一点，像一个局外人一样冷眼旁观正在复盘的事情。
第三，复盘之后一定要有行动
既然复盘是面向未来的，那么复盘之后，除了有最痛的领悟之外，一定要有行动。
若没有行动，只是在脑子里想想、嘴上说说，那怕你想出来的内容再华丽，说出来的再浮夸，也是没有意义的，因为你只想不做。而没做之前，你想的可能都是错的！
现在，很多人（包括我自己）都在说：“让我们复盘一下吧”。其实这是不对的，复盘本身不是目的，由复盘产生行动、由行动产生我们想要的结果，这才是“复盘”的目的。
一句话，复盘的目的，是为了行动；行动之后，不要忘了复盘。
第四，失败要复盘，成功更要复盘
我们在工作当中，更多的是复盘故障和失败，从来没有复盘过成功。
事实上，无论是成功还是失败，都只是一个事件。
如果是事件，那么都可以拿来复盘。尤其，很多成功的案例反倒更值得我们去复盘。
为什么？
因为成功会让我们忘乎所以，以为自己无所不能。而只有复盘之后，我们才能知道，我们的这次成功是出于运气还是实力。
如果是出于运气，那么有哪些是运气的成分？如果这些成分没了，我还能成功吗？我该如何避免这种不确定性？
如果是出于实力，具体这个实力又体现在哪几方面？我能继续把这些实力优势发挥下去吗？
可以看到，复盘失败和复盘成功一样重要，我们不应该对此有差别心。
其他行业的复盘工具
复盘并不是互联网公司首创的，每个行业都有它的复盘方法论，这里仅列举三个例子：
第一，在我国的航天领域有所谓的“归零”，这其实就是一种复盘。
第二，军队在执行任务之后，会写任务后的报告（AAR，after action report），这也是一种复盘。
第三，丰田公司的精益制造中，对问题的愿意有一个5-WHY的询问过程（会在根因思维里着重介绍），这其实是一种复盘的方法。
“狼人杀”谜底揭晓！
如果你耐着性子看到了这里，那么我想你一定想知道文章开头故事中的故障定责到底定给了谁？
现在就让我们揭晓答案。
首先，这个故障最终还是定给了故障当事人。
好的一面是，在当事人老板的斡旋之下，故障等级降了一档，这就意味着当事人从“一年白干”变成了“半年白干”。同时，当事人老板的团队绩效也没有受到影响。
遗憾的是，半年之后当事人还是转岗了。
其次，测试妹子并没有在这次复盘中获罪。
后来她的表现还算不错。然而，出于公司每年强制绩效的要求（你的团队里总有一个人是末位），她的老板在之后的故障复盘里让另一个人“顶”了罪。
总的来说，这样的结局算不上happy ending也算不上bad ending，甚至都算不上是个真正意义上的结局——复盘结束的之后，他们的生活也并没有因这次复盘而走向ending（结束）。
毕竟，复盘之后，他们的生活才刚刚开始，而跌宕起伏才是生活的真实面貌。
在这样跌宕起伏的人生历程里，一个小小的故障又算得了什么呢？
本章小结
本文介绍了“三省吾身”的复盘思维，解释了为何要复盘、如何复盘以及复盘的关键点。
学习复盘思维相当于给自己装上了助推器，让你能够从容应对生活和工作中的各种起伏颠簸。
同时，如果你能够在某个领域里全面践行复盘思维，并且坚持把复盘的“知”变为复盘的“行”，相信过不了多久，你就会成为这个领域中屈指可数的专家。
以上，就是我所知道的“复盘思维”的全部内容，希望对你有用。
(本章完，版权归作者王晓辰所有，若要转载，请标明出处)
作者简介
王晓辰，软件研发工程师，8年+金融科技从业者，文字价值和文字理想的信仰者和践行者，公众号“架构师的白日梦”的作者。
他坚信用心写就的文字具有无穷的能量，可以穿越时空的阻隔，向读者传达最纯粹的经历、最质朴体悟以及最深邃的思索，最终完成思想的启迪和灵魂的交流。
架构创造未来，文字打败时间！
“吾日三省吾身：
为人谋而不忠乎？
与朋友交而不信乎？
传不习乎？”
《论语·学而》
复盘会上的“狼人杀”
会议室里静悄悄的，人们围坐在方桌前，大家一言不发。
除了摆放在面前苹果电脑之外，会议室里的这群人还分享着另一个共同点——他们的表情都异常凝重，凝重到他们头顶的空气都要凝固了。
在一个互联网公司里，出现这样的场面并不奇怪，毕竟现在他们开的是一个故障复盘会——或者，你也可以把它叫做互联网人的修罗场。
实际上，这次会议要复盘的故障，早在前一周就已经发生、发现并且解决了。但是，因为最近一段时间故障实在是太多了，大家实在分身乏术，所以对这个故障的复盘和定责迟迟没有完成。
只要故障定责没有完成，对于某些人来说，悬在心头的那块巨石就不会落地。因为一旦背上故障，这一年就约定于白干了。所以，虽然现在大家现在都一言不发，但是大家心里很清楚，此次会议的结论事关重大。
毕竟，没有那个打工人愿意白干一年，或是一年白干。
在展开这个故事之前，不妨让我们看看都有哪些人在参加这个会议。
首先，那个看上去神情疲惫、眼圈深陷的家伙，当然就是这次故障的当事人了。
事实上，在故障发生到现在的这段时间里，当事人一直都在惶恐中组织应急，连一个整觉都没有睡过。甚至，就连现在投在电视上的故障复盘报告里的绝大多数内容，都是他昨天熬夜写的——写这份报告本应该是复盘组织者——故障管理小组的职责，但是最近发生的故障实在太多了，故障管理小组的同事已经忙不过来了，于是他们把这个苦差事借着当事人的愧疚之情推给了他。
墙倒众人推，不管从哪个方面来看，故障当事人已经把自己送上了绝路——这一年他可能要白干了。
实际上，这次捅出这么个天大的篓子，当事人从一开始就已经放弃了治疗，能够坚持到现在把故障处理完，凭的是他已经残存不多的职业道德。至于之后怎么样？是一年白干？还是以后都不用干了？这件事情他不是不想思考，而是压根就没有时间思考——他已经被榨干了。
在故障当事人身旁正襟危坐的那个人，便是当事人的老板。
虽然表情同样凝重，但在当事人老板的眼神中却丝毫看不出一点慌乱，甚至在他那凝重的脸上反而透露着一丝的不耐烦——好像他早就知道结果所以不想在这里浪费时间了似的。
当事人的老板，少说也有七八年了的工龄了。他不是第一次参加此类故障复盘会议，对这种会议里的的各种明规则和潜规则早已经烂熟于心。
关于本次的这个故障，虽然当事人是自己团队的人，但是他一点都不可怜当事人，因为他早就想把这个做事毛手毛脚的当事人给汰换掉了。但是从团队的角度出发，他知道背上这么一个严重的故障对他和他的团队意味着什么——很可能让大家一年都白干了——而这，绝对是他无法接受的。
所以，就在复盘会议的前两天，他就已经早早动手了——他私下找各方老板沟通了一遍。也许他早就拿到了自己想要的结果——要么把故障等级降低，要么干脆把故障甩给别人。也许他已经找到了战略同盟，一会儿为了定责开撕的时候，不至于让自己落单成为众矢之的——反正，完全背这个故障，在他的列表里没有、也不可能有这个选项。
再往当事人老板的旁边看，便是产品经理。
就在刚才，在产品经理收到他同事的消息的时候，他那满脸的愁容就已经一扫而光了。消息上说：“我们的没问题，我们的prd（产品文档设计）上描述得很清楚。”
从设计文档、测试文档、产品文档、业务文档等各种文档中找寻证据，证明自己与这个故障没有关系，是故障定责时的惯用招数。现在产品经理知道自己手握关键证据。有这么一张大牌，这个故障的责任怎么着也不会落到他的头上。
产品经理抬头环视会议室里的其他人，看到的是千篇一律的凝重表情。真是幽默啊，他在心中窃喜。是的，目前整个会议室里没有谁能比他更轻松了，他把眼前的苹果电脑一合，把椅子往后一推，身体展开舒服地斜躺在椅子里。
下一秒，这个产品经理已经变成了与世无争的吃瓜群众。
和产品经理形成巨大反差的，是坐在产品经理旁的测试妹子和她的老板。
从来没有见过这样的阵仗，刚刚毕业的测试妹子被吓到了，她连大气都不敢出，连头也不敢抬。
测试妹子连做梦也没有想到，自己入职的第一个重大项目，竟是以线上故障的方式收场的，而导致那个故障的问题，现在看来实在是太低级、太不应该了，但是当时她确实没有测试出来。
现在她即懊恼又害怕。
懊恼，是因为自己的大意、明明是可以测出来的，她在心里埋怨自己。
害怕，则是因为在入职培训的时候，她知道公司对线上故障的零容忍态度——学生时代分数思维未脱的她，怕自己在年终拿到一个不好的绩效，然后被赶走。
老实说，她真的很喜欢这份工作。
反观她的老板，虽然此时一样脸色凝重，但在他的头脑里，正盘算着着一个完全不同的抉择——他正在为今年的最差绩效的人选而发愁。
现在机会来了，要不要抓住呢？要不要让测试妹子“一年都白干了”呢？
善恶交织的念想让刚成为小组长不久的他纠结不已。公允来说，测试妹子的能力和潜力并不算差，让她背锅她可能真的就离职了，着实有点可惜和不公。但是，他又怕后面不再有这样顺理成章的机会了——要知道一个团队的绩效可不是那么好打的，这几年他可听了不少因为绩效反目成仇的故事。另外，如果他主动把这个故障揽下来，今年团队的故障指标就会用掉一个，后面如果再来一个故障的话可不好受……
to be or not to be，这一直都是一个问题。
就这样，互联网公司里一次典型的故障复盘会，就在这样近乎同床异梦的情况下展开了。
如果你没有参加过大厂的故障复盘会，那么很可能你会怀疑这个故事的真实性。
这真的大可不必，我会告诉你艺术源于生活。
而且，根据我长期观察，故障复盘可以说是大家最讨厌同时又最喜欢的一种会议形式。
换言之，故障复盘会不单单是一个修罗场，有时候它还是一个秀场。
甚至，当两拨人撕到上头的地方，会让实际搞出故障的那个人产生一种“你们吵得这么嗨，这故障好像和我没什么关系”的错觉。
在曾经的几次故障复盘会上，看着大家撕来撕去，我不禁感叹，这个复盘过程本身就需要来一次复盘。
对了，我想你一定很好奇故事里这个故障的责任最后定给了谁。
这里姑且先让我卖个关子，在揭晓谜底之前，不妨让我们先看一下到底什么是复盘？
什么是复盘？
复盘，首先是一个围棋概念。在围棋中，复盘也称 “复局”。
指对局完毕后，棋手复演这盘棋的记录，以检查对局中双方招法的优劣与得失关键。
用人话来说，就是在复盘的过程中，棋手需要分析关键步骤。此时他们需要会站在旁观者的视角提问：“我为什么要这样走？有没有更好的走法？对手为什么要那样走？有没有更好的走法？”。
通过这种方式，棋手可以加深对这局对弈的印象，找出双方攻守的漏洞，提高自己的博弈水平。
在工作和生活中，我们常说的复盘，就是把已经发生的事情，同当事人一起重新梳理和推演，找到事情何以至此的原因，并在未来予以优化或者避免。
用更概括的语言来说，复盘的过程，是把自己从当局者变成旁观者，从整体上检视并反思已经发生的事件，并对未来提供指导的过程。
例子：公司里的故障复盘会
现实中，我们的故障复盘流程是这样的：
会议前
主持人向故障当事人收集材料，编写故障复盘报告。故障复盘报告的内容组织一般按照故障发生的时间线的方式展开。
会议中
1 主持人以时间线的方式介绍整个故障的过程，包含但不限于：
-
故障的时间：这个故障是什么时候引入的，什么时候发现的，什么时候恢复的
-
故障的原因：引起故障的原因，一般有技术原因和管理原因
-
人的因素：谁在什么时候做了什么决策，谁又去执行了什么操作，执行结果是什么？
2 分析故障的根因
以时间线展开，分析在每个关键节点上，我们的决策和执行是否正确？是否有更好的解决方？这个环节需要研发、测试、产品等各方的共同参与，以便不同的视角对问题进行分析，力求全面和细致。
3 提出避免相同故障再次出现的解决方案
更具不同的角度，一般会有多个可以落地执行的action，并指定执行人和action的完成时间。
4 故障定责
这一步，简单来说是为了杀一儆百。在技术层面来看，这一步可能是最不重要的。但在政治层面一旦涉及到谁要白干一年，就是另一个回事儿了。从过往的经验来看，在故障非常重大、各方没有达成一致的时候，这一步反而是最花时间的。
会议后
通报故障结果，跟踪和执行action。
在一个好的复盘里，action一定要落地执行到位，这个我后面也会提到。
受限于篇幅，这里只能对公司里的故障复盘流程做简单介绍。虽然每个公司的复盘流程都不尽相同，但是实施复盘的原则永远都是一样的：
既然已经说到了实操的原则，那么你可能会疑惑：为什么要复盘？
为什么要复盘？
曾子说：“吾日三省吾身：为人谋而不忠乎？与朋友交而不信乎？传不习乎？”
从曾子的角度来看，他认为每天复盘的原因，是为了做更好的自己。
从现代工程师的角度来看，我想需要复盘的原因有如下三点：
第一，复盘可以避免未来的失败
在脑海中失败的越多，才能减少在现实中的失败。
如前文中描述的故障复盘，其实就是从线上故障中寻找原因和解法，进而避免未来再次出现相同的故障。
这种思想在各行各业都是适用的，所谓吃一堑长一智，这几乎是动物的本能。
第二，复盘是成功的催化剂
避免了失败，不代表我们一定会成功。如果想要成功，我们更要时时复盘那些成功案例。从中找出能够让我们走向成功的主要原因，并且想方设法加强这个主要原因。
比如，我们对自己的能力进行分析、找到自己的优势，或者在商业上我们会对公司的优势进行分析，这个时候，我们就需要复盘自己的过去，找到促使自己成功的主要原因，然后设法放大这个主要原因。
第三，复盘产生新知，新知可以传承
复盘要求我们从全局视角去重新审视已经发生的事件。
在切换视角之后，即便是同一件事情也可以从中看到不同的内容，所以说复盘是一个重新学习（relearn）的过程。
在这个过程中，我们会从未知走向已知（这句话未来我可能会反复提起很多遍，就和下面的图一样），发现自己之前不曾关注的信息、知识甚至规律，梳理出更加体系化的知识和智慧。
在一个具体的领域中，这些知识和智慧就是这个领域当中的经验。而知识和智慧可以传承，无论对于个人还是组织，都是一笔无形的财富。
比如，我们曾经处理过金额单位转换错误（比如，把100分当成100元），引发的线上资损问题。
复盘下来我们才意识到——原来有些国家货币的最小单位是元而不是分，如日元，越南盾等等。进一步分析，我们发现就算是同一种币种的金额，其单位在不同系统的接口上的定义也是不同的。另外，不同国家的币种之间也会因为汇率转换而出现舍入误差。最后，作为整个复盘的结果，我们产出了一套标准的金额处理方法在团队里推广，这就避免了相同的问题在未来再次出现。
可以看到，这样体系化的知识，如果不跳出自己的固定视角去分析，在事后予以梳理和重新学习，在当时是很难发现的——这就是所谓的“当局者迷，旁观者清”。
而且，在故障复盘之后，我们会保存复盘报告，这既是一种归档，也是一种知识的传承，方便后来者查阅学习、避免重复犯错。
值得一提的是，我们常说那些的歇后语，本质上就是前人在复盘之后的智慧传承。
既然复盘这么重要，那么怎么复盘才是正确的姿势呢？
如何复盘？
首先，从复盘材料的来源看，复盘有两种方式。
-
第一种，复盘自己的经历。
-
第二种，复盘别人的经历。
第一种方式-复盘自己的经历。概括下来，就是“我当时为何要这样做？做对了还是做错了？如果重来一遍，有无更好的做法？”
复盘自己的经历，好处是自己是当事人，体验了切肤之痛之后，可以做到尽可能的场景还原，而且复盘过程相对私人化，更能对症下药。当然，自我复盘的坏处也很明显——自己复盘自己的经历，可能结果会非常主观，也有可能“不识庐山真面目”。
第二种方式-复盘别人的经历。概括下来，就是“他当时为何要那样做？做对了还是做错了？如果重来一遍，有无更好的做法？”
复盘别人的经历，则可能只能看到表面的部分，很难完全还原当时的场景，更难感同身受，这样的复盘收获只能作为一种参考。但是，无论如何我们都要感谢那些乐于分享自己经历的人。从某种意义上来说，他们是人类智慧的传承者（所以看完本文应该做什么呢？）。
其次，关于复盘的内容，可以是成功的经历，也可以是失败的经历。
复盘的目的无非有二：学习成功者如何成功，学习失败者如何失败。
比如，前文故事中的故障复盘，其实就是在复盘失败的经历，避免下次出现同样的错误。而阅读成功者的传记，则是在复盘别人成功的经历，希望能够学习成功者的处事方式。
再次，从复盘的过程来看，信息的全面性、客观性非常重要。
为了能够对整个事件有全面的把握，我们要把事件的始末梳理清楚，我们要尽可能地还原出每个人在事件中的所思所想和行动。
当然，聪明的你肯定想到了，在人性使然下众人必然各执一词，所以绝对的客观绝对不是一件简单的事情，但是再难也得想办法去接近真相。
比如，在故障复盘中，我们需要把故障的前因后果分析清楚，把故障中每个人的关键动作记录在案，几乎是以福尔摩斯的抽丝剥茧，产出故障报告。
这样，在实际复盘的时候，我们才能确保不同角色的人对故障的过程理解一致，才能知道如何改进，不会因为信息不完整而做出错误的判断。
此外，复盘人数可以是一个人也可以是多人。
一个人复盘不难理解，毕竟有些事情只能一个人在心里慢慢复盘。
但是多人复盘却能够避免盲区，集思广益。
当然，无论一人复盘还是多人复盘，都要强迫自己从当局者变成旁观者，唯其如此，才能看到问题的本质。
最后，复盘一定要有指导未来的结果。
复盘不是空想和空谈，不能因为盘过了就抛之脑后，浪费了大量的时间，还不如不盘。
复盘之后，一定要有可以执行的动作，一定要有改进措施，最重要的是把这些措施执行下去。
只有把复盘得到知识用于实践，我们才不会被同一个石头绊倒两次。
何时复盘？
对于重大事件，比如故事中故障复盘，最好的复盘时间是故障发生后的一周之内，此时人们对事件的记忆还比较清晰，复盘效果最好。
对于日常生活来说，每天复盘实在过于频繁，我们能够做到一周一次小复盘，一个月一次大复盘即可。
另外，个人复盘的内容，可以通过日记或者周记保存，便于后续查阅。
复盘的关键点
无论复盘的具体形式是怎样的，都必须遵循如下四个关键点：
第一，复盘最怕肤浅
既然是复盘，那就要想方设法弄清楚所复盘事件的前后因果，找到驱动整个事件的“底层逻辑”，要有一定的思考深度。
如果复盘只是简单的走个过场，流于表面，把复盘报告（日记）拿出来照着念一遍，那还不如不复盘，不要浪费大家的时间。
第二，复盘不是追责
复盘盘的是事情的始末源委，盘事情的目的是为了未来把事情做好，而不是为了给哪个人定责。
如果抱着追责的心态去复盘，那复盘的过程就成了走过场，复盘场也就变成了修罗场。
最可怕的是，在对立情绪之下，复盘的结果必然也是扭曲的，那还不如不复盘。
如果要做复盘，请把“自我”抽离出去，谦虚一点，像一个局外人一样冷眼旁观正在复盘的事情。
第三，复盘之后一定要有行动
既然复盘是面向未来的，那么复盘之后，除了有最痛的领悟之外，一定要有行动。
若没有行动，只是在脑子里想想、嘴上说说，那怕你想出来的内容再华丽，说出来的再浮夸，也是没有意义的，因为你只想不做。而没做之前，你想的可能都是错的！
现在，很多人（包括我自己）都在说：“让我们复盘一下吧”。其实这是不对的，复盘本身不是目的，由复盘产生行动、由行动产生我们想要的结果，这才是“复盘”的目的。
一句话，复盘的目的，是为了行动；行动之后，不要忘了复盘。
第四，失败要复盘，成功更要复盘
我们在工作当中，更多的是复盘故障和失败，从来没有复盘过成功。
事实上，无论是成功还是失败，都只是一个事件。
如果是事件，那么都可以拿来复盘。尤其，很多成功的案例反倒更值得我们去复盘。
为什么？
因为成功会让我们忘乎所以，以为自己无所不能。而只有复盘之后，我们才能知道，我们的这次成功是出于运气还是实力。
如果是出于运气，那么有哪些是运气的成分？如果这些成分没了，我还能成功吗？我该如何避免这种不确定性？
如果是出于实力，具体这个实力又体现在哪几方面？我能继续把这些实力优势发挥下去吗？
可以看到，复盘失败和复盘成功一样重要，我们不应该对此有差别心。
其他行业的复盘工具
复盘并不是互联网公司首创的，每个行业都有它的复盘方法论，这里仅列举三个例子：
第一，在我国的航天领域有所谓的“归零”，这其实就是一种复盘。
第二，军队在执行任务之后，会写任务后的报告（AAR，after action report），这也是一种复盘。
第三，丰田公司的精益制造中，对问题的愿意有一个5-WHY的询问过程（会在根因思维里着重介绍），这其实是一种复盘的方法。
“狼人杀”谜底揭晓！
如果你耐着性子看到了这里，那么我想你一定想知道文章开头故事中的故障定责到底定给了谁？
现在就让我们揭晓答案。
首先，这个故障最终还是定给了故障当事人。
好的一面是，在当事人老板的斡旋之下，故障等级降了一档，这就意味着当事人从“一年白干”变成了“半年白干”。同时，当事人老板的团队绩效也没有受到影响。
遗憾的是，半年之后当事人还是转岗了。
其次，测试妹子并没有在这次复盘中获罪。
后来她的表现还算不错。然而，出于公司每年强制绩效的要求（你的团队里总有一个人是末位），她的老板在之后的故障复盘里让另一个人“顶”了罪。
总的来说，这样的结局算不上happy ending也算不上bad ending，甚至都算不上是个真正意义上的结局——复盘结束的之后，他们的生活也并没有因这次复盘而走向ending（结束）。
毕竟，复盘之后，他们的生活才刚刚开始，而跌宕起伏才是生活的真实面貌。
在这样跌宕起伏的人生历程里，一个小小的故障又算得了什么呢？
本章小结
本文介绍了“三省吾身”的复盘思维，解释了为何要复盘、如何复盘以及复盘的关键点。
学习复盘思维相当于给自己装上了助推器，让你能够从容应对生活和工作中的各种起伏颠簸。
同时，如果你能够在某个领域里全面践行复盘思维，并且坚持把复盘的“知”变为复盘的“行”，相信过不了多久，你就会成为这个领域中屈指可数的专家。
以上，就是我所知道的“复盘思维”的全部内容，希望对你有用。
(本章完，版权归作者王晓辰所有，若要转载，请标明出处)
作者简介
王晓辰，软件研发工程师，8年+金融科技从业者，文字价值和文字理想的信仰者和践行者，公众号“架构师的白日梦”的作者。
他坚信用心写就的文字具有无穷的能量，可以穿越时空的阻隔，向读者传达最纯粹的经历、最质朴体悟以及最深邃的思索，最终完成思想的启迪和灵魂的交流。
架构创造未来，文字打败时间！
“吾日三省吾身：
为人谋而不忠乎？
与朋友交而不信乎？
传不习乎？”
《论语·学而》
复盘会上的“狼人杀”
会议室里静悄悄的，人们围坐在方桌前，大家一言不发。
除了摆放在面前苹果电脑之外，会议室里的这群人还分享着另一个共同点——他们的表情都异常凝重，凝重到他们头顶的空气都要凝固了。
在一个互联网公司里，出现这样的场面并不奇怪，毕竟现在他们开的是一个故障复盘会——或者，你也可以把它叫做互联网人的修罗场。
实际上，这次会议要复盘的故障，早在前一周就已经发生、发现并且解决了。但是，因为最近一段时间故障实在是太多了，大家实在分身乏术，所以对这个故障的复盘和定责迟迟没有完成。
只要故障定责没有完成，对于某些人来说，悬在心头的那块巨石就不会落地。因为一旦背上故障，这一年就约定于白干了。所以，虽然现在大家现在都一言不发，但是大家心里很清楚，此次会议的结论事关重大。
毕竟，没有那个打工人愿意白干一年，或是一年白干。
在展开这个故事之前，不妨让我们看看都有哪些人在参加这个会议。
首先，那个看上去神情疲惫、眼圈深陷的家伙，当然就是这次故障的当事人了。
事实上，在故障发生到现在的这段时间里，当事人一直都在惶恐中组织应急，连一个整觉都没有睡过。甚至，就连现在投在电视上的故障复盘报告里的绝大多数内容，都是他昨天熬夜写的——写这份报告本应该是复盘组织者——故障管理小组的职责，但是最近发生的故障实在太多了，故障管理小组的同事已经忙不过来了，于是他们把这个苦差事借着当事人的愧疚之情推给了他。
墙倒众人推，不管从哪个方面来看，故障当事人已经把自己送上了绝路——这一年他可能要白干了。
实际上，这次捅出这么个天大的篓子，当事人从一开始就已经放弃了治疗，能够坚持到现在把故障处理完，凭的是他已经残存不多的职业道德。至于之后怎么样？是一年白干？还是以后都不用干了？这件事情他不是不想思考，而是压根就没有时间思考——他已经被榨干了。
在故障当事人身旁正襟危坐的那个人，便是当事人的老板。
虽然表情同样凝重，但在当事人老板的眼神中却丝毫看不出一点慌乱，甚至在他那凝重的脸上反而透露着一丝的不耐烦——好像他早就知道结果所以不想在这里浪费时间了似的。
当事人的老板，少说也有七八年了的工龄了。他不是第一次参加此类故障复盘会议，对这种会议里的的各种明规则和潜规则早已经烂熟于心。
关于本次的这个故障，虽然当事人是自己团队的人，但是他一点都不可怜当事人，因为他早就想把这个做事毛手毛脚的当事人给汰换掉了。但是从团队的角度出发，他知道背上这么一个严重的故障对他和他的团队意味着什么——很可能让大家一年都白干了——而这，绝对是他无法接受的。
所以，就在复盘会议的前两天，他就已经早早动手了——他私下找各方老板沟通了一遍。也许他早就拿到了自己想要的结果——要么把故障等级降低，要么干脆把故障甩给别人。也许他已经找到了战略同盟，一会儿为了定责开撕的时候，不至于让自己落单成为众矢之的——反正，完全背这个故障，在他的列表里没有、也不可能有这个选项。
再往当事人老板的旁边看，便是产品经理。
就在刚才，在产品经理收到他同事的消息的时候，他那满脸的愁容就已经一扫而光了。消息上说：“我们的没问题，我们的prd（产品文档设计）上描述得很清楚。”
从设计文档、测试文档、产品文档、业务文档等各种文档中找寻证据，证明自己与这个故障没有关系，是故障定责时的惯用招数。现在产品经理知道自己手握关键证据。有这么一张大牌，这个故障的责任怎么着也不会落到他的头上。
产品经理抬头环视会议室里的其他人，看到的是千篇一律的凝重表情。真是幽默啊，他在心中窃喜。是的，目前整个会议室里没有谁能比他更轻松了，他把眼前的苹果电脑一合，把椅子往后一推，身体展开舒服地斜躺在椅子里。
下一秒，这个产品经理已经变成了与世无争的吃瓜群众。
和产品经理形成巨大反差的，是坐在产品经理旁的测试妹子和她的老板。
从来没有见过这样的阵仗，刚刚毕业的测试妹子被吓到了，她连大气都不敢出，连头也不敢抬。
测试妹子连做梦也没有想到，自己入职的第一个重大项目，竟是以线上故障的方式收场的，而导致那个故障的问题，现在看来实在是太低级、太不应该了，但是当时她确实没有测试出来。
现在她即懊恼又害怕。
懊恼，是因为自己的大意、明明是可以测出来的，她在心里埋怨自己。
害怕，则是因为在入职培训的时候，她知道公司对线上故障的零容忍态度——学生时代分数思维未脱的她，怕自己在年终拿到一个不好的绩效，然后被赶走。
老实说，她真的很喜欢这份工作。
反观她的老板，虽然此时一样脸色凝重，但在他的头脑里，正盘算着着一个完全不同的抉择——他正在为今年的最差绩效的人选而发愁。
现在机会来了，要不要抓住呢？要不要让测试妹子“一年都白干了”呢？
善恶交织的念想让刚成为小组长不久的他纠结不已。公允来说，测试妹子的能力和潜力并不算差，让她背锅她可能真的就离职了，着实有点可惜和不公。但是，他又怕后面不再有这样顺理成章的机会了——要知道一个团队的绩效可不是那么好打的，这几年他可听了不少因为绩效反目成仇的故事。另外，如果他主动把这个故障揽下来，今年团队的故障指标就会用掉一个，后面如果再来一个故障的话可不好受……
to be or not to be，这一直都是一个问题。
就这样，互联网公司里一次典型的故障复盘会，就在这样近乎同床异梦的情况下展开了。
如果你没有参加过大厂的故障复盘会，那么很可能你会怀疑这个故事的真实性。
这真的大可不必，我会告诉你艺术源于生活。
而且，根据我长期观察，故障复盘可以说是大家最讨厌同时又最喜欢的一种会议形式。
换言之，故障复盘会不单单是一个修罗场，有时候它还是一个秀场。
甚至，当两拨人撕到上头的地方，会让实际搞出故障的那个人产生一种“你们吵得这么嗨，这故障好像和我没什么关系”的错觉。
在曾经的几次故障复盘会上，看着大家撕来撕去，我不禁感叹，这个复盘过程本身就需要来一次复盘。
对了，我想你一定很好奇故事里这个故障的责任最后定给了谁。
这里姑且先让我卖个关子，在揭晓谜底之前，不妨让我们先看一下到底什么是复盘？
什么是复盘？
复盘，首先是一个围棋概念。在围棋中，复盘也称 “复局”。
指对局完毕后，棋手复演这盘棋的记录，以检查对局中双方招法的优劣与得失关键。
用人话来说，就是在复盘的过程中，棋手需要分析关键步骤。此时他们需要会站在旁观者的视角提问：“我为什么要这样走？有没有更好的走法？对手为什么要那样走？有没有更好的走法？”。
通过这种方式，棋手可以加深对这局对弈的印象，找出双方攻守的漏洞，提高自己的博弈水平。
在工作和生活中，我们常说的复盘，就是把已经发生的事情，同当事人一起重新梳理和推演，找到事情何以至此的原因，并在未来予以优化或者避免。
用更概括的语言来说，复盘的过程，是把自己从当局者变成旁观者，从整体上检视并反思已经发生的事件，并对未来提供指导的过程。
例子：公司里的故障复盘会
现实中，我们的故障复盘流程是这样的：
会议前
主持人向故障当事人收集材料，编写故障复盘报告。故障复盘报告的内容组织一般按照故障发生的时间线的方式展开。
会议中
1 主持人以时间线的方式介绍整个故障的过程，包含但不限于：
-
故障的时间：这个故障是什么时候引入的，什么时候发现的，什么时候恢复的
-
故障的原因：引起故障的原因，一般有技术原因和管理原因
-
人的因素：谁在什么时候做了什么决策，谁又去执行了什么操作，执行结果是什么？
2 分析故障的根因
以时间线展开，分析在每个关键节点上，我们的决策和执行是否正确？是否有更好的解决方？这个环节需要研发、测试、产品等各方的共同参与，以便不同的视角对问题进行分析，力求全面和细致。
3 提出避免相同故障再次出现的解决方案
更具不同的角度，一般会有多个可以落地执行的action，并指定执行人和action的完成时间。
4 故障定责
这一步，简单来说是为了杀一儆百。在技术层面来看，这一步可能是最不重要的。但在政治层面一旦涉及到谁要白干一年，就是另一个回事儿了。从过往的经验来看，在故障非常重大、各方没有达成一致的时候，这一步反而是最花时间的。
会议后
通报故障结果，跟踪和执行action。
在一个好的复盘里，action一定要落地执行到位，这个我后面也会提到。
受限于篇幅，这里只能对公司里的故障复盘流程做简单介绍。虽然每个公司的复盘流程都不尽相同，但是实施复盘的原则永远都是一样的：
既然已经说到了实操的原则，那么你可能会疑惑：为什么要复盘？
为什么要复盘？
曾子说：“吾日三省吾身：为人谋而不忠乎？与朋友交而不信乎？传不习乎？”
从曾子的角度来看，他认为每天复盘的原因，是为了做更好的自己。
从现代工程师的角度来看，我想需要复盘的原因有如下三点：
第一，复盘可以避免未来的失败
在脑海中失败的越多，才能减少在现实中的失败。
如前文中描述的故障复盘，其实就是从线上故障中寻找原因和解法，进而避免未来再次出现相同的故障。
这种思想在各行各业都是适用的，所谓吃一堑长一智，这几乎是动物的本能。
第二，复盘是成功的催化剂
