设计研发价值流图，先选一条有代表性的需求流，按工作项状态拆成可观测的环节，分别记录每个环节的处理时间与等待时间，再计算流动效率和前置时间，把等待最长、积压最多的环节列为瓶颈并安排改进与复测。图的价值在于用同一口径反复测量，画一次就归档的图很难支撑决策。下面按范围、环节、取数、指标、瓶颈、分工、示例和检查的顺序展开。
要点总览（TL;DR）
- 先选一条有代表性的需求流并写清对象、起点、终点、时间窗口与样本量，范围宜控制在8到15个环节，保证取数与复核可完成。
- 环节按工作项状态的进入与退出切分，每个环节定义进入条件与完成标志，处理时间与等待时间在同一环节内分别计量。
- 时间数据优先从工作项状态变更记录提取，处理时间与等待时间采用统一口径；样本不足或记录缺失时缩小结论范围并标注有效样本量。
- 流动效率＝处理时间合计÷前置时间合计，配合前置时间与在制品、积压一起解读，指标作为比较基线而非考核分数。
- 瓶颈按等待时长与积压量排序，区分容量不足、交接等待与返工三类成因，每条改进动作落到负责人与复测时点，复测沿用同一口径。
先定范围：画哪条价值流、画到哪一步
价值流图的第一项产出是范围说明，它决定后面所有数字能不能比较。研发部门同时存在需求交付、缺陷修复、技术优化等多条流，混在一张图里统计，环节数量和停留时长都会失真。起步阶段选一条发生频率高、参与角色完整、结果可验收的需求类型作为对象，例如面向外部客户的业务需求，或某个产品线的迭代需求。
范围说明需要写清五项内容：
- 对象：哪一类需求，用一句话描述其共同特征，例如“由客户提出、需要产品与研发共同评估的功能需求”。
- 起点：需求提出，或需求通过评审进入研发。两者取哪个，取决于你想分析的是“从想法到上线”还是“从排期到交付”，选定后全文统一。
- 终点：上线发布，或交付验收通过。若上线后还有灰度观察期，明确是否计入。
- 时间窗口与样本量：例如取最近一个季度内完成的全部该类需求，样本量记为 N。样本太少时结论只能作为方向参考，需在图上标注。
- 排除项：紧急插单、被取消的需求、跨团队联合交付中由其他团队负责的段落，逐项写明不纳入的原因。
范围宜小不宜大。一条流包含 8 到 15 个环节时，取数和绘图都还能人工完成；环节超过 20 个，口径统一和复核成本会迅速上升。范围说明完成后由主导角色与业务方确认一次，避免中途改边界导致前后数据不可比。
拆解流程环节与状态：把研发过程切成可观测的段
环节划分的锚点是工作项状态的进入与退出。一个环节对应工作项在某状态或某组状态上的停留，进入条件说明什么情况下算进入该环节，完成标志说明什么条件下算离开。这样划分的好处是停留时长可以直接从状态变更记录中提取，不依赖个人回忆。
划分时遵循三条规则。第一，按实际交接点切分，而不是按组织架构切分；一个环节内如果发生多次角色交接，应拆成多个环节。第二，每个环节只对应一种主要工作内容，例如“需求评审”“方案设计”“开发实现”“测试验证”“发布上线”。第三，环节名称使用团队日常称呼，避免为画图另造一套术语。
处理时间与等待时间在同一环节内区分：处理时间指有人实际投入工作的时间，等待时间指工作项停留在该状态但无人处理的时间。以“测试验证”为例，进入条件是提测单提交且构建通过，完成标志是测试报告出具；测试人员实际执行用例的时长计入处理时间，提测后排队等待测试资源的时长计入等待时间。
| 环节名称 | 进入条件 | 完成标志 | 负责角色 | 是否并行 |
|---|---|---|---|---|
| 需求评审 | 需求单提交 | 评审结论记录完成 | 产品负责人 | 否 |
| 方案设计 | 评审通过 | 设计文档评审通过 | 技术负责人 | 否 |
| 开发实现 | 任务拆分完成 | 代码合并至主干 | 开发工程师 | 可与部分测试准备并行 |
| 测试验证 | 提测单提交 | 测试报告出具 | 测试工程师 | 否 |
| 发布上线 | 测试通过 | 生产环境验证完成 | 运维或发布负责人 | 否 |
并行环节在图上用并列分支表示，统计前置时间时按实际时间跨度计一次，不重复累加。返工回流单独画一条回退箭头，例如测试不通过退回开发实现，回退产生的额外停留时间计入对应环节，并在数据表中单独标注返工次数，便于后续区分容量问题与质量问题。
采集时间数据：等待时间怎么量、处理时间怎么取
时间数据的首选来源是工作项状态变更记录。每条记录包含状态、变更时间和操作人，把同一工作项的状态序列按时间排序，相邻两次变更的时间差就是该状态的停留时长。将停留时长按环节归集，即可得到每个环节的平均停留时间。停留时间中属于有人处理的部分记为处理时间，其余记为等待时间。
处理时间的取法有两种常见口径，选定一种并在全图统一。第一种按状态细分：如果团队把“处理中”和“待处理”拆成不同状态，停留时长可直接对应。第二种按投入记录：结合工时填报或每日站会记录，估算环节内实际投入的人天。第一种口径稳定、可批量提取，适合作为主口径；第二种更贴近真实投入，适合在关键环节做抽样校准。
数据缺失时的处理原则是缩小结论范围，而不是补估算值。常见情况包括：状态被跳过导致某环节时长为零、状态被批量变更导致停留时长失真、历史记录不完整。对应做法是剔除异常样本、在数据表中标注有效样本量，并在结论中写明“基于 N 条有效样本”。样本量低于约定下限时，图仍可绘制，但瓶颈结论只作为待验证假设。
数据采集需要指定责任人与核对方式。通常由效能或项目管理角色负责提取，各环节负责人核对本环节的进入条件与完成标志是否与实际一致，核对结果记录在数据表备注列。核对完成后数据表冻结版本，后续复测沿用同一口径。
当团队使用 ONES 管理需求与任务时，工作项的状态流转记录可以作为停留时长的取数基础，按需求类型筛选后导出各状态的变更时间，再按本文口径归集为处理时间与等待时间。具体字段与导出方式建议在自身环境中先行核验，确认与团队实际状态设置一致后再批量取数。
计算流动指标：流动效率、前置时间与在制品
三个指标构成价值流图的核心读数，计算口径必须在图上注明，复测时保持不变。
- 前置时间：从起点到终点的时间跨度。起点取需求提出时，前置时间包含评审前的排队；起点取进入研发时，前置时间只覆盖研发段。两种口径不能混用。
- 流动效率：处理时间合计除以前置时间合计，结果以百分比表示。例如前置时间合计 20 天、处理时间合计 5 天，流动效率为 25%。
- 在制品与积压：在制品指统计时点处于流程中尚未完成的工作项数量；积压指某环节入口处等待进入的工作项数量。两者按环节分别统计，取时间窗口内的平均值或时点快照，注明取法。
| 环节 | 有效样本量 | 平均处理时间（天） | 平均等待时间（天） | 平均停留时间（天） |
|---|---|---|---|---|
| 需求评审 | 30 | 0.5 | 1.5 | 2.0 |
| 方案设计 | 30 | 1.0 | 2.0 | 3.0 |
| 开发实现 | 30 | 4.0 | 2.0 | 6.0 |
| 测试验证 | 30 | 2.0 | 4.0 | 6.0 |
| 发布上线 | 30 | 0.5 | 2.5 | 3.0 |
| 合计 | — | 8.0 | 12.0 | 20.0 |
上表为演示数据，用于说明填写方式。按此计算，流动效率为 8÷20＝40%，前置时间为 20 天。解读时注意三个边界：流动效率低说明等待占比高，不直接说明人员不努力；前置时间受样本构成影响，混入大需求会拉高均值，应按需求规模分层看；在制品高与前置时间长通常同向变化，但因果需要结合环节积压数据判断。把指标当作比较基线，而不是考核分数，才能避免团队为改善数字而调整状态填写方式。
定位瓶颈并形成改进动作
瓶颈识别按两个维度排序：等待时长和积压量。等待时长最长的环节直接拉低流动效率，积压量最大的环节说明上游产出速度超过下游消化能力。两个维度指向同一环节时，该环节是首要改进对象；指向不同环节时，先处理积压量大的环节，因为它会持续放大后续等待。
成因分三类，对应不同动作：
| 成因类型 | 典型表现 | 改进动作 | 预期影响 |
|---|---|---|---|
| 容量不足 | 某环节长期排队，处理时间稳定但等待持续增长 | 调整人员配比、限制上游投入量、设置该环节的在制品上限 | 该环节等待下降，前置时间缩短 |
| 交接等待 | 环节之间信息不全、需反复确认才能开始 | 明确进入条件与交付模板，约定交接响应时限 | 环节间空转时间减少 |
| 返工 | 回退次数多，同一工作项重复经过某环节 | 在返工集中的环节前置检查项，补充评审或自动化校验 | 返工次数下降，有效处理时间占比上升 |
每个瓶颈项写成一条改进动作，包含环节、成因、动作、负责人和复测时间。复测时点建议设在动作落地后的一个完整统计周期，沿用同一范围、同一环节划分和同一取数口径，对比等待时长、积压量和流动效率三项变化。动作未产生预期影响时，回到成因判断，而不是直接追加资源。
角色分工与交付物清单
价值流图需要三类角色：主导角色负责范围确定、环节划分、指标计算和版本维护，通常由效能负责人或研发管理者担任；数据提供角色由各环节负责人承担，负责核对本环节的进入条件、完成标志与停留数据；评审角色由业务方和技术负责人组成，确认范围合理、结论可信、改进动作可执行。
| 角色 | 数据采集 | 绘图与计算 | 评审 | 版本更新 |
|---|---|---|---|---|
| 主导角色 | 提取状态记录、汇总数据表 | 绘制价值流图、计算指标 | 组织评审 | 负责 |
| 环节负责人 | 核对本环节数据与口径 | 提供环节说明 | 参与 | 配合 |
| 业务与技术评审方 | — | — | 确认范围与结论 | 知会 |
交付物清单包括：范围说明、环节清单表、时间数据表、指标计算表、标注数值的价值流图、瓶颈与改进动作表。所有交付物标注版本号与数据截止日期，存放在团队可访问的同一位置。版本更新责任归主导角色，触发条件为改进动作复测完成或范围发生变更。
一个示例：从需求提出到上线的价值流图
以下为演示情景，数据为虚构，用于展示完整填写过程。某团队选择“客户提出的功能需求”作为对象，起点为需求提出，终点为上线验证完成，时间窗口为最近一个季度，有效样本 30 条，排除紧急插单和被取消需求。
环节按状态划分为需求评审、方案设计、开发实现、测试验证、发布上线五段，其中开发实现与测试准备存在部分并行，按实际时间跨度计一次。时间数据见前文指标章节的表格：处理时间合计 8 天，等待时间合计 12 天，前置时间 20 天，流动效率 40%。
按等待时长排序，测试验证等待 4 天为最长，发布上线等待 2.5 天次之；按积压量统计，测试验证入口平均积压 6 项，为全流程最高。两个维度指向同一环节，判定测试验证为首要瓶颈。进一步查看成因：测试资源在迭代末期集中排队，属于容量不足；提测材料不完整导致测试启动延迟，属于交接等待；测试不通过退回开发 4 次，属于返工。
据此提出三条动作：为测试环节设置进入的在制品上限，超过上限时上游暂停提测；统一提测模板，明确环境、账号、变更说明三项必填；在开发实现环节增加自测检查项，减少提测后返工。负责人分别为测试负责人、产品负责人和开发负责人，复测时间设为一个迭代结束后，沿用同一口径对比测试验证等待时长与流动效率。
完成检查：这张图能不能用来做决策
交付前逐项核对，任一项不通过则回到对应章节修正，不带着口径问题进入评审。
- 范围一致：对象、起点、终点、时间窗口、样本量和排除项在范围说明、数据表和图上表述一致，没有中途改边界。
- 环节可观测：每个环节都有进入条件和完成标志，环节负责人确认与实际状态设置相符，并行与返工有明确表示方式。
- 数据可追溯：每个环节的时间数据标注来源、有效样本量和取数口径，异常样本的剔除有记录，处理时间与等待时间的划分规则全文统一。
- 指标可复算：前置时间、流动效率、在制品与积压的计算过程可从上表数据复算得出，图上标注的数值与计算表一致。
- 瓶颈有支撑：瓶颈结论同时给出等待时长与积压量依据，成因归类有数据或记录支持，不凭印象指定。
- 动作可执行：每条改进动作落到具体环节、负责人和复测时点，预期影响可观察，复测口径与本次一致。
六项全部通过，这张图就可以作为团队讨论流动效率的共同基线；后续每次复测沿用同一结构，只更新数据与结论，逐步形成可比较的趋势记录。
常见问题
团队刚开始做价值流图，样本量很少怎么办？
样本量少时图仍然可以画，但结论要降级使用。做法是：在范围说明中写清有效样本量，数据表中标注每个环节的样本数，瓶颈结论表述为“待验证假设”，并在评审时说明后续需要补充的样本来源。若某环节有效样本低于约定下限，可以先合并相邻环节减少分段，或延长统计窗口，而不是用估算值填补缺失数据。等样本积累到约定数量后，用同一口径重新计算，再确认或修正此前的瓶颈判断。
状态变更记录不完整，比如状态被跳过或批量变更，怎么处理？
先识别异常样本再决定取舍。状态被跳过导致某环节停留时长为零的，剔除该样本；状态被批量变更导致停留时长明显失真的，同样剔除，并在数据表备注列记录剔除原因和数量。剔除后如果某环节有效样本不足，可以缩小结论范围，只对样本充足的环节下判断。同时建议在流程侧做一次状态设置核对，确认状态与实际交接点对应，减少后续取数时的失真。核对结果由各环节负责人确认，避免只由取数一方判断。
流动效率算出来偏低，是不是应该直接加人？
不建议直接加人。流动效率低说明等待时间占比高，但等待的成因不同，动作也不同：容量不足表现为某环节长期排队、处理时间稳定而等待持续增长，此时调整人员配比或设置该环节在制品上限有效；交接等待表现为信息不全、反复确认才能开始，应先明确进入条件与交付模板；返工表现为同一工作项重复经过某环节，应在前置环节增加检查项。先按等待时长和积压量定位到具体环节，再判断成因，最后决定是否追加资源。加人只对容量不足一类成因直接有效。
价值流图多久复测一次比较合适？
复测时点跟随改进动作的落地节奏，通常设在动作落地后的一个完整统计周期，例如一个迭代结束后。复测时沿用同一范围、同一环节划分和同一取数口径，只更新数据与结论，对比等待时长、积压量和流动效率三项变化。如果动作未产生预期影响，回到成因判断重新分析，而不是直接追加资源。范围发生变更或流程状态调整时，应重新做一次范围说明并标注版本，避免新旧数据混在一起比较。
价值流图和团队日常的迭代看板是什么关系？
两者用途不同。迭代看板服务于日常任务推进，关注当前工作项在哪个状态、谁在处理；价值流图服务于流动分析，关注一类需求从提出到上线在各环节停留了多久、等待集中在哪。价值流图的环节划分可以直接对应看板上的状态列，这样状态变更记录就能作为取数来源，不需要另建一套记录。设计时保持环节名称与看板状态一致，可以减少核对成本；如果看板状态过细，可以在价值流图中合并相邻状态，但合并规则要在数据表中写明，复测时保持不变。
