看板如何做好进行中？PMO最佳实践与操作步骤

一个项目团队的“进行中”列里有 38 张卡片，其中 11 张超过两周没有更新，5 张正等着外部部门反馈。负责人看到的是“大家都很忙”，PMO看到的却是另一件事：看板把任务状态展示出来了，但没有说明什么工作可以开始、什么情况算阻塞、谁负责让任务继续流动。看板要做好“进行中”，关键不是多加一列，而是把进入条件、并行规则、异常处理和完成标准设计成一套可执行的工作流。

一、先讲结论：“进行中”不是状态标签，而是流动规则

1. PMO要管的不是卡片数量，而是工作如何流动

我判断一个看板是否真正管好了“进行中”，通常不先看列名，也不先看工具里有多少自动化功能，而是沿着一张任务卡片追问：它为什么此刻进入这一列？谁在推动？如果停住了，谁会发现？什么条件满足后，它才能离开？这四个问题答不清，“进行中”就更像一个任务收纳箱。

一套可运行的规则至少包括四部分：明确进入条件，限制同时开展的工作，暴露等待和阻塞，约定完成与交接标准。PMO的作用不是替团队回答每张卡片的进度，而是让这些规则在团队之间可理解、可执行、可复盘。

2. 不要用“大家都很忙”替代流程判断

进行中卡片很多，可能是需求入口不受控，也可能是任务粒度太大、跨团队等待没有单独标识，或者团队确实正处于交付高峰。仅凭卡片数量不能断定团队效率低。PMO要先判断工作停在哪里、为什么停、是否经常停在同一节点，再决定是限流、拆分任务，还是处理依赖。

我的判断顺序是：先让状态可信，再让问题可见，最后才讨论限额和效率。如果状态长期不更新，直接根据看板设WIP限制，可能只是把不准确的数据变成更严格的规则。

二、为什么“进行中”容易变成任务仓库

1. 任务一启动，后续状态却没有人负责

不少团队把“有人点开任务”“负责人开始阅读需求”当成开始执行。任务因此很早就进入进行中，但它可能还缺少验收口径、外部输入或关键决策。卡片看起来动了，实际工作并没有形成连续推进。

更稳妥的做法是把“已认领”和“执行中”分开考虑。未必一定要增加一列，但团队至少要说清：领取任务是否意味着开始计入在制品；哪些准备活动属于执行；任务缺少什么条件时不得进入正式执行。PMO需要统一的是判断口径，不是强迫所有团队使用相同列名。

2. 外部等待被误记成团队正在处理

项目任务常常要等待审批、接口、数据、供应商交付或其他团队的决策。如果这些卡片仍混在普通进行中任务里，团队和管理者就很难区分“正在加工”与“没有条件继续”。结果是每天看板上都很忙，真正需要协调的事项却没有明确的责任人和升级路径。

我建议至少让等待原因可见。可以设置独立的等待阶段，也可以用阻塞标记、原因字段和预计复查时间表达。采用哪种方式取决于团队规模和看板复杂度；重点不是视觉上多一列，而是有人能据此采取下一步行动。

3. 任务太大，卡片在进行中停留过久

“完成新系统上线”“优化客户体验”这类描述往往跨越多个团队和数周工作。任务粒度过大时，一张卡片无法展示阶段性成果，也难以判断它是正常推进还是已经卡住。PMO若只追问完成百分比，容易得到主观估算，却看不到具体交付物和依赖。

任务拆分不等于把工作切成大量无意义的小卡片。更有效的拆分依据是：每个子任务能否产生可检查的交付物，能否明确责任人，能否独立暴露等待或风险。对于必须连续完成的工作，也可以保留父子关系，但用子任务呈现推进节点。

4. 看板承担了汇报职责，却没有解决协调问题

如果每日检查变成每个人依次复述“昨天做了什么、今天做什么”，看板就会退化成电子版进度会。卡片内容被重复朗读，阻塞问题却未必有人接手。检查的重点应该从“谁看起来最忙”转到“哪项工作需要帮助才能继续”。

这也是PMO设计会议节奏时容易忽略的一点：状态更新可以异步完成，会议时间应留给依赖协调、优先级冲突和异常升级。看板要减少信息搜集成本，而不是创造新的汇报负担。

三、PMO需要纠正的五个常见误区

1. 误区一：列越多，看板就越精细

增加列能帮助团队表达真实环节，但每多一列，就多一条状态判断和维护成本。若没人知道“待评审”和“评审中”如何区分，或者任务在多个列之间反复跳转，细化只会让数据更难解释。

我通常先找出真实工作流中的交接点、等待点和验收点，再决定是否单独设列。若一个阶段的停留时间、责任归属或处理规则确实不同，单列有价值；如果只是为了让看板看起来专业，先用标签或卡片字段试行更稳妥。

2. 误区二：每人同时只能做固定数量的任务

团队常希望得到一个简单答案，例如每人最多同时做两项。但工作类型、任务粒度、协作方式和突发支持责任并不相同，给所有人套同一个数字容易形成形式主义：任务被拆成更多卡片，或工作实际启动了却不进入看板。

WIP限制更适合从团队或流程阶段开始试设，再根据观察结果调整。若确实要设置个人上限，应先确认任务定义一致，并明确紧急支持、值班响应等工作如何计入。限制是帮助团队暴露拥堵的约束，不是判断个人忙不忙的尺子。

3. 误区三：状态更新越频繁，管理越有效

频繁更新不一定代表信息更真实。若团队每天被要求多次改状态，成员可能把精力花在维护看板上；若更新时间有统一规则、更新能触发协作动作，才有管理价值。PMO需要约定“何时更新”和“更新后谁会采取行动”，而不是简单规定刷新次数。

4. 误区四：WIP限制是为了让团队少做事

限制并行工作不是减少总工作量，而是减少过多启动、反复切换和长期等待。设置限制后，如果任务满额，团队应优先帮助现有工作完成或解除阻塞，而不是机械拒绝所有新需求。真正的取舍仍需由优先级规则和业务责任人完成。

5. 误区五：把流程指标直接用于个人绩效排名

周期时间、完成数量和阻塞情况都受工作难度、依赖关系、需求变更与系统环境影响。若把单一指标直接绑定个人考核，团队可能拆小任务、提前改状态或回避复杂工作。PMO应把指标用于发现系统性问题，个人反馈则要结合任务背景、协作质量和交付结果。

四、用一套判断逻辑设计“进行中”规则

1. 先定义进入条件：任务具备开始工作的最低信息

PMO可以组织团队共同写出一张简短的“进入检查卡”，重点不是增加审批，而是避免任务在关键条件缺失时被过早启动。每个团队应根据工作类型调整字段，保留真正影响开始工作的条件。

• 目标：任务要解决什么问题，预期交付物是什么。
• 责任：谁负责推动，必要时谁负责协调依赖。
• 优先级：与当前承诺和紧急事项是否冲突。
• 依赖：启动所需的输入、权限、数据或决策是否具备。
• 完成标准：谁验收，哪些条件满足才算交付。

如果任务暂时不满足条件，可以留在待准备、待确认或待办状态，而不是先放入进行中再等信息。这样做的价值在于把“未准备好”和“已开始但推进困难”区分开，便于PMO找到真实的入口问题。

2. 再定义离开条件：完成不等于“负责人觉得做完了”

任务从进行中离开，需要有可检查的交付或明确的交接。软件开发可能需要代码评审、测试或发布确认；运营项目可能需要内容上线、数据核验或相关方确认。不同团队的完成条件不同，但都应能被另一位协作者理解。

特别要区分“执行完成”和“业务验收完成”。如果两者之间存在等待，就不要为了让进行中列变短而提前标记完成。可以用验收中、待发布等阶段表达，也可以在卡片里记录交接时间和接收方。

3. 设定WIP限制：先测现状，再用小步试行

WIP限制没有跨行业通用的固定值。PMO可以先选一个团队和一个流程阶段，连续观察一段时间的在制品数量、停留时间和阻塞原因，再提出试行值。试行期间必须同时约定超限处理：暂停新任务、优先协助已开始的工作，或由负责人确认是否存在必须插入的紧急事项。

调整限制时不要只看“卡片是否减少”。如果任务数下降，但交付等待变长、质量返工增加，限制可能过严或设置位置不合适。反过来，任务数量稳定但阻塞集中在一个审批环节，首先该处理的是流程依赖，而不是继续压低团队的并行数。

4. 为阻塞设置字段和升级时限

阻塞标记需要能引发行动。建议记录阻塞原因、等待对象、当前协调人、下一步动作和下次检查时间。若只是把卡片染成红色，却没有责任人和复查安排，标记很快会变成背景装饰。

升级机制应按问题影响而不是按情绪启动。团队内部可解决的问题由执行团队处理；跨部门依赖由项目负责人或PMO协调；影响范围、预算或承诺日期的事项，再交由有决策权限的人处理。升级的目标是缩短等待和消除障碍，不是增加一层汇报。

5. 用可解释的指标观察改善，而不是追求一个漂亮数字

PMO可从少数几个指标开始，先把口径写清楚。比如“停留时间”按日历天还是工作日计算，“阻塞任务”是否只统计已标记事项，“完成数量”按卡片还是交付批次统计。口径不一致时，跨团队比较没有解释力。

五、一个可复盘的模拟案例：从38张卡片到能解释的流程

1. 先把问题拆开，而不是立即要求团队清空进行中

以下是用于说明诊断方法的情景模拟，不代表某家企业的真实案例。设一个跨职能项目团队在周一检查看板时有38张进行中卡片。初步抽查后发现：22张正在执行，10张等待外部输入，5张明确阻塞，另有3张超过7天未更新。若管理者只看到“38项工作在进行”，很容易得出团队忙碌但难以判断是否拥堵的结论。

PMO接下来不应立即要求“每人只能做两项”，而是先核对这三张长期未更新卡片的实际状态，再确认10项等待任务是否有接收方和复查时间。这样可以把状态失真、依赖等待和真正执行中的工作分开，避免限额政策掩盖数据问题。

2. 选择一个窄范围试行，而不是一次性改造全公司

假设进一步检查发现，10项等待中有6项都卡在同一类跨部门确认，另外4项是不同性质的外部输入。团队可以先为这类确认增加等待标记、协调人和下次检查时间，同时将“确认条件齐备”写入进入执行的规则。其他等待原因则保持单独记录，避免把不同问题混成一个流程改革项目。

接着，团队针对主要执行阶段设定一个试行WIP上限。上限来自近期观察，而不是套用所谓行业标准。试行期间，每周检查未启动的新工作是否受到影响、已开始任务是否更容易完成、紧急事项是否需要例外处理。PMO应记录规则带来的副作用，不只汇报卡片数变化。

3. 把复盘结果写成下一轮可检验的问题

试行后，复盘不应只问“大家觉得怎么样”，而要问：等待任务是否更早暴露？超限时团队是否先协助已有任务？任务从开始到完成的时间是否更可预测？完成后是否出现更多返工？若没有改善，就回到原因层面检查：限额是否设错位置、任务是否太大、依赖方是否没有响应机制，或团队是否把状态更新当成形式任务。

六、按团队处境决定先做什么，也决定暂时不做什么

1. 看板刚上线：先统一定义，不急着上复杂指标

新看板最常见的问题是团队对列的理解不一致。此时优先完成列定义、进入条件、离开条件、阻塞表达方式和责任人约定。运行一段时间后再观察数据质量，过早做跨团队排名，往往会把定义差异误当作绩效差异。

如果团队规模较小、协作关系简单，可以先用少量列加卡片字段；当等待、评审或交接已经成为重要管理节点，再考虑拆出阶段。取舍重点是让信息足以支持行动，同时不让更新成本超过管理收益。

2. 进行中持续堆积：优先找任务为何无法离开

当任务积压不断增加，先按状态抽样：有多少仍在实质执行，有多少等待输入，有多少已完成但未验收，有多少已失去优先级。若积压主要来自单一评审或审批阶段，PMO应该推动处理该瓶颈，而不是只压低入口数量。

如果主要问题是同时启动太多工作，可以试行团队级WIP限制，并设定超限后的协作动作。若主要是任务粒度太大，则先改善拆分和阶段性交付。两种情况可能同时发生，但应一次验证少量改动，否则团队无法判断是哪项措施有效。

3. 跨部门依赖突出：先建立协调机制，再讨论个人上限

依赖工作占比高时，个人上限解决不了等待方没有响应、接口责任不清或决策路径过长的问题。PMO可建立依赖责任清单，明确提出方、接收方、期望反馈时间和升级对象，并在定期协调中处理跨团队阻塞。

此时要取舍的是会议与异步跟踪的比例。若依赖事项少而稳定，卡片字段和提醒足够；若事项频繁冲突、影响关键承诺，就需要固定的跨团队协调窗口。不要把所有卡片都带进会议，只讨论需要决策或协商的事项。

4. 需求变化频繁：保留紧急通道，但让代价透明

完全禁止插单不现实，完全不设规则又会让团队永远处于超载状态。可以约定谁有权认定紧急、紧急任务进入后需要暂停或移出的工作是什么，以及对现有承诺造成的影响。这样既保留业务响应能力，也让优先级变化的成本可见。

对需要稳定交付节奏的团队，尽量通过固定补充节奏安排新工作；对运营支持或突发响应较多的团队，则可以预留容量或单独跟踪服务请求。PMO要根据工作波动选择机制，不应把产品研发、项目交付和现场支持硬套成一种节奏。

七、工具、例会与PMO治理：把规则放进日常工作

1. 工具先服务规则，采购和配置不能替代流程设计

项目管理工具可以承载状态、字段、提醒、权限和报表，但它不能替团队定义什么叫开始、什么叫阻塞，也无法自动消除部门间的责任空档。上线前，PMO应先用真实任务走一遍工作流：任务如何进入、如何等待、如何升级、如何验收，再配置工具字段和自动化。

对于中大型企业和100人以上组织，工具选型还需同时考虑多团队协作、权限治理、部署方式、数据迁移和管理报表。以PingCode为例，若团队评估其用于承载研发与项目协作，应把需求范围、私有化部署要求、既有系统迁移方案和实际迁移验证列入评估清单；涉及Jira平滑迁移时，应先做字段映射、状态映射、附件与历史数据抽样核验，再决定迁移范围。不能仅凭“支持迁移”就假设所有历史配置都能无损复现，也不宜把任何平台称为适用于所有企业的唯一选择。

选型时建议用真实场景做验证：任选一条跨部门任务，检查权限是否满足要求、等待是否可追踪、状态历史是否可审计、报表口径能否解释、异常流程能否配置。工具适配度要由使用场景和治理要求共同决定，而不是由功能清单长度决定。

2. 日常看板检查：从最需要帮助的工作开始

每日或每周检查的顺序可以从“已阻塞、长期未更新、即将影响承诺”的任务开始，再看哪些工作可以通过协作尽快完成。主持人不必逐人点名汇报，卡片信息已清楚的事项无需重复朗读。会议要把时间留给决策、协调和资源冲突。

• 先查看有明确阻塞或超过约定停留时间的卡片。
• 确认每个阻塞事项的下一步动作、责任人和复查时间。
• 检查是否有人可以帮助已有任务完成，而不是立即开启新任务。
• 仅对优先级变化、跨团队依赖或需要决策的事项进行讨论。
• 会后更新行动项，并确认责任人知道何时反馈。

3. PMO治理：统一最小标准，允许团队保留差异

企业级看板治理容易走向两个极端：每个团队完全自定义，导致数据无法解释；或者所有团队必须使用相同流程，导致一线工作被模板束缚。更实用的做法是规定最小共同标准，例如状态含义、阻塞信息、责任字段、指标口径和升级原则，同时允许团队根据工作类型增加专属阶段。

PMO还应建立规则变更机制。若要调整WIP限制、列定义或指标口径，说明调整原因、试行范围、观察周期和回退条件。这样既能避免规则随意变化，也能防止某个试点做法未经验证便扩散到所有团队。

八、落地检查清单与最后的行动建议

1. 先用一周完成一次轻量诊断

不要从全公司流程重构开始。先选择一个有代表性的团队，抽查近期进行中的任务，确认状态是否真实、等待是否可辨、责任是否明确、完成条件是否可验证。诊断结果应描述流程事实，而不是给团队贴上“执行力不足”的标签。

2. 用一个周期试行两到三项规则

一个试点可以从以下动作中选择两到三项：明确进入条件、增加阻塞信息、设定阶段级WIP限制、约定超限处理、调整例会检查顺序。不要一次引入太多指标和流程门槛，否则既增加维护负担，也难以判断哪些改变产生了效果。

3. 在复盘时同时看结果、成本和副作用

复盘至少回答三个问题：任务是否更容易流动，阻塞是否更早被发现，规则是否增加了不必要的更新和会议成本。若交付变得更可预测但维护负担明显增加，就应简化字段或自动化提醒；若卡片数量下降但返工增加，则要检查完成标准和需求澄清。

可以直接用下面的清单作为首次检查依据：

• 团队是否能用相同的话解释“进行中”？
• 任务进入执行前，目标、责任和必要依赖是否基本明确？
• 任务离开进行中时，是否有可检查的交付或交接条件？
• 等待和阻塞是否能区分，是否记录责任人及下一步动作？
• WIP限制是否来自团队观察，并约定了超限后的处理方式？
• 日常检查是否围绕流动、阻塞和协作，而非逐人重复报进度？
• 指标口径是否清楚，是否避免直接用于个人排名？
• 试行规则是否有复盘时间、调整条件和回退办法？

看板“进行中”管理的核心，不是让所有任务看起来都在移动，而是让真正的工作、等待和阻塞都能被准确区分。对PMO来说，下一步不是先改工具或发布一套全员限额，而是选一个团队、抽查一批卡片、找出最常见的停滞原因，再试行少量能被验证的规则。看板只有在能够触发协作和决策时，才从状态展示板变成工作流管理机制。