怎样度量需求质量

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

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

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

简单描述一下：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

那么，如何度量需求的质量？

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

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

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

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

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

在评估低质需求的影响时，需要注意：

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

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

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