敏捷拥抱变化，当需求变更不造成大量返工时，是允许需求变更的，但需要在一定的时间窗内变更。某些团队的变更时间窗可能是需求过半，在另一些团队可能是内部集成前。当然变更的范围也需要尽量少，如接口字段追加或更新还可以接受，但如果整个集成方式都要变，那就需要触发新的迭代规划，重新估算工作量进行排期。
评估低质需求带来的影响
最后评估低质量的需求对团队造成的恶劣影响：
- 返工：由于需求缺陷或变更造成返工的工作量；
- 前置时间：由于需求缺陷或变更造成产能降低，价值交付周期延长；
- 机会成本：那些被浪费掉的产能，如投入生产所带来的的潜在价值；
交付价值与研发投入之间的关系
在评估低质需求的影响时，需要注意：
- 或许在某个平衡点之前，牺牲一部分质量需求能够快速交付更多价值，此时比较经济的做法是更快的交付；
- 但在持续投入超过平衡点后，低质需求会导致大量的浪费，此时提升需求质量是效果显著的；
需求质量度量的效果评价
在需求阶段进行度量和改进，需要整体评估投资回报率。原因在于，需求是在整个研发周期的早期阶段，在此优化的效果可能当时并不明显。一方面是回报阶段的后置，需求改进可能最终改善的是交付质量，或者整体产能。另一方面是回报周期的延迟，有可能在需求阶段投入改进的成本，要在一个季度后才能略见收益。
既然需求质量改进的投资效果不明显，我们为什么还是要度量并改进呢？原因其实是相同的，也正是由于需求阶段是整个研发过程的前置阶段，所以需求的质量才尤为重要。总该找准方向再深耕，方向不对，做得越多错得越多。
做正确的事 OVER 忙着做事，研发团队多关注需求的质量，才能保证后续研发过程的高质高效。
源自公众号 圆小豆的美梦工场