极简知识 | 想要提高产品交付的质量,产品经理必须要知道......

司马特小分队 2020年06月04日
教你5招治好熊孩子。
鸟哥笔记,数据运营,司马特小分队,策略,<a href=产品运营">

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


产品运营" alt="鸟哥笔记,数据运营,司马特小分队,策略,产品运营" style="width:149pxpx;height:auto;">

交付的时候却成了乞丐版

产品运营" alt="鸟哥笔记,数据运营,司马特小分队,策略,产品运营" style="width:187pxpx;height:auto;">

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


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

为什么交付质量低呢?

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

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

1.需求质量必须过关

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

3.沟通是连续的

4.换个视角来验收

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

一、保证需求质量

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


需求文档

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

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

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

1. 建立自己的checklist

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

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

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

产品运营" alt="鸟哥笔记,数据运营,司马特小分队,策略,产品运营" width="500" style="width:500px;height:auto;">

产品运营" alt="鸟哥笔记,数据运营,司马特小分队,策略,产品运营" width="500" style="width:500px;height:auto;">

二、弥补理解偏差

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


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

产品运营" alt="鸟哥笔记,数据运营,司马特小分队,策略,产品运营">

1、需求评审环节

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

2、测试评审环节

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

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

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

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

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

三、持续的沟通

沟通是连续的


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

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

四、验收

换个视角来验收


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

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

 五、建立衡量标准

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


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

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

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

什么才是高质量呢?

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

  六、最后

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

-END-

产品运营" alt="鸟哥笔记,数据运营,司马特小分队,策略,产品运营">

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


产品运营" alt="鸟哥笔记,数据运营,司马特小分队,策略,产品运营" style="width:149pxpx;height:auto;">

交付的时候却成了乞丐版

产品运营" alt="鸟哥笔记,数据运营,司马特小分队,策略,产品运营" style="width:187pxpx;height:auto;">

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


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

为什么交付质量低呢?

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

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

1.需求质量必须过关

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

3.沟通是连续的

4.换个视角来验收

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

一、保证需求质量

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


需求文档

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

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

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

1. 建立自己的checklist

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

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

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

产品运营" alt="鸟哥笔记,数据运营,司马特小分队,策略,产品运营" width="500" style="width:500px;height:auto;">

产品运营" alt="鸟哥笔记,数据运营,司马特小分队,策略,产品运营" width="500" style="width:500px;height:auto;">

二、弥补理解偏差

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


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

产品运营" alt="鸟哥笔记,数据运营,司马特小分队,策略,产品运营">

1、需求评审环节

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

2、测试评审环节

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

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

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

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

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

三、持续的沟通

沟通是连续的


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

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

四、验收

换个视角来验收


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

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

 五、建立衡量标准

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


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

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

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

什么才是高质量呢?

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

  六、最后

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

-END-

产品运营" alt="鸟哥笔记,数据运营,司马特小分队,策略,产品运营">

推荐阅读

互联网运营

互联网产品PM