研发在制品数量（WIP）指在统计时点或时间窗内，已进入研发流程、尚未完成的工作项数量。要算得可复算，需要先定统计对象、流程边界和统计方式，再按状态过滤计数。本文给出时点WIP与区间平均WIP的公式、取数与清洗规则、一个两周迭代的完整算例，并说明数字的解读边界。
要点总览（TL;DR）
- 研发在制品数量（WIP）指统计时点或时间窗内已进入研发流程、尚未完成的工作项数量，计算前先定统计对象、起始与完成状态、时间窗。
- 时点WIP＝统计时点处于在制状态的工作项数；区间平均WIP＝各时点WIP之和÷有效统计时点数，分母为零或时点缺失时标记无效、不参与平均。
- 数据取自工作项状态字段与状态变更历史，状态回退、重开、跨项目流转、拆分合并取消都要在取数规则中写明处理方式。
- WIP需与完成速率、周期时间在同一时间窗内对照解读，单指标不构成瓶颈结论；不设通用达标线，基线来自团队自身历史数据。
- 跨团队比较前先对齐工作项粒度与状态定义，报告应同时写明口径与取数方式，保证他人可复算。
先明确评估目标：WIP数量要回答什么问题
算WIP之前先回答一个问题：这个数字要支撑什么判断。目标不同，统计对象、时间窗和呈现方式都会变化。常见的评估目的有三类。
第一类是识别在制堆积。团队感觉“事情很多但推不动”时，WIP按状态分组后能看出堆积集中在哪个环节，例如开发完成待测试的数量持续偏高。这类目的适合用日快照加状态构成，观察一段时间内的变化趋势。
第二类是判断流动是否受阻。当WIP持续上升而完成速率没有同步提高，说明新工作进入的速度快于完成的速度，流程中存在阻塞点。这类目的需要WIP与完成速率、周期时间放在同一时间窗内对照。
第三类是为限制在制提供基线。团队准备引入WIP上限时，需要先知道当前各环节的实际在制水平，作为设定上限和后续观察效果的起点。这类目的要求口径稳定、可重复计算，否则前后数字无法比较。
不同目的对应不同的统计选择：识别堆积偏向细粒度状态分组和较短时间窗；判断受阻需要与速率指标对齐时间窗；设定基线则要求口径在多个周期内保持一致。本文的范围限于工作流动层面的WIP计算与解读，不涉及人员主观体验评估，也不用于单个项目的进度纠偏与排期调整。
指标与范围：统计对象、流程边界与时间窗
WIP的定义看似简单，实际计算中最容易出问题的是边界。以下五个要素需要在取数前写清楚，形成一份口径定义表，供他人复算。
| 口径要素 | 需要明确的内容 | 常见选择 |
|---|---|---|
| 统计对象 | 计数的基本单位 | 需求、用户故事、任务、缺陷 |
| 起始状态 | 从哪个状态开始算“在制” | 进入开发、就绪、已排期 |
| 完成状态 | 到哪个状态算“已完成” | 已上线、已验收、已关闭 |
| 时间窗 | 统计的时点或区间 | 时点快照、日快照、周平均 |
| 统计范围 | 按什么组织维度汇总 | 团队、项目、价值流 |
统计对象决定粒度。以需求为单位和以任务为单位，同一时间段算出的WIP可能相差数倍，两组数字不能直接比较。选定一种对象后，跨周期、跨团队都应沿用同一种，除非明确说明口径变更。
流程边界的界定直接影响分子。起始状态定得早，等待排期的工作也会计入在制；定得晚，则开发前的准备阶段被排除。完成状态同理：以“已上线”为完成，测试通过但未发布的工作仍算在制；以“已验收”为完成，则发布后等待验收的时间也计入。两种选择都合理，关键是写清楚并保持一致。
时间窗决定统计方式。时点快照取某一时刻的在制数量，适合快速查看当前状态；日快照每天记录一次，适合观察趋势；周平均把一周内的日快照取平均，能平滑单日波动。三种方式的结果不同，报告中应注明采用的是哪一种。
统计范围需要与组织实际对齐。按团队统计适合团队自我管理，按项目统计适合跨职能协作观察，按价值流统计适合端到端流动分析。范围一旦交叉，例如一个工作项同时属于两个团队，需要在口径中约定归属规则，避免重复计数。
数据口径与证据：从工作项状态取数
WIP的数据来源是工作项管理系统中的状态字段与状态变更历史。当前状态字段支持时点快照，状态变更历史支持还原任意历史时点的状态，两者结合才能算出区间平均WIP。取数前需要把以下清洗规则写进口径文档。
状态回退与重开。工作项从“测试中”退回“开发中”，在制数量不变，因为它始终处于在制区间内；只有回退到起始状态之前，才从在制中移出。重开的已完成工作项，从重开时点起重新计入在制。规则应明确：以状态变更历史为准，逐条判断每个时点的状态归属。
跨项目流转。工作项从一个项目移到另一个项目时，如果两个项目都在统计范围内，数量不变；如果只有一个在范围内，移出时减一、移入时加一。按团队统计时同理，需要约定以当前归属还是历史归属计数。
拆分、合并与取消。一个工作项拆成两个，在制数量从一变为二，这是粒度变化而非真实堆积增加，报告中应注明；合并则相反。取消的工作项从取消时点起不再计入在制，历史时点仍按当时状态计算。
缺失值与状态滞后。状态字段为空的工作项无法判断归属，应单独列出并标记，不默认计入或排除。状态未及时更新是常见问题，可通过对比状态变更时间与关联活动记录（如代码提交、测试执行）识别滞后，滞后的工作项在口径中约定按实际状态还是按记录状态计数。
证据要求。一份可复核的WIP计算应保留三样东西：口径定义文档、取数脚本或报表配置、以及至少一个周期的原始快照数据。他人按同一口径应能复算出相同结果。在ONES中，工作项的状态字段和状态变更历史是取数的基础，团队可以基于工作项类型和状态配置生成按状态分组的统计视图，把口径固化到报表配置里，减少每次手工取数的偏差。
计算步骤：时点WIP与区间平均WIP公式
口径确定后，计算本身只有两个公式。
时点WIP = 统计时点处于在制状态的工作项数，单位为个。这里的“在制状态”指起始状态（含）到完成状态（不含）之间的所有状态。例如起始状态为“就绪”、完成状态为“已上线”，则就绪、开发中、待测试、测试中、待发布都计入。
区间平均WIP = 各时点WIP之和 ÷ 统计时点数。按日快照时，即日WIP总和 ÷ 统计天数。分母是有效统计时点的数量，不是自然日天数。
按状态分组的WIP构成 = 各在制状态的工作项数 ÷ 时点WIP总数，用于观察堆积集中在哪个环节。各状态占比之和应为100%，若不为100%说明存在未归类状态，需要检查状态映射。
分母处理有三条规则。第一，统计时点缺失（如某天未取数）时，该时点标记为无效，不参与平均计算，分母相应减少。第二，分母为零时平均值无定义，应标记为无效而非记为0，避免把“没有数据”误读为“在制为零”。第三，按周或按迭代聚合时，聚合区间内的日快照应与区间边界对齐，例如两周迭代取14个日快照，迭代首日和末日都计入，避免边界日重复或遗漏。
计算完成后建议同时输出三个数：区间平均WIP、区间内最高时点WIP、按状态构成。平均值反映整体水平，最高值反映峰值压力，构成反映堆积位置，三者结合才有解读价值。
算例：一个两周迭代的WIP计算
以下为演示情景，数字用于说明计算过程。设定统计对象为需求，起始状态为“就绪”，完成状态为“已上线”，时间窗为两周迭代的14个自然日，每日18:00取一次快照。
| 日期 | 就绪 | 开发中 | 待测试 | 测试中 | 待发布 | 当日WIP |
|---|---|---|---|---|---|---|
| 第1天 | 3 | 2 | 1 | 1 | 0 | 7 |
| 第2天 | 3 | 3 | 1 | 1 | 0 | 8 |
| 第3天 | 2 | 4 | 2 | 1 | 0 | 9 |
| 第4天 | 2 | 4 | 3 | 1 | 1 | 11 |
| 第5天 | 1 | 4 | 4 | 2 | 1 | 12 |
| 第6天 | 1 | 3 | 5 | 2 | 1 | 12 |
| 第7天 | 1 | 3 | 5 | 3 | 1 | 13 |
| 第8天 | 2 | 3 | 4 | 3 | 2 | 14 |
| 第9天 | 2 | 2 | 4 | 4 | 2 | 14 |
| 第10天 | 1 | 3 | 3 | 4 | 2 | 13 |
| 第11天 | 1 | 2 | 3 | 3 | 3 | 12 |
| 第12天 | 1 | 2 | 2 | 3 | 3 | 11 |
| 第13天 | 0 | 2 | 2 | 2 | 4 | 10 |
| 第14天 | 0 | 1 | 2 | 2 | 4 | 9 |
日WIP总和 = 7+8+9+11+12+12+13+14+14+13+12+11+10+9 = 155。统计时点数为14，区间平均WIP = 155 ÷ 14 ≈ 11.1个。区间最高时点WIP为14个，出现在第8天和第9天。
以第8天为例看状态构成：待测试4个、测试中3个、开发中3个、待发布2个、就绪2个，合计14个。待测试与测试中合计7个，占50%，说明在制主要堆积在测试环节前后。这一观察需要结合测试环节的完成速率进一步确认，单看构成只能提示方向。
算例中的两处处理值得说明。第10天“开发中”从2回到3，是一个需求从待测试退回开发中，它始终在在制区间内，当日WIP不变，只是状态构成变化。第13天“就绪”降为0，是一个已就绪需求被取消，从取消时点起不再计入，因此第13天起总数相应减少。若该需求在第12天仍处于就绪，第12天的快照仍计入它。
解读与限制：WIP数字能说明什么、不能说明什么
WIP是一个过程指标，它描述某一时点或区间内有多少工作处于未完成状态，本身不构成瓶颈结论。解读时需要把它放进指标组合里。
与完成速率一起看，可以判断流动方向。WIP上升而完成速率持平或下降，说明进入快于完成，流程中存在阻塞；WIP下降而完成速率上升，说明流动改善。与周期时间一起看，可以观察在制水平与交付速度的关系。这些对照都要求三个指标使用同一时间窗和同一统计对象，否则比较没有意义。
跨团队比较前先对齐口径。工作项粒度不一致是最常见的问题：一个团队以需求计数，另一个以任务计数，数字相差数倍并不代表流动效率差异。状态定义差异同样影响结果，有的团队“待测试”包含测试环境准备，有的不包含。统计时点选择也会改变数字，例如在每日站会后取快照与在下班前取快照，结果可能不同。跨团队比较的前提是口径文档一致。
不设通用达标线。不同产品、不同阶段、不同工作类型的合理在制水平差异很大，用外部数字作为目标容易误导。基线应来自团队自身的历史数据，例如过去六个迭代的平均WIP和波动范围，作为观察变化的参照。
引入WIP限制后需要观察实际影响再判断。设定上限本身不保证流动改善，可能只是把工作挡在流程之外，形成新的等待队列。建议在引入限制后持续跟踪周期时间、完成速率和阻塞情况，确认限制确实缩短了交付时间，再决定是否调整上限。
最后，WIP数字需要与口径一起呈现。一份只写“平均WIP为11”的报告无法被复核，也无法跨周期比较；写明统计对象、起止状态、时间窗和取数方式的报告，才能让他人按同一口径复算并讨论变化原因。
常见问题
统计对象用需求还是任务，算出的WIP能直接比较吗？
不能直接比较。以需求为单位和以任务为单位，同一时间段算出的WIP可能相差数倍，这是粒度差异而非流动差异。选定一种统计对象后，跨周期、跨团队都应沿用同一种；确需变更口径时，应在报告中注明变更时点和原因，新旧数字分段呈现，避免把口径变化误读为在制水平变化。
工作项在统计期间被取消或拆分，历史时点的WIP要不要改？
历史时点按当时状态计算，不追溯修改。取消的工作项从取消时点起不再计入在制，取消之前的快照仍计入它；拆分使在制数量从一变为二，属于粒度变化，应在报告中注明，避免被当成真实堆积增加。合并的处理相反。这些规则写进口径文档后，同一份历史数据每次复算的结果才能保持一致。
某天忘记取快照，区间平均WIP怎么算？
把缺失的时点标记为无效，不参与平均计算，分母相应减少，即用有效时点的WIP之和除以有效时点数。不要用前一天或后一天的数值填补，填补会引入人为平滑，改变结果。若缺失时点较多，例如超过统计窗口的两成，建议在报告中说明数据完整性不足，平均值的代表性有限。
WIP持续偏高，是不是就该马上设上限？
先确认偏高集中在哪个环节，再决定是否设限。按状态分组的构成能提示堆积位置，例如待测试与测试中合计占比过半，说明瓶颈可能在测试前后，此时更直接的动作是补充测试能力或调整提测节奏。设定上限本身不保证流动改善，可能只是把工作挡在流程之外形成新的等待队列。引入限制后应持续跟踪周期时间、完成速率和阻塞情况，确认交付时间确实缩短再调整上限。
两个团队的平均WIP一个是8一个是15，能说明后者流动更差吗？
不能直接下这个结论。先核对三件事：统计对象是否一致（需求对任务不可比）、状态定义是否一致（“待测试”是否包含测试环境准备）、统计时点是否一致（站会后取数与下班前取数结果可能不同）。三项对齐后，再结合各自的完成速率和周期时间看流动表现。即便口径一致，不同产品复杂度与工作类型的合理在制水平也有差异，比较应聚焦趋势变化而非绝对数值高低。
