如何通过复盘归因，解锁提升交付质量的终极秘诀？

本文共计1755个文字，预计阅读时间需要8分钟。

前言：写这篇短文的初衷，是前几日在团队内部进行了一次危机和用户反馈建议的复盘分享，有所收获。

正文：美好的一天，看到chenkl老师的文章《团队交流质量如何评估》，其中提到‘如何’一词，在交流中扮演着至关重要的角色。

前言

写这篇文章的初衷，是前几天在团队内部进行了一次缺陷和用户反馈建议的复盘归因分享，略有所得。

正好昨天看到chenkl老师的一篇文章：《团队交付质量如何评估》。其中讲到的很多点如缺陷趋势图、交付时长、线上BUG逃逸率、用户反馈等，给了我很多不一样的启发。

这篇文章，我想来聊聊，如何通过复盘归因，来提高交付质量。

软件交付质量

在日常的工作流程中，比较通用的流程如下图所示：

从质量保障和交付的角度来讲，软件交付生命周期中大体可分为如下三个阶段：

需求设计质量

这个阶段包括原型图、PRD文档、交互设计、技术方案、测试用例等几项重要产出物，当然他们有一定的前后依赖关系。

我们谈软件交付质量，不可避免的要从它的源头说起，而源头就是需求和设计阶段要做的事情。

如上图所示，我们为什么需要做大量的评审工作呢？因为如果在源头存在问题，那么研发过程和后面的用户使用质量，就无从谈起。方向错了，就全错了。

评审最大的作用就是集各个角色(产品&研发&测试)从不同角度对需求设计进行解读理解，提出疑问和建议并进行修正。

确保在最开始确定方向和需求细节方面，尽可能降低或者避免遗漏及不合理带来的质量交付风险。

研发过程质量

有句话怎么说来着？“软件质量是构建出来的，不是测试出来的”。