设置WIP上限的关键在于先测清团队当前的在制品数量和真实并行能力，再按流程状态设定可执行的上限，并以固定周期小幅下调。本文给出基线测算、设限步骤、分阶段下调路径、角色分工与完成检查，帮助研发管理者把在制品数量从超限状态逐步收敛到可控水平。
要点总览（TL;DR）
- 先按流程状态统计当前在制品数量，结合人数、可用工时、平均停留时间和历史完成速率估算并行能力，初始上限取估算值或估算值加一，让超限先暴露出来。
- 设限以状态级为主、团队级为辅，配合“先完成再开始”的拉动规则；达到上限时停止拉入新任务，成员转向完成下游工作或清除阻塞。
- 下调以两周为周期，每次只调瓶颈环节，幅度为一项或不超过20%，以阻塞减少、停留时间缩短、连续一周期未频繁超限为触发条件，受阻时回退一档。
- 团队负责人、流程负责人和一线成员分别承担设限决策、看板维护与规则执行，检查动作固定在每日站会和每周例会上完成。
- 机制生效的判断标准是上限被遵守且有超限处置记录、在制品与停留时间同步改善、拉动规则在日常流转中被实际执行。
先算清当前在制品数量与并行能力
WIP上限要建立在两组数据上：每个流程状态里现在压着多少工作项，以及团队在同一时间真正能推进多少项。缺少这两组数据，上限只能凭感觉设定，执行时容易变成口号。
统计当前在制品数量的口径
按流程状态逐列统计，而不是只算一个总数。常见状态包括待分析、开发中、评审中、测试中、待发布。统计时明确三条口径：
- 以工作项进入某状态的时刻为起点，离开该状态为终点，处于中间的工作项计入该状态的在制品。
- 被阻塞的工作项仍然计入在制品，同时单独标记阻塞原因，避免把阻塞项从统计中隐藏。
- 统计时点固定，例如每天固定时间截取一次看板快照，保证不同日期的数据可比。
估算团队真实并行能力
并行能力可以从三个角度交叉估算。第一是人数与可用工时：用团队人数乘以每人每周可用于推进工作项的有效工时，扣除会议、支持和休假。第二是平均停留时间：统计过去四到六周每个状态的平均停留时间，停留时间越长，说明该状态同时能消化的项数越有限。第三是历史完成速率：统计每周实际完成的工作项数量，这是团队产出的上限参考。
把三者放在一起看，每个状态的可并行项数大致等于该状态投入人数乘以单人可同时推进的项数。单人同时推进多项时效率会下降，估算时按每人一到两项计算更接近实际。
基线表需要记录的字段
| 字段 | 说明 | 示例 |
|---|---|---|
| 流程状态 | 按看板列逐一列出 | 开发中 |
| 当前在制品数 | 统计时点该状态的工作项数量 | 9 |
| 平均停留时间 | 过去四到六周该状态的平均天数 | 5.5天 |
| 投入人数 | 主要在该状态工作的人数 | 4人 |
| 并行能力估算 | 人数乘以单人可并行项数 | 6项 |
| 阻塞项数 | 其中被阻塞的工作项数量及原因 | 2项，等待环境 |
这张基线表是后续设限和对比的依据，建议每周更新一次，保留历史版本以便观察趋势。
按状态设置WIP上限的具体步骤
设限的目标是让拥堵显性化，而不是一次把数字压到理想值。初始上限应略高于或等于并行能力估算值，让团队先适应拉动规则，再逐步收紧。
选择设限粒度
以状态级为主、团队级为辅。状态级上限直接对应看板列，能定位拥堵发生在哪个环节；团队级上限控制整体在制品总量，防止各状态分别达标但总量失控。个人级上限容易造成成员之间等待和闲置，一般不作为主要手段，可在个别环节作为补充约定。
初始上限的取值方法
对每个状态，取并行能力估算值作为初始上限的基准。如果当前在制品数已经明显高于估算值，初始上限可以设为估算值加一，给团队一个缓冲期；如果当前数量接近估算值，直接按估算值设定。初始上限的作用是先把超限暴露出来，不追求一步到位。
拉动规则与“先完成再开始”
拉动规则的核心约定是：某状态达到上限后，上游不再向该状态拉入新工作项。成员此时转向帮助下游完成工作或清除阻塞，而不是继续开启新任务。规则需要写清楚三件事：谁有权决定拉入、达到上限时成员做什么、超限时如何处置。超限处置通常包括暂停新任务、集中处理阻塞、在例会上记录原因。
把上限写入看板与工作项状态
上限要落在团队每天看得到的地方。可以在看板列标题上标注上限值，例如“开发中（上限6）”，并在列内工作项数量超过上限时用颜色或标记提示。工作项状态流转时，系统或人工检查目标状态是否已满，已满则暂缓流转。若团队使用ONES这类研发管理工具，工作项状态与看板可以作为承载上限标注、阻塞标记和流转检查的日常载体，具体配置方式按团队现有流程约定执行。
逐步降低在制品的分阶段路径
下调在制品数量是一个分阶段过程，节奏由瓶颈疏通情况决定，而不是按日历强行压减。每次下调幅度小，团队才有时间消化。
下调周期与幅度
以两周为一个下调周期，与常见的迭代节奏对齐。每个周期只调整瓶颈环节的上限，每次下调一项，或在基数较大时下调不超过20%。非瓶颈环节的上限保持稳定，避免同时变动导致无法判断效果。
以下调触发条件替代固定压减
下调前先确认三个条件：瓶颈环节的阻塞项已明显减少、该状态平均停留时间较上一周期缩短、团队在该上限下连续一个周期未出现频繁超限。三个条件满足再下调，否则维持当前上限继续观察。这样下调跟着瓶颈疏通走，而不是跟着计划表走。
下调受阻时的回退与暂停
下调后如果连续出现超限、停留时间反弹或阻塞项增加，回退一档并暂停下调一个周期。回退不是失败，而是把上限调回团队当前能承受的水平，先处理阻塞再继续。回退决定需要在例会上记录原因，作为下一轮调整的输入。
目标值的设定依据
目标值参考团队稳定完成速率和可接受的平均停留时间。整体在制品总量大致等于每周完成量乘以目标停留周期，各状态目标值按该状态在流程中的占比分配。目标值不设统一数字，由团队根据自身交付节奏确定，并在每个季度复盘时校准。
| 阶段 | 瓶颈状态上限 | 触发条件 | 观察指标 |
|---|---|---|---|
| 第1周期 | 6 | 基线测算完成，拉动规则宣贯 | 超限次数、阻塞项数 |
| 第2周期 | 5 | 阻塞项减少，停留时间缩短 | 平均停留时间、完成量 |
| 第3周期 | 4 | 连续一周期未频繁超限 | 超限处置记录、流动趋势 |
| 目标状态 | 按完成速率校准 | 停留时间稳定在目标区间 | 在制品总量、交付周期 |
角色分工与各环节交付物
WIP机制能否落地，取决于设限、监控和下调是否有人负责。角色不必多，但每个动作要有明确的责任人和产出。
三类角色的职责
| 角色 | 主要职责 | 交付物 | 更新频率 |
|---|---|---|---|
| 团队负责人 | 组织基线测算，确认初始上限，主持下调决策 | 基线表、上限设定记录 | 设限阶段每周，之后每周期 |
| 流程负责人 | 维护看板上限标注与阻塞标记，跟踪停留时间 | 在制品趋势记录、阻塞清单 | 每日更新，每周汇总 |
| 一线成员 | 遵守拉动规则，超限时转向完成或清障，报告阻塞 | 阻塞说明、完成状态更新 | 每日 |
例会上的检查动作
每日站会检查三件事：各状态当前在制品数与上限的对比、新增阻塞项及负责人、达到上限时成员的工作安排。每周例会回顾一周的超限次数和处置记录，判断是否满足下调条件。检查动作固定在看板上完成，避免另建一套台账。在ONES中，工作项状态、阻塞标记和看板视图可以承接这些日常检查动作，让上限对比和阻塞跟踪与工作项本身保持同步。
一个团队从超限到收敛的示例
以下为演示情景，用于说明设限与下调的完整过程，数据不代表真实团队。
某八人研发团队，流程分为待分析、开发中、评审中、测试中四个状态。基线测算显示开发中在制品9项、平均停留5.5天、投入4人，并行能力估算为6项；测试中在制品5项、平均停留4天、投入2人，并行能力估算为3项。初始上限设为开发中7项、测试中4项，其余状态按估算值设定。
第一周期，开发中多次达到上限，团队按规则暂停拉入新任务，集中处理两项等待环境的阻塞项。周期末阻塞项降到一项，开发中平均停留时间缩短到5天。第二周期把开发中上限下调到6项，测试中维持4项。下调后测试中一度超限，团队回退测试中上限到5项并暂停一个周期，先补充测试环境。第三周期测试中阻塞清除，上限下调到4项，开发中下调到5项。收敛后开发中在制品稳定在5项左右，平均停留时间降到4天以内，超限从每周多次降到偶发，且每次都有处置记录。
完成检查：判断WIP机制是否生效
机制是否真正落地，可以用以下清单逐项核对。全部满足说明WIP上限已经进入日常运转，部分满足则针对缺口继续改进。
- 每个流程状态都有明确的上限值，并标注在看板或工作项状态上，团队成员能直接看到。
- 超限有处置记录，记录包含超限状态、原因、处置动作和责任人，而不是只在口头上提醒。
- 在制品数量呈下降或稳定趋势，平均停留时间同步改善，两者变化方向一致。
- 拉动规则在日常站会和状态流转中被实际执行，达到上限时确有成员转向完成或清障。
- 下调按周期进行，每次调整有触发条件依据，受阻时有回退记录。
- 基线表和趋势记录持续更新，每季度复盘一次目标值并校准。
检查频率建议每月一次，由团队负责人组织，流程负责人提供数据。发现上限长期被突破且无处置记录，说明机制停留在形式层面，需要回到拉动规则和例会检查重新落实。
常见问题
团队刚开始设WIP上限，当前在制品数量远超并行能力估算值，初始上限应该直接压到估算值吗？
不建议一步压到估算值。初始上限的作用是先把超限暴露出来，让团队先适应拉动规则。当前数量明显高于估算值时，可以把初始上限设为估算值加一，给一个缓冲期；等团队能稳定遵守拉动规则、阻塞项开始减少后，再按周期下调。直接压到估算值往往导致大量工作项卡在上游等待，反而掩盖了真实的瓶颈位置。
下调WIP上限后团队频繁超限，应该继续坚持还是回退？
先回退一档，并暂停下调一个周期。频繁超限说明当前上限低于团队在该环节的实际消化能力，继续坚持会让工作项堆积在上游，流动情况更难观察。回退后把精力放在清除阻塞上，例如补充环境、协调评审资源，等阻塞项减少、平均停留时间回落后再重新尝试下调。回退决定要在例会上记录原因，作为下一轮调整的依据。
瓶颈环节会随项目阶段变化，WIP上限需要跟着重新分配吗？
需要，但调整节奏要慢于瓶颈变化。建议在每个下调周期复盘时确认当前瓶颈状态，只对瓶颈环节的上限做调整，非瓶颈环节保持稳定，避免同时变动导致无法判断效果。如果瓶颈从开发中转移到测试中，可以把测试中的上限作为下一周期的调整对象，开发中维持当前值观察一到两个周期。目标值按季度校准，不随单个项目阶段频繁改动。
个人级WIP上限在什么情况下可以作为补充手段？
个人级上限一般不作为主要手段，因为容易造成成员之间等待和闲置。在个别环节可以作为补充约定，例如需要高度专注的设计或复杂缺陷修复，约定每人同时只推进一项。使用时要配合状态级上限一起看，避免出现个人未超限但团队整体在制品持续堆积的情况。补充约定应写清楚适用范围和解除条件，不写成全员统一要求。
WIP上限标注在看板上之后，如何避免它变成只做展示的形式？
关键在超限时是否有实际动作和记录。可以在每日站会上固定检查各状态当前数量与上限的对比、新增阻塞项及负责人、达到上限时成员的工作安排；每周例会回顾超限次数和处置记录。如果上限长期被突破且没有处置记录，说明机制停留在展示层面，需要回到拉动规则和例会检查重新落实。检查动作在看板上完成，不另建台账。
