进行中管理指南：实施团队如何做好看板，实操方法全流程

实施团队的看板上，最危险的不是任务太少，而是“进行中”里塞满了任务：有人在配置，有人在等客户资料，有人等内部审批，还有些卡片只是几天没更新。它们看起来都在推进，实际却处于完全不同的状态。做好进行中管理，关键不是把卡片挪得更勤，而是让团队看清工作是否真的在流动、哪里在等待、谁要采取下一步行动。

一、先讲结论：管理进行中，重点是让工作流动起来

1. 看板不是状态墙，而是协作决策工具

我判断一张看板是否有效，通常不先看列名是否齐全，而是看团队能否从卡片上回答四个问题：这项工作现在处于什么状态？它为什么停在这里？谁负责推动下一步？如果继续停滞，什么时候需要协调或升级？

如果团队只能回答“卡片在进行中”，却说不清后面三个问题，看板就只记录了状态，没有支持管理。进行中管理的目标也不是让所有任务不断向右移动，而是尽早暴露任务堆积、依赖等待和资源冲突，让团队把注意力放到最需要推动的工作上。

2. 优先管理流动，再讨论个人忙碌程度

在实施项目里，顾问一天接十几条消息、同时处理多个客户，不等于交付速度快。多项工作并行可能只是把未完成任务分散到不同人和不同群聊里。看板的价值，是让团队看到当前的在制品数量、任务停留时间和阻塞来源，而不是用卡片数量给个人贴上“忙”或“不忙”的标签。

《看板指南》（The Kanban Guide，2020）将明确工作流、主动管理工作项、持续改进工作流列为看板方法的核心实践，并提出在制品数量、吞吐量、工作项年龄和周期时间等流动指标。这些指标用于观察系统，不等同于个人绩效排名。下文的项目数字均为情景模拟，用于展示计算与判断方式，不是行业基准或真实客户数据。

3. 先设规则，再选工具

团队开始管进行中之前，应先约定什么工作能进入、什么情况算等待、何时算完成，以及阻塞多久需要升级。工具只能呈现和支持这些规则，不能替团队决定客户验收标准，也不能自动消除跨部门依赖。

二、背景与真实场景：实施项目的“进行中”为什么特别容易失真

1. 交付任务同时受内部工作和外部条件影响

实施工作通常不是一条只由实施顾问控制的直线。需求确认后，可能要等客户提供基础数据；配置完成后，可能要等测试环境；内部方案评审之后，还可能等待安全、财务或业务部门审批。任务本身有负责人，不代表任务推进完全由负责人决定。

这也是“进行中”最容易被滥用的原因：为了让项目看起来在动，团队把所有已启动但未关闭的工作都放进同一列。结果，真正正在处理的任务和实际上无人能继续的任务混在一起，管理者无法判断瓶颈来自人手、流程、客户响应还是交付标准不清。

2. 一个典型情境：卡片没动，不一定是负责人没做事

假设一项系统初始化任务已经分配给顾问。顾问完成了内部配置，但客户尚未提供组织架构表，后续导入无法开始。如果卡片仍显示“实施中”，项目经理看到的只是任务停留；如果卡片显示“等待客户资料”，并记录资料清单、客户联系人、跟进人和下次复查日期，团队才知道应该采取什么行动。

这里的管理重点不是给等待任务换个颜色，而是把等待的对象、责任和时间说清楚。没有这些字段，“等待中”也可能变成新的任务仓库。

3. 管理者要区分任务停留与团队闲置

一张卡片停留时间较长，可能是任务复杂、验收周期长，也可能是依赖没有到位；不能仅凭天数就判断负责人效率低。团队应把任务年龄与工作类型、进入时间、当前状态及依赖情况一起看，先找出流程原因，再决定是协调资源、拆分任务，还是调整承诺时间。

三、常见误区：卡片越多、更新越勤，不等于管理越好

1. 误区一：把所有未完成工作都放在“进行中”

如果一张卡片既可能代表正在配置，也可能代表等客户、等审批或等测试，列名就没有管理意义。建议至少区分主动处理和等待状态。团队不一定要为每种等待都建一列；也可以用清晰的等待标记，但必须能查询等待原因和持续时间。

2. 误区二：把 WIP 上限当成固定公式

在制品限制（WIP limit）不是“每个人最多几张卡”的通用标准，也不是设置后就不能改。任务粒度、人员技能、交付环节和并行依赖不同，适合的限制自然不同。团队可以从最常堆积的环节开始试行，根据任务年龄、吞吐量和阻塞情况调整，而不是照抄别人的数字。

还要区分个人工作量和流程在制品。一个顾问负责三张小任务，不一定比负责一张复杂任务更忙；团队的 WIP 限制主要用于控制流程里同时启动却尚未完成的工作，不能脱离任务大小和工作类型机械应用。

3. 误区三：每天逐张读卡片，却不解决卡片上的问题

看板检查如果变成每个人依次汇报“昨天做了什么、今天做什么”，团队容易把注意力放在个人陈述上。更有效的顺序通常是先看临近承诺日期的任务，再看停留时间较长、阻塞或超过 WIP 限制的任务，最后确认协作人和下一步动作。

每次检查结束时，应该留下可执行的结果，例如“今天由项目经理联系客户确认数据负责人，明天下午复查”。“继续跟进”不是足够具体的行动，因为它没有说明由谁、在什么时候、针对什么对象采取什么动作。

4. 误区四：用完成数量给个人排名

完成任务数量会受到任务复杂度、工作拆分方式和客户响应速度影响。团队若为了多完成几张卡而把大任务切成很多无意义的小卡，吞吐量看起来上升，交付结果未必更好。周期时间、完成量和在制品应该结合解释，先用于识别流程问题，不应直接变成个人排行榜。

四、专业判断逻辑：从工作流设计到任务卡规则

1. 从真实交付路径反推看板列

设计看板时，我会先让团队复盘最近完成的几项交付：工作从哪里进入？中间经过哪些必须发生的步骤？在哪些交接点最常等待？什么条件满足后可以交付？先还原真实流程，再决定列名，而不是先复制一个通用模板。

一个实施团队可以从“待确认、已准备、实施中、客户验证、待验收、已完成”开始，但这只是示例。若“客户验证”包含实施人员协助测试，团队要明确这列究竟表示客户正在验证，还是实施人员正在准备验证环境。列名应让团队对状态形成一致理解。

2. 给关键状态设定进入与离开条件

状态定义不需要写成长篇制度。每列只需说明进入条件、离开条件和必要责任。例如，“实施中”的进入条件可以是范围已确认、负责人已接手、关键输入可用；离开条件可以是配置完成并达到内部检查标准。若资料不齐却必须先做部分准备，应把可做部分拆出来，避免整张卡片被错误地标成全面启动。

3. 任务卡只保留能推动决策的信息

一张可执行的任务卡，至少要能看出交付物、负责人、当前状态、下一步动作和完成标准。存在外部依赖时，再补充依赖方、阻塞原因、等待开始时间与复查日期。客户名称、项目编号等信息是否放在卡片上，应根据团队的检索和权限要求决定。

字段多不一定更专业。每增加一个字段，都要回答它是否帮助协作、追踪或决策。如果团队从不使用某个字段，就不要为了表单完整而强制填写；反过来，如果大家反复在聊天记录里寻找“谁在等谁”，就值得把依赖信息加到卡片中。

4. WIP 限制要从堆积点试起

先统计各列的任务数量和停留情况，找出经常积压的环节，再设一个试行上限。比如某团队的客户验证列连续几周都积压，团队可以暂时限制新任务进入该环节，同时集中处理反馈、补齐验收条件或协调客户资源。限制的目的不是让任务进不来，而是让团队优先把已经开始的工作推进到完成。

如果限制设得过低，且团队成员有可用能力、工作也不存在依赖，可能造成无谓等待；如果设得过高，则限制失去作用。团队可以每周检查一次：超过上限时是否停止启动新任务、成员是否主动协助清理旧任务、任务是否因限制而出现不合理排队，再据此调整。

五、具体案例与数据观察：一项实施任务怎样从停滞变得可管理

1. 情景模拟：客户资料缺失导致初始化任务停留

假设某实施团队有12名成员，同时跟进多个客户项目。一项组织初始化任务需要客户提供组织架构表、角色清单和测试账号。此前任务卡长期显示“实施中”，顾问每隔几天在群里询问一次，项目经理却无法从看板上判断资料是否已收齐，也不知道下一次跟进是什么时候。

团队重新梳理后，把任务拆成“资料核对”和“系统初始化”两个可交付工作项：资料核对进入等待客户状态，卡片记录缺失字段、客户联系人、内部跟进人及复查日期；系统初始化只有在必要资料齐备后才进入实施中。这样做不是为了多建卡，而是让两个工作项拥有不同的责任、条件和下一步。

2. 用四周观察而不是印象判断改动效果

为避免把单个项目的波动误当成流程改善，团队可以选定相近任务类型，记录改动前后的一段时间。下面的数字为情景模拟：假设统计口径为同一类初始化任务，从负责人开始实际处理到完成验收计算周期时间；等待时长单独记录。真实团队应先统一起止点、任务范围和例外规则，再做前后比较。

这组模拟数据要表达的不是“照做就能缩短四天”，而是如何避免单指标误读。等待原因记录率提高，首先说明看板更能呈现问题；只有当等待时长、返工率或周期时间也出现可解释的变化，团队才有理由讨论流程改善。若完成量上升但验收返工增加，不能简单宣布改进成功。

3. 关注任务年龄，找出“老卡片”为什么老

团队可以在例会中查看工作项年龄，即任务从进入当前流程或开始处理到现在经过的时间。发现年龄较长的卡片后，不要先问“为什么还没做完”，而要查它属于复杂任务、等待依赖、范围变更、人员交接还是验收迟迟未确认。相同的停留时长，可能需要完全不同的处理动作。

例如，复杂任务可能需要拆分可独立验收的交付物；客户待确认可能需要项目经理联系决策人；内部审批延迟可能需要明确响应时限或调整审批路径。看板让异常可见，真正的改善发生在团队为异常选择了合适的动作之后。

六、不同情况下的行动建议：让异常状态对应下一步

1. 任务已开始，但输入资料不齐

先判断是否有独立的准备工作可以继续。如果有，拆出可交付的准备项；如果没有，就把主任务转为等待状态，记录缺失资料、提供方、跟进人和复查时间。不要为了“看起来在推进”而让整张卡片继续占据主动处理列。

2. 某一列持续超过 WIP 上限

先停止向该环节新增工作，再由团队检查现有任务：哪些能在短时间内完成？哪些卡在同一个依赖方？哪些可以由其他成员协助？如果超限源于工作量突然增加，可以重新协商交付顺序或资源；若长期反复超限，则应检查前一环节的放行规则是否过松，或该环节是否存在结构性瓶颈。

3. 卡片停留较久，但原因不明

由负责人和协作方一起补齐当前状态、最近一次有效推进时间、待办动作及依赖。若任务内容过大，拆分出可独立验收的部分；若卡片描述含糊，先澄清完成标准。单纯要求负责人频繁更新日期，只会让数据更勤快，不会让工作更清楚。

4. 客户反馈或验收迟迟未回

先确认客户收到的交付物、反馈方式、验收范围和回复期限是否明确，再约定由谁联系、何时复查。若客户确实暂时无法参与，可将工作项显示为等待客户，并评估项目计划是否需要调整。不要把客户未响应造成的等待直接记成实施人员的执行周期。

5. 多项目都在争抢同一位专家

看板应把专家参与作为资源依赖显式呈现，而不是让每个项目都把任务标为“进行中”后再私下排队。团队可以约定专家支持的入口、优先级和每周可用容量，并按交付风险和承诺日期排序。若任务无法并行，就明确排队规则，避免多个项目经理各自承诺同一资源。

七、不同情况下的取舍：限制并行、拆分任务和增加字段各有边界

1. 什么时候应该减少并行工作

如果多个任务反复在人员、环境或审批环节排队，优先减少启动数量通常比继续加开任务更有价值。减少并行会让部分新工作晚一点开始，但有机会让已经投入的工作更快完成。适合这种做法的信号包括：团队切换频繁、旧任务积压、关键资源被多项目争用、已启动任务的等待时间不断增长。

如果任务之间相互独立、等待时间很短，而且团队能够保持稳定交付，过度压低在制品可能造成资源空闲。此时应先验证瓶颈是否真实存在，不要把“WIP 越低越好”当作目标。目标是让工作在可承受的并行度下稳定流动。

2. 什么时候应该拆分任务

当一张卡片包含多个可分别交付、可分别验收的结果，或其中一部分可以先解除客户风险时，拆分通常有帮助。比如先完成数据模板核对，再开展系统初始化。但如果拆分出来的子任务彼此高度依赖、没有独立价值，只会增加维护成本和汇报负担。

3. 什么时候增加状态或字段

当团队反复遇到一种有明确处理方式的等待，且现有状态无法支持排序、提醒或复盘时，可以考虑新增状态或字段。新增前先问：这个信息是否影响决策？由谁维护？什么时候更新？如果没有明确答案，先通过标签或卡片备注试行，不必立刻改造整套流程。

4. 什么时候需要项目管理平台支持

小团队可以先用共享表格或轻量看板验证流程；当多个项目、跨职能团队、权限隔离、审计要求和组织级报表同时出现时，才需要评估平台化管理。评估时应把工作流配置、权限模型、迁移成本、数据导出、私有化部署要求和长期维护能力放在一起比较，而不只是看界面和功能清单。

对于100人以上、需要在多个团队间统一工作流的组织，可以把 PingCode 纳入候选评估。若采购条件包含私有化部署或从 Jira 平滑迁移，应逐项核验实际部署方案、字段和历史数据映射、权限兼容、自动化规则、附件迁移、验收责任与切换计划。支持某项能力不等于迁移零风险，也不意味着对所有组织都是唯一选择。最稳妥的做法是选一个代表性项目做迁移验证，再决定扩展范围。

5. 指标用于改善系统，不用于制造新的内耗

周期时间变长时，团队先检查任务类型和等待原因；吞吐量变低时，检查工作是否集中卡在某一列；在制品过多时，检查是否持续开新工而不完成旧工。只有把指标放回具体工作流中，数据才会变成改善线索。若直接用个人完成量排名，团队可能通过拆小任务、隐藏等待或挑选简单工作来优化数字，却损害真实交付。

八、落地全流程：从试点到复盘，逐步建立可持续的看板规则

1. 选一个工作流作为试点

不要一开始就要求所有项目、所有部门同时换流程。选一个任务类型相对稳定、参与角色清楚、团队愿意复盘的工作流，例如标准化的客户初始化或版本升级支持。记录当前工作状态、主要等待点和在制品数量，作为试点前的观察基线。

2. 共同定义状态与完成标准

让实际执行、项目管理和交付验收相关人员一起定义列名、进入条件、离开条件和等待规则。把定义写在团队看得到的地方，试运行时遇到模糊情况就补充例子。规则应尽量短，但必须能处理最常见的争议。

3. 用最小字段启动任务卡

开始时保留任务名称、交付物、负责人、状态、下一步动作和完成标准。发生外部等待时，再填写依赖方、等待原因和复查日期。先运行一段时间，再根据团队真正使用的信息决定要不要增加字段。

4. 约定看板检查节奏与阻塞升级

团队可以每天短暂检查阻塞和老任务，也可以每周做一次较完整的流动复盘。频率应与任务变化速度匹配，不必为了形式每天开长会。团队还要约定阻塞多久需要升级、由谁协调，以及跨团队问题如何记录决策结果。

5. 经过观察期后再调整 WIP 与流程

试点一段时间后，至少一起看在制品数量、周期时间、工作项年龄、吞吐量和阻塞原因。不要只看改动前后一个数字；如果任务类型、客户响应速度或人员配置发生变化，也要记录为背景条件。随后删除无人使用的状态和字段，修正无法执行的规则，保留真正帮助团队协作的部分。

实施团队的看板不需要一开始就很复杂，但必须能让任务状态对应真实工作，让等待有责任人，让阻塞触发行动。建议下一步先抽取最近十张已完成或仍在进行中的任务卡，检查它们是否写清当前状态、停留原因、下一步动作和完成标准；再挑出最常堆积的一列试行一条 WIP 规则，并在复盘时用数据决定保留、调整还是撤销。

看板管理的核心不是让每个人都显得很忙，而是减少团队对“工作到底卡在哪里”的猜测。当一张进行中卡片能清楚说明它为何存在、由谁推动、何时复查，以及怎样才算完成，看板才从状态展示页变成了交付管理的一部分。