需求波动大或人员兼职时，在制品限制仍然适用，但用法要改：需求波动时按瓶颈环节设限并定期复核，人员兼职时按可投入时段折算容量、把上限调小。判断是否值得采用，关键看团队能否识别瓶颈、估出每日可投入时间，并在超限时先完成再拉入。若需求完全不可控、兼职时间无法预估，或工作项尚未可视化，宜先暂缓，从建立看板和完成定义起步。
要点总览（TL;DR）
- 需求波动大时在制品限制仍适用，但上限应设在瓶颈环节，并随需求峰谷定期复核，超限时先完成再拉入。
- 人员兼职时同样适用，容量需按可投入时段折算，上限通常调小，并明确交接标准与完成定义。
- 采用前需要工作项可视化、完成定义、瓶颈识别依据和团队对超限规则的共识。
- 需求完全不可控且无优先级机制、兼职投入时间无法预估、工作项未可视化时宜暂缓，先建立看板与完成定义。
- 可先选一个瓶颈环节做两到四周单点限制试点，根据队列长度、等待时间和超限原因判断继续、调整或停止。
条件式结论：什么情况下仍然适用
在制品限制的核心作用，是把同时进行的工作数量控制在瓶颈环节能够消化的容量内。只要团队存在并行任务、存在交接和排队，这个作用就成立。需求波动和人员兼职改变的是上限怎么定、多久调一次，并不取消限制本身的价值。因此更准确的判断是分三类：直接适用、调整后适用、暂缓采用。
| 情形 | 判断 | 关键动作 |
|---|---|---|
| 需求相对平稳，成员投入时间可预估 | 直接适用 | 按瓶颈环节设定固定上限，按周或按迭代复核 |
| 需求波动大，但来源和优先级有人把关 | 调整后适用 | 限制设在瓶颈环节，上限随峰谷定期调整，超限时先完成再拉入 |
| 人员兼职，但可投入时段大致可估 | 调整后适用 | 按可投入时段折算容量，上限调小，明确交接点 |
| 需求完全不可控且无优先级机制 | 暂缓 | 先建立需求准入与排序规则 |
| 兼职投入时间无法预估，工作项未可视化 | 暂缓 | 先做可视化与完成定义，再引入限制 |
这张表想说明的是：波动和兼职属于需要调整参数的条件，不属于放弃做法的理由。真正需要暂缓的，是连“瓶颈在哪、每人每天能投入多少、什么算完成”都说不清的状态。此时设一个数字上限，只会变成形式上的约束。
在制品限制解决的是什么问题
在制品限制直接作用在流动时间上。同时开工的任务越多，每项任务分到的人手和注意力越少，任务在环节之间等待的时间越长，从开始到交付的周期就越长。把并行数量压下来，任务更快走完整个流程，平均流动时间随之缩短。这个关系在需求波动时同样成立，因为波动影响的是进入量，流动效率仍取决于并行控制。
它还有一层可见化作用。当某个环节的在制品持续堆积，队列变长，瓶颈就暴露出来。团队不需要靠感觉争论谁最忙，看板上哪一列堆得最多、哪一列长期超出上限，就是判断依据。对兼职团队来说，这一点尤其有用：兼职成员的空闲时段分散，堆积往往出现在交接和等待上，限制能把这类隐性等待显性化。
超限时的行为规则是这套做法能否落地的关键。上限被触碰时，团队先集中完成已有工作，再拉入新任务，而不是继续开工。这个动作把协作从“各自领任务”转为“一起清队列”，也让完成优先于启动成为可观察的日常习惯。需求波动大时，这条规则能防止高峰期无限加塞；人员兼职时，它能防止有限的可投入时间被切得太碎。
需要说明的是，这些是机制层面的解释，具体能缩短多少时间取决于团队原有的并行程度、任务颗粒度和交接次数，不宜预设统一收益。
需求波动大时的适用条件与设限方式
波动场景下，限制应设在瓶颈环节，而不是给全流程每一列都配同一个数字。瓶颈环节的上限决定整体吞吐，其他环节的上限只需与之匹配，避免上游堆料或下游空转。如果团队还不确定瓶颈在哪，可以先观察一两周各环节的队列长度和等待时间，再确定限制位置。
上限需要随需求峰谷定期复核。常见做法是每个迭代或每两周看一次：高峰期是否长期超限、低谷期上限是否形同虚设。复核的依据是实际队列和完成情况，而非主观感觉。调整幅度宜小步进行，一次只改一个环节的上限，便于判断效果。
需求来源和优先级必须有人把关。波动本身不可怕，可怕的是所有需求都以同等紧急度涌入。需要明确谁负责接收需求、谁决定排序、什么条件下可以插队。没有这道关口，在制品限制会被不断突破，规则很快失效。
超限时的处理规则要提前约定并写清楚：上限已满时，新需求进入等待区而非直接开工；确需插队的，由把关人明确替换掉哪一项在制品，被替换的任务回到待办。这样上限始终有效，优先级决策也留下记录，便于后续复核。
人员兼职时的适用条件与设限方式
兼职场景下，容量要按可投入时段折算，不能按人头计数。两名各投入半天的人，与一名全职者的可用工时接近，但可协作的时段可能完全不重叠。设限前先估出每个角色每周或每天真正可用于该工作流的小时数，再换算成能并行推进的任务数。上限通常要比全职团队更小，因为切换成本和等待交接的时间更多。
角色分工与交接点要明确。兼职成员往往只在特定时段出现，任务在角色之间的传递必须有清晰的交接标准：上一位交付什么、下一位从什么状态接手、交接发生在哪个时点。交接点不清楚，任务就会卡在两人之间，形成看不见的在制品。
完成定义和验收口径需要提前统一。兼职成员参与时间有限，返工代价更高，因此“什么算完成”要写成可核验的条目，例如包含哪些产出、通过谁的验收、满足哪些条件。口径一致，才能避免任务反复在“快完成”状态停留。
上限调小会改变交付节奏，这一点要提前对齐预期。并行任务少，单项任务完成更快，但同时推进的事项数量下降，整体吞吐在短期内可能看起来变慢。团队和管理者需要接受这一取舍，否则容易在压力下重新放开上限，让限制失去意义。
| 对比项 | 需求波动大 | 人员兼职 |
|---|---|---|
| 限制设在哪 | 瓶颈环节，其他环节与之匹配 | 按角色和可投入时段设限 |
| 上限怎么定 | 按瓶颈容量，随峰谷调整 | 按折算工时，通常更小 |
| 复核节奏 | 每个迭代或每两周 | 随成员投入变化及时调整 |
| 关键前提 | 需求准入与优先级把关人 | 交接标准与完成定义 |
| 超限处理 | 先完成再拉入，插队需替换 | 先完成再拉入，避免任务切碎 |
投入与前提：采用前需要准备什么
在制品限制要真正起作用，需要先具备几项基础条件。这些准备本身也是团队梳理工作方式的过程，投入不大，但缺一项就容易让限制流于形式。
- 工作项可视化与状态定义。所有进行中的工作都要在看板上可见，状态列的含义统一，进入和离开每一列的条件清楚。隐藏的工作项会让上限失真。
- 完成定义与验收标准。每个工作项有明确的完成条件和验收人，避免任务长期停留在“接近完成”的状态占用名额。
- 瓶颈识别所需的数据或观察。至少能说清哪个环节队列最长、等待最久。初期靠观察即可，后续可用累计流图等记录辅助判断。
- 团队对超限规则的共识与执行纪律。上限被触碰时先完成再拉入，这条规则需要团队共同认可并坚持执行，否则限制会被日常压力逐步侵蚀。
在可视化这一环，团队可以用ONES的工作项与看板把任务状态、负责人和流转过程集中呈现，状态列与完成条件在同一个工作项上维护，队列堆积和超限情况可以直接在看板上看到。这样，设限、观察和复核就有了共同的依据，兼职成员的交接也能围绕同一份工作项记录进行。
暂缓条件：哪些情况先不采用
有些状态下引入在制品限制弊大于利，应先解决更基础的问题。以下情形宜暂缓：
- 需求来源完全不可控且没有优先级机制。所有需求都被视为必须立即处理，上限设了也会被反复突破。替代动作是先建立需求接收入口和排序规则。
- 兼职投入时间无法预估。连每人每周能投入多少都说不清，容量折算就失去依据。替代动作是先记录一到两周的实际投入，形成大致估算。
- 工作项未可视化、状态定义混乱。看不到在制品，限制无从谈起。替代动作是先统一看板列和状态含义。
- 团队规模与协作方式尚不稳定。人员频繁变动、分工尚未成形时，上限刚定就要改。替代动作是先稳定基本协作节奏，再引入限制。
暂缓不等于放弃。这些替代动作本身就是采用在制品限制的前置准备，完成后再回来设限，成功率会明显提高。
试点判断：如何小范围验证是否适合
与其一次性在全流程推行，不如选一个瓶颈环节做单点限制，用小范围试点验证适配性。具体做法如下：
- 选点。挑队列最长或等待最久的那个环节，只在这一列设上限，其他环节暂不限制。
- 定周期。设定两到四周的观察期，覆盖至少一个需求波动周期，兼职团队则要覆盖成员投入的完整轮次。
- 定指标。观察该环节的队列长度、任务平均等待时间、超限发生次数和超限原因。指标不必复杂，能对比试点前后即可。
- 记录超限原因。每次超限都记下原因：是需求突增、人员缺席，还是任务颗粒度过大。这些记录是后续复核上限的直接依据。
观察期结束后按以下依据判断：队列长度和等待时间下降、超限原因多为可解释的外部波动，说明限制有效，可以维持或小幅调整上限；超限频繁且原因集中在容量不足，说明上限设得过高或需要补充投入；超限原因多为规则未被遵守，说明问题在执行纪律而非限制本身，应先解决共识问题；若连基本数据都难以记录，说明可视化基础不足，回到准备阶段。继续、调整还是停止，都应以这些记录为依据，而非单次感受。
常见问题
需求波动大时，在制品上限应该多久调整一次？
常见做法是每个迭代或每两周复核一次，依据实际队列长度、等待时间和超限记录来判断。调整时一次只改一个环节的上限，幅度宜小，便于观察效果。如果需求峰谷周期明显短于两周，可以缩短复核间隔，但不宜频繁变动，否则团队难以形成稳定预期。
兼职成员投入时间不稳定，还能设定在制品上限吗？
可以，但前提是能对可投入时段做出大致估算。如果连每人每周能投入多少都说不清，建议先记录一到两周的实际投入，形成粗略基线后再设限。上限应比全职团队更小，并随成员投入变化及时调整，避免用固定数字套用所有时段。
在制品限制和迭代管理中的Sprint规划是什么关系？
在制品限制关注的是并行工作数量与流动效率，属于工作流层面的约束；Sprint规划、执行、评审与回顾属于迭代管理的具体方法。两者可以配合使用，例如在迭代内设定在制品上限，但具体规划与回顾流程不在本文展开，可参考迭代管理相关主题。
试点期间超限频繁，应该先调上限还是先查原因？
先查原因。记录每次超限的具体触发因素：需求突增、人员缺席、任务颗粒度过大，还是规则未被遵守。若原因集中在容量不足，可小幅上调上限或补充投入；若原因多为规则执行问题，应先解决团队共识与纪律，再考虑调整数字。直接调上限容易掩盖真实瓶颈。
