24 开发中的问题一再出现，应该怎么办？
background
同样的线上故障反复出现，类似饿big在不通的地方一再惹祸，能力强的同学每天就是在”灭火”中消耗人生
解决方案：
复盘
对奕者下完一盘棋，重新把对弈过程摆一边看看哪些地方下得好，哪些下的不好，哪些地方可以有不同甚至是更好的下法等。
这种把过程还原，进行研讨与分析的方式，就是复盘。
主要的优点：
客体化
俗话说，我们进行软件开发的例子，在解决问题的时候，我们的注意力更多在解决问题本身上，而很少会想到这个问题怎么引发的。
当你复盘时，你会站在另外一个视角，去思考引起这个问题的原因，这个时候，你不再是当事者，而变成旁观者/你观察原来哪件事的发生过程，就好像别人在做一样。你由一个主观的视角变成一个客观的视角。
用别人的视角看问题，这就是客体化。
回顾会议
常用的分为三类：
做的好的，做的欠佳的，问题或建议
一个是写事实，不要写感受
因为事实就是明摆在哪里的东西，而感受无法衡量，你感觉好的东西，也许比尔呢感觉很糟糕。
每张便签只写一条，因为后面我要对便签归类
做的好的，需要继续保持。我们的主要目的是改善和提升，我们的重点在于解决做得不好的部分和有问题出现的地方。
每个人可以三票，投给自己认为重要的主题，每个人需要在诸多内容中作出取舍，你如果认为哪一项极其重要，可以把所有的票投给这个主题。
选出自己认为最重要的几项。因为我们不会无限制的开会，只有最重要的几个主题才会得到讨论。我们根据优先级的概念，主题的顺序，一个一个地进行讨论。
如何解决一个问题
1.解决一个问题，我们回先关注现状。
让反馈意见的人稍微详细地介绍他看到的现象。 例如： 最近的bug比较多，相比于上一个开发周期，bug增加了50%。
2.分析原因
有人会说，最近的任务很重，没有时间写测试
3.尝试找到一个解决方案，给出行动项。
例如：任务重。我们可以让项目经理更有效的控制一下需求的输入，再把非必要的需求减少一下。
测试被忽略,我们需要把测试覆盖率加入构建脚本，当测试覆盖率不足时，就不允许提交代码。
所有的行动项应该是可检查的，而不是一些无法验证的内容。
例如： 如果行动项是让每个程序员都“更仔细一些”，这是做不到的，因为“仔细”这件事很主观，你说程序员不仔细，程序员说我仔细了，这就是这扯皮的开始。
列好了一个个的行动项，接下来就是找负责人，负责人要对行动项负责。
项目经理负责需求控制，
技术负责人将覆盖率加入构建脚本。
有了负责人，我们可以保保障这项目不是一个无头公案。下一次做回顾的时候，我们就可以拿着一个个的检查询问负责人任务的完成情况了。
分析问题，找到根因都是重要的一环
你的团队如果能一下啊洞见到根本原因固然好，如果不能，那么对好多问几个为什么。 5个为什么（why）
因为最初的提问，你能得到只是表面的原因，只有多问几个为什么，你才有可能找到根本原因。
例子： 服务器经常返回504，那我们可以采用“5”个为什么“的方式来问一下。
1.为什么会出现504 呢？因为服务器处理时间比较长，超时了。
2.为什么会超时？ 因为服务器查询被后面的redis卡住了
3.为什么访问redis会卡住了？因为另外一个恒心redis的服务删除了大批量的数据，然后，重新插入，服务器阻塞了。
4.为什么他要大批量的删除数据重新插入呢？因为更新算法设计的不合理
5.为什么一个设计的不合理的算法就能上线呢？因为这个设计没有按照流程进行评审。
问到这里，你就发现问题的根本原因了：设计没有经过评审，找到了问题的原因，解决之道自然就浮出了水面。一个核心的算法一定要经过相关人员的评审。
所以 ”5个为什么“中的 ”5“只是一个参考数字，不是目标
有一点注意的是。问题顺着一条主线追问，不能问5个无关的问题。
无论是“回顾会议”也好，“5个为什么”也罢，其中最需要注意的点在于，不要用这些方法责备某个人，我们的目标想要解决问题，不断的改进，而不是针对某个人发起情感批判。
定期复盘，找到问题根因，不断改善，
改进：
两周一次复盘，
来自，1.身体健康（运动，饮食，睡眠，冥想）好的身体才是一切动力来源
2.来自认知和学习（像通过极客时间专栏的学习，对认知的提升，还有英语的学习和技术的学习）
3.工作生活 （对前一天的总结，并且提炼出成就事件和需要改进的方面）
生活嘛（就是学会享受生活）
4.关系心里（如何自我相处，如何和他人相处，如何维持好的人际关系）
5.理财（理财只是方面的学习和一些理财的实践）
首先，先对比实际结果和期初所定目标有什么差距，其次，情景再现，回顾项目的几个阶段。然后，对那个阶段进行得失分析，找出问题原因。最后，总结规律，化作自己技能沉淀，再次遇到是可以规避，
重要的事
复盘资料应该记录到知识库，无论新来的或是接手的人，都能从中获益，从而提升组织的能力。
