项目中遇到严重问题，如何快速定位和进行问题复盘【管理有度10】
文摘
其他
2025-01-25 10:33
河北
作为项目经理，经常会面临各种各样的复盘，项目阶段复盘，项目结束复盘，迭代复盘，线上问题复盘等等，拿到一个复盘的任务，我要从哪里开始着手？如何复盘才能起到效果，才能找到问题的根本原因，才能避免将来犯同样的错误？作为一个奋战在项目管理一线的经理，对复盘这件事情总结了一些经验，想要分享给你。
所有的分析都是建立在准确的事实还原的基础之上的。我们非常容易犯的错误是，一上来就开始讲问题，讲原因，讲措施，讲着讲着会发现，原来我们的问题还没搞明白，显然这就是没有把还原事实这件事情做到位。原计划5月14日晚8点进行安排发布的功能，由于下午16:30开发环境测试发现依赖中台的功能出现问题，日期组建下拉框超出组建高度，无法完全展示。16:40 查看弹框组建，日期组建配置，未发现配置错误18:06 XX开发人员A升级乐高组建，将vc-deep版本由2.1.12-->2.2.1，问题仍未修复21:30 再次在旧项目中创建中台项目，vc-deep升级，功能正常显示
旧项目中vc-deep版本低于2.1.2，该版本未支持“内部浮层定位”功能，组建展示不完全18:22升级至2.2.1版本后问题仍未修复，于第二日自然修复，原因不能完全确定和vc-deep版本有关从上面这个事件经过的描述，和最终结论的得出可以看出，这就变成了一个“无头悬案”，其实根本不是什么无头悬案，只是因为分析人，没有对事件的经过认真还原。同一个案例，纠正了还原事实的过程后，可以清晰的看出问题在哪里。16:30 应用端测试A发现组件异常，反馈给应用端开发B19:07 XX开发D于18:09进行了升级，由于发现组件异常，进行了重新打包升级，vc-deep从2.1.12-->2.2.1版本，但是问题未修复，XX开发D持续跟进中。21:30 中台开发C反馈，vc-deep的2.1.2版本中增加Dialog弹框组建“内部浮层定位设置”，修复了组建展示不完全的问题，2.1.2之前的版本均存在弹框内展示不全的bug。22:08 中台反馈无发布，但是当天此问题仍然没有被修复，决定推迟发布。14:12 XX开发D回应2.2.1版本存在bug，目前已修复，升级为2.2.2版本可修复；得出结论：可以看出，当天应用端测试出组件问题，但中台合作方XX组件升级后问题依然未修复，影响了当天应用端的按期发布。只有一个严谨的事实还原，才能准确定位到问题，才能在后续复盘中得出有价值的改进意见。5WHY分析法
复盘的时候，这个5WHY分析法就很好用。什么叫5WHY法，从名字上的意思可以理解为连续问5个为什么，直到找到问题的根本原因的一种分析方法。但是其实这里的5个WHY，并不是指5个为什么，而是指追问多个为什么，必须时需要5个为什么，也有些时候2个为什么就可以找到答案，但有的时候5个为什么还不够，5WHY的本质其实是希望层层递进的追问，来找到问题的根本原因。常见问题的追问技巧
除了要学会5WHY分析法，我们还需要了解不同的问题应当如何进行追问。我在历史复盘的过程中遇到最多的就是以下这些问题。我们来看看这些问题，我们往往如何来展开追问。用户使用问题
看到这个问题的归类，研发团队的潜台词就是“这个明显跟开发无关啊，是用户不会用而已”，当我们说出这句话的时候，你会想到什么？把问题推给别人，当然可以减轻自己的压力，但是很显然，这样我们自身就无法得到提升了。- 功能的使用频率有多高这些问题决定直接决定者，我们是否需要优化这个功能，以及优化这个功能的紧急程度。
历史遗留问题
开发很多时候会把问题定位为历史遗留问题，好像只要定位为了历史遗留问题，这个问题就应该与自己无关，就卸下了沉重的包袱。面对这种情况，作为负责复盘的人应该如何进行追问呢？是从何时遗留下来的我们在得出结论时，我们先要了解事实以及具体的细节，细节是魔鬼，我们从细节中才可以发现我们的结论是否正确。 一直没有被触发有一些历史遗留问题，是因为解决成本高，对实际用户影响小，属于已知未解决问题；也有一些，需要在特殊的场景下才会触发，发布至今一直未被触发；也有一些历史遗留问题，是用户量增加，历史代码的性能问题被暴露出来了；除了以上三类，还有一类就是本质上并不属于历史遗留问题，是由于新的代码发布，导致过去的一些并不健壮的代码问题暴露出来了，触发的本质还是近期发布的代码引发的。 第三方/依赖方问题
软件开发过程中，会涉及到各种各样的第三方，在我做互联网金融项目时，会依赖存管第三方，现在的项目中依赖中台。依赖方出现问题时，应用就会受到影响，这种情况下，我们应该如何复盘。发布问题
发布问题，这是非常常见的一类问题。但是跟发布相关的问题其实非常广，由于发布准备不够充分导致的发布问题，还是由于发布过程引发的问题。发布准备的问题还可以分为，依赖方沟通不到位引起的发布问题，还是由于测试不充分、或者是步骤不准备不充分引起的发布问题。- 如果是发布准备问题，是测试漏测，还是发布步骤准备不充分
- 如果是发布过程问题，发布过程配合问题，还是发布过程没有准寻既定的发布步骤或者
历史数据未订正
历史数据未订正导致的问题，也是屡见不鲜。出现历史数据未订正，至少有两个环节出现了问题，开发未评估到影响面，且测试用例未覆盖。
改进措施需要依据具体的根本原因分析来制定。改进措施的制定需要遵循几个原则：园区初始化时，会涉及到用户既存在线上测试园区账号，正式园区账号，测试园区和正式园区所在的组织不同，不同组织的多园区场景，虽然产品上考虑是支持的，但是历史并不存在这类实际场景，所以有许多场景的考虑并不完备，修复的成本较高。且从产品层面来看，这种场景在很长一段时间内是不会存在的。类似上述案例场景中的问题，修复的成本较高，但是紧急程度较低，如果预留了修复的action，只会占用大家的注意力，无法近期完成修复，这样的改进措施我们会考虑从待办中去掉。
最后，对于线上一些较为严重的问题，我们还制定了一个复盘模板，大家也可以作为参考。![]()
现任国内500强公司PMO，项目管理经验超过10年。---------------------------------------------应广大粉丝要求，我们建立了一个【PMO前沿交流群】，小伙伴们热情踊跃，目前人数已经上万人了，不能直接进群啦，想要进群的添加小编微信，拉你进群。两个添加其一即可！
