——这是我的第91篇原创文章——
学习 B 端产品，就看「司马特小分队」从客户调研到竞品分析，做出了一个优秀的产品方案，脑海里设想的是豪华版交付的时候却成了乞丐版作为产品经理，怎么保证需求实现的质量呢？我们都知道事前预防成本远远低于事后补救，这也是为什么越来越多的公司对测试人员的比例控制更严格，而通过各类手段从上游保障质量，因为事后检查处理的代价其实是最高的。为什么交付质量低呢？导致项目质量交付低，大部分原因无外乎需求不清晰，工期太紧，代码不规范，测试不到位等等。一个需求从设计完成到上线，需要经过多个环节，每个环节都会导致信息失真，如果没有采取任何措施，过程中信息衰减最大值可达到60%，出现卖家秀到买家秀也不就奇怪了。作为产品经理，可以做什么来帮助提高产品交付的质量呢 ？根据个人经验总结了以下5点
- 需求质量必须过关
- 通过测试评审弥补理解偏差
- 沟通是连续的
- 换个视角来验收
- 建立质量标准，让数据说话
保证需求质量
No.1
这个环节主导者产品经理，是产品质量的源头保障。前期做完了充分调研和需求分析，也完成了需求设计。需求文档需求结构的完整性：修订记录、结构图、全局说明、需求列表、主流程。需求描述：背景、业务价值、交互逻辑、业务逻辑。对页面内容说明时，要简洁，避免把解释写的箭头乱飞，尽可能清晰简单，可读性强。怎么交付高质量的PRD，这篇文章你一定要看，一文说透PRD要害 ：高质量原型必知必读怎么减少逻辑错误或遗漏，根据经验有3个办法1. 建立自己的checklist2. 产品组内初评，需求串讲，和开发的代码review一样的道理。3. 需求复盘。找出不足不断改进完善checklist，踩过的坑不踩第二遍。我也看到过技术同学总结的开发时间评估避坑指南，本质都是总结不足持续改进。这是我之前用过的自检list，包含了通用的和根据当前产品特性增加的检查项。这是比较简单的一个版本，按每个功能总结出的checklist更好。
检查
是新增模块吗？产品包是否需要变动？
是否存在区分权限的功能？
是否存在关联功能的改造点？如：系统设置、费用、web/h5客户记录、统计、消息提醒
是否完整梳理了当前功能对客户的影响？
是否已预估数据爆发量级，及其处理措施？
是否已计划好功能上线后的验证方法？
是否存在法律及合规风险？
是否需要增加通知或提醒？
功能是否影响了当前客户？
有影响统计报表吗？是否需要增加新报表？
是否需要数据打点（包括统计方式）
交互
有排序的地方，有排序逻辑吗？
有多选的情况下，有默认项吗？
有用户输入的地方，考虑字数限制，考虑提交失败情况
提示是否清晰能理解？
有显示的地方，考虑内容太多时的显示情况？
页面是否存在空值状态？
页面的逆向操作是否有完整的路径，返回是否能完成？
弥补理解偏差
No.2
造成理解偏差的原因也有很多，比如产品和技术对词汇的理解不一致，概念没有统一，这些都需要在需求阶段就进行明确。
1、需求评审环节特别注意的是不能局限于我告诉你做什么，要去讲背景，讲需求能带来的业务价值，为技术建立对需求的完整认知，提高做正确的概率。具体怎么做需求评审，推荐过去的两篇文章已经很详尽：
经常被研发、运营怼？一篇文章教你告别过去！
持续的沟通
No.3
强调的是，不要指望这2个评审能解决掉全部的问题，沟通本就是是连续的过程中，在开发过程中若有需求变更，或出现理解不一致，都需要及时的把相关人聚在一起，共同讨论，确保需求理解的一致性。在项目开发期间举行每日站立会，是个不错的办法，拿出专门的时间让大家交流，加强成员的内部沟通。
和开发沟通的技巧，可以查看之前的精选文章。
产品经理vs开发的巅峰对话
只要4步，让开发心甘情愿加需求
验收
No.4
建立衡量标准
No.5
怎么检验是哪个环节出现了问题，让数据说话，更客观。反馈的 Bug 分类统计，常见的分类有需求定义不清、设计缺陷、代码错误、测试遗漏、配置相关、部署错误等等。从数据统计上，去判断问题主要出在哪个环节，再决定下一步是要求提高需求质量，还是提高测试用例的覆盖。每次版本都进行复盘，分析原因，找出最关键的3点去改善，坚持2个月，就能快速提高产品质量。什么才是高质量呢？需要根据具体的产品阶段的情况，去制定可衡量的质量标准，比如产品初期阶段和商业化后的质量标准自然是不同的。最重要的是团队要达成共识，并以此质量标准要要求自己。
最后
No.6
怎么把你的产品高质量的交付，研发过程肯定有说不完的（血泪）故事，欢迎加入B端产品之家，一起思考和复盘，获得更快的成长。
End司马特小分队在星球成立「B 端产品经理之家」，目前已汇集 150+来自教育、医疗、电商等领域的小伙伴，每天都有产品话题讨论，还有行业专家答疑解惑。
回复「优惠券」，可获得 50 元星球立减券，数量有限哦。点击查看星球介绍：我们的星球 - B端产品经理之家