研发价值流图把一条需求从提出到上线的全过程拆成若干阶段，分别记录等待与处理时间，再汇总前置时间、增值比和瓶颈位置。本文给出一张填写完整的示例图，数值为演示假设，用来展示字段怎么填、数据怎么取、结论怎么读，不代表任何真实团队。
要点总览（TL;DR）
- 示例以一条中等规模需求从受理到上线为主线，按阶段记录等待时间、处理时间与完成准确率，数值为演示假设。
- 等待时间与处理时间按工作项状态变更时点切分，同一时段只计入一个阶段；完成准确率以阶段产出交付下游的次数为分母。
- 示例中前置时间 283 小时、总处理时间 59 小时、增值比约 20.8%，排期等待 96 小时为首要瓶颈。
- 改进动作需针对成因（容量不足、批次过大、评审返工）设计，并用同一口径复测对比。
- 单条需求示例只用于演示读图方法，不评价个人绩效与体验，也不能代表团队整体分布。
示例目标：这张研发价值流图要回答什么
先交代示例的设定，后面的表格和计算才有明确的解释范围。这张图是假设情景，用于演示填写方法，不对应任何真实客户或团队。
示例背景卡如下：
| 项目 | 设定 |
|---|---|
| 分析对象 | 一条中等规模需求，涉及前端页面调整与后端接口改造，需要测试验证 |
| 起点 | 需求提出并被受理登记的时刻 |
| 终点 | 需求上线完成、状态关闭的时刻 |
| 时间窗 | 从受理到上线共跨越约五周 |
| 待回答问题 | 时间主要花在哪些阶段；首要瓶颈在哪里；增值比是多少 |
| 范围限定 | 只分析工作流动，不评价人员绩效与主观体验 |
选择一条中等规模需求作为对象，是因为它通常要经过受理、评审、排期、开发、测试、发布等完整环节，字段填得满，也便于观察各阶段之间的等待。规模过小的需求可能跳过评审或测试，规模过大的需求又容易掺入跨团队协调，都会让示例失真。
这张图要回答三个问题：时间花在哪、瓶颈在哪、增值比多少。三个问题对应三类数据——各阶段等待与处理时间、等待时间排序、处理时间占前置时间的比例。示例只覆盖一条需求，结论用于演示读图方法，不用于推断团队整体水平。
完整示例：一条需求从提出到上线的价值流图
下表是填写完成的示例。阶段按工作项状态流转切分，等待时间与处理时间分列，完成准确率记录该阶段产出被下游直接接受的比例。
| 阶段 | 等待时间（小时） | 处理时间（小时） | 完成准确率 | 说明 |
|---|---|---|---|---|
| 需求受理 | 4 | 2 | 100% | 提出后进入待受理队列，受理人登记并补充背景 |
| 需求评审 | 20 | 3 | 80% | 评审一次通过，另有一次补充说明 |
| 排期等待 | 96 | 1 | 100% | 进入待排期池，等待进入迭代 |
| 开发 | 8 | 32 | 75% | 开发完成后提测，首轮提测有两处缺陷退回 |
| 测试等待 | 40 | 1 | 100% | 提测后排队等待测试资源 |
| 测试 | 6 | 16 | 70% | 两轮测试，首轮发现的问题需开发修复后复测 |
| 发布等待 | 48 | 1 | 100% | 测试通过后等待发布窗口 |
| 上线 | 2 | 3 | 100% | 发布执行与上线后确认 |
三项汇总指标按同一口径计算：
- 前置时间：各阶段等待时间与处理时间之和，合计 224 小时加 59 小时，共 283 小时，约合 11.8 个工作日（按每天 24 小时连续计时口径）。
- 总处理时间：各阶段处理时间之和，共 59 小时。
- 增值比：59 ÷ 283 ≈ 20.8%，即约五分之一的时间处于实际处理状态。
按等待时间排序，排期等待 96 小时居首，发布等待 48 小时次之，测试等待 40 小时第三。首要瓶颈是排期等待，它单独占了前置时间的三分之一左右。开发与测试两个阶段的完成准确率分别为 75% 和 70%，说明返工也在消耗流动时间，但返工时间已计入对应阶段的处理时间，不与等待时间重复计算。
逐项解释：每个字段为什么这样填
表格看起来简单，填写时的判断才是关键。下面按字段说明取数口径和常见错误。
等待时间与处理时间怎么区分
等待时间指工作项处于可流动但无人处理的状态所持续的时间，例如在待排期池中排队、提测后等待测试资源。处理时间指有人实际投入处理的时间，例如开发编码、测试执行。两者的分界是状态变更时点：工作项从“待排期”变为“开发中”，排期等待结束、开发处理开始，同一时段只计入一个阶段。
取数来源上，状态流转记录能直接给出各状态的进入与离开时间，适合计算等待时间；处理时间若系统只记录状态区间，需要人工确认其中实际投入的部分，例如开发阶段中等待联调的时间是否剔除。示例中开发处理时间取 32 小时，是按开发人员实际投入估算，属于需要人工确认的数据。
完成准确率怎么定义
完成准确率指该阶段产出被下游直接接受、无需退回补充或修复的比例。示例中需求评审准确率 80%，对应一次评审通过、一次补充说明；开发准确率 75%，对应首轮提测有两处缺陷退回；测试准确率 70%，对应首轮测试发现的问题需要修复后复测。统计时以阶段产出交付下游的次数为分母，首次即被接受的次数为分子。
阶段边界怎么切
切分原则是按工作项状态流转，相邻阶段以状态变更时点为界，跨阶段的时间不重复计时。常见错误是把“提测”既算作开发结束又算作测试开始，导致同一小时被计入两个阶段。修正方式是明确每个状态只归属一个阶段，边界时点取状态变更记录中的时间戳。
常见填写错误与修正
| 错误 | 后果 | 修正方式 |
|---|---|---|
| 等待与处理混算 | 增值比虚高，看不出排队问题 | 按状态区分，处理时间只计实际投入 |
| 阶段重叠计时 | 前置时间被放大 | 每个状态只归属一个阶段，边界取变更时点 |
| 返工时间漏记 | 处理时间偏小，瓶颈判断失真 | 返工计入对应阶段处理时间 |
| 准确率按人次统计 | 与阶段产出口径不一致 | 以阶段产出交付次数为分母 |
数据来源可以分两类：状态流转时间戳、提测与缺陷记录来自系统，属于可追溯数据；实际投入工时、评审补充说明的原因往往需要人工确认。两类数据在表中应能区分，复测时才能保证口径一致。工作项状态流转记录是这类数据的主要来源，ONES 的工作项状态变更会留下时间记录，可作为等待时间与阶段边界的取数依据；实际投入部分仍需团队按统一口径补充确认。
从示例读出的瓶颈与改进切入点
读图的第一步是按等待时间排序，找出占比最大的环节。示例中排期等待 96 小时、发布等待 48 小时、测试等待 40 小时，三者合计 184 小时，占前置时间的六成以上。这说明流动时间主要消耗在排队，而非处理。
第二步是判断成因。同样是等待，成因不同，改进动作也不同：
- 容量不足：等待队列持续变长，处理方长期满负荷。示例中测试等待 40 小时，若测试人力固定而提测集中，属于此类。
- 批次过大：一次排入过多需求，导致单个需求在队列中停留更久。示例中排期等待 96 小时，若每个迭代排入的需求数量远超团队吞吐，属于此类。
- 评审返工：需求在评审或提测阶段被退回，重新进入等待。示例中开发准确率 75%，返工使需求二次排队。
第三步是针对首要瓶颈给出可验证的改进动作。以排期等待为例，可尝试限制每个迭代的排入数量、按吞吐能力控制队列长度，观察下一个统计周期内排期等待是否下降。以测试等待为例，可尝试提测前增加准入检查、分散提测时点。以返工为例，可在评审环节增加验收标准确认，观察开发准确率是否上升。
改进后必须用同一阶段划分、同一取数口径、同一统计周期复测，才能与改进前对比。示例中的 96 小时是基线，复测时若排期等待降到 60 小时而其他阶段不变，前置时间相应缩短，增值比上升，这样的对比才有意义。复测数据同样依赖状态流转记录的完整性，ONES 中按状态区间导出时间数据，可以减少人工汇总的偏差。
可迁移规律：换一个团队怎么套用
示例的数值不能照搬，方法和调整点可以复用。套用分四步：
- 确定分析对象与起止点。选一条有代表性的需求，明确从哪个状态开始、到哪个状态结束。
- 按自身研发模式划分阶段。迭代制团队可保留排期等待与发布等待；看板制团队可把阶段切得更细，按列的状态流转划分；持续交付程度高的团队，发布等待可能很短，阶段可合并。
- 统一取数口径并采集数据。先约定等待与处理的区分规则、准确率的统计分母，再取数，避免边取边改口径。
- 计算指标、排序瓶颈、制定改进动作，并在下一周期复测。
需要调整的项包括：阶段数量随流程复杂度增减；统计周期按迭代长度或发布节奏选择，周期太短样本不足，太长则掩盖波动；数据采集频率可与迭代评审同步，避免临时补录。
小样本与数据缺失时的处理：单条需求只能演示方法，要判断团队整体情况，需按需求类型抽样，例如抽取一个季度内同类中等规模需求若干条，分别填写后看分布而非单点。某阶段状态记录缺失时，可用相邻状态的变更时点推算，并在表中标注为估算值，复测时保持同样的估算方式。抽样时注意覆盖不同规模与不同提出方，避免只选顺利走完的需求。
适用边界：这张图能说明什么、不能说明什么
价值流图的结论有明确解释范围，越界使用容易得出错误判断。
| 能说明 | 不能说明 |
|---|---|
| 一条需求在各阶段的等待与处理分布 | 某个人的工作效率或绩效水平 |
| 当前流程中排队最严重的环节 | 团队整体的流动水平（单条需求不足以代表分布） |
| 在统一口径下改进前后的对比 | 口径不一致时的跨团队比较 |
| 返工对流动时间的影响程度 | 开发者的主观体验与协作感受 |
这张图只反映工作流动，不评价个人绩效与体验。等待时间长可能来自排期机制、资源分配或需求批次安排，把它归因到个人既不准确也无助于改进。单条需求示例不能代表整体分布，要得出团队层面的结论，需要按类型抽样并看分布。
数据口径不一致时结论不可比。两个团队若对等待与处理的划分不同、统计周期不同，直接比较增值比没有意义。价值流图与项目进度纠偏、开发者体验议题各有分工：进度纠偏关注单个项目是否按计划推进，价值流图关注工作在各阶段的停留；开发者体验关注人的感受与负担，价值流图不覆盖这部分内容。三类分析可以并列使用，结论不宜互相替代。
常见问题
示例中的数值是真实团队的数据吗？
不是。示例数值为演示假设，用于展示字段怎么填、数据怎么取、结论怎么读，不代表任何真实团队或客户案例。套用时需要替换为自己团队按统一口径采集的数据。
等待时间和处理时间在系统里怎么区分？
按工作项状态变更时点切分：工作项处于可流动但无人处理的状态所持续的时间计为等待时间，有人实际投入处理的时间计为处理时间。状态流转记录能直接给出各状态的进入与离开时间，适合计算等待时间；处理时间若系统只记录状态区间，需要人工确认其中实际投入的部分，并在表中标注估算口径。
单条需求的价值流图能用来判断团队整体效率吗？
不能。单条需求只能演示方法，要判断团队整体情况，需按需求类型抽样，例如抽取一个季度内同类中等规模需求若干条，分别填写后看分布而非单点。抽样时注意覆盖不同规模与不同提出方，避免只选顺利走完的需求。
改进后复测需要注意什么？
复测必须使用同一阶段划分、同一取数口径和同一统计周期，才能与改进前数据对比。若阶段边界、等待与处理的区分规则或统计周期发生变化，前后数据不可比。复测数据同样依赖状态流转记录的完整性，建议在改进前就固定取数方式。
价值流图和项目进度管理、开发者体验分析是什么关系？
三者各有分工：价值流图关注工作在各阶段的停留与流动瓶颈；项目进度管理关注单个项目是否按计划推进；开发者体验关注人的感受与负担。三类分析可以并列使用，结论不宜互相替代。价值流图不评价个人绩效与主观体验。
