设计累积流图，先要锁定统计口径，再画图：确定观察哪类工作项、从哪个状态算到哪个状态、每天何时取数，然后把真实流转状态映射成4–7个列，逐日累加各列在制品数量并绘成条带。本文按口径、列映射、取数绘图、角色分工、读图示例和完成检查六步展开，示例数据均为示意。
要点总览（TL;DR）
- 先锁定统计口径：选择单一工作项类型作为流动单元，明确起点状态、终点状态、统计时间窗和每日取数时点，并把口径变更记录在图上。
- 把真实流转状态映射成4–7个列，区分处理中与等待中，每列定义进入事件与离开事件，保证计数可判定且状态不重叠。
- 每日同一时点统计各列在制品数量，按列顺序累加后绘制堆叠面积图，缺数日保留位置并标注，避免斜率被误读。
- 读图看三类信号：某列条带持续变宽表示堆积，整体斜率变平表示交付速率下降，等待列与处理列宽度对比帮助判断瓶颈位置。
- 用完成检查清单核对口径唯一、列覆盖完整、取数连续、变更可追溯、结论可落地，全部通过后再进入固定取数与读图循环。
先定统计口径：画什么工作项、从哪算到哪
累积流图失真的最常见原因，是统计口径在观察期内悄悄变化。同一张图上如果今天统计需求、明天把缺陷也算进来，条带宽度就不再反映真实的堆积。因此设计的第一步是把口径写成一份可查的表，并在开始取数前确认一次。
口径需要锁定四项内容：流动单元、起止状态、统计时间窗与取数时点、变更记录方式。这四项确定后，后续的列划分和取数才有稳定基础。
| 口径要素 | 需要确定的内容 | 示例写法 |
|---|---|---|
| 流动单元 | 单一工作项类型，不同时混合需求、缺陷、任务 | 统计对象为“产品需求”，缺陷单独出图 |
| 起点状态 | 从哪个状态开始计入流动 | 从“已确认”状态起算，草稿阶段不计入 |
| 终点状态 | 到哪个状态视为完成并离开图 | 到达“已上线”即视为完成 |
| 统计时间窗 | 观察的起止日期 | 2025年1月1日至3月31日 |
| 取数时点 | 每日固定的统计时刻 | 每日18:00统计当日状态 |
| 变更记录 | 口径调整的时点与内容 | 2月15日新增“待评审”列，图上标注竖线 |
选择单一工作项类型的理由在于，不同性质的工作项流动规律差异明显。需求从确认到上线往往经历多轮评审与等待，缺陷则可能快速修复。混在同一张图里，两类堆积叠加在同一条带上，读图时无法判断究竟是哪类工作卡住。
起止状态决定了图的边界。起点之前的状态不计入，意味着图上的总量只反映进入流动之后的工作；终点之后的状态同理。边界一旦确定，观察期内应保持一致。若中途因流程调整必须变更，应在图上用竖线或注释标出变更日期，并说明变更内容，避免把变更前后的曲线直接比较斜率。
完成标志：口径定义表填写完整并经团队确认，表中每一项都有明确取值，没有“视情况而定”的模糊项。
把真实流转状态映射成列
列是累积流图的骨架。列划分的目标，是让每一列对应一个可观察的等待或处理状态，使条带宽度能直接回答“工作卡在哪”。列数建议控制在4–7个，过少会掩盖中间环节的堆积，过多则条带细碎、难以辨认趋势。
划分时优先区分处理中与等待中。处理中表示有人正在推进，等待中表示工作项已就绪但尚未被接手。等待列往往是堆积最先出现的位置，也是识别瓶颈的重要观察点。如果团队流程中存在明显的排队环节，例如等待评审、等待测试环境、等待发布窗口，应单独成列。
每列必须定义进入事件与离开事件，使计数可判定。进入事件是工作项被计入该列的条件，离开事件是它离开该列的条件。两个事件应能通过工作项的状态字段或看板位置直接判断，不依赖人工回忆。
| 列名称 | 类型 | 进入事件 | 离开事件 |
|---|---|---|---|
| 待分析 | 等待 | 需求状态变为“已确认” | 开始分析，状态变为“分析中” |
| 分析中 | 处理 | 状态变为“分析中” | 分析完成，提交评审 |
| 待评审 | 等待 | 提交评审，状态变为“待评审” | 评审通过，状态变为“开发中” |
| 开发中 | 处理 | 状态变为“开发中” | 开发完成，提交测试 |
| 待测试 | 等待 | 提交测试，状态变为“待测试” | 测试开始，状态变为“测试中” |
| 测试中 | 处理 | 状态变为“测试中” | 测试通过，状态变为“已上线” |
列与看板列或工作项状态字段应保持一一对应。一个状态只能归入一列，一列可以合并多个语义相近的状态，但不能出现同一状态被两列同时计入的情况。映射关系确定后，写入映射表并作为取数依据。
完成标志：状态—列映射表覆盖全部流转状态，每列都有明确的进入与离开事件，且不存在状态重叠或遗漏。
每日取数与绘制步骤
取数与绘图是一个固定节奏的重复动作，关键在于时点固定、口径一致、记录可追溯。操作流程如下：
- 每日同一时点，按映射表统计各列当前的工作项数量。统计对象只包含已进入起点状态、尚未到达终点状态的工作项。
- 将当日各列数量按列顺序累加。第一列的累计值等于该列数量，第二列的累计值等于第一列累计值加第二列数量，依此类推。累加结果构成各条带的边界。
- 把每日的累加结果记录到取数记录表中，一行对应一天，一列对应一个累计边界。
- 用表格或图表工具绘制堆叠面积图。横轴为日期，纵轴为累计工作项数量，每一层对应一列，层与层之间的宽度即该列的在制品数量。
数据缺失日的处理需要事先约定。推荐做法是在图上保留该日期位置并标注“缺数”，而不是直接跳过。跳过会让横轴时间间隔不均，曲线斜率被误读为交付速率变化。若缺失较多，应在读图结论中说明数据完整性对判断的影响。
完成标志：取数记录表连续覆盖统计时间窗内的每个工作日，累积流图初版绘制完成，缺数日已标注。
在状态映射与每日取数环节，如果团队使用ONES管理需求与任务，工作项的状态字段和流转记录可以作为取数依据：按状态筛选当前工作项数量，按状态变更时间还原每日各列的在制品数。这样口径与系统记录保持一致，减少人工统计的偏差。具体字段与报表能力以团队实际配置为准。
角色分工与交付物
累积流图要持续可用，需要把维护数据、读图分析和改进承接分开到人。角色不清时，图往往画了几周就中断，或者读出的结论无人跟进。
| 角色 | 职责 | 交付物 | 频率 |
|---|---|---|---|
| 数据维护人 | 按口径每日取数，记录缺数，维护映射表 | 取数记录表、更新后的累积流图 | 每日 |
| 读图责任人 | 定期读图，识别堆积点与斜率变化，组织分析 | 读图分析记录，含结论与对应列 | 每周或每迭代 |
| 改进承接人 | 针对确认的瓶颈列制定并执行改进动作 | 改进事项及跟踪状态 | 按改进周期 |
数据维护人通常由团队内熟悉工作项状态的人担任，重点是保证每日取数时点一致、口径不变。读图责任人一般由团队负责人或流动效率责任人承担，职责是把图上的信号转化为具体问题，例如“待评审列连续两周变宽”，并组织相关角色分析原因。改进承接人则针对确认的瓶颈列采取动作，例如调整评审排期或增加测试资源，并在下一次读图时核对条带是否收窄。
三个角色的交付物应能相互衔接：取数记录表支撑读图分析，读图结论指向具体列，改进事项对应到列并留下跟踪记录。完成标志：角色与交付物清单经团队确认，每个角色知道自己的产出和更新频率。
读图示例：从条带变化定位瓶颈
以下示例为示意数据，用于说明读图方法，不作为任何团队或产品的实测结论。
假设某团队统计四周的需求流动，列依次为待分析、分析中、待评审、开发中、待测试、测试中。前两周各条带宽度大致稳定，整体累计曲线以较陡的斜率上升。第三周起出现两个变化：待评审列的条带持续变宽，从约3个需求增至8个；整体曲线的斜率变平，每周完成的需求数量下降。
读图时可以按三个信号依次判断：
- 某列条带持续变宽，表示该处工作项堆积。示例中待评审列变宽，说明评审环节的进入速度大于离开速度。
- 整体斜率变平，表示交付速率下降。示例中曲线斜率在第三周后变缓，与待评审堆积出现的时间吻合。
- 对比等待列与处理列，判断瓶颈位置。示例中“分析中”和“开发中”两个处理列的宽度没有明显增加，而“待评审”这一等待列显著变宽，说明瓶颈更可能位于评审环节的等待，而非分析与开发的处理能力。
据此可以形成一条可行动的结论：待评审列堆积导致整体交付变慢，改进动作应聚焦评审的排期与人力安排。下一次读图时，观察待评审列条带是否收窄、整体斜率是否恢复，作为改进是否有效的判断依据。
完成标志：读图结论能对应到具体列，并转化为一条可跟踪的改进动作。
完成检查：图是否可用
在把累积流图用于日常分析之前，逐项核对以下检查项。全部通过，说明设计达到可用状态；有未通过项，先修正再开始读图。
- 口径唯一且已记录：流动单元为单一工作项类型，起止状态、统计时间窗、取数时点均已写入口径定义表。
- 列覆盖完整且无重叠：状态—列映射表覆盖全部流转状态，每个状态只归入一列，每列都有进入事件与离开事件。
- 列数适中：列数在4–7个之间，等待列与处理列区分清楚。
- 取数连续、时点固定：取数记录表覆盖统计时间窗内每个工作日，缺数日已标注，取数时点前后一致。
- 变更可追溯：口径或列调整的日期与内容已在图上标注，变更前后曲线未被直接比较。
- 读图结论可落地：每条读图结论对应到具体列，并有承接人与跟踪方式。
- 角色与交付物明确：数据维护人、读图责任人、改进承接人的职责与产出已确认。
完成标志：检查清单逐项通过并留存记录，累积流图进入固定节奏的取数与读图循环。
常见问题
团队同时有需求和缺陷，能不能画在同一张累积流图上？
建议分开出图。需求和缺陷的流动规律差异明显：需求往往经历多轮评审与等待，缺陷可能快速修复。混在同一张图里，两类堆积会叠加在同一条带上，读图时无法判断究竟是哪类工作卡住。如果确实需要在一张图上观察，至少应把流动单元限定为单一类型，另一类单独统计。
列数超过7个会有什么影响，怎么精简？
列数过多会让条带细碎，趋势难以辨认，读图时容易把局部波动当成堆积信号。精简的做法是把语义相近、且团队很少单独关注的状态合并为一列，例如把多个等待评审的子状态合并为“待评审”。合并的前提是进入事件与离开事件仍能通过状态字段明确判定，且合并后不丢失关键等待环节。
中途流程调整新增了一个状态，图还能继续用吗？
可以继续用，但需要在图上标注变更。新增状态意味着列映射发生变化，变更前后的条带宽度不具备直接可比性。推荐做法是在变更日期处画一条竖线或加注释，说明新增了哪一列、从哪天开始生效；读图时把变更前后分段分析，不直接比较整体斜率。
某天忘记取数，应该补数据还是跳过？
建议保留该日期位置并标注“缺数”，不要直接跳过。跳过会让横轴时间间隔不均，曲线斜率被误读为交付速率变化。如果缺失天数较少，可在读图结论中说明数据完整性对判断的影响；如果缺失较多，应重新评估这段时间的读图结论是否可靠。
读图发现某列堆积，下一步应该做什么？
先把结论落到具体列，再组织相关角色分析原因。以“待评审”列持续变宽为例，需要确认是评审人力不足、评审排期集中，还是提交评审的节奏过于集中。确认原因后制定改进动作，指定承接人，并在下一次读图时观察该列条带是否收窄、整体斜率是否恢复，作为改进是否有效的判断依据。
