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

项目看板里最容易制造“进度正常”错觉的，不是待办太多，而是“进行中”越来越满：卡片都有负责人，状态也有人更新，可项目负责人仍说不清哪些任务能按期完成、哪些在等依赖、哪些只是被遗忘在列里。做好进行中，不是让团队更勤快地改状态，而是把任务进入、并行数量、更新方式、阻塞处理和退出条件说清楚。

一、先讲结论：进行中不是存放任务的地方

1. 状态要代表事实，而不是意愿

“进行中”应该表示团队已经对这项工作投入了实际执行，并且当前有可验证的下一步。任务被分配给某人、排进本周计划、或者负责人说“我会尽快做”，都不等于任务已经开始。

我判断一张卡片是否适合留在进行中，通常会看四件事：谁在负责、目前做到哪一步、下一步是什么、预计何时检查或完成。如果这四项里有两项说不清，卡片大概率只是挂着一个状态，并没有提供有效的项目进度信息。

2. 管好进行中，重点是限制并行、清理等待

一张任务卡显示“进行中”，代表它占用了团队的注意力、沟通时间或交付能力。进行中的卡片越多，不一定代表推进越快；它也可能意味着工作被切得过碎、优先级频繁变化，或者大量任务实际上在等待他人。

项目负责人要管理的不是“卡片有没有移动”，而是工作是否持续流动。因此，进行中需要有进入条件、团队认可的并行工作量边界、固定的信息更新规则，以及卡住时的处理办法。

3. 一个可落地的管理闭环

1. 准入：任务目标、负责人、完成标准和必要依赖基本明确后，再进入进行中。
2. 限量：观察团队正在做多少项工作，避免新任务不断插入、旧任务无人收尾。
3. 更新：卡片记录当前进展、下一步动作、检查时间和阻塞信息。
4. 处置：阻塞任务写清等待对象、所需动作、协助人和复查时间。
5. 退出：任务达到验收标准后移出进行中；暂停、取消和转交也要明确记录。

这五步不是一套复杂流程，而是让看板从“展示状态”变成“推动决策”的最低限度规则。团队规模小，可以写在一页协作约定里；跨部门项目，则应落实到任务字段、状态流转和负责人职责中。

二、为什么进行中会堆满：从真实工作场景找原因

1. 看板上的“正在做”，可能只是“正在等”

一个常见场景是：产品任务标记为进行中，实际在等业务确认；开发任务标记为进行中，实际上游接口尚未交付；测试任务也标记为进行中，但测试环境还没有准备好。几张卡都在同一列，表面上工作很多，实质上却没有多少工作可以继续往前推。

如果等待时间没有单独呈现，负责人就容易把“工作未完成”误判成“执行人推进慢”。更合理的做法不是一遇到等待就新增大量状态，而是至少让“阻塞原因、等待对象、下次检查时间”可见。团队确实需要区分等待阶段时，再增加“待依赖”或“待验证”等状态。

2. 新工作不断插入，旧工作没有明确收尾责任

项目负责人常面对紧急需求、临时缺陷和高层追加事项。每次插入一件新工作，可能都会打断原有任务的连续性。如果新任务只被加到进行中，却没有人决定哪项旧工作降级、暂停或转交，进行中列会在视觉上膨胀，团队的实际交付能力却没有增加。

我的处理原则是：新增工作必须伴随一次明确的优先级决策。插入任务时，不只问“谁来做”，还要问“因此推迟或停止什么”。这条规则对临时需求尤其重要，因为紧急事项如果不记录对原计划的影响，周复盘时就会变成无法解释的延期。

3. 任务粒度太大，状态更新就会变得空洞

“完成整个客户门户改版”可能持续数周，若只用一张卡追踪，团队很难在中途提供有意义的状态变化。负责人每次只能写“继续推进”，项目成员也不知道下一次可验收的结果是什么。

任务太小同样有代价：如果一项工作被拆成几十张没有独立决策价值的卡片，维护看板会变成额外劳动。拆分的标准不是卡片越多越好，而是每个阶段是否能产生可检查的交付物、责任交接或风险判断。

4. 只看卡片数量，不看任务停留时间

进行中有十项任务，不一定比五项任务更危险。十项任务如果都能持续推进，且团队容量充足，未必需要立即干预；五项任务若其中四项已经连续多日没有下一步，反而可能暴露出依赖和决策问题。

因此我会把任务数量与停留时间一起看。停留时间不是拿来给个人排名，而是帮助负责人识别“哪类工作经常卡住”“哪个交接环节等待最长”以及“计划里的任务是否长期没有转成实际交付”。

三、常见误区：看板变得更忙，工作流却没有更快

1. 把“已经分派”当成“已经开始”

任务负责人明确，是责任清晰的必要条件，但它不能证明任务具备开工条件。负责人可能还缺少需求确认、账号权限、预算审批、测试环境或上游交付物。此时把任务放进进行中，只会让计划看起来更乐观。

更稳妥的做法是把“准备条件”写清楚。团队不一定要设置一个独立的“准备中”列，但至少应约定：关键输入未到时，任务应留在待办、标为等待，或附上明确的依赖计划。

2. 以为限制并行任务就是不让团队接活

工作量限制不是把团队变得僵硬，也不是遇到突发事项一律拒绝。它的作用是让团队在新增工作时看见机会成本：如果要开始一项新任务，是否可以先完成一项、暂停一项，或者重新安排优先级？

如果团队的工作存在大量突发事件，建议把预留容量和常规工作分开观察，而不是将所有任务塞进一个统一上限。否则，团队可能为了遵守数字而隐瞒工作，或把临时任务放在看板之外，最终失去透明度。

3. 把每天催问当成进度管理

“今天做得怎么样？”通常得不到足够可用的信息。执行人可能回答“还在做”，但负责人仍不知道完成了什么、接下来要做什么、是否需要协助。重复催问不仅增加沟通成本，还可能让成员把精力放在解释状态，而不是推进工作。

更好的更新格式是：已完成什么、下一步是什么、预计何时完成或复查、当前是否有阻塞。如果信息已经清楚，负责人就不必重复询问；如果信息缺失，要求补充具体字段，而不是要求团队每天写长篇日报。

4. 任务停留久，就认定负责人执行力差

一张卡停留时间长，可能是任务拆分不合理、验收标准含糊、优先级被反复打断、外部依赖没有回应，也可能确实是负责人没有推进。项目负责人需要先辨别原因，再决定是帮忙清障、调整范围、重新分配，还是做绩效沟通。

直接把任务停留时间当成个人效率分数，会鼓励团队拆小任务、频繁改状态，甚至回避复杂工作。看板指标应该帮助改进工作流，不应取代对工作背景和任务难度的理解。

5. 为了“管理精细”设置过多状态

状态越多，团队越需要理解每个状态的边界，工具维护成本也越高。若成员经常分不清“等待反馈”“待确认”“暂缓处理”之间的区别，说明这些状态并未转化成一致的管理动作。

状态只有在改变负责人、下一步动作、风险处理方式或验收流程时，才值得独立存在。否则，可以先通过标签或字段补充信息，避免把看板做成一套没人愿意维护的分类目录。

四、专业判断逻辑：任务什么时候进入、停留、离开

1. 进入条件：先确认做什么，再确认谁来做

我建议项目负责人用一组简短的准入问题检查任务，而不是要求每张卡填写大量表单。目标是让团队在开始前发现那些会导致返工、等待或责任争议的缺口。

• 目标是否明确：这项任务要产生什么交付物或可验证结果？
• 负责人是否确认：谁对推进和状态更新负责？协作人是否需要单独列出？
• 完成标准是否可理解：什么条件满足后，可以把任务标记为完成？
• 关键依赖是否可用：输入、权限、审批、环境是否已经具备？若未具备，等待计划是否明确？
• 优先级是否有效：这项工作是否在当前计划中？如果是插入事项，它将影响什么？

不要求每项任务的所有细节都在开工前完全确定。探索型工作尤其如此。但如果目标还不清楚，适合先安排一个范围澄清或方案验证任务，而不是把一个未知的大任务长期放在进行中。

2. 并行工作量：先观察，再设团队自己的边界

没有一个适用于所有团队的“进行中任务标准数量”。一个由多角色组成的交付团队，和一个负责内容运营的团队，任务周期、依赖结构、工作切换成本都不同。按人数简单规定“每人只能有两项工作”，可能忽略团队协作和任务复杂度。

实践中可先记录两到四周的并行任务数量、任务完成节奏、阻塞时长和临时插入频率，再在团队层面设一个试行上限。这个周期不是行业标准，只是便于获得初始观察样本的建议做法；若项目周期短或风险高，应按迭代和交付节点调整。

设限后要同时约定例外机制：发生紧急事项时，谁有权改变优先级？哪些工作必须先暂停？被暂停的任务需要记录哪些信息？没有例外处理规则的容量限制，往往会变成表面合规，实际工作转入私下沟通。

3. 更新规则：把状态变成可行动的信息

团队应该约定更新频率，但不必所有任务都每天更新。短周期协作、风险较高或依赖密集的任务，可以在每日站会或关键节点更新；周期较长且短期内变化不大的工作，可以按周或里程碑更新。

我会优先要求负责人更新“下一步动作”，因为它比“完成百分比”更容易复核。很多任务写着“完成80%”，但最后20%可能包含验收、集成、审批或上线，真正的风险恰恰在这些步骤里。

4. 退出条件：完成、暂停、取消和转交要分开

任务完成不能只看执行人是否勾选了完成。项目负责人要确认任务满足约定的交付标准；如果工作还需要测试、业务验收或发布，团队可以把这些环节分成不同状态，也可以在同一任务里列出验收子项，选择哪一种取决于交接责任是否需要独立追踪。

暂停任务时，至少记录暂停原因、恢复条件和复查时间。取消任务时，记录决策依据，避免其他成员继续投入。转交任务时，更新责任人、当前进展、未完成事项和下一步动作，避免新负责人重新调查一遍。

一张卡片离开进行中，不代表它一定完成；它也可能被暂停、取消或转交。把这些结果混在“完成”里，会让项目复盘失去可信度。

五、示例与数据观察：从一张任务卡看清管理动作

1. 用一个示例任务演示信息如何逐步补齐

下面是一张模拟任务卡，任务名称为“完成客户门户登录流程改造”。它不是来自某个真实客户项目的数据，而是用来展示：同一项工作如何从待办进入执行、遇到阻塞后暴露问题，再通过明确动作恢复流转。

这张示例卡的价值不在字段多，而在于每一次状态变化都能触发一个实际动作：开工前确认依赖，阻塞后找到责任方，解除后恢复计划，完成后按标准验收。若字段没有对应的决策用途，就不必为了“看起来完整”而保留。

2. 观察停留时间时，要同时记录原因和口径

团队可以每周查看进行中任务的停留时间，但必须先定义起点和终点。例如，从进入进行中到移出该状态，是否包含等待验收？阻塞期间是否计入？暂停任务如何处理？口径不同，计算结果就不能直接比较。

建议把停留时间与阻塞原因放在一起复盘。若任务长时间停留的主要原因是等待审批，解决办法可能是调整审批时限或提前安排决策；若主要原因是任务范围不断变化，则应先处理需求冻结和变更机制，而不是对执行人增加催办频率。

3. 评估方法有没有用，别只比较“任务完成更多了没有”

进行中管理调整后，可以对比一段时间内的并行任务数量、任务停留时间、阻塞时长、按期交付情况和临时插入次数。若完成量上升，但返工和紧急插入也明显增加，不能简单得出管理改善的结论。

数据观察至少要保持统计口径一致，并尽量比较相似类型的工作。跨部门复杂任务与重复性事务的周期差异很大，混在一起算平均值，可能掩盖真正的问题。指标适合发起追问，不适合脱离上下文直接评判个人。

六、不同规模与工作类型下，项目负责人怎么做

1. 小团队：先用最少规则解决状态失真

人数较少、协作链路简单的团队，通常不需要一开始就建立复杂工作流。先要求每张进行中卡片有唯一负责人、下一步动作和检查时间，再约定阻塞时必须说明等待对象和需要的支持。

如果团队经常出现任务被分配后长期未启动，可以先增加“准备中”状态或准入检查；如果主要问题是工作被临时打断，则优先建立插入规则。一次只改一个明显痛点，比同时增加多个状态、字段和会议更容易验证效果。

2. 跨部门项目：把等待责任和升级路径写出来

跨部门任务的难点往往不是执行人不知道要做什么，而是不同团队对优先级、交付时间和验收责任理解不同。此类项目的进行中卡片，最好明确依赖方、期望反馈时间、影响范围和升级联系人。

当依赖方逾期时，负责人先确认对方是否收到请求、所需信息是否完整、反馈时间是否现实，再决定是否升级。只在卡片上写“等业务”“等研发”，不足以推动问题；要说明需要对方提供什么，以及最晚何时需要。

3. 研发与交付团队：按真正的交接点拆分状态

研发、测试、发布和客户验收之间存在明确交接时，可以把“开发中”“待测试”“测试中”“待验收”拆开，让不同责任人和等待时间可见。但若同一责任人完成全部环节，或者团队无法及时维护多个状态，采用较少状态并配合验收字段可能更实际。

具体取舍可以看两个问题：状态变化是否意味着责任人改变？状态变化是否触发不同的处理动作？如果都不是，增加状态的收益可能有限。若交接经常丢信息、任务在测试环节长期排队，细分状态才更有助于定位拥塞。

4. 中大型组织：工具能力要服务流程治理

当团队和项目数量增加，跨团队依赖、权限治理、审计留痕和数据汇总会变成实际问题。以 PingCode 为例，它主要面向中大型企业及 100 人以上组织，支持私有化部署，并提供 Jira 平滑迁移相关能力。对于国产替代评估中的组织，这些能力可以纳入工具比较，但不应仅凭功能清单做最终选择。

我会建议评估者把真实流程带进试点：选取一条跨团队任务流，验证进行中状态是否能按角色配置、阻塞信息是否可追踪、历史数据迁移后字段含义是否保留、权限和部署要求是否满足。迁移工具能降低数据搬运成本，但流程定义、字段映射和团队使用习惯仍需组织自己确认。

如果组织有私有化、安全合规或国产化要求，可以把部署方式、数据权限、审计能力、接口和迁移计划列为硬性评估项；如果团队规模小、需求简单，则更应比较配置和维护成本，避免为了企业级功能承担不必要的管理复杂度。

七、不同情况下的行动建议与取舍

1. 进行中任务很多，但多数都在推进

行动建议：先不急着降低任务数量，检查团队容量、任务类型和交付周期是否匹配。若成员能够持续完成工作、阻塞可控、临时插入有记录，任务较多可能只是工作流的正常形态。

需要取舍：不要为了让看板视觉上更整洁，强行把实际工作移出进行中。应优先保证状态真实，再通过泳道、责任人筛选或团队视图提高可读性。

2. 进行中任务很多，而且不少卡片长期无更新

行动建议：先按最后更新时间和下一步动作筛查，不要一次性追问所有人。对无进展卡片逐项确认：是否已完成但忘记更新、是否在等待、任务是否过大、优先级是否被改变。

需要取舍：清理卡片时，不能把“没有更新”直接等同于“没有工作”。先确认事实；如果团队长期漏更新，再简化字段或调整节奏，而不是继续堆叠日报要求。

3. 项目不断插入紧急事项

行动建议：设立紧急事项的进入条件，例如明确影响范围、决策人和必须处理的时间。每次插入时，同时指定被暂停或降级的工作，并在复盘时记录插入原因。

需要取舍：流程灵活性与计划稳定性不能同时无限最大化。对高风险、高时效工作要允许快速调整，但要接受原计划可能延期，并把影响透明地传达给相关方。

4. 任务卡在等待外部团队或审批

行动建议：把等待对象、具体请求、截止时间、影响范围和下一次检查时间写进卡片。若等待期间仍有可独立完成的部分，可以拆出子任务并行推进，但不要通过拆分制造虚假的进度。

需要取舍：任务拆分能减少整体等待造成的停摆，却会增加协调和合并成本。只有在子任务有独立产出、责任明确且后续能顺利整合时，才值得并行处理。

5. 团队不愿意维护看板

行动建议：观察哪些字段没人使用、哪些更新重复发生、哪些会议内容已经在其他系统记录。删减不产生决策价值的维护动作，再保留负责人、下一步和阻塞等核心信息。

需要取舍：信息完整度和维护负担之间需要平衡。对低风险短任务，可以简化记录；对高风险、跨团队或受合规约束的任务，则需要保留必要的过程信息和决策记录。

八、项目负责人日常检查清单与下一步

1. 每日或每次同步时，检查五件事

• 有没有新任务未经优先级判断就进入进行中？
• 有没有卡片缺少负责人、下一步动作或检查时间？
• 有没有任务实际上在等待，却仍显示为正常执行？
• 有没有超过团队约定并行边界的情况，需要完成、暂停或重新排序？
• 有没有已经达到验收条件，却仍留在进行中占用注意力？

检查清单不是要求负责人逐张卡片盘问，而是快速找出需要决策的异常项。若一项任务信息完整、按计划推进且没有依赖问题，就没有必要因为管理动作而额外增加沟通。

2. 每周复盘时，问流程问题而不只问个人进度

• 本周哪些阻塞反复出现？它们来自输入、审批、环境还是优先级变化？
• 哪些任务停留时间明显偏长？是否因为任务规模或验收方式不合理？
• 紧急插入了多少工作？对原有计划造成了什么影响？
• 团队约定的并行边界是否过紧、过松，或被看板之外的工作绕过？
• 哪些状态和字段真正帮助了决策，哪些只是增加维护成本？

复盘的结果最好落实为一个小调整，例如补充一条准入条件、明确一个审批时限，或删掉一个没有实际用途的状态。一次改动便于观察效果，也能降低团队对流程变化的抵触。

3. 先试行两周，再决定是否扩大规则

如果团队目前没有明确的进行中规则，我建议先从一项最常见的问题开始：要求每张进行中任务卡都有负责人、下一步动作和检查时间。连续观察两周，记录长期未更新卡片、阻塞原因和任务停留情况，再判断是否需要增加容量上限或细分状态。

两周只是一个便于启动的试行周期，不是适用于所有项目的标准时长。交付周期很短的团队可以按迭代检查；长周期项目则应至少覆盖一个有代表性的工作阶段，避免用少量短期数据过早下结论。

4. 最终判断：看板好不好，取决于能否触发正确动作

一张看板不需要状态很多、颜色丰富或每天都被更新。它真正的价值，是让项目负责人更早看见工作拥塞，让任务负责人知道下一步，让协作方明白自己何时需要提供输入，让管理者能基于事实调整优先级。

进行中不是一面展示忙碌的墙，而是团队正在承担的工作承诺。下一步可以先打开当前项目看板，挑出三张停留最久的卡片，逐张确认它们的真实状态、下一步动作和阻塞责任。先把这三张卡处理清楚，再把有效规则推广到整个团队，比一次性重做整套流程更容易落地。