需求交付时长
概念
定义
需求交付时长是需求从创建到交付的总时长。可按照需求在实践域或项目管理系统中流转的状态划分，统计各个状态阶段的时间占比，帮助定位拖长需求交付时长的阶段。如果需求的颗粒度不统一，可以统计需求的功能点、故事点、代码当量等进行校准。其中功能点是常用于估算软件规模的单位，有国家标准作为依据，适用于小颗粒需求或小规模专业性强的团队，或航天、军工、政务等行业。为了校准需求的实际颗粒度，可以采用每个需求交付后对应的代码当量作为一个统计指标，来观察各个需求颗粒度的分布。如果它们的代码当量符合正态分布，则需求交付时长的结果可作为观察交付速率的有效参考，否则应重点排查代码当量过大或过小的需求，首先统一需求颗粒度，再采用需求交付时长指标。
例如，下图展示了几个月份中，需求交付时长的均值和低80%分位值。
价值
需求交付时长反映研发团队的快速响应能力。理论上，向客户交付价值的速度越快越好，但必须综合考虑交付价值是否满足顾客期望、需求吞吐率和交付质量等其他方面。快速交付不一定等同于优秀的研发实践。
应用
角色认知
| 角色 | 认知域 |
|---|---|
| 项目经理、开发者 | 交付效率 |
MARI 方法
度量（Measure）
计算方法
对于某个需求，需求交付时长 = 需求发布时间 - 需求创建时间。可以按照需求在各个状态中停留的时长，将需求交付时长细分为多个组成部分。可以只统计指定范围内的需求，计算它们的交付周期。
- 统计项目维度需求交付时长。
- 统计周期内平均或 80% 的需求的交付周期。
- 统计需求在不同实践域（需求分析、设计、开发、测试、发布）或不同状态的停留时长。
分析（Analyze）
对比不同项目的需求交付速度，找到交付最快和最慢的项目。
分析各个周期内平均需求交付时长的变化趋势，进行纵向对比，定位最大值、最小值、连续上升周期、连续下降周期等关键点。
分析各个周期内80%的需求的交付周期的变化趋势，进行纵向对比，定位最大值、最小值、连续上升周期、连续下降周期等关键点。
信息为什么选用80%分位数而不是使用平均数？ 统计的意义在于以真实有效的数据进行预测，支持更优决策，而均值和中分位数无法具备支持预测的作用。 通常情况下，均值和80%分位数的统计结果会出现两倍的差距，80%分位数和99%分位数也往往是约两倍关系。 因此，80%分位数是一个很好的预测平衡点。
分析对比需求在不同实践域或不同状态的停留时长，识别耗时最长的环节，找到影响整体交付速度的关键瓶颈。
需求交付时长与需求吞吐量关联分析，辨别需求交付趋势是否健康。
- 健康趋势：需求交付时长缩短并且需求吞吐量增加。
- 不健康趋势：需求交付时长延长并且需求吞吐量降低。
回顾（Review）
基于分析结果，聚焦少数关键点，采用石川图（鱼骨图）或根因分析法（RCA），进行根本原因的分析、调研和回顾。例如：连续几个统计周期，需求交付时长变长，需要进一步调研需求在不同阶段的停留时长，找到耗时最长的阶段进行根因分析：
- 需求阶段耗时过长：需求不明确、变更频繁、需求颗粒度过大、需求优先级没有定义清楚、需求分析师或产品经理的资源或经验不足？
- 设计阶段耗时过长：需求文档不清晰、研发负责人或架构师的资源或经验不足？
- 开发阶段耗时过长：设计文档不清晰、任务分配不均匀、流负载（并行任务）过高、技术债过多、bug过多、开发人员资源或经验不足？
- 测试阶段耗时过长：需求文档不清晰、代码质量差、自动化测试少、测试人员资源或经验不足？
- 发布阶段耗时过长：构建或部署时间过长、运维人员资源或经验不足？
改进（Improve）
基于回顾结果，聚焦关键根因，从规范、流程、工具、行为等方面给出针对性改进措施，明确提升目标、改进措施、验证周期及责任人。
以下为可参考的改进思路：
- 与客户或业务方沟通明确需求、合理拆解需求和定义优先级、邀请业务方、研发负责人、测试负责人进行需求评审。
- 邀请产品经理、研发人员、测试负责人进行设计评审。
- 减小需求或任务颗粒度、均匀分配任务、降低流负载、增加单元测试、及时解决技术债和代码问题以减少bug和返工的数量。
- 测试左移、开发自测、代码评审、增加自动化测试、提升持续集成能力。
- 自动化部署、缩短构建时间、提升持续交付能力。
- 对各个岗位人员进行合理的资源分配和必要的培训。
改进成果也应当是可量化的，便于持续度量，追踪改进效果。