如何设置WIP上限并逐步降低研发在制品数量

2026年11月11日

设置WIP上限的关键，是先按“团队—环节—个人”三层给在制品设限，用当前并行量和瓶颈环节的实测数据确定初始值，再以固定周期小步下调，观察流动指标，直到在制品数量与瓶颈产能匹配。本文按盘点、设限、下调、分工、示例和验收六个步骤展开，适合希望改善研发流动效率的团队负责人参考。

Table of Contents

要点总览（TL;DR）

先按工作项状态、流程环节、责任人三种口径盘点当前在制品，区分处理中与排队等待，形成含并行数量、平均停留时间、疑似瓶颈的基线表。
WIP上限分团队层、环节层、个人层三层设置，初始值取瓶颈环节实测并行量的近似值或略低于现状，先让上限被遵守再收紧。
下调以固定周期为单位，每轮幅度控制在当前上限的10%至20%或1至2项，观察在制品实际值、平均停留时间、吞吐量和阻塞项后再决定下一步。
出现瓶颈持续积压、下游频繁等待或吞吐量连续下降时停止下调，当前上限即为与瓶颈产能匹配的工作点。
机制生效的判断标准是上限被稳定遵守、流动指标改善，而非上限表写得完整；失效信号包括长期破例、状态不更新和拆项规避计数。

先算清当前在制品：设置WIP上限的起点

在制品（WIP）指已经启动但尚未完成的工作项。设限之前必须先拿到一个可信的基线数字，否则上限只能凭感觉定，后续下调也缺少参照。盘点的目标不是精确到每一项，而是让团队对“现在同时压着多少活”形成一致认识。

确定计数口径

同一批工作按不同口径统计，结果可能相差很大，因此要先约定一种主口径，并说明是否包含排队项。常见三种口径如下：

口径	计数方式	适用场景	注意事项
按工作项状态	统计处于“进行中”“开发中”“测试中”等已启动状态的工作项数量	团队整体在制品总量	需先统一状态定义，避免同一状态在不同团队含义不同
按流程环节	统计每个环节（如设计、开发、测试、发布）当前占用的工作项数	识别瓶颈环节	一个工作项可能同时占用多个环节，需明确主责环节
按责任人	统计每个人名下处于处理中的工作项数	个人层设限与负载观察	协作项、评审项是否计入需提前约定

区分排队等待与真正在处理

只有处于处理中的工作才占用环节产能，排队等待的工作项应作为拉动前的缓冲单独记录。盘点时对每个环节分别标记“处理中”和“等待中”的数量，等待时间过长的环节往往就是后续要重点关注的瓶颈候选。

统计各环节并行数量

按流程环节逐个统计当前并行数量，并记录每个环节的平均停留时间。平均停留时间可以用最近一段时间内工作项进入和离开该环节的时间差取平均，样本不足时先用粗略估计，后续每轮调整时再修正。完成统计后形成如下基线表：

环节	处理中数量	等待中数量	平均停留时间	疑似瓶颈
需求澄清	—	—	—	—
设计	—	—	—	—
开发	—	—	—	—
测试	—	—	—	—
发布	—	—	—	—

初步识别瓶颈

瓶颈环节通常表现为：处理中数量明显高于其他环节、平均停留时间最长、下游环节频繁处于等待状态。三者同时出现的环节应优先列为瓶颈候选。初步判断不必追求一次准确，后续下调过程中会持续验证。

如果团队已经在使用工作项管理工具，在制品统计可以直接基于工作项状态和看板列完成。ONES支持以工作项和看板承载研发流程，团队可以把上述环节映射为看板列，按列统计处理中与等待中的工作项数量，作为基线盘点和后续每轮观察的数据来源；具体报表口径以团队实际配置为准。

WIP上限怎么定：三层设限与初始值算法

WIP上限按团队层、环节层、个人层三层设置，三层分工不同，不能互相替代。初始值以瓶颈环节的实测并行量为主要参照，先让上限被遵守，再逐步收紧。

三层上限的分工

层级	作用	设定依据	示例
团队层	控制团队整体同时推进的工作总量	团队吞吐能力与瓶颈环节产能	团队同时进行的工作项不超过N项
环节层	控制每个流程环节的并行数量，保护瓶颈	该环节处理中数量与平均停留时间	测试环节同时处理不超过M项
个人层	控制个人同时处理的任务数，减少频繁切换	个人实际可并行处理的任务数	每人同时处理不超过2项

三层上限中，环节层是核心，团队层和个人层用于配合。瓶颈环节的上限应最严格，非瓶颈环节可以适当放宽，避免上游过度限制导致瓶颈环节吃不饱。

初始值取法

初始值建议取瓶颈环节当前实测并行量的近似值或略低于现状。例如测试环节当前同时处理8项、平均停留时间最长，初始上限可设为7或8，先观察团队能否稳定遵守。若一开始就压到明显低于现状的水平，容易造成上游积压和频繁破例，反而削弱规则的可信度。

非瓶颈环节的初始上限可以取当前并行量，或略高于瓶颈环节上限，保证瓶颈环节有足够的输入。个人层初始上限取当前人均并行任务数的中位数，向下取整。

与拉动和准入规则配合

上限只有和拉动机制配合才有效：下游环节腾出容量后，才从上游拉入新的工作项；上游工作项进入下一环节前需满足准入条件，例如需求已澄清、设计已评审。准入条件不满足的工作项留在上游等待，不占用下游名额。

同步调整的规则

设限后需要同步明确两项规则：一是准入条件，即工作项进入某环节前必须满足的最低要求；二是完成定义，即工作项在什么条件下才算离开该环节。完成定义模糊会导致工作项长期滞留，使上限形同虚设。三层上限表与配套规则应形成书面记录，作为后续调整的依据。

逐步降低在制品的操作步骤

下调在制品是一个分阶段过程，节奏比幅度更重要。每轮只做小幅调整，观察一轮再决定下一步，避免一次性压缩造成阻塞。

调整周期与下调幅度

建议以固定周期为单位，例如每两周为一轮。每轮下调幅度控制在当前上限的10%至20%，或每次下调1至2项，取两者中较小的幅度。幅度小意味着可以回退，团队也更容易接受。

下调前观察的流动指标

每轮调整前先看以下指标，确认上一轮调整已经稳定：

在制品实际值：是否持续低于上限，还是频繁触顶或破例；
平均停留时间：各环节是否缩短或至少不再延长；
吞吐量：单位周期完成的工作项数量是否稳定或上升；
阻塞项：当前阻塞工作项的数量与原因分布。

遇到阻塞时的处理顺序

下调后出现阻塞，按以下顺序处理：先确认阻塞是否由本轮下调引起；若是，暂停下调并维持当前上限，优先清理阻塞项；阻塞缓解后再观察一个周期，确认指标稳定后才继续下调。若阻塞与下调无关，例如外部依赖延迟，则记录原因，不因此回退上限。

停止下调的判断条件

出现以下任一情况时停止下调：瓶颈环节持续积压且平均停留时间上升；下游环节频繁等待；吞吐量连续两个周期下降；团队无法稳定遵守当前上限。停止不等于失败，当前上限就是与瓶颈产能匹配的工作点，后续产能变化时可以重新评估。

角色分工与各环节交付物

WIP机制能否落地，取决于每个角色是否清楚自己负责什么。以下分工可按团队规模调整，小团队可由一人兼任多个角色。

角色	主要职责	交付物
团队负责人	确定三层上限、主持每轮调整决策、处理跨团队协调	三层WIP上限表、每轮调整记录
环节负责人	维护本环节准入条件与完成定义、监控本环节并行数量	环节准入与完成规则、环节在制品数据
个人	遵守个人层上限、及时更新工作项状态、上报阻塞	准确的工作项状态
数据记录人	维护看板与统计表、每轮汇总流动指标	在制品基线表、指标趋势记录
跨团队对接人	协调外部依赖、同步上下游团队的上限与节奏	依赖清单与协调记录

例会中的检查动作

每日站会检查：各环节处理中数量是否超过上限、是否有新增阻塞项、个人名下并行任务是否超限。每周或每轮结束时检查：在制品实际值趋势、平均停留时间变化、吞吐量变化，并据此决定是否进入下一轮下调。检查项应固定成清单，避免每次临时决定看什么。

看板维护责任

看板列与工作项状态需要保持一致，数据记录人负责每轮核对，发现状态滞留或重复计数及时修正。看板是上限执行的可见载体，列上标注各环节上限值，超限时在站会上直接指出。

一个团队从24降到12的示例

以下为演示情景，用于说明设限与下调的完整过程，数字为示例设定，不代表任何真实团队。

初始盘点结果

某研发团队共12人，按环节统计当前处理中工作项合计24项：需求澄清3项、设计4项、开发9项、测试6项、发布2项。测试环节平均停留时间最长，下游发布频繁等待，初步判定测试为瓶颈环节。

首轮上限设定

测试环节当前处理中6项，初始上限设为6；开发环节上限设为8，略高于测试上限以保证输入；需求澄清与设计各设3项；发布设2项。团队层上限设为22项，个人层每人不超过2项。首轮执行两周，实际在制品维持在21至23项之间，测试环节未出现持续积压。

两到三轮下调

轮次	测试环节上限	团队层上限	在制实际值	观察结果
初始	6	22	21–23	上限基本被遵守
第一轮	5	20	19–21	平均停留时间略降，吞吐量稳定
第二轮	4	18	17–19	开发环节出现短暂积压，清理后恢复
第三轮	4	16	15–17	吞吐量稳定，停留时间继续下降

第三轮后团队层在制品稳定在15至17项，测试环节上限保持4项。继续下调时测试环节出现持续积压，团队决定停止下调，将测试上限维持在4项、团队层上限维持在16项，此时在制品总量约为初始24项的一半。

示例中的取舍与边界

该示例中下调幅度每轮约2项，周期为两周，遇到积压时暂停而非回退。实际团队的人数、环节划分和瓶颈位置不同，初始值和下调幅度需要按自身基线数据调整。示例只说明操作顺序和判断逻辑，不构成统一标准。

完成检查：判断WIP机制是否生效

机制是否生效，不看上限表写得多完整，而看上限是否被遵守、流动是否改善。以下清单可逐项核对。

上限遵守检查项

各环节处理中数量在观察周期内是否持续低于上限；
超限时是否有明确的处理动作，而非默认放行；
个人层并行任务是否在约定范围内；
准入条件与完成定义是否被实际执行，滞留工作项是否减少。

流动指标改善标准

平均停留时间较基线下降或保持稳定；
吞吐量在观察周期内稳定或上升；
阻塞项数量下降，阻塞原因可追溯；
在制品实际值与瓶颈产能匹配，不再频繁触顶。

机制失效的典型信号

上限长期被突破且无人处理；工作项状态长期不更新，看板数据与实际不符；下调后指标无变化，说明上限没有真正约束流动；团队把上限当作考核指标，倾向于拆分工作项规避计数。出现这些信号时，应先回到基线盘点，确认口径和数据是否可信。

需要固化的规则与文档

验收通过后，将三层上限表、各环节准入条件与完成定义、每轮调整记录、例会检查清单整理为固定文档，明确维护责任人。后续团队人数或流程变化时，按同一方法重新盘点并调整上限，保持机制持续可用。

常见问题

团队规模很小，三层WIP上限都要设吗？

三层上限的分工不同，小团队可以简化但不能只设一层。团队层控制总量，环节层保护瓶颈，个人层减少频繁切换。人数少时，团队层与环节层可以合并为一张看板上的列上限，个人层保留一条简单规则，例如每人同时处理不超过2项。关键是瓶颈环节的上限最严格，其他层级围绕它配合。

下调WIP后上游工作项堆积严重，应该先放宽哪一层上限？

先确认堆积发生在哪个环节。如果堆积在上游非瓶颈环节，说明该环节上限偏紧或准入条件过严，可以适度放宽上游环节上限，保证瓶颈环节有足够输入；如果堆积在瓶颈环节之前，则不应放宽瓶颈上限，而应检查瓶颈产能是否真的提升。处理顺序是：先清理阻塞项，再评估上游准入条件，最后才考虑调整上限数值，并记录本轮调整原因。

在制品数量已经降到目标值，还需要继续下调吗？

目标值本身不是继续下调的理由。判断依据是流动指标：若平均停留时间仍在下降、吞吐量稳定、瓶颈环节没有持续积压，可以再尝试小幅下调一轮；若指标已经平稳甚至变差，当前上限就是合适的工作点。后续团队人数、环节划分或外部依赖发生变化时，按同一方法重新盘点并评估，不必为了数字好看持续压缩。

看板上的状态更新不及时，WIP统计还可信吗？

状态不及时会直接让在制品统计失真，上限也就失去约束力。处理办法是先固定状态流转规则和完成定义，明确工作项在什么条件下必须更新状态；再由数据记录人每轮核对看板列与工作项状态是否一致，发现滞留项及时修正。站会上把超限和状态滞留一起检查，比单独强调更新纪律更有效。若长期无法保证数据准确，应先缩小统计范围，只统计关键环节，等规则稳定后再扩大。