研发看板的在制品上限，应按瓶颈环节的实际吞吐能力来确定，而不是按团队人数平均分配。可执行的做法是：先按列识别瓶颈，用近4–6周的实际完成量估算每列每周可处理项数，再以瓶颈能力为基准给各列设上限，总在制品上限控制在瓶颈周吞吐的1.5倍左右；运行1–2周后依据阻塞时长和流动效率调整，每次只改一列。本文给出计数口径、四步测算、角色分工、完整算例和落地检查清单。
要点总览（TL;DR）
- 在制品上限按瓶颈环节的实际吞吐能力确定，先按列识别瓶颈，再用近4–6周每周完成项数估算基准吞吐。
- 初始上限以瓶颈周吞吐为基准：瓶颈列与周吞吐持平或略低，上游各列按瓶颈节奏分配，总在制品上限约为瓶颈周吞吐的1.5倍。
- 运行1–2周后依据阻塞时长、流动效率和前置时间调整，每次只改一列，并记录依据数据与下次复核时间。
- 看板负责人组织测算与维护上限表，各环节负责人保证计数准确，团队在站会中处理超限项，管理层支持瓶颈资源调整。
- 上限是否有效看计数是否一致、超限是否有处置、阻塞与等待是否可观察、调整是否有记录，长期空列或长期超限时回到吞吐测算重新校准。
先定口径：在制品上限限制的是什么
在制品（WIP）指已经进入流动、正在被处理的项。未启动的待办、需求池中的条目、已经完成的项都不计入在制品。上限按看板列或泳道设置，限制的是同一时刻处于该状态的项数。比如“开发中”列上限为4，意思是团队同时最多有4个项处于开发中状态，第5个项要等其中一个完成或移出该列后才能进入。
这个口径需要在团队内形成书面说明，否则计数会失真。常见的失真来源有三类：一是把待办列也设了上限，导致计划活动被误当作流动限制；二是把“待发布”这类已完成开发但等待外部动作的项计入测试列，虚增了在制品数量；三是同一需求拆成多个子任务后，按子任务计数还是按需求计数没有统一。口径说明应逐列写明：该列计入什么、不计入什么、按需求还是按任务计数。
上限的作用是暴露瓶颈和缩短前置时间，与考核个人工作量无关。当某列达到上限，团队应停止向该列拉入新工作，转而帮助该列完成现有项。这个规则在站会中执行，由团队共同遵守，不针对个人做绩效评价。
确定上限的四步操作
以下四步按顺序执行，每步都说明输入、动作、输出和完成标志，便于团队照做并留下记录。
第一步：划分列并标出瓶颈
输入是现有看板列和近几周各列的积压情况。动作是沿价值流检查每一列：哪一列前面排队最长、哪一列的项停留时间最久、哪一列经常需要其他列的人来支援。输出是一张标注了瓶颈环节的列清单。完成标志是团队对“当前瓶颈在哪一列”达成一致，并写进上限表的备注栏。如果团队刚建看板、没有历史数据，可以先按经验判断瓶颈，运行两周后再用数据修正。
第二步：统计瓶颈列的基准吞吐
输入是瓶颈列近4–6周每周实际完成的项数。动作是逐周记录该列移出的项数，取周均值作为基准吞吐。用4–6周是为了平滑单周波动，周期太短容易被一次集中发布或一次故障干扰。输出是一个数值，例如“测试列每周完成约8项”。完成标志是该数值有逐周明细支撑，而不是凭印象估计。统计时注意口径一致：按需求计数就全部按需求计数，不混入子任务。
第三步：以瓶颈吞吐为基准设初始上限
输入是第二步得到的瓶颈周吞吐。动作是先给瓶颈列设上限，一般取该列一周能完成的项数略低或持平，让队列保持适度压力但不无限堆积；再向上游各列分配上限，使上游产出节奏与瓶颈消化节奏匹配；总在制品上限取瓶颈周吞吐的1.5倍左右。这个倍数的作用是给流动留出缓冲，避免上游一停就断供，同时防止在制品无限膨胀。输出是一张初始上限表，含各列上限值、设定依据和计划复核时间。完成标志是表中每一列都有数值和依据，团队确认后张贴在看板旁。
第四步：运行后按数据调整
输入是运行1–2周后的阻塞时长、流动效率和前置时间数据。动作是观察哪一列长期超限、哪一列长期空置、阻塞项集中在哪个环节，据此调整。调整原则是每次只改一列，改完再观察1–2周，避免多列同时变动导致无法判断是哪次调整起了作用。输出是修订后的上限表和调整记录。完成标志是每次调整都写明了依据数据、调整值和下次复核时间。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、划分列并标瓶颈 | 现有看板列、近几周积压情况 | 逐列检查排队与停留时间 | 标注瓶颈的列清单 | 团队对瓶颈列达成一致 |
| 二、统计基准吞吐 | 瓶颈列近4–6周完成项数 | 逐周记录并取均值 | 瓶颈周吞吐数值 | 有逐周明细支撑 |
| 三、设初始上限 | 瓶颈周吞吐 | 先设瓶颈列，再配上游，总算取1.5倍 | 初始上限表 | 每列有值和依据 |
| 四、运行后调整 | 阻塞时长、流动效率、前置时间 | 每次只改一列 | 修订上限表与调整记录 | 调整有依据和复核时间 |
角色分工与各阶段交付物
上限能否落地，取决于设定、执行、复核三类动作是否有人负责。看板负责人或敏捷教练负责组织测算、维护上限表并在复核时召集讨论；各环节负责人负责本列计数准确，超限时组织本列优先完成现有项；团队在站会中处理超限项，推动完成而不是新开工作；管理层提供吞吐数据，并在瓶颈属于资源不足时支持调整。角色不必新增岗位，可以由现有成员兼任，但每项动作要有明确的责任人。
| 角色 | 动作 | 产出 | 频次 |
|---|---|---|---|
| 看板负责人/敏捷教练 | 组织测算、维护上限表、召集复核 | 上限表与调整记录 | 初始一次，之后每1–2周复核 |
| 各环节负责人 | 保证本列计数准确，超限时组织完成现有项 | 本列计数与超限处置记录 | 每日 |
| 团队 | 站会中处理超限项，停止拉入新工作 | 站会决议与阻塞项清单 | 每日站会 |
| 管理层 | 提供吞吐数据，支持瓶颈资源调整 | 数据支持与资源决策 | 按复核周期 |
在工具层面，看板列的状态流转和计数需要与实际工作一致。ONES 的敏捷看板用于管理任务状态，站会中可以借助看板对齐进度与风险；系统会记录工作项滞留时间等过程数据，可作为复核上限时的参考。团队可以结合自身流程配置看板列与组件，使计数口径与工具中的状态划分对应起来。具体到按列设置上限并在超限时提示的能力，选型或配置时需向厂商确认实际支持范围。
示例：一个研发看板的初始上限测算
以下为演示情景，用于说明推导过程，数值为假设，不代表任何真实团队。
某研发团队的看板列依次为：待开发、开发中、待测试、测试中、待发布。团队统计近6周数据，发现测试中列每周完成约8项，且待测试列经常积压超过10项，判断测试环节为瓶颈。据此设定初始上限：测试中列上限设为8，与周吞吐持平，保证测试人员满负荷但不积压过多在测项；待测试列上限设为6，略低于测试消化能力，形成适度队列；开发中列上限设为5，与测试节奏匹配；待开发列上限设为4；待发布列上限设为3。总在制品上限取瓶颈周吞吐8的1.5倍，即12，各列上限之和控制在12附近。测试列上限最紧，原因是它决定整个价值流的产出速度，放宽测试列只会让在测项堆积、前置时间变长。
运行两周后，团队观察到待测试列长期满额、测试中列偶有空位，阻塞主要集中在等待测试环境。团队只调整了一列：将待测试列上限从6降到5，减少等待队列，同时与管理层协调测试环境资源。再运行两周后，测试中列完成量稳定在每周8项左右，前置时间趋于平稳。这次调整记录了依据（待测试列满额天数、环境等待时长）、调整值和下次复核时间。
完成检查：上限是否有效的判断标准
上限设好后，用以下清单逐项核对，判断规则是否真正落地并产生效果。检查可按每1–2周一次的频次进行，由看板负责人组织，团队共同确认。
- 各列计数与实际状态一致：抽查若干工作项，确认其所在列与计数口径说明相符，没有把待办或已完成项计入。
- 超限时有明确处置动作：达到上限后团队停止拉入新工作，站会中有推动完成现有项的记录，而不是默认放行。
- 阻塞项与等待时间可观察：阻塞项有标记，等待时长有记录，前置时间呈稳定或下降趋势。
- 上限表有复核记录：每次调整写明依据数据、调整值和复核时间，调整不是随意改动。
- 异常列能触发重新校准：某列长期空置说明上限过松或上游供给不足，某列长期超限说明瓶颈测算需要更新，两种情况都应回到第二步重新统计吞吐。
检查中发现计数口径与实际不符时，先修正口径再谈调整数值；发现瓶颈已经转移时，按新的瓶颈列重新测算，而不是在原表上逐列微调。上限是服务于流动的工具，随团队能力和工作结构变化而更新，保持记录可追溯比追求一次设定到位更重要。
常见问题
团队刚建看板、没有历史吞吐数据，初始上限怎么定？
可以先按经验判断瓶颈列，给各列设一个临时上限，运行两周后收集数据再修正。临时上限的作用是让流动先跑起来并暴露问题，不必追求一次准确。两周后按第二步统计瓶颈列每周实际完成项数，用真实吞吐替换经验值，并把这次替换记录在上限表里。
如果连经验判断都难以达成一致，可以先只给最可能积压的那一列设上限，其余列暂不设限，观察两周内哪一列排队最长，再补设其他列。
在制品上限设好后，某列长期空置或长期超限，应该先改上限还是先查流程？
先查流程再改数值。长期空置可能是上游供给不足、列划分过细或该环节本身工作量少；长期超限可能是瓶颈测算过时、人员或环境资源不足，也可能是计数口径把不该计入的项算了进来。先确认计数口径与实际状态一致，再判断瓶颈是否已经转移。
确认瓶颈转移后，按新的瓶颈列重新统计吞吐并重设上限，比在原表上逐列微调更可靠。若瓶颈未变而某列长期超限，优先处理该环节的资源或阻塞问题，上限值可暂时保留作为压力信号。
按需求计数和按子任务计数，对上限值有什么影响？
两种口径都能用，关键是全表统一。按需求计数时，上限反映的是同时推进的需求数量，数值通常较小，适合关注端到端交付节奏的团队；按子任务计数时，上限反映的是同时进行的具体工作项数量，数值较大，适合任务拆分较细、多人并行开发的团队。
混用会让计数失真：同一需求拆成多个子任务后，若部分列按需求计、部分列按任务计，总在制品上限就失去可比性。口径说明中应逐列写明计数单位，调整上限时也沿用同一单位。
总在制品上限取瓶颈周吞吐的1.5倍，这个倍数需要严格照搬吗？
1.5倍是经验起点，作用是给流动留出缓冲，避免上游一停就断供，同时防止在制品无限膨胀。团队运行1–2周后，如果前置时间稳定、阻塞可控，可以维持；如果缓冲明显过多、在制品堆积，可以下调；如果上游频繁断供、瓶颈列经常空转，可以适度上调。
调整倍数时同样遵循每次只改一处的原则，并记录调整前后的阻塞时长和前置时间变化，让倍数有数据支撑，而不是凭感觉反复改动。
用工具管理看板时，在制品上限的计数和提示需要注意什么？
工具中的看板列划分要与计数口径说明一一对应，状态名称和流转规则应让成员一眼看出某项处于哪一列。ONES 的敏捷看板可用于管理任务状态，站会中借助看板对齐进度与风险，系统会记录工作项滞留时间等过程数据，可作为复核上限时的参考。
按列设置上限并在超限时提示或阻止流转，属于具体配置能力，选型或配置时需向厂商确认实际支持范围。工具未提供自动提示时，可以由各环节负责人在站会中人工核对计数，效果取决于计数是否及时准确。
