5Why分析法——提测质量问题复盘

背景

我们的产品致力于为金融领域的客户提供优质服务。在市场层面，我们拥有广泛的客户群体。由于开发周期和合同签订时间的差异，不同客户所使用的系统往往运行在不同版本的代码分支上。

近期在排查一个PageHelper的使用问题时，具体文章参考《PageHelper缓存在线程中的分页对象未释放问题排查方案》。发现在最近一段时间内，有若干问题仅在我们最新的代码版本中得到了修正，而并未及时同步更新到每位客户所使用的版本中。

目标

鉴于问题是我亲自发现的，我将负责跟进这些问题的修复工作，并确保各个客户版本的更新与推进。

推进过程

1. 对客户实际运用的版本进行统计，并了解他们对于更新的接受度；
2. 在汇总了所有客户的版本信息后，将版本相近的客户群整合，形成一个新的版本，以简化代码分支的维护工作；
3. 整合所有的修改内容，并提交至测试环节；
4. 完成测试后，生成更新包；
5. 推动各客户进行系统升级。

结果

从下图中看出1月份完成任务35个，2月初完成13个任务。

下图中可以看出1月份有1次易现缺陷数。

在前期支撑各种需求时质量尚可，但是在月末到二月初提测质量明显下降，出现了内部归类为易现的错误。下面将对此进行复盘。

复盘

• why：为什么会出现上面的两个问题？
  answer：上诉的问题需要依赖部署环境，所以在修改时没有进行部署，只是简单调试就就提测了。

• why：为什么没有进行详细的自测？
  answer：一方面是因为本期需求较多，所以时间比较紧张；另一方面也是因为有所松懈，认为只要在部署平台导入就行，实际部署不会有问题。

• why：为什么会有所松懈，认为只要在部署平台导入就行，实际部署不会有问题？
  answer：根据之前的经验部署流程较为简单，而且未曾碰到过部署才出问题的。大部分情况下在导入时就能直接报错提示了。

• why：为什么这种观念会导致质量下降？
  answer：有了这种观念后就不会做详细的自测，就会导致很多看起来很明显的问题发生。

总结

从上述的复盘分析来看，核心问题在于过度自信。如果能保持与月初相同的严谨态度和充分的自测，相信这样的问题是可以避免的。

另一方面，本期需求的过多也是导致问题频发的一个重要原因。

解决方案

提升自我警觉性：始终保持警惕，避免过度自信，确保每个环节都经过充分的自测和审查。

优化需求排期：合理规划需求，避免过多的任务堆积，确保有足够的时间进行测试和质量保证。

强化风险管理：在项目开始阶段，进行全面的风险评估，制定相应的应对措施，以减少潜在的问题发生。

持续学习和改进：总结经验教训，不断学习新的技术和方法，提高团队的整体能力和水平。