你是怎么复盘的，有哪些高效的方法推荐？

　　Step 1 提出问题（Name the Issue）
　　1）给定问题的唯一编号，以便系统记录
　　2）给予问题一个临时的单句描述。这个描述必须使用issue句式。句子结构必须包含出现问题的对象主体、出现问题的现象描述。标准句式为：
　　问题主体 + [问题发生的疑似条件]+ 问题呈现的具体现象
　　（带＂[]＂的可以从缺）
　　如：
　　鸡蛋羹有气泡 / 鸡蛋羹颜色偏白 / 鸡蛋羹缺少足够组织强度 / 鸡蛋羹在高海拔地区恰当加热时间不稳定 / 服务器在无人值守期间频繁自动重启
　　之所以称之为＂临时表述＂、是因为在完成整个过程之前，你很可能并不能正确认识问题的真实性质，从而对issue的实质有错误认知。
　　其中，问题主体不允许为具体个人。
　　例如：
　　张三在总账清结时频繁出现计算错误（错）
　　项目财务助理在总账清结时频繁出现计算错误（对）
　　因此，才有一个绝对的必要给issue一个不表意的编号，以便在issue的描述有所修正时候仍然精确的指向该讨论主题。
　　以下描述没有实际意义，应尽量避免：
　　xxx质量不佳 / xxx感觉不对 / xxx表现不好
　　3）列出问题表现的标本性材料，形成标准样本。
　　这包括但不限于：
　　图片 / 视频 / 录音 / 投诉书 / 采访记录 / 财务记录 / 问题截屏、录屏 等
　　一切使人觉察到该issue的资料和信号都包括在内。
　　这个过程本身就是一个再认识问题的过程。你很可能在观看了这些数据之后发现几种典型的问题——如对问题的描述本身有偏差；该问题实际上是两个问题的复合体。
　　在发现这些问题之后，就需要重新定义问题描述，并基于新的问题描述重新采集问题资料。
　　在进行这一步的时候，要保持这种认识——事实上这个原始标本才是issue的实体，而issue描述只是issue的名字，不要本末倒置。
　　原有的资料和原有的描述要存档并做出日志追踪。
　　以上步骤要反复重复，直到issue识别的完整性、彻底性已经令人满意、相关issue的表述与对应资料均已令人满意的稳定化为止。
　　这里已经着重强调了以＂令人满意＂为边界条件，这是为了防止人出于傲慢而追求＂彻底、全面、绝对正确＂。
　　你要认识到这些理想境界是人类所不能觊觎的，一定要勉强，只会导致继续进展的效率很低，进度不可见。
　　从实践的角度来说，事实上所谓的＂令人满意＂，是指分配给issue naming的时间资源耗尽时你所达到的水平，只要是尽力而为的，就一律在实践上可以被认定为＂令人满意＂的。
　　Step 2 案情重建 （Case Building）
　　一旦issue被初步确定，就要按照与该issue的相关关系，建立该issue从发端到发作的完整时间线。
　　例如，该issue是客户对某交付物的延迟不满。
　　那么该交付物的整个生产过程中的所有流程记录都应该被调取出来，按照时间线排列起来。
　　所有的相关流程负责人、参与者、审核者，都在采集证词的范围之内。
　　所有的相关要素，都要从进入事件到退出事件最完整的描述。
　　着非常像刑事侦查中的案情重建步骤。
　　在这个步骤里，不要去急于考虑到底谁是凶手，也不要去急于考虑什么案情真相。而要专心的以有序的整理罗列全部事实为要。以免对某种假说的过度倾向（over investment）造成证据搜索只为证实该假说而进行，这极易导致错误结论。
　　这其中很可能出现互相矛盾的资料和陈述，使得可能的叙事线分叉成几个不同的版本。那么首先根据物理定律之类的绝对限制排除掉不可能的可能性，同时也要追查造成这些叙事分歧的机制。
　　很多情况下，这些产生叙事分歧的机制本身就是问题所在。
　　在案件调查完成后，很可能会发现问题的表述本身存在偏差，存在再度修正的必要，那么就要及时完成再次修正，并根据修正再次调整问题样本和case building，使得三者互相协调一致。
　　这种对问题本身的反复修正、反复重建，是一个问题的到正确提出的复杂性所在，也是导致绝大多数人在提出问题阶段失败的主要原因。
　　一般人总是一拍脑袋就在样本残缺、案情不全、逻辑不协调的情形下，基于情绪的驱使，按照自己的心理焦虑的迫切需要来定义问题。
　　从这第一步就已经踏入逻辑地狱，从此只会造成极端不公的结论和破坏性的后果——其实就是在冤枉人，还把对方不愿受冤枉的表现视为＂抵赖＂。
　　那注定是没有好结果的。
　　Step 3 方案探讨 （Solution Forging）
　　方案探讨包含几个标准程序——
　　首先，要对该问题进行估价。
　　如果是有生命周期的问题——例如仅仅会在当前项目中出现、而当前项目是一个非经常性项目——那么按照它发生的概率、造成的损失、可能出现的时间和场合区域，为它预估一个总价。
　　这个总价定义了为了解决它而可以投入的资源上限。
　　要注意，为了识别和整理问题而付出的成本，已经在从这个上限中支出，你事实上只能用剩下的余额作为解决问题的本钱，而一般来说你还需要在其中留出合理的利润空间。
　　剩下的钱可能都不够你召集相关人开会用的——开会是非常贵的。
　　不错，这里一样有盈利要求。
　　这一考量意味着一个明显的原则——不是所有问题都需要或者值得解决，有一些问题你可以直接接受。
　　而面对这个状况，你也可以选择重新提炼问题，将问题的定性泛化，从而使得它成为一个在永续经营中会高频出现的问题。
　　比如——＂鸡蛋羹的组织强度不稳定＂这个问题，如果你只打算吃一次鸡蛋羹而已，就没有必要投入资源解决。
　　但是它可以通过表述为＂食物口感控制的系统方法在热成型布丁类应用中不可靠＂而成为一个适用于一切热成型布丁类场景下都适用的问题，从而一下把支出科目从＂项目备用金＂科目转移到＂战略研究基金＂科目下。前者不过是十几二十万而已、其价值主张要在项目收入中表现，而后者却可以到千万、亿级别，其价值在公司股价中表现。
　　你的预算会充足得多。
　　看明白了吗？
　　这是＂提出问题的艺术＂的一个典型的范例。
　　再确定问题预算之后，有以下几种经典的任务小组（task force）的组建方案：
　　a）仅纳入（involve）绝对必要的专家和决策层进行闭门讨论。
　　这个方案效率最高、也是最推荐、最常见的处理方式。
　　b）以彻底解决问题为导向，纳入全部必要的专家和决策层进行闭门讨论。
　　这个方案成本较高，不仅仅是单位时间消耗的成本增加，因为人数更多，讨论秩序更难维持，事实上还会花费更多时间。它比方案A的成本往往大8-10倍。
　　采用这个方式讨论的问题，一般是会导致经营战略被修正的重大问题。
　　c）以根绝问题为导向，纳入全部必要专家和决策层进行公开讨论。
　　因为围观人员的时间并不需要现场同步，可以通过邮件组、内部论坛或者直播录像等方法异步的关注，所以这个方案的直接成本与方案B在同一数量级。
　　但这种讨论方式会造成巨大的组织影响，其决议有不可置疑的权威性和执行力度。
　　采用这个级别的手段应对的问题，往往会涉及到到企业伦理、企业文化、企业基本规章制度的修正。
　　在上述的各个方案中，都可以考虑加入一两名见习性质的后备人员参与，以作为人才梯队培养的制度安排。
　　现场观察ta们提出问题、发现相关性、探索问题内涵与外延、提出创造性方案、平衡成本、效率与风险的思维能力以及面对质疑、表达意见、和提出建议、说服不同意见等等态度和技术的表现，是决定其升黜的核心根据之一。
　　在确定任务小组的构成与讨论方式后，举行会议对问题进行讨论。
　　如果不是紧急的问题，这个讨论可以通过留言讨论方式异步的进行，以节约成本。
　　如果是紧急的问题，则适合采用线上线下会议的形式。
　　在这里，有必要明确解决方案的定义。
　　所谓的解决方案，指且仅指组织规则的更新。
　　这包括但不限于以下典型的文件：
　　企业章程（含股东构成表）、企业奖惩条例、工艺流程、工艺规范、培训手册、招聘标准、选拔流程、选拔标准、术语定义、愿景、战略规划、年度计划、月度计划、组织架构、岗位职责定义……等等。
　　简单来说，所谓的解决方案，就是＂我们的哪一份文件的哪一部分需要修改/增补成什么样子＂的答案。
　　它应该被表述为这个形式，也应该围绕这个中心被讨论。它的要害在于字斟句酌，会有大量的＂这么说好还是那么说好＂和＂要不要增加一段额外说明＂这样以文本为中心的时间投入，而不是在围绕＂我们要怎么办＂这样一个事实上没有严格共识的虚幻目标浪费时间。
　　组织的本质，不是组织的行为、也不是组织的人员组合，也不是组织的财产和地点，这些都只是组织的外皮、表象。
　　组织的本质，是组织的规则。
　　规则就是组织真正的实体，是它的本体，是它的肉体本身。
　　在规则条文的背后所集中体现出来的那个总的原则、目的和纲领，则是它的灵魂。
　　一个组织，其实是可以一个办公场地都没有、一文钱也没有，甚至一个成员也没有的，甚至可以没有称呼。
　　这就好像你在银行数据库里创建了一个银行账户，它已经存在，但它的持有人一栏是空的、交易记录是空的、余额也是空的、名称也是空的、甚至序列号也是空的，但那些都是这个账户的身外之物，不是这个账户的本质。
　　这个账户的本质，是这个账户所适用的一切数据库规则的总和。你是创造了一个可以执行一切这些规则的entity，只是它还没有名字、没有各种待填充的值，那些并不真正影响它的实在性。
　　换句话来说，增强一个组织，就是推动它的规则自洽化、与其目的的一致化和与环境的兼容化、与挑战的适应化。
　　所谓的组织强化，就是指这个组织规则的四化建设。
　　时刻如此，永远如此。
　　换句话说，任何一种事件，无论其是具体的带来利润还损失利润，如果没有导致组织的规则文本的增加或者修改，对于组织成员而言或者意义重大，但对于＂组织＂这一实体自身而言，毫无意义。
　　组织成员只是那个流水的兵，组织是那个＂铁打的营盘＂。
　　站在组织的角度，经验和教训只有在形成一些文本的意义上才是存在的。如果你们开了两周会议，没有形成任何文本（包含其解释的文本），那么不管你们自觉得多么心情舒畅、信心十足，在最终意义上都是没有意义的。
　　因为将来你们不会记得，这个组织的后续成员不会继承，最终它会像没有发生过一样。
　　所以，再强调一遍——一切的改进方案，都必须以＂如何修订我们的规则文档＂为中心和唯一形式来进行。
　　否则你是在浪费所有人的时间。
　　更重要的是，你在浪费苦难本身。
　　在确立了以修改规则为中心的探讨原则之后，很自然的会导致一个自然而然的结论——关于复盘的讨论，不涉及个人的奖惩判决。