怎样度量需求质量

2 天前   出处:圆小豆的美梦工场  作/译者: 于晓南  

本文只探讨需求质量的度量,需求价值的度量不在讨论范围内。

一天晚上,给娃讲绘本《肚子里有个火车站》,故事用形象生动的比喻讲解消化吸收的原理与科学饮食的重要性。


绘本故事:《肚子里有个火车站》

简单描述一下:

  1. 我们的肚子里有个火车站,吃进来的食物会被小精灵们加工好后进行装车,然后以一定的频率发车。

  2. 有时很久没有食物进来,小精灵们就会闲得睡大觉。

  3. 有时突然一下食物堆积成山,小精灵们就加班加点忙个不停。

  4. 进来的食物需要大小适宜,当食物块儿太大时,就会把小精灵砸晕,他就没法工作了。

  5. 有时吃了太凉或太刺激的食物,火车站就会停摆。

  6. 小精灵们无法继续工作,就会罢工。

讲着讲着,发现这不就是我们的版本火车么,简直不能更像。

发布周期对需求质量的高要求

周期性发布:需求质量要求高

为了保证版本火车顺利发车,我们对需求的质量有着怎样的期待呢?

  1. 高价值:少吃垃圾食品,多吃高质量的食物,每一条需求都应追溯到业务价值或用户诉求

  2. 稳定的供给:以相对稳定周期均匀的供给,不能一次太多或太少

  3. 稳定的支出:以相对稳定的频率均匀的支出,保证上线的范围相对稳定

  4. 便于分工:搭配合理、营养均衡,既要交付价值,也要留有余量以应对紧急需求

  5. 大小适宜:太小太细碎会增加管理成本,太大则无法直接进入研发,需要进一步拆解

按需发布:需求质量要求更高

刚才我们讨论的是周期性发布的情况,那如果是按需发布,对需求质量的要求可以降低吗?

考虑到按需发布和周期性发布的差异在于发布频率,两者在需求规划阶段的思考侧重点就不尽相同。

周期性发布时,需求需要如期交付,所以在进行迭代规划时,我们参照迭代容量和需求优先级,从需求池中选取适量需求放入迭代即可。

按需发布在规划时需要识别可以独立交付的功能,这对需求拆分和优先级排序是更大的挑战。如何进行端到端的需求拆分,以便于每次发布都能独立交付价值,是在这个过程中需要重点考虑的问题。因此按需发布对需求质量的要求会更高。

高质量需求的判定

我们怎样知道需求是满足预期的呢?好的需求应该长成什么样子?

1. 需求本身的质量:是否满足INVEST原则

  1. 需求的验收标准是否清晰:明确知道需求实现完成,可进一步流转

  2. 需求的内容相对稳定:可响应少量的必要变化,不建议频繁变更

  3. 需求拆分是否恰当:拆分合理便于协作与管理

  4. 需求的范围相对稳定:可支持适量的“高价值需求”插队

  5. 需求的优先级明确:需提供优先级排序,便于团队安排工序

概括一下就是:价值精确、时效适宜、拆分得当、排序合理。

研发过程中的需求痛点

供给困难

项目A的需求供给情况不乐观,马上要进入迭代了,需求卡片还没有准备好。小伙伴们面面相觑,不知道该不该进入迭代。找到需求分析师问原因,“客户就是不批卡呀,我能怎么办,我也很无奈。”

质量堪忧

项目B的需求供给相对稳定,但每次故事启动时问题太多,考虑较少。产品美眉听完问题,经常瞪着茫然的大眼睛无辜地望着大家,虽然很美但团队也是很崩溃的。主要还是我们的业务上下文过于复杂,老司机也难免翻车,何况小萌新。

频繁变更

项目C需求供给稳定,质量尚可,但经常是研发做着做着就来个紧急更新,不是需求变了就是方案变了,一顿返工是免不了的。业务方思维活跃,总想迭代需求,一来二去团队要消化不良。

需求痛点有多痛,真是“不幸的人各有各的不幸”。团队里每个人都很努力,但又都很痛苦。当去找业务方或客户提需求、要资源时,又往往难于自证,没有说服力当然要不来支持。

需求质量度量:可视化痛点

在什么情况下需要度量需求的质量?当需求的痛点对团队造成极大的浪费时,我们需要针对痛点做根因分析,必要时可以度量需求的质量,为持续改进提供定性或定量的依据。

那么,如何度量需求的质量?

评估需求本身的缺陷

首先我们看需求本身的质量问题,即需求阶段引入的缺陷,主要体现在以下几个方面:

  • 价值模糊:对用户而言无法清晰定义需求价值,或者需求描述与用户价值没有直接因果关系

  • 无法验收:验收标准描述不清晰,或者验收点拆分不合理

  • 粒度过大或过小:粒度过大则无法直接进入研发,需要进一步拆解;粒度过小会增加管理和协作的成本

  • 强依赖:需求之间不独立,或者拆卡不合适,没有端到端的拆分需求价值

  • 细节限制:需求描述没有站在交付价值的角度,而是限制过多实现细节

  • 难以评估工作量:通常伴随价值模糊或者粒度不合适,往往是问题定位不清晰导致

评估需求时效性

再来看未满足需求交付对时效性的要求:

  • 需求延误:需求未如期交付研发的次数,或者累计延误天数

  • 变更:需求变更的频率或者范围,或者允许变更的时间窗

敏捷拥抱变化,当需求变更不造成大量返工时,是允许需求变更的,但需要在一定的时间窗内变更。某些团队的变更时间窗可能是需求过半,在另一些团队可能是内部集成前。当然变更的范围也需要尽量少,如接口字段追加或更新还可以接受,但如果整个集成方式都要变,那就需要触发新的迭代规划,重新估算工作量进行排期。

评估低质需求带来的影响

最后评估低质量的需求对团队造成的恶劣影响:

  • 返工:由于需求缺陷或变更造成返工的工作量

  • 前置时间:由于需求缺陷或变更造成产能降低,价值交付周期延长

  • 机会成本:那些被浪费掉的产能,如投入生产所带来的的潜在价值


交付价值与研发投入之间的关系

在评估低质需求的影响时,需要注意:

  1. 或许在某个平衡点之前,牺牲一部分质量需求能够快速交付更多价值,此时比较经济的做法是更快的交付

  2. 但在持续投入超过平衡点后,低质需求会导致大量的浪费,此时提升需求质量是效果显著的

需求质量度量的效果评价

在需求阶段进行度量和改进,需要整体评估投资回报率。原因在于,需求是在整个研发周期的早期阶段,在此优化的效果可能当时并不明显。一方面是回报阶段的后置,需求改进可能最终改善的是交付质量,或者整体产能。另一方面是回报周期的延迟,有可能在需求阶段投入改进的成本,要在一个季度后才能略见收益。

既然需求质量改进的投资效果不明显,我们为什么还是要度量并改进呢?原因其实是相同的,也正是由于需求阶段是整个研发过程的前置阶段,所以需求的质量才尤为重要。总该找准方向再深耕,方向不对,做得越多错得越多。

做正确的事 OVER 忙着做事,研发团队多关注需求的质量,才能保证后续研发过程的高质高效。


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
122°|1220 人阅读|0 条评论

登录 后发表评论
最新文章