看板进行中教程：企业管理者实操方法，避坑指南

看板上的“进行中”越满，团队未必越忙得有成效：如果十几张卡片同时推进，却没有人说得清哪些工作被阻塞、哪些可以完成、谁有权拉入新任务，那么看板只是在展示忙碌，而不是管理交付。管理者真正要做的，不是催每张卡片更新状态，而是设定进入规则、控制同时开工的数量，并让等待和阻塞变得可见。

一、先讲结论：管好“进行中”，先让工作流动起来

1. “进行中”不是一个状态，而是一组管理约定

不少团队把“进行中”当成一个大筐：开发中的工作、等待客户回复的事项、待设计确认的需求、已经做完但没人验收的任务，全放在同一列。看板看起来完整，管理者却无法判断工作到底是在推进、等待，还是已经失去负责人。

我建议先把“进行中”拆成三个问题：什么条件满足后可以开始？开始后由谁推动？出现等待或阻塞时如何处理？这三个问题有明确答案，才有管理规则；只有一列状态和若干张卡片，通常只是任务展示板。

2. 管理目标不是让每个人手里都有活

看板管理容易出现一个反直觉的现象：一味追求“每个人都在做事”，可能让整体交付变慢。因为一个人同时切换多个任务，任务之间的等待、重新进入上下文和交接成本都会增加。管理者应该优先关注工作能否持续完成，而不是每个人是否一直处于忙碌状态。

管理“进行中”的核心，是限制团队同时承诺的工作，尽早发现停滞，并优先帮助现有工作到达完成。这不意味着任何时候都不能开始新工作，而是新工作进入前，团队先检查现有任务是否需要完成、合并、暂停或解除阻塞。

3. 先定义规则，再讨论工具和数字

我不建议一上来就讨论“每个团队的进行中上限应该是几”。行业、工作类型、团队人数、依赖关系都不同，脱离现场给出一个固定数字，容易制造形式上的合规。更稳妥的做法是记录当前同时进行的工作量和交付情况，再用小步试行寻找合适的限制。

• 进入条件：任务信息齐备、优先级明确、负责人清楚，关键依赖已经识别。
• 完成条件：有可验证的验收标准，不能只凭“我做完了”判断。
• 阻塞规则：能标出阻塞原因、下一步动作、跟进人和升级条件。
• 限额规则：说明按人、按团队还是按流程阶段计数，超限后如何处理。
• 复盘规则：固定观察周期，依据交付和等待数据调整，不凭一次争论改规则。

二、为什么看板容易失灵：状态更新了，工作却没有流动

1. 真实现场往往不是卡片太少，而是等待被藏起来

一个常见的项目场景是：需求已经被标成进行中，实际却在等业务方补资料；开发工作显示进行中，实际正在等接口确认；任务显示待验收，但验收人还没排出时间。若团队只看状态名称，不记录等待原因，这些工作都会呈现为“有人负责、正在推进”，但没有新的可交付结果。

管理者看到这种情况，容易追加催办频率，要求成员每天更新状态。更新可以让信息更及时，却不会自动消除依赖。真正有效的介入方式，是确认缺失的信息由谁提供、跨部门决定由谁推动、验收能力是否不足，以及是否应该暂停低优先级工作。

2. 一张卡片最好表达一个可检查的工作单元

如果卡片写着“完成新业务系统”，管理者很难判断它是否进入进行中太早，也无法知道卡片长期不动是哪个环节出了问题。把它拆成可验证的工作单元，例如“确认权限矩阵”“完成接口联调”“业务代表验收关键流程”，更容易定位下一步。

拆分并不等于把任务切得越碎越好。小到每一条消息或每一次点击，反而会让看板维护成本上升。判断标准是：这个单元是否能在团队约定的观察周期内产生一个可以确认的结果？如果不能，就要检查是否需要拆分；如果拆分后只增加行政更新、不增加决策价值，就不必继续细化。

3. 先看真实流程，不要照搬理想流程

很多团队画流程图时，会把工作写成“需求，开发，测试，上线”，却省略了反复确认、等待依赖、返工和审批。结果是看板很整齐，团队仍在原来的隐性队列里排队。建板前，我会先让团队回看最近一批已完成工作：它们实际经历了哪些状态、在哪里等待、什么原因造成返工。

流程图的价值不是展示组织想象中的标准流程，而是把工作实际经过的节点暴露出来。先如实记录，再讨论哪些等待可以减少、哪些审批确有风险控制需要、哪些交接可以改为并行。否则，管理者可能把“流程图很简洁”误当成“工作已经简单”。

三、常见误区：哪些做法会把看板变成“忙碌展示墙”

1. 把“进行中”卡片越多，误认为产能越高

进行中数量上升，可能意味着团队承接了更多工作，也可能只是新工作不断进入、旧工作迟迟没有完成。只看卡片数量，无法区分产能增加和积压扩大。管理者至少要同时看完成量、停留时间和超限情况，判断新增工作是否真的变成了交付。

如果新任务不断插入，原有任务又不暂停，成员就会在多个工作之间反复切换。此时，继续往板上加卡片看起来像响应业务，实际上可能让团队更难完成当前承诺。新的工作进入时，必须明确它替代什么、推迟什么，或为什么值得突破原有规则。

2. 只设一个总上限，不看流程瓶颈

团队总共只能有十个进行中事项，不代表每个阶段都不会拥堵。如果前置评审只有一个负责人，后续开发人员却很多，卡片仍可能集中堵在评审前。相反，把每个阶段都设成一样的上限，也未必合理，因为阶段工作量和处理方式可能完全不同。

设置限制时要说明计数口径：是按团队总量，还是按某个流程阶段？子任务是否独立计数？被阻塞的工作是否仍占用名额？若这些规则不明确，超限讨论很快会变成“这张卡算不算”的争执，限制机制也就失去作用。

3. 超限后靠加班消除超限

限制的目的不是让团队通过加班把数字压回去，而是提醒管理者检查当前的流动问题。出现超限时，先问是否有优先级冲突、阻塞未升级、验收排队、任务颗粒度不合适，或管理层持续插入紧急工作。只有定位原因，才可能改变下一轮的工作方式。

如果团队反复超限是因为紧急需求真实存在，就不能靠一条“禁止超限”的规定解决。需要明确紧急事项的入口、决策人、被挤出的工作和复盘方式。每次例外都不记录代价，所谓限制只是写在板上的装饰。

4. 用个人排名替代流程诊断

把周期时间或完成数量直接用于个人排名，可能诱导成员优先挑容易完成的工作、拆分卡片以增加完成量，或把难题长期留在板外。指标越接近考核，越需要谨慎解释其边界。流程指标首先用于发现整体阻塞和波动，不能不加区分地代表个人贡献。

• 看到周期变长，先检查工作类型和依赖是否变化，不要立刻认定执行效率下降。
• 看到完成量增加，检查返工、质量和任务大小是否同步变化。
• 看到卡片停滞，确认阻塞责任是否跨团队，不要只追问当前负责人。
• 看到上限频繁突破，检查是否存在管理层持续插单或规则设计失配。

四、专业判断逻辑：如何设定上限、识别阻塞并读懂指标

1. 先确定“进行中”边界，再设在制品限制

在制品限制通常被称为 WIP 限制，指团队或流程阶段同时允许处理的工作数量上限。它的作用不是追求某个神奇数字，而是促使团队在接入新工作前，先完成、协助或解除现有工作。

设置前先回答三个问题：一张卡片代表多大的工作量？团队成员是否会共同处理卡片？阶段之间的交接是否算在某个阶段的数量里？如果一张卡片可能代表半天，也可能代表两个月，简单按张数限额就很难比较。要先统一工作单元，必要时按工作类别分组观察。

2. 用“完成优先”规则应对满载

当某个阶段达到上限，默认动作不应是继续塞入新任务，而是检查阶段内的工作。团队可以协助完成已有事项、推动阻塞解除、处理待验收工作，或者由管理者决定暂停哪个低优先级事项。只有确有业务原因时，才使用例外入口，并记录例外带来的影响。

一个容易执行的团队约定是：满载时先协作清空，确需插单时由指定角色做取舍，并明确被延后的事项。这比要求每个人只做自己的卡片更能促进端到端交付，也避免新工作进入后，旧工作无人维护。

3. 把阻塞拆成“原因、动作、责任、时间”

“卡住了”不是完整的阻塞记录。管理者至少要看到阻塞原因、当前需要的动作、负责推动的人，以及何时复查或升级。负责人不一定是造成阻塞的人：例如等待业务决策，任务负责人可能无法自行作出决定，但应有人负责向决策方推进。

4. 组合观察在制品、周期、吞吐和老化工作

单一指标很容易被误读。进行中数量说明当前负荷，周期时间说明工作从约定起点到完成经历多久，吞吐量说明一段时间完成了多少工作，老化工作则提醒团队哪些未完成事项停留得异常久。它们需要配合使用，才能看见流动状态。

周期时间的起点和终点尤其要统一。若一个团队从“承诺开始”计时，另一个团队从“实际开工”计时，两者的数字不能直接比较。吞吐量也要注明统计窗口和工作类型：某周完成十张小修复，不等同于完成十个复杂需求。

五、案例与数据观察：一次小范围试行应该怎么复盘

1. 用模拟团队说明问题，而不是伪装成企业实绩

下面是一个用于说明判断方法的情景模拟：某跨职能团队有8名成员，负责一类周期较短的内部改进事项。试行前，团队板上同时有24项进行中工作，最近一个月完成了18项；不少卡片没有记录阻塞原因，负责人需要在周会上逐张询问状态。

这个场景不能证明“限制在某个数字就能提高效率”，但能说明应该怎么设计观察。团队先统一卡片粒度，把等待确认和待验收从实际执行中区分出来，再将进行中限制设为试行值，并记录每周完成数量、周期时间、超限次数和阻塞类别。

2. 复盘时先比较过程，再判断结果

试行一段时间后，不能只比较“以前有多少项、现在有多少项”。如果进行中事项变少，但验收队列增加，说明拥堵可能只是从一个栏目移到了另一个栏目。若完成量下降，也要核对团队是否处理了更多复杂工作、是否发生假期或外部依赖变化。

我会用一组复盘问题判断是否值得继续：卡片是否更容易找到下一步？阻塞被发现得是否更早？管理者是否减少了逐项追问？交付周期是否在同类工作中出现改善？超限例外是否有清楚理由？只要其中的过程信号没有改变，就需要先修规则，不能急着扩大推广。

特别要注意：阻塞记录从4项增加到11项，可能是可见性提高，不必直接判定试行失败。真正需要追踪的是这些阻塞是否更快被处理、是否减少了无主等待，以及团队是否能据此调整依赖和优先级。

六、不同情况下怎么行动：按症状选择先手动作

1. 如果进行中很多，但完成量长期不变

先暂停新增非紧急工作，检查当前事项有没有明确负责人、下一步动作和完成标准。按老化程度排序，挑出最久未推进且仍有价值的事项，组织相关角色一起解决。如果一张卡片包含多个阶段，拆出可验收的工作单元；若价值已变化，则由业务负责人决定取消或暂缓，不要让过期工作占着名额。

这种情况下，最不应该做的是要求成员同时“再快一点”。如果系统正在堆积，继续增加并行任务会让管理者失去优先级控制。先恢复清晰的承诺，再谈是否需要增加人手或调整产能。

2. 如果任务常常进展顺利，却在验收处排队

这通常不是执行端的速度问题，而是验收能力或验收规则不足。可以安排固定验收时段、提前邀请验收角色参与需求澄清，或把验收标准写入卡片。对于需要专业审批的事项，明确替代审批人和升级路径，避免关键人员不在时整个流程停摆。

不要为了让看板“看上去完成得更多”，把待验收事项直接标为完成。这样会让周期数据失真，也会把质量风险留到后续环节。状态名称必须反映真实工作阶段，而不是管理者希望看到的结果。

3. 如果紧急插单多，原有限额总被突破

先定义什么叫紧急：例如法规时限、线上故障、重大客户风险，还是一般业务催办。由指定角色判断优先级，并记录插入的新工作替代了什么。若紧急事项占比持续偏高，管理者需要调整容量预留、需求入口或组织承诺，而不是把每次插单都包装成例外。

可以考虑给明确类别预留弹性容量，但不要没有数据就预留固定比例。先统计一段时间内紧急工作的频率、耗时和来源，再决定容量安排。对于需求高度波动的团队，规则应能容纳变化；对于节奏相对稳定的团队，则可以更严格地控制承诺入口。

4. 如果跨部门等待是主要瓶颈

把等待时间和依赖对象记录下来，并区分“等待决策”“等待输入”“等待资源”三类。对于重复出现的依赖，建立固定对接人、响应约定和升级机制；对于偶发依赖，卡片上明确下一步跟进日期即可。若管理者无法调动依赖团队，应由更高层级确认优先级，而不是让执行者承担无法控制的等待。

跨部门协作的关键并非多开一次进度会，而是让请求有明确格式、接收方有清楚责任、逾期有可行升级路径。看板能揭示依赖，却不能自动替组织做出资源和优先级决定。

5. 如果团队人数较多或流程跨多个部门

小团队可以先用共享表格或简单任务板试行；当团队跨多个部门、工作类型多、权限和审计要求更复杂时，才需要评估协作平台是否能承载流程治理。关注点包括字段和流程配置、跨团队视图、权限管理、历史记录、数据导出、部署方式、迁移成本和使用者培训。

例如，PingCode 面向中大型企业及百人以上组织，支持私有化部署，也提供 Jira 平滑迁移能力。对于评估国产替代的企业，这些可能是候选条件，但不能据此直接得出“最适合所有团队”的结论。选型时仍应验证现有流程能否迁移、历史数据和权限是否完整、关键集成是否可用，以及团队是否愿意持续维护流程规则。

七、不同情况下怎么取舍：效率、透明度与灵活性并非同时最大

1. 限制越严格，聚焦可能更好，但应急弹性更低

较严格的在制品限制有助于团队保持焦点，但若业务需求波动很大，完全没有例外机制会让团队陷入规则僵化。解决方式不是取消限制，而是明确例外决策者、例外条件、被替代的工作和复盘方式。灵活性需要有成本记录，才不会变成无边界插单。

2. 状态越细，过程越清楚，但维护成本也越高

增加状态可以揭示评审、测试、验收等环节的等待；但每多一个状态，就多一份更新责任和规则解释成本。只有当新增状态能支持明确决策时，才值得保留。若团队不能说明“看到这一列后要做什么”，这列大概率只增加视觉复杂度。

3. 透明度越高，越需要建立安全的复盘氛围

看板公开阻塞、延期和返工，可能让问题更早暴露，也可能让成员担心被追责而隐藏风险。管理者要明确：记录问题是为了改善系统，不是为了找出“谁拖慢了团队”。若组织把每个红色标记都用于个人惩罚，团队会倾向于晚报、少报，透明度反而下降。

4. 集中流程管理便于统一，团队自治更适应差异

跨部门项目需要统一的最低规则，例如状态定义、紧急入口和数据口径；但具体阶段和限制值可以由团队依据工作特征调整。完全统一容易忽略不同工作类型，完全自治则可能让跨团队协作变得无法比较。较稳妥的取舍是统一接口和原则，允许局部流程在明确边界内变化。

• 工作稳定、依赖少：可以提高限额执行力度，重点观察完成流动。
• 需求波动大、紧急事项多：保留明确例外通道，同时记录被挤出的工作。
• 质量风险高、验收复杂：增加必要的验证状态，不要为缩短周期跳过质量门槛。
• 团队成熟度较低：先少量状态、少量指标，避免复杂机制压过日常交付。
• 组织规模较大：统一跨团队协作规则，局部团队保留流程配置空间。

八、从小范围开始：一份管理者可执行的试行清单

1. 试行前：记录现状并统一术语

选一条边界清楚的流程，找参与工作的成员一起回看近期事项。记录当前状态、典型等待、返工原因和验收方式，明确什么算进入、什么算完成。先不要追求把整家公司所有工作都搬到一张看板上，试点范围越大，越难分辨哪些变化来自规则、哪些来自其他因素。

• 选定一类工作和参与角色，写清楚试点边界。
• 统一卡片粒度、状态含义、开始条件和完成标准。
• 选少量指标：进行中数量、周期时间、完成量、老化事项和阻塞原因。
• 说明数据仅用于流程复盘，不直接用于个人排名。

2. 试行中：先处理现有工作，再逐步调整限制

试行初期不要同时改变流程、考核和工具。管理者可以先观察工作是否按约定进入，阻塞是否被记录，满载时团队是否协助完成已有工作。若限制值过紧，出现大量等待或频繁例外，要看是工作单元太大、资源不均还是流程设计不合适；若限制值太宽，工作仍持续堆积，则要考虑逐步收紧。

每次调整都记录原因、预期变化和观察指标。例如，团队把“待验收”从执行状态中拆开，是为了看清验收队列；调整后就观察等待是否更容易定位、验收周期是否缩短，而不是只看卡片颜色或列数是否更整齐。

3. 复盘后：保留有效规则，删除没有决策价值的字段

复盘时既要问结果，也要问团队是否更容易做正确的下一步。如果数据变化不明显，但阻塞责任更清楚、管理者能更早协调依赖，这也是有价值的过程改善。反过来，如果卡片更新负担明显增加，却没人据此做出不同决策，就应该删减字段或自动化重复维护。

扩展到更多团队前，先确认试点规则可解释、可维护，并且没有把局部做法强加给工作性质不同的团队。看板推广不是复制列名，而是复制一种持续发现问题、明确责任并调整流程的能力。

4. 管理者每周复盘时可以直接问的五个问题

1. 本周哪些事项从开始走到了完成？哪些老化事项没有变化？
2. 最常见的阻塞是什么，下一步由谁在何时推动？
3. 是否有新工作进入，却没有明确说明它替代或推迟了什么？
4. 当前瓶颈在执行、评审、验收还是跨团队依赖？证据是什么？
5. 下周只调整一条规则时，想验证什么变化，观察哪些数据？

九、总结：看板的价值，不在卡片可见，而在管理动作变得更准确

管理者面对“进行中”越来越满时，第一反应不该是再催一次，也不该立即更换工具。先检查状态是否准确、工作是否过早进入、卡片是否长期等待、阻塞是否有负责人、紧急工作是否有取舍。很多时候，团队不是缺少一张更漂亮的板，而是缺少对工作如何进入、如何退出和如何处理例外的共同约定。

我建议下一步只做一件小事：选一条流程，把最近一批工作实际经历的状态画出来，并记录每项工作为什么等待。随后定义进入条件、阻塞处理方式和一组最小指标，再用团队自己的数据试行调整。先让看板揭示真实问题，再决定要不要收紧限制、增加状态或采用新的协作平台。这比追求一个通用的“最佳上限”，更能帮助管理者做出适合自己的判断。