【管理有度10】项目中遇到严重问题如何快速定位和进行问题复盘

2022-12-0708:46:04DevOps评论1,666字数 3170阅读10分34秒阅读模式

作为项目经理，经常会面临各种各样的复盘，项目阶段复盘，项目结束复盘，迭代复盘，线上问题复盘等等，拿到一个复盘的任务，我要从哪里开始着手？如何复盘才能起到效果，才能找到问题的根本原因，才能避免将来犯同样的错误？作为一个奋战在项目管理一线的经理，对复盘这件事情总结了一些经验，想要分享给你。

作为项目经理，经常会面临各种各样的复盘，项目阶段复盘，项目结束复盘，迭代复盘，线上问题复盘等等，拿到一个复盘的任务，我要从哪里开始着手？

如何复盘才能起到效果，才能找到问题的根本原因，才能避免将来犯同样的错误？

作为一个奋战在项目管理一线的经理，对复盘这件事情总结了一些经验，想要分享给你。

还原事实

所有的分析都是建立在准确的事实还原的基础之上的。我们非常容易犯的错误是，一上来就开始讲问题，讲原因，讲措施，讲着讲着会发现，原来我们的问题还没搞明白，显然这就是没有把还原事实这件事情做到位。

案例场景

事件描述：

原计划5月14日晚8点进行安排发布的功能，由于下午16:30开发环境测试发现依赖中台的功能出现问题，日期组建下拉框超出组建高度，无法完全展示。

事件经过：

16:40 查看弹框组建，日期组建配置，未发现配置错误

17:00 XX技术支持及开发介入排查

18:06 XX开发人员A升级乐高组建，将vc-deep版本由2.1.12-->2.2.1，问题仍未修复

20:40 在旧项目中创建页面，表现同样问题

21:00 在新项目中创建页面，功能正常。

21:30 再次在旧项目中创建中台项目，vc-deep升级，功能正常显示

得出结论：

旧项目中vc-deep版本低于2.1.2，该版本未支持“内部浮层定位”功能，组建展示不完全18:22升级至2.2.1版本后问题仍未修复，于第二日自然修复，原因不能完全确定和vc-deep版本有关从上面这个事件经过的描述，和最终结论的得出可以看出，这就变成了一个“无头悬案”，其实根本不是什么无头悬案，只是因为分析人，没有对事件的经过认真还原。同一个案例，纠正了还原事实的过程后，可以清晰的看出问题在哪里。

5月14日事件经过：

16:30 应用端测试A发现组件异常，反馈给应用端开发B

16:30 开发B反馈给中台开发C，C开始排查

17:24 开发C联系开发B，给XX服务授权

19: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 中台反馈无发布，但是当天此问题仍然没有被修复，决定推迟发布。

5月15日

14:12 XX开发D回应2.2.1版本存在bug，目前已修复，升级为2.2.2版本可修复；

14:25 开发B升级后，组件显示正常；

得出结论：可以看出，当天应用端测试出组件问题，但中台合作方XX组件升级后问题依然未修复，影响了当天应用端的按期发布。只有一个严谨的事实还原，才能准确定位到问题，才能在后续复盘中得出有价值的改进意见。

根因分析

5WHY分析法

复盘的时候，这个5WHY分析法就很好用。什么叫5WHY法，从名字上的意思可以理解为连续问5个为什么，直到找到问题的根本原因的一种分析方法。但是其实这里的5个WHY，并不是指5个为什么，而是指追问多个为什么，必须时需要5个为什么，也有些时候2个为什么就可以找到答案，但有的时候5个为什么还不够，5WHY的本质其实是希望层层递进的追问，来找到问题的根本原因。

常见问题的追问技巧

除了要学会5WHY分析法，我们还需要了解不同的问题应当如何进行追问。我在历史复盘的过程中遇到最多的就是以下这些问题。我们来看看这些问题，我们往往如何来展开追问。

用户使用问题

看到这个问题的归类，研发团队的潜台词就是“这个明显跟开发无关啊，是用户不会用而已”，当我们说出这句话的时候，你会想到什么？把问题推给别人，当然可以减轻自己的压力，但是很显然，这样我们自身就无法得到提升了。

我会继续往下追问：

是否是产品不友好引起；
逻辑是否有提升空间；
交互上是否有提升空间；
功能的使用频率有多高这些问题决定直接决定者，我们是否需要优化这个功能，以及优化这个功能的紧急程度。

历史遗留问题

开发很多时候会把问题定位为历史遗留问题，好像只要定位为了历史遗留问题，这个问题就应该与自己无关，就卸下了沉重的包袱。面对这种情况，作为负责复盘的人应该如何进行追问呢？

1. 历史遗留

是从何时遗留下来的我们在得出结论时，我们先要了解事实以及具体的细节，细节是魔鬼，我们从细节中才可以发现我们的结论是否正确。

2. 为什么历史

一直没有被触发有一些历史遗留问题，是因为解决成本高，对实际用户影响小，属于已知未解决问题；也有一些，需要在特殊的场景下才会触发，发布至今一直未被触发；也有一些历史遗留问题，是用户量增加，历史代码的性能问题被暴露出来了；除了以上三类，还有一类就是本质上并不属于历史遗留问题，是由于新的代码发布，导致过去的一些并不健壮的代码问题暴露出来了，触发的本质还是近期发布的代码引发的。

第三方/依赖方问题

软件开发过程中，会涉及到各种各样的第三方，在我做互联网金融项目时，会依赖存管第三方，现在的项目中依赖中台。依赖方出现问题时，应用就会受到影响，这种情况下，我们应该如何复盘。

1. 是否可以从应用侧进行优化

发布问题

发布问题，这是非常常见的一类问题。但是跟发布相关的问题其实非常广，由于发布准备不够充分导致的发布问题，还是由于发布过程引发的问题。发布准备的问题还可以分为，依赖方沟通不到位引起的发布问题，还是由于测试不充分、或者是步骤不准备不充分引起的发布问题。

是发布准备的问题，还是发布过程的问题
如果是发布准备问题，是测试漏测，还是发布步骤准备不充分
如果是测试漏测，这类问题如何规避，是否可以规避
如果是步骤准备不充分，具体遗漏了哪些步骤
如果是发布过程问题，发布过程配合问题，还是发布过程没有准寻既定的发布步骤或者
是否跟依赖方有关
是否为对方发布失败引起
是否跟依赖方发布顺序未沟通到位有关

历史数据未订正

历史数据未订正导致的问题，也是屡见不鲜。出现历史数据未订正，至少有两个环节出现了问题，开发未评估到影响面，且测试用例未覆盖。

1. 开发影响面是否评估到位

2. 测试用例是否覆盖

改进措施

改进措施需要依据具体的根本原因分析来制定。改进措施的制定需要遵循几个原则：

· 改进措施的成本

· 改进的紧急程度案例场景：

园区初始化时，会涉及到用户既存在线上测试园区账号，正式园区账号，测试园区和正式园区所在的组织不同，不同组织的多园区场景，虽然产品上考虑是支持的，但是历史并不存在这类实际场景，所以有许多场景的考虑并不完备，修复的成本较高。且从产品层面来看，这种场景在很长一段时间内是不会存在的。类似上述案例场景中的问题，修复的成本较高，但是紧急程度较低，如果预留了修复的action，只会占用大家的注意力，无法近期完成修复，这样的改进措施我们会考虑从待办中去掉。

复盘模板

最后，对于线上一些较为严重的问题，我们还制定了一个复盘模板，大家也可以作为参考。

【管理有度10】项目中遇到严重问题如何快速定位和进行问题复盘-图片2

若有收获，就点个赞吧

复盘文章分享：

一图掌握如何做好项目复盘步骤和方法及模板

一图掌握如何做好项目复盘？【慕哲制图】

关于复盘，这会是你看过的最简单易懂的复盘图解了

------------------------

作者介绍：暖益

PMP/Prince2/CSM；

现任国内500强公司PMO，项目管理经验超过10年。

---------------------------------------------

文章末尾固定信息

历史上的今天

12 月

我的微信

我的微信

一个码农、工程狮、集能量和智慧于一身的、DIY高手、小伙伴er很多的、80后奶爸。

【管理有度10】项目中遇到严重问题如何快速定位和进行问题复盘

5WHY分析法