——这是我的第91篇原创文章——

学习 B 端产品，就看「司马特小分队」
从客户调研到竞品分析，做出了一个优秀的产品方案，脑海里设想的是豪华版
交付的时候却成了乞丐版
作为产品经理，怎么保证需求实现的质量呢？
我们都知道事前预防成本远远低于事后补救，这也是为什么越来越多的公司对测试人员的比例控制更严格，而通过各类手段从上游保障质量，因为事后检查处理的代价其实是最高的。
为什么交付质量低呢？
导致项目质量交付低，大部分原因无外乎需求不清晰，工期太紧，代码不规范，测试不到位等等。一个需求从设计完成到上线，需要经过多个环节，每个环节都会导致信息失真，如果没有采取任何措施，过程中信息衰减最大值可达到60%，出现卖家秀到买家秀也不就奇怪了。

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

  1. 需求质量必须过关
  2. 通过测试评审弥补理解偏差
  3. 沟通是连续的
  4. 换个视角来验收
  5. 建立质量标准，让数据说话 

保证需求质量

No.1

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

需求文档
需求结构的完整性：修订记录、结构图、全局说明、需求列表、主流程。
需求描述：背景、业务价值、交互逻辑、业务逻辑。对页面内容说明时，要简洁，避免把解释写的箭头乱飞，尽可能清晰简单，可读性强。
怎么交付高质量的PRD，这篇文章你一定要看，一文说透PRD要害 ：高质量原型必知必读 
怎么减少逻辑错误或遗漏，根据经验有3个办法
1. 建立自己的checklist
2. 产品组内初评，需求串讲，和开发的代码review一样的道理。
3. 需求复盘。找出不足不断改进完善checklist，踩过的坑不踩第二遍。我也看到过技术同学总结的开发时间评估避坑指南，本质都是总结不足持续改进。 
这是我之前用过的自检list，包含了通用的和根据当前产品特性增加的检查项。这是比较简单的一个版本，按每个功能总结出的checklist更好。
模块

检查
功能

是新增模块吗？产品包是否需要变动？

是否存在区分权限的功能？

是否存在关联功能的改造点？如：系统设置、费用、web/h5客户记录、统计、消息提醒

是否完整梳理了当前功能对客户的影响？

是否已预估数据爆发量级，及其处理措施？

是否已计划好功能上线后的验证方法？

是否存在法律及合规风险？

是否需要增加通知或提醒？

功能是否影响了当前客户？
数据

有影响统计报表吗？是否需要增加新报表？

是否需要数据打点（包括统计方式）

交互

有排序的地方，有排序逻辑吗？

有多选的情况下，有默认项吗？

有用户输入的地方，考虑字数限制，考虑提交失败情况

提示是否清晰能理解？

有显示的地方，考虑内容太多时的显示情况？

页面是否存在空值状态？

页面的逆向操作是否有完整的路径，返回是否能完成？


弥补理解偏差

No.2

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

造成理解偏差的原因也有很多，比如产品和技术对词汇的理解不一致，概念没有统一，这些都需要在需求阶段就进行明确。
1、需求评审环节
特别注意的是不能局限于我告诉你做什么，要去讲背景，讲需求能带来的业务价值，为技术建立对需求的完整认知，提高做正确的概率。

具体怎么做需求评审，推荐过去的两篇文章已经很详尽：

经常被研发、运营怼？一篇文章教你告别过去！

4个技巧带你闯过产品经理第一关：需求评审
2、测试评审环节
这个环节能弥补各个参与人的理解偏差，是一次关键的补救机会。
主导人是测试人员，参加者包含开发和产品经理。
为什么需要测试用例的评审？
一方面检查研发对需求理解有没有偏差，用例的覆盖、操作步骤、边界是否全面。
另一方面这也是检验需求的质量，有没有逻辑漏洞，交互场景是不是覆盖全面，逆向操作有没有考虑到、关联影响是不是全面。尽早发现需求问题，及时补救，把风险提前消灭。

持续的沟通

No.3

沟通是连续的
强调的是，不要指望这2个评审能解决掉全部的问题，沟通本就是是连续的过程中，在开发过程中若有需求变更，或出现理解不一致，都需要及时的把相关人聚在一起，共同讨论，确保需求理解的一致性。
在项目开发期间举行每日站立会，是个不错的办法，拿出专门的时间让大家交流，加强成员的内部沟通。 

和开发沟通的技巧，可以查看之前的精选文章。

产品经理vs开发的巅峰对话

只要4步，让开发心甘情愿加需求

验收

No.4

换个视角来验收

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

 建立衡量标准

No.5

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

怎么检验是哪个环节出现了问题，让数据说话，更客观。
反馈的 Bug 分类统计，常见的分类有需求定义不清、设计缺陷、代码错误、测试遗漏、配置相关、部署错误等等。
从数据统计上，去判断问题主要出在哪个环节，再决定下一步是要求提高需求质量，还是提高测试用例的覆盖。每次版本都进行复盘，分析原因，找出最关键的3点去改善，坚持2个月，就能快速提高产品质量。
什么才是高质量呢？
需要根据具体的产品阶段的情况，去制定可衡量的质量标准，比如产品初期阶段和商业化后的质量标准自然是不同的。最重要的是团队要达成共识，并以此质量标准要要求自己。

  最后

No.6

怎么把你的产品高质量的交付，研发过程肯定有说不完的（血泪）故事，欢迎加入B端产品之家，一起思考和复盘，获得更快的成长。

End
司马特小分队在星球成立「B 端产品经理之家」，目前已汇集 150+来自教育、医疗、电商等领域的小伙伴，每天都有产品话题讨论，还有行业专家答疑解惑。
回复「优惠券」，可获得 50 元星球立减券，数量有限哦。
点击查看星球介绍：我们的星球 – B端产品经理之家
声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。