从客户调研到竞品分析，做出了一个优秀的产品方案，脑海里设想的是豪华版

交付的时候却成了乞丐版

作为产品经理，怎么保证需求实现的质量呢？

我们都知道事前预防成本远远低于事后补救，这也是为什么越来越多的公司对测试人员的比例控制更严格，而通过各类手段从上游保障质量，因为事后检查处理的代价其实是最高的。

为什么交付质量低呢？

导致项目质量交付低，大部分原因无外乎需求不清晰，工期太紧，代码不规范，测试不到位等等。一个需求从设计完成到上线，需要经过多个环节，每个环节都会导致信息失真，如果没有采取任何措施，过程中信息衰减最大值可达到60%，出现卖家秀到买家秀也不就奇怪了。

作为产品经理，可以做什么来帮助提高产品交付的质量呢 ？根据个人经验总结了以下5点

1.需求质量必须过关

2.通过测试评审弥补理解偏差

3.沟通是连续的

4.换个视角来验收

5.建立质量标准，让数据说话

一、保证需求质量

这个环节主导者产品经理，是产品质量的源头保障。前期做完了充分调研和需求分析，也完成了需求设计。

需求文档

需求结构的完整性：修订记录、结构图、全局说明、需求列表、主流程。

需求描述：背景、业务价值、交互逻辑、业务逻辑。对页面内容说明时，要简洁，避免把解释写的箭头乱飞，尽可能清晰简单，可读性强。

怎么减少逻辑错误或遗漏，根据经验有3个办法

1. 建立自己的checklist

2. 产品组内初评，需求串讲，和开发的代码review一样的道理。

3. 需求复盘。找出不足不断改进完善checklist，踩过的坑不踩第二遍。我也看到过技术同学总结的开发时间评估避坑指南，本质都是总结不足持续改进。

这是我之前用过的自检list，包含了通用的和根据当前产品特性增加的检查项。这是比较简单的一个版本，按每个功能总结出的checklist更好。

二、弥补理解偏差

弥补理解偏差，抓住2个关键环节

造成理解偏差的原因也有很多，比如产品和技术对词汇的理解不一致，概念没有统一，这些都需要在需求阶段就进行明确。

1、需求评审环节

特别注意的是不能局限于我告诉你做什么，要去讲背景，讲需求能带来的业务价值，为技术建立对需求的完整认知，提高做正确的概率。

2、测试评审环节

这个环节能弥补各个参与人的理解偏差，是一次关键的补救机会。

主导人是测试人员，参加者包含开发和产品经理。

为什么需要测试用例的评审？

一方面检查研发对需求理解有没有偏差，用例的覆盖、操作步骤、边界是否全面。

另一方面这也是检验需求的质量，有没有逻辑漏洞，交互场景是不是覆盖全面，逆向操作有没有考虑到、关联影响是不是全面。尽早发现需求问题，及时补救，把风险提前消灭。

三、持续的沟通

沟通是连续的

强调的是，不要指望这2个评审能解决掉全部的问题，沟通本就是是连续的过程中，在开发过程中若有需求变更，或出现理解不一致，都需要及时的把相关人聚在一起，共同讨论，确保需求理解的一致性。

在项目开发期间举行每日站立会，是个不错的办法，拿出专门的时间让大家交流，加强成员的内部沟通。

四、验收

换个视角来验收

通常在测试环节，没有从用户的视角来检验产品，用户对功能的应用场景与测试的视角相差还是较大，测试效果很难保障。怎么解决呢？除了产品经理的验收，项目排期内要有1-2天的时间让业务人员验收，让销售和客服一起使用新功能，从另一个视角检验。

这样其实一举两得，在新功能上线后，销售客服对功能足够了解，可以更好的服务客户，解答疑问。

五、建立衡量标准

建立质量标准，让数据说话

怎么检验是哪个环节出现了问题，让数据说话，更客观。

反馈的 Bug 分类统计，常见的分类有需求定义不清、设计缺陷、代码错误、测试遗漏、配置相关、部署错误等等。

从数据统计上，去判断问题主要出在哪个环节，再决定下一步是要求提高需求质量，还是提高测试用例的覆盖。每次版本都进行复盘，分析原因，找出最关键的3点去改善，坚持2个月，就能快速提高产品质量。

什么才是高质量呢？

需要根据具体的产品阶段的情况，去制定可衡量的质量标准，比如产品初期阶段和商业化后的质量标准自然是不同的。最重要的是团队要达成共识，并以此质量标准要要求自己。

-END-