看板如何做好进行中？项目经理实操方法与操作步骤

看板里的“进行中”越满，项目未必越快；很多时候，团队只是同时打开了更多任务，却没有让更多工作真正完成。做好“进行中”，关键不是把卡片颜色改得更醒目，而是让团队对“何时开工、同时做多少、卡住怎么办、什么条件算完成”有一致规则，并且每天按规则推动工作流动。

一、先说结论：管好流动，比填满“进行中”更重要

1. “进行中”不是任务的暂存区

项目看板上的“进行中”，应代表一项工作已经具备启动条件，而且团队正在采取明确行动。它不应该成为“已经分配但还没开始”“等别人回复”“做了一点但忘记更新”等状态的统称。

如果一张卡片进入“进行中”后，团队说不清下一步是什么、由谁推动、当前缺少什么，那么它更可能是状态信息，而不是正在流动的工作。项目经理真正需要管理的，是卡片从进入到退出这一列的规则和过程。

2. 先设三类规则，再谈工具和报表

我会先和团队约定三件事：进入“进行中”的准入条件、同一时间允许并行的工作量，以及离开“进行中”时必须满足的完成条件。三件事缺一不可：只设准入条件，任务可能越开越多；只设数量上限，团队可能把卡片挤在边界外；只写完成标准，也无法解决等待和阻塞。

在此基础上，再规定阻塞标记、状态更新频率和升级路径。项目管理工具可以承载这些约定，但它不会自动替团队判断任务是否可执行，也不会自动消除审批等待或跨团队依赖。

3. 用三个问题检查“进行中”是否健康

• 能不能开工：任务目标、责任人、输入和验收要求是否清楚？
• 能不能推进：当前是否有明确的下一步行动？如果没有，卡点是什么？
• 能不能退出：交付物达到什么条件后可以转到下一阶段或完成？

如果团队能对这三个问题给出一致答案，“进行中”才有管理意义。否则，卡片数量看起来很具体，实际却无法用来判断工作是否在前进。

二、为什么“进行中”最容易失控：看板显示的是工作，不是忙碌感

1. 任务分配完成，不等于任务已经启动

常见场景是：项目经理把工作分给负责人，卡片立刻从“待办”拖到“进行中”；但需求输入还没确认，设计评审尚未完成，外部团队也没有提供接口说明。卡片虽然换了列，实际工作仍停在等待。

这种做法会让团队高估已经启动的工作，也会让后续会议陷入“卡片为什么没动”的追问。更好的做法是把分配和开工分开：任务可以先有负责人，但只有满足团队约定的启动条件，才进入“进行中”。

2. 被打断的任务，常常没有在看板上留下痕迹

一项任务可能正在等待审批、测试环境、客户反馈或其他团队的交付。如果团队没有阻塞标记，这些工作仍显示为普通的“进行中”，项目经理就很难区分主动执行与被动等待。

我不建议把每一种等待都立即增加为一整列。列越多，维护成本越高，也可能让团队把时间花在选择状态上。可以先用“阻塞”标签、原因字段和责任人记录；当等待已成为稳定且重要的流程阶段时，再考虑是否拆成独立列。

3. 任务太大时，状态会变得模糊

“完成新客户管理模块”可能横跨需求确认、页面设计、开发、联调、测试和发布。这样的卡片在进行中停留很久，并不一定意味着团队没有工作，而可能是一个卡片包含了多个不同阶段的工作。

项目经理要判断是否拆分，不能只看卡片停留天数，还要看交付物能否独立验收、工作是否存在清楚的先后关系，以及拆分后是否有助于更早发现风险。机械地拆成几十个极小任务，也会增加维护负担。

4. “看起来很忙”容易掩盖系统性等待

如果每个人手上都有多项任务，团队很容易形成忙碌感，却不容易看出工作在哪个环节积压。卡片分散在多人手里，评审、审批或测试环节可能排队，整体交付仍然缓慢。

下图为用于说明判断方法的情景模拟，不是行业统计。它展示一种可能的任务等待构成：工作停滞不仅可能来自执行环节，也可能来自依赖、评审和范围变化。实际团队应按自己的阻塞记录重新分类。

三、常见误区：表面上有规则，实际上没有管理闭环

1. 把任务卡数量当成工作进度

“进行中有二十张卡”只能说明看板上有二十张卡被标记为进行中，不能直接说明完成了多少价值，也不能说明团队的交付速度。任务大小、复杂度、依赖和验收标准不同，卡片数量并不是可直接比较的工作量单位。

项目经理应把“进行中”数量与完成记录、阻塞情况、任务停留时间和工作类型一起看。如果卡片数上升而完成数没有相应变化，值得调查是否出现并行过多、任务粒度不一致或下游积压，但不应仅凭这一现象判定团队效率低。

2. 把 WIP 上限照搬成一个固定数字

在制品限制常被简称为 WIP 限制，指团队约定某个流程阶段或工作类型中允许同时存在的工作量。它不是全行业通用的固定数字。团队人数、任务差异、评审方式、外部依赖和业务风险都会影响合理的上限。

例如，同样是五名参与者，如果任务需要多人协作，不能简单按“一人一张卡”推导；如果任务由不同专业角色分别处理，也不能把所有工作混成一个数字。上限应作为待验证的团队政策，而不是看板装饰。

3. 达到上限后继续开新任务

如果规则写着“进行中最多八项”，但一到紧急事项就直接开第九项，这个上限就没有发挥作用。真正的例外机制不是“谁着急谁插队”，而是明确由谁批准、插入工作影响什么、现有哪项工作因此暂停或降级。

达到上限时，团队应先帮助已有工作向前移动。可能的动作包括补充缺失信息、组织评审、解决环境问题或协调依赖。如果确有必要插入新任务，就把被挤出的工作和影响同步展示，而不是让新增工作隐形增加。

4. 把阻塞任务从 WIP 中拿掉，让数字看起来更好

阻塞不等于工作不存在。若一项任务已经开始，只是等待输入，把它移出“进行中”可能会让在制品数量显得下降，却掩盖真实交付压力。是否将阻塞任务计入当前阶段的 WIP，需要团队先定义口径，并保持一致。

有些团队会让卡片留在原阶段并加阻塞标记；有些团队会设置等待状态，但仍在整体工作量统计中计入。无论选哪种方式，关键是不能通过移动卡片来美化数据。

5. 用停留时间给个人排名

卡片停留时间长，可能源于复杂度、依赖、评审排队、需求变更或任务拆分不合理。它是调查线索，不是对个人能力的直接结论。把单一周期指标用于个人排名，容易诱发拆卡、延迟录入或回避复杂工作等反效果。

更稳妥的做法是先看工作类型和流程环节，再分析异常任务。指标适合帮助团队提出问题，例如“为什么评审等待增加”，不适合替代具体讨论，直接回答“谁做得不好”。

四、项目经理的判断逻辑：先确认可执行，再控制并行和例外

1. 设计进入“进行中”的准入条件

准入条件应足够具体，能在任务开始前检查，又不能复杂到每次开工都要填一张审批表。对于多数团队，可以从以下项目中挑选适用项：

• 任务目标和预期交付物已经说明。
• 负责人或明确的执行协作方式已经确定。
• 必要输入、权限、环境或依赖已经具备，或已有确认的获取时间。
• 验收方式和完成边界可被执行者理解。
• 任务优先级与当前团队目标相符。

团队可以将规则写成：“满足必要输入、责任明确、验收要求可检查时，任务才从待办进入进行中。”这里的“必要”要由业务流程定义；并非每个任务都需要完整规格文档，也不是每项工作都必须等所有不确定性消失。

2. 用拉动机制替代“持续派活”

如果项目经理不断把新工作推入执行阶段，团队就容易同时启动过多任务。拉动式的做法是：当团队有容量时，从已排序的待办中选择下一项满足条件的工作，而不是只因为有人提出就立刻启动。

这并不表示项目经理放弃优先级管理。项目经理仍要说明业务顺序、紧急程度和取舍，只是启动时还要考虑团队当前容量，以及已有工作能否先向前推进。

3. 按工作类型设置 WIP 口径

团队可以按流程列、工作类型或服务类别设置限制。重要的是统计口径要清楚：一张父任务带三个子任务时算一项还是四项？等待评审的卡片是否仍计入？紧急工作是否有单独通道？如果团队成员对这些问题理解不一致，上限就无法稳定执行。

开始时不必追求精细复杂。可以先选一个最容易观察的范围，记录现有并行数量和完成情况，再试行上限。若工作差异很大，可以分类型观察，避免把小修复与大型跨团队任务当作同质卡片。

4. 把阻塞处理变成有责任人的流程

“已阻塞”并不是处理动作。每张阻塞卡至少应说明阻塞原因、需要谁协助、下一步行动和何时再次检查。项目经理应优先协调那些影响后续工作或可能扩散到多个任务的阻塞，而不是按声音大小依次处理。

升级路径可按影响设置，例如：团队内部问题由负责人协调；跨团队依赖由项目经理联系对应负责人；可能影响里程碑、合规或客户承诺的事项进入既定决策机制。不同项目无需复制同一套层级，但应避免“大家都知道卡住了，却没人负责推动”。

5. 依据可观察信号调整规则

上限偏高或偏低，不能凭“看起来舒服”判断。可以观察新任务是否频繁等待、已有工作是否长期堆积、团队是否总因临时插单破坏承诺、下游环节是否形成队列，以及阻塞是否有规律地集中在某一阶段。

以下图表是流程政策的示意，不代表真实团队基准。它强调的不是哪个数字最优，而是把不同 WIP 上限下的工作量、等待和协调成本放在一起评估，再依据实际结果调整。

五、具体案例：用四周模拟数据看“进行中”如何改进

1. 案例边界：这是示意项目，不是客户实绩

为了说明操作过程，下面构造一个虚拟的产品交付团队：十二名成员，工作包括需求澄清、开发、评审和测试。团队发现进行中任务较多，但卡片常常等待评审或依赖输入。以下数据是情景模拟，用来演示如何观察和复盘，不应当作行业平均值或效率承诺。

模拟团队先统一“完成”的口径：卡片有明确交付物，通过约定的检查后才算完成。团队随后为任务增加阻塞原因和下一步行动字段，并试行进行中上限。这里没有把某个数字包装为推荐标准；示例上限只是团队讨论后的试点政策。

2. 第一步：先记录基线，不急着改所有流程

第一周，团队只记录每项任务进入进行中的日期、离开日期、阻塞原因和任务类型，不急于一次性更改列结构。这样做的好处是，项目经理可以先了解任务停在哪些阶段，而不是凭印象认定“大家任务太多”。

模拟记录显示，任务等待并非全部来自执行工作：部分任务在等需求确认，部分任务排队评审，还有一些因范围变化重新打开。若团队只增加“加快开发”的要求，问题很可能仍然存在。

3. 第二步：小范围试行准入和阻塞规则

第二周开始，团队把缺少关键输入的工作留在待办，不再因为已经指派负责人就直接标成进行中。已经开工但需要外部协助的卡片则保留原阶段，并用阻塞信息呈现原因、责任人和检查时间。

第三周，团队选一个主要工作流试行 WIP 上限。当上限达到时，成员先协助推进已有卡片；确需插入紧急任务时，项目经理说明优先级变化，并明确哪项原工作因此暂停或延后。

4. 第三步：用流程数据检查变化，而不是宣称“效率提升”

第四周，团队比较试点前后的任务数量、平均停留时间和阻塞记录。下表中的数值完全是模拟数据，只用于说明复盘口径：如果等待时间下降，同时完成量没有明显减少，可能值得继续观察；如果等待下降是因为大量任务被移出统计，则结论不成立。

5. 用多个证据验证，不把单一数字当成果

从模拟表格看，进行中任务减少、周期中位数缩短、阻塞责任人记录更完整，可能说明工作更可见、更易协调。但要判断是否真的改善，还要核对工作复杂度、紧急插单、人员投入和验收质量是否变化。

例如，如果试点期间团队把大型任务拆成更多小卡片，完成任务数可能上升，却不代表交付价值同步提高；如果团队延后记录起始日期，周期时间也可能看起来缩短。项目经理应抽查样本并解释口径，避免把“报表变好”误认为流程已改善。

六、日常操作步骤：从每日检查到周期复盘

1. 每天先看工作流，再看个人状态

日常同步不必从“每个人逐项汇报做了什么”开始。我更建议项目经理先扫一遍看板：哪些列积压，哪些卡片停留异常，哪些事项被阻塞，是否有工作接近完成但卡在验收或评审环节。

这种顺序能让讨论围绕工作流动展开。若团队一上来就逐人汇报，会议容易变成口头状态复述，看板只是背景板，真正的依赖和瓶颈反而不容易暴露。

2. 对每张停滞卡片，问清四件事

1. 当前状态准确吗？卡片所在列是否反映实际工作，而不是上一次更新时的状态？
2. 下一步是什么？下一项可观察、可执行的动作是什么，由谁负责？
3. 是否存在阻塞？缺少输入、审批、环境、决策还是跨团队交付？
4. 需要什么协助？团队能否当场解决，还是需要项目经理协调或升级？

如果一张任务卡无法说明下一步，也没有明确阻塞原因，就不要只留下“继续跟进”这样的模糊结论。应补充具体行动，例如“由负责人在周三前取得接口确认；未取得则升级给双方负责人”。

3. 达到 WIP 上限时，按固定顺序处理

1. 确认当前工作量是否按团队定义的口径统计，避免父子任务重复计数。
2. 检查已有工作中是否有能够通过协作、评审或补充信息推进的事项。
3. 识别是否有真正的紧急工作，并确认其业务影响和截止时间。
4. 若插入紧急工作，明确暂停或延后的原任务，并更新优先级。
5. 记录例外原因，周期复盘时检查例外是否频繁到需要调整政策。

重点不是机械地拒绝所有新工作，而是让每一次插入都能看见代价。若紧急事项每周都出现，问题可能不在团队执行，而在需求入口、优先级治理或容量规划。

4. 用异常阈值触发调查，不用它自动问责

团队可以设定一个观察阈值，例如任务超过某个工作日未更新、阻塞超过约定时间、同一阶段积压明显高于平时。阈值的作用是提醒项目经理调查，不是系统自动认定任务失败。

阈值应从历史记录和业务节奏中逐步校准。对于高频、短周期的任务，几天不更新可能值得关注；对于需要外部审批的工作，停留时间可能包含计划内等待。把阈值与工作类型、阶段和依赖背景一起解释，才能减少误判。

5. 每周复盘规则是否可执行

每周复盘不必追求复杂报表。团队可以检查四件事：哪些任务在进入前缺少信息、哪些阻塞反复出现、哪些工作被多次插队、哪些卡片完成标准不清。复盘的输出应是规则或流程上的一项改动，而不是仅仅记录“下周继续关注”。

如果团队采用电子看板，可以利用筛选、字段和提醒减少人工查找；如果使用实体看板，也可以用颜色标记阻塞和例外。工具选择取决于协作范围和管理要求，特别是中大型组织，往往还需考虑权限、审计、数据迁移和部署方式。工具能力是支持条件，不是看板实践的替代品。

七、不同情况下怎么取舍：不要把规则做成新的官僚流程

1. 小团队与大型组织，管理粒度不同

小团队沟通路径短，可以用较轻的准入规则和简单阻塞标记；如果每张卡都要求完整字段，维护成本可能超过信息价值。项目经理应优先确保目标、负责人和下一步行动清晰。

中大型组织往往涉及多团队依赖、权限边界和审计要求，状态定义与责任交接需要更明确。此时可以考虑按团队或流程设置不同政策，但要避免同一列在不同团队代表完全不同含义，否则跨团队汇总会失真。

2. 高不确定性探索工作与标准化交付工作，不能用同一准入尺子

探索类工作可能无法在启动前写出完整验收条件，要求所有输入确定后才开工，可能会阻碍发现问题。此类工作可以把“完成”定义为验证结果、决策依据或原型，而不是最终交付物，并给探索阶段设定时间或范围边界。

标准化交付工作则更适合检查输入齐备、验收标准明确和依赖就绪。项目经理要避免把探索工作的不确定性误判为执行混乱，也要避免用“还在探索”掩盖没有明确问题和产出的情况。

3. 紧急任务频繁时，先判断入口问题还是应急业务

偶发的紧急工作可以通过例外机制处理，但若插单不断出现，项目经理要分析来源：是否存在不受控的需求入口、计划外缺陷、审批延误或业务方不断改变优先级。反复插队说明团队的计划机制需要重新讨论。

如果安全、合规或客户事故确实需要立即响应，建立单独的应急通道可能比把所有工作都塞进普通 WIP 上限更合理。但应保留应急工作数量、来源和影响记录，定期检查通道是否被常态化滥用。

4. 需要高透明度时，不代表要追求更多字段

跨部门协作中，项目经理通常需要知道负责人、当前状态、阻塞原因、预计下一步和风险影响。但字段越多，更新负担越重。每增加一个字段，都应回答：谁会使用它做什么决定？如果没有具体用途，就不必强制填写。

可以采用“核心字段必填、特定风险字段按需补充”的方式。比如普通任务只记录负责人和验收条件；出现跨团队依赖时，再补充依赖方、承诺日期和升级联系人。信息结构应支持决策，不应变成填表竞赛。

5. 选择指标时，在可比性和业务解释力之间取舍

周期时间、吞吐量、在制品数量和阻塞时间都可能有用，但口径不清时会制造误导。周期时间从哪个状态开始计、完成以哪个验收节点为准、暂停任务是否纳入统计，都需要提前定义。

团队可以先选少量指标，观察趋势并配合案例复核。若指标只能告诉团队“变差了”，却不能帮助判断原因，就要补充分类信息或改进数据记录，而不是继续增加一排报表。

八、项目经理的一页式执行清单：从今天开始试行

1. 先用一场短讨论确认“进行中”的定义

让团队回答：“什么情况下才算已经开始？”“等待输入时卡片放在哪里？”“完成需要什么证据？”把答案写在看板旁或团队工作约定中。规则不需要写得很长，但要能让不同成员对同一张卡做出相同判断。

2. 选择一个工作流进行小范围试点

不要一上来改造全部项目流程。选择一个工作类型相对稳定、团队成员能参与复盘的工作流，先记录当前状态、等待和阻塞，再试行准入条件与 WIP 规则。试点的目的，是发现规则是否适合真实工作，不是提前证明它一定成功。

3. 把阻塞处理写成可执行动作

每个阻塞事项都尽量补齐原因、责任人、下一步动作和检查时间。若问题需要项目经理协调，就明确由谁联系哪个角色、何时升级。没有责任人和时间点的“持续跟进”，很难在下一次同步时判断是否有进展。

4. 每周只改一到两项关键规则

同时改变列结构、WIP 上限、验收方式和会议流程，会让团队很难判断哪项变化带来了影响。每周复盘时，优先选一个最影响流动的问题调整，并记录调整前后的观察结果。若结果不理想，也要允许恢复或再次修改。

5. 用下面的问题判断试点是否值得继续

• 成员是否更容易判断任务能不能开工？
• 是否更早发现等待和依赖，而不是临近截止日期才暴露？
• 达到 WIP 上限时，团队是否知道下一步该做什么？
• 卡片停滞时，是否能找到明确的责任人和协同行动？
• 完成条件是否减少了反复退回或状态争议？
• 数据是否能解释流程，而不是只用于汇报和排名？

如果大多数问题都能得到肯定回答，团队可以继续观察趋势，并逐步扩大适用范围。如果规则增加了大量维护负担，却没有让阻塞更可见、协作更顺畅，就应简化规则，而不是再添加更多字段和会议。

九、结语：管理“进行中”，最终是在管理团队的选择

看板“进行中”做得好，不是因为这一列卡片少，也不是因为所有卡片都能每天移动，而是团队知道为什么启动一项工作、为什么暂缓另一项工作，以及遇到阻塞后由谁采取什么行动。

我认为最有价值的管理转变，是从“每个人手里都有事”转向“团队能把已开始的工作持续推向完成”。这需要清楚的准入规则、适度的并行限制、真实的阻塞信息和可检查的完成条件，也需要项目经理在例外发生时公开说明取舍。

下一步可以从一个小范围试点开始：记录一周当前任务与等待情况，和团队确认进入、阻塞、退出规则，再试行一个适合本团队的在制品上限。两周后结合任务类型和真实交付记录复盘。不要追求一次设定永久正确的数字；要建立一套能让团队看见问题、采取行动并持续修正规则的工作方式。