一天晚上，给娃讲绘本《肚子里有个火车站》，故事用形象生动的比喻讲解消化吸收的原理与科学饮食的重要性。
简单描述一下：
我们的肚子里有个火车站，吃进来的食物会被小精灵们加工好后进行装车，然后以一定的频率发车。
有时很久没有食物进来，小精灵们就会闲得睡大觉。
有时突然一下食物堆积成山，小精灵们就加班加点忙个不停。
进来的食物需要大小适宜，当食物块儿太大时，就会把小精灵砸晕，他就没法工作了。
有时吃了太凉或太刺激的食物，火车站就会停摆。
小精灵们无法继续工作，就会罢工。
讲着讲着，发现这不就是我们的版本火车么，简直不能更像。
发布周期对需求质量的高要求
周期性发布：需求质量要求高
为了保证版本火车顺利发车，我们对需求的质量有着怎样的期待呢？
- 高价值：少吃垃圾食品，多吃高质量的食物，每一条需求都应追溯到业务价值或用户诉求；
- 稳定的供给：以相对稳定周期均匀的供给，不能一次太多或太少；
- 稳定的支出：以相对稳定的频率均匀的支出，保证上线的范围相对稳定；
- 便于分工：搭配合理、营养均衡，既要交付价值，也要留有余量以应对紧急需求；
- 大小适宜：太小太细碎会增加管理成本，太大则无法直接进入研发，需要进一步拆解；
按需发布：需求质量要求更高
刚才我们讨论的是周期性发布的情况，那如果是按需发布，对需求质量的要求可以降低吗？
考虑到按需发布和周期性发布的差异在于发布频率，两者在需求规划阶段的思考侧重点就不尽相同。
周期性发布时，需求需要如期交付，所以在进行迭代规划时，我们参照迭代容量和需求优先级，从需求池中选取适量需求放入迭代即可。
按需发布在规划时需要识别可以独立交付的功能，这对需求拆分和优先级排序是更大的挑战。如何进行端到端的需求拆分，以便于每次发布都能独立交付价值，是在这个过程中需要重点考虑的问题。因此按需发布对需求质量的要求会更高。
高质量需求的判定
我们怎样知道需求是满足预期的呢？好的需求应该长成什么样子？
- 需求本身的质量：是否满足INVEST原则（见下面）；
- 需求的验收标准是否清晰：明确知道需求实现完成，可进一步流转；
- 需求的内容相对稳定：可响应少量的必要变化，不建议频繁变更；
- 需求拆分是否恰当：拆分合理便于协作与管理；
- 需求的范围相对稳定：可支持适量的“高价值需求”插队；
- 需求的优先级明确：需提供优先级排序，便于团队安排工序；
概括一下就是：价值精确、时效适宜、拆分得当、排序合理。
研发过程中的需求痛点
供给困难
项目A的需求供给情况不乐观，马上要进入迭代了，需求卡片还没有准备好。小伙伴们面面相觑，不知道该不该进入迭代。找到需求分析师问原因，“客户就是不批卡呀，我能怎么办，我也很无奈。”
质量堪忧
项目B的需求供给相对稳定，但每次故事启动时问题太多，考虑较少。产品美眉听完问题，经常瞪着茫然的大眼睛无辜地望着大家，虽然很美但团队也是很崩溃的。主要还是我们的业务上下文过于复杂，老司机也难免翻车，何况小萌新。
频繁变更
项目C需求供给稳定，质量尚可，但经常是研发做着做着就来个紧急更新，不是需求变了就是方案变了，一顿返工是免不了的。业务方思维活跃，总想迭代需求，一来二去团队要消化不良。
需求痛点有多痛，真是“不幸的人各有各的不幸”。团队里每个人都很努力，但又都很痛苦。当去找业务方或客户提需求、要资源时，又往往难于自证，没有说服力当然要不来支持。
需求质量度量：可视化痛点
在什么情况下需要度量需求的质量？当需求的痛点对团队造成极大的浪费时，我们需要针对痛点做根因分析，必要时可以度量需求的质量，为持续改进提供定性或定量的依据。
那么，如何度量需求的质量？
评估需求本身的缺陷
首先我们看需求本身的质量问题，即需求阶段引入的缺陷，主要体现在以下几个方面：
- 价值模糊：对用户而言无法清晰定义需求价值，或者需求描述与用户价值没有直接因果关系；
- 无法验收：验收标准描述不清晰，或者验收点拆分不合理；
- 粒度过大或过小：粒度过大则无法直接进入研发，需要进一步拆解；粒度过小会增加管理和协作的成本；
- 强依赖：需求之间不独立，或者拆卡不合适，没有端到端的拆分需求价值；
- 细节限制：需求描述没有站在交付价值的角度，而是限制过多实现细节；
- 难以评估工作量：通常伴随价值模糊或者粒度不合适，往往是问题定位不清晰导致；
评估需求时效性
再来看未满足需求交付对时效性的要求：
- 需求延误：需求未如期交付研发的次数，或者累计延误天数；
- 变更：需求变更的频率或者范围，或者允许变更的时间窗；
