研发在制品数量、并行任务数和WIP限制描述的是同一件事的三个侧面：在制品数量是某一时点已开始、未完成工作的总量，是现状；并行任务数说明这些工作如何分布在同时段内被推进，是分布；WIP限制是对在制品数量设定的上限规则，是约束。理解这三者的关系，有助于判断团队是工作堆积、并行过度，还是缺少明确的开工边界。
要点总览（TL;DR）
- 研发在制品数量是某一时点已开始、未完成的工作项总量，属于现状统计值；并行任务数是同一时段内被同时推进的任务条数，是在制品数量在时间维度上的分布来源。
- WIP限制是对某状态或某环节在制品数量设定的上限规则，属于约束值而非实际值；它通过限制同时开工的任务数，间接把在制品数量控制在设定范围内。
- 三者构成“现状—分布—约束”的关系：并行任务数决定在制品数量的实际规模，WIP限制约束开工节奏，在制品数量下降后周期时间通常随之缩短。
- 观察和调整时，先统一计数口径统计在制品与并行分布，再识别瓶颈环节，从瓶颈处设置分环节WIP上限，并用工作项状态与看板列承载统计和约束。
研发在制品数量到底指什么
研发在制品数量（Work in Process，常缩写为WIP）指团队已经启动、尚未完成的工作项总量。它统计的是“正在做”的部分，排队等待、尚未启动的待办事项不计入其中。这个定义看似简单，实际使用时需要先明确两个边界，否则不同人报出的数字无法比较。
第一个边界是起止状态。工作项从进入“进行中”类状态开始计入在制品，到完成或关闭时退出。中间经过评审、测试、待合并等状态时，只要工作项仍处于已启动未完成的范围，通常继续计入。团队需要约定哪些状态算“已开始”：是开发人员第一次提交代码，还是工作项被移动到看板的进行中列。约定不同，统计结果会明显不同。
第二个边界是计数单位。常见的口径有三种：按任务计数，统计进行中的开发任务条数；按需求计数，统计已启动但未交付的用户故事或需求数量；按人天计数，把每项工作的预估剩余工作量累加，得到以人天为单位的在制品规模。按条数计数便于看板管理，按人天计数更能反映实际负荷。两种口径可以并存，但比较时须使用同一口径。
在制品这个概念借自制造业的库存式在制品，两者有相似之处：都指已投入资源、尚未转化为可交付成果的中间状态。差异在于研发工作的中间产物难以像实物库存那样清点和计价，一项需求在“开发完成、等待测试”时，其完成度很难用统一单位衡量。因此研发在制品更适合用工作项条数和状态分布来描述，而非追求精确的金额或数量核算。
并行任务数如何影响在制品数量
并行任务数是同一时段内被同时推进的任务条数。将在制品数量按时间切片展开，每个时间点上正在被推进的任务条数，累加起来就构成在制品数量的实际规模。换句话说，并行任务数是在制品数量的来源，在制品数量是并行推进的结果。
并行度可以按个人和按团队两个层面观察。个人并行度指一名成员同时手上推进的任务数；团队并行度指整个团队在同一时段内处于进行中的任务总数。个人并行度高，往往表现为频繁切换任务、等待反馈的时间被拉长；团队并行度高，则表现为看板上进行中列持续膨胀，而完成列增长缓慢。两者都会推高在制品数量，但成因不同：前者与任务分配方式有关，后者与团队整体的开工节奏有关。
并行任务增加时，在制品数量同步上升，机制并不复杂：每启动一项新工作，在制品就增加一项；只有工作完成或关闭，在制品才减少。如果启动速度快于完成速度，在制品数量就会持续累积。这种累积在短期内可能被“大家都很忙”的表象掩盖，但完成节奏并未同步提升。
一种典型表现是并行任务数很高、流转却很慢。看板上进行中的任务很多，每项都推进了一点，但没有一项走到完成。此时在制品数量高，周期时间被拉长，团队的实际产出反而下降。这说明并行任务数只是规模来源，本身不保证流动效率。
WIP限制如何作用于在制品数量
WIP限制是对某一状态或某一环节在制品数量设定的上限规则。它规定某个环节最多允许同时存在多少项进行中的工作，超过上限时不再启动新工作。WIP限制是一个约束值，在制品数量是实际统计值，两者不能混为一谈：限制设为5，实际在制品可能是3，也可能是5，但不应长期超过5。
限制对象的选择决定了约束的作用范围。按看板列设置，限制的是某一状态列中的工作项数量，例如“开发中”列最多5项；按人设置，限制的是每人同时推进的任务数，例如每人最多2项；按环节设置，限制的是某个流程阶段整体的在制规模，例如测试环节最多8项。按列设置便于在看板上直接观察，按人设置更贴近个体负荷，按环节设置适合跨角色协作的流程。团队可根据瓶颈位置选择，也可以组合使用。
达到上限时，团队需要约定处理方式。常见做法有三种：停止开工，新工作留在待办列等待，直到下游腾出容量；拉动下游，优先推动已在进行中的工作完成，把容量释放出来；协助瓶颈，把空闲人力调配到堆积最严重的环节。三种做法的共同点是让开工节奏服从完成节奏，而不是让新任务无限进入。
WIP限制压低在制品数量的路径是间接的：它不直接减少已有工作，而是限制同时开工的任务数，使在制品数量被控制在设定范围内。在制品数量下降后，每项工作获得的关注和等待时间减少，流动时间随之缩短，流程中堆积最严重的环节也更容易暴露出来。
三者关系与相邻概念的区别
把三个概念放在一起看，它们分别回答不同问题：在制品数量回答“现在有多少工作没完成”，并行任务数回答“这些工作如何分布在同时段内”，WIP限制回答“最多允许同时做多少”。三者构成现状、分布与约束的关系，缺一不可。
| 概念 | 回答的问题 | 数值性质 | 主要用途 |
|---|---|---|---|
| 在制品数量 | 已开始未完成的工作有多少 | 实际统计值 | 观察积压规模与状态分布 |
| 并行任务数 | 同时段内推进多少项 | 实际分布值 | 判断并行度与切换成本 |
| WIP限制 | 最多允许同时进行多少 | 规则上限值 | 约束开工节奏、暴露瓶颈 |
与相邻概念相比，吞吐量指单位时间内完成的工作项数量，衡量的是产出速度；周期时间指一项工作从开始到完成所经历的时间，衡量的是流动快慢；瓶颈指限制整体流动的环节。在制品数量与这三者都有联系：在制品高通常伴随周期时间长，瓶颈环节往往堆积最多在制品，但吞吐量由完成端决定，不能用在制品数量代替。
任务依赖描述工作项之间的先后关系，资源利用率描述人力被占用的程度，二者与在制品数量相关但不等同。依赖关系多，容易造成等待和堆积；资源利用率高，可能意味着并行过度。常见混淆是把WIP限制当成在制品数量的目标值，认为设了上限就应该把在制品填满到上限。上限是防止过量的边界，实际在制品低于上限同样正常，甚至更有利于流动。
一个具体例子与常见误解
以下为演示情景，数据为假设，不代表任何真实团队。一个5人研发团队，每人同时推进3项任务，团队在制品数量为15项。假设每人每天能完成的任务量有限，任务在开发、测试之间来回等待，平均一项任务从开始到完成需要10天。此时看板上进行中列长期有15项左右，完成列每天只增加少量条目。
团队决定在“开发中”和“测试中”两列分别设置WIP上限，开发中最多6项，测试中最多4项。达到上限后，新任务留在待办列，成员优先推动手头工作完成，测试堆积时开发人员协助测试。运行一段时间后，在制品数量从15项降到10项左右，每人并行任务数从3项降到2项，平均周期时间随之缩短。这个变化的关键在于开工节奏被约束，而非工作量减少。
由此可以纠正三个常见误解。误解一是在制品越多产出越多：在制品增加只代表启动更多，完成端未同步提升时，多出来的部分只是等待和切换，产出不会同比例增长。误解二是WIP限制等于降低工作量：限制约束的是同时进行的数量，待办工作并未减少，只是按完成节奏逐步进入。误解三是并行任务数等于在制品数量：并行任务数是同一时段内的推进条数，在制品数量是跨时段的累计未完成总量，两者在统计口径和时间范围上都不同。
如何在团队中观察和调整这三项指标
观察和调整可以从四步动作入手，每一步都有明确的产物和完成标志。
- 统计当前在制品数量与并行分布。选定计数口径，按状态列统计进行中的工作项条数，同时记录每人的并行任务数。产物是一张按状态和按人分布的在制品清单，完成标志是团队对口径达成一致。
- 识别瓶颈环节与堆积状态。观察哪一列长期堆积最多、哪一环节的等待时间最长，结合周期时间判断瓶颈位置。产物是瓶颈环节的标注，完成标志是团队能指出具体哪一列或哪一角色是流动的主要限制。
- 设置分环节WIP上限并观察流动变化。从瓶颈环节开始设置上限，约定达到上限后的处理方式，运行一段时间后对比在制品数量、周期时间和完成节奏的变化。产物是上限规则与观察记录，完成标志是上限被实际执行而非停留在看板上。
- 用工作项状态与看板承载统计和约束。把状态定义、计数口径和上限规则落到工作项状态与看板列上，使统计和约束成为日常可见的机制，而非额外的手工汇总。
在工具承载层面，ONES 的工作项状态与看板能力可以支持上述动作：团队按流程配置状态列，将进行中的工作项呈现在看板上，按列观察在制规模；状态流转记录为统计在制品数量和周期时间提供依据。将WIP上限与看板列结合，团队在每日站会或拉动工作时就能看到某列是否已满，从而决定是否启动新任务。工具承载的是统计与约束的管理动作，上限设多少、瓶颈在哪，仍需要团队根据自身流程判断和调整。
常见问题
在制品数量应该按任务条数统计，还是按人天统计？
两种口径各有用途，关键是团队内部保持一致。按任务条数统计便于在看板上直接观察状态分布，适合日常站会和拉动工作；按人天统计把每项工作的预估剩余工作量累加，更能反映实际负荷，适合判断容量是否过载。两种口径可以并存，但比较不同时间点或不同团队的数据时，必须使用同一口径，否则数字没有可比性。
WIP上限设了之后，在制品数量长期低于上限，是否说明限制设得太松？
不一定。WIP限制是防止过量的边界，实际在制品低于上限属于正常状态，甚至更有利于流动。判断上限是否合适，应看瓶颈环节是否被有效约束、周期时间是否稳定，而不是看实际在制品是否填满上限。如果某列长期远低于上限，可能说明该环节不是瓶颈；如果某列频繁触顶并造成等待，才需要考虑调整上限或处理瓶颈。
个人并行任务数很高，但团队整体在制品数量不高，这种情况需要处理吗？
需要关注。个人并行度高通常表现为频繁切换任务、等待反馈时间拉长，即使团队整体在制品数量不高，个体层面的切换成本仍会拖慢完成节奏。处理方式可以从任务分配入手，减少单人同时推进的任务数，或者把部分任务转为协作推进。团队层面的在制品统计无法反映这种个体分布问题，因此两项指标需要结合观察。
WIP限制达到上限时，新任务应该一直等待，还是可以临时放行？
常见做法是让新任务留在待办列等待，直到下游腾出容量，同时优先推动已在进行中的工作完成。临时放行会削弱上限的约束作用，使在制品重新累积。如果等待时间过长，说明瓶颈环节容量不足，应处理瓶颈本身，例如调配人力协助或拆分工作项，而不是靠放行新任务缓解表面压力。
在制品数量下降后，团队产出会立刻提升吗？
通常不会立刻提升。在制品数量下降首先带来的是等待和切换减少，周期时间缩短，完成节奏趋于稳定；产出提升取决于瓶颈环节的容量是否被释放。如果瓶颈没有变化，在制品下降只是让工作更顺畅地流过同一瓶颈，吞吐量的提升幅度有限。因此在制品数量、周期时间和吞吐量需要一起观察，不能只看单一指标。
