看板进行中全流程：项目经理效率提升与一文讲清

看板上有 18 张卡片都标着“进行中”，项目经理却说不清哪几项本周能交付、哪几项正在等别人、哪一项需要今天协调资源，这不是看板不够漂亮，而是“进行中”没有被定义成可管理的状态。看板进行中全流程的核心，不是让任务不断向右移动，而是让每项工作都有明确的进入条件、责任人、下一步、阻塞信号和完成标准。

一、先讲结论：项目经理要管理流动，而不只是更新状态

1. 看板的价值不在列，而在工作能否持续流动

我判断一块看板是否有效，通常不先看它有几列、颜色是否统一，而是随机点开一张“进行中”的任务卡，问五个问题：谁负责？现在做到哪一步？下一步是什么？有什么依赖或阻塞？满足什么条件才算完成？如果团队成员只能回答“还在做”，看板显示的就只是一个状态标签，并没有提供可用于管理的事实。

项目经理的效率也不应理解为少开几次会或少发几条催办消息。更有价值的变化是：问题更早暴露、责任边界更清楚、资源协调更有依据、优先级调整有记录。看板不能替项目经理作决策，但可以把决策所需的信息放在同一个工作界面里。

2. 一张“进行中”卡片至少要有四类信息

• 责任：当前由谁推进，不能只写一个部门或一组人的名字。
• 进展：已经完成了什么可验证的工作，而不是填写一个缺乏口径的百分比。
• 下一步：接下来要做什么，预计何时发生，是否需要其他人配合。
• 异常：是否存在等待、阻塞、风险或依赖，谁负责推动解除。

这四类信息不一定要拆成四个软件字段，但必须能在任务卡、关联记录或团队约定中找到。项目经理查看看板时，应该能从卡片本身判断是否需要介入，而不是再逐个私聊询问背景。

3. 管理重点是限制未完成工作，而不是鼓励更多任务开工

很多团队把“任务开始得快”误认为“团队效率高”。但同时开启的工作越多，人员切换、上下游等待和优先级冲突越容易被隐藏。我的建议是先观察工作堆积的位置，再讨论是否需要限制并行任务；不要为了套用方法论，先给每个人规定一个看似精确的任务上限。

下面的图表是一个用于讨论的情景模拟，不是行业基准。它说明，当团队把正在处理的任务从 12 项压到 8 项时，等待时间可能随之下降；实际效果仍取决于任务大小、人员配置和外部依赖。

二、真实场景：为什么“都在进行中”反而让人看不见进度

1. 状态名称一样，任务所处阶段可能完全不同

设想一个跨部门项目：产品方案已进入评审，开发任务正在编码，测试任务在等测试环境，采购任务则等供应商报价。四件事都被放进“进行中”，但它们需要的管理动作完全不同。方案评审需要决策人确认，编码需要工程资源，环境等待需要协调基础设施，供应商报价则需要跟进外部时间点。

如果项目经理只看到“进行中”三个字，就会把四种情况都处理成“再催一下”。这往往是低效跟进的起点：真正需要决策的事项被普通进度问题淹没，外部依赖没有被单独暴露，执行者还要重复解释背景。

2. 状态应该描述工作事实，而不是团队的乐观程度

“完成了 80%”“大部分差不多了”“正在收尾”听上去像进展，实际却很难用于判断。任务如果没有可验证的完成条件，百分比通常只是个人估计；而“差不多”也无法回答还剩下什么、由谁处理、是否影响交付日期。

更可靠的状态描述是可观察的事实。例如，“接口开发已合并，待联调”“文案初稿完成，等法务确认”“测试环境申请已提交，平台团队承诺周三反馈”。这样的信息可以帮助项目经理选择动作，也能减少下一次同步时的重复沟通。

3. 示例：一张卡片如何从模糊变得可管理

模糊卡片可能只写着“完成支付改造”，负责人是“研发组”，状态是“进行中”。这种卡片没有明确范围，也没有交付验证方式。一旦项目延期，项目经理很难判断究竟是工作量估算错误、需求变更，还是第三方接口未就绪。

改写后，卡片可以变成：“完成移动端支付失败提示调整；负责人：林某；验收条件：三类失败场景均展示对应提示，并通过测试环境验证；当前进展：交互稿已确认，等待接口错误码；下一步：接口负责人于周三前提供错误码映射；阻塞责任人：接口负责人。”这不是要求每张卡都写成文档，而是让关键信息足够支持协作。

从项目经理角度看，最需要优先识别的不是卡片颜色，而是等待与工作是否被混在一起。只要任务已经没有可执行动作、正等待外部输入，就应明确标记为等待或阻塞，并记录解除条件与跟进责任。

三、常见误区：看板失灵通常不是因为工具不够多

1. 把“进行中”当成大筐，任何已开始的事情都往里放

有些团队只有“待办、进行中、完成”三列。简单流程未必有问题，但当工作中存在评审、测试、等待客户确认等不同阶段时，所有未完成任务都挤在“进行中”，管理信息就会丢失。反过来，列拆得过细也会增加维护成本，成员每天忙着搬卡，却不能更快完成交付。

我的判断标准是：如果某个阶段需要不同的责任人、管理动作或完成条件，它可能值得独立呈现；如果只是为了显示看起来更细，且团队不会据此采取不同动作，就不一定需要单独设列。

2. 把百分比当作进度事实

百分比容易制造精确感，却未必有一致口径。一个人认为“完成 90%”意味着主体工作已结束，另一个人可能把测试、审核和发布也算在剩余的 10% 里。项目经理如果据此汇总多个任务，很可能得到一个准确到小数点、但无法指导决策的整体进度。

更适合日常跟进的方式，是把进展写成已完成的成果、未完成的工作和下一节点。对于确实需要衡量完成度的复杂交付，先定义工作分解和权重，再讨论百分比，否则数字只是主观印象的包装。

3. 任务只设负责人，不设完成标准

有负责人不等于任务可执行。如果任务卡没有边界，负责人可能持续补充范围，验收方也可能在最后阶段追加要求。项目经理应要求团队在开工前写清楚“交付什么”和“怎样算完成”，并记录确实发生的范围变更。

完成标准不必写成复杂验收文档。一个小任务可能只需说明产物、验证方式和必要审批；一个涉及合规、财务或生产系统的任务，则可能需要测试证据、审批记录和回滚方案。标准的复杂度应与任务风险匹配。

4. 只移动卡片，不处理卡住的工作

看板上任务从一列移动到另一列，不代表问题解决了。若团队每天更新状态，却没有人对长期等待的事项做决定，卡片只会更准确地展示积压，并不会自动缩短交付周期。看板的作用是暴露问题，问题仍需要明确的责任人、处理时限和升级路径。

项目经理可以把跟进顺序改为：先看阻塞，再看超期风险，然后看即将到期的交付，最后才看没有异常的常规任务。这样做的目的不是制造紧张感，而是把有限的管理注意力投向可能影响整体交付的事项。

5. 用指标给个人排名，导致真实问题被隐藏

任务数量、完成速度和关闭卡片数都容易受到任务大小、依赖条件和工作类型影响。若直接用于个人比较，团队成员可能把大任务拆成更多小卡、延迟上报风险，或优先做容易关闭的工作。指标应首先服务于流程诊断，而不是脱离上下文地评价个人。

判断一个指标是否值得保留，我会先问三件事：它的定义是否一致？数据由谁、在什么时间点记录？看到异常后，团队会采取什么行动？如果这些问题都没有答案，增加图表只会让信息更复杂。

四、专业判断逻辑：先识别工作类型，再设计状态和管理动作

1. 先画出真实流转过程，不要从模板开始

搭建看板前，先选最近完成的几项工作，按时间顺序回顾它们实际经过的阶段：需求提出后谁判断是否接收，准备完成后谁开工，交付之后谁验收，遇到等待时工作停在哪里。关注真实发生的流程，而不是组织制度文件中理想化的步骤。

回顾时可以记录每个阶段的进入条件、离开条件、主要责任人和常见等待原因。某些步骤只偶尔发生，不一定要成为常驻列；但如果它会显著影响交付，并且经常让任务停留数天，就值得在看板上有明确表达。

2. 状态、标记和字段要各司其职

状态回答“工作处于流程的哪个阶段”；标记回答“这件工作有什么特殊情况”；字段记录责任人、优先级、计划日期等属性。不要把所有信息都变成状态列，否则流程难以阅读；也不要用一个备注字段承载所有信息，否则关键风险会被淹没。

3. 给“进行中”设置进入条件和退出条件

进入条件的作用，是避免没有准备好的任务过早占用执行容量。常见检查项包括：范围已澄清、负责人明确、必要依赖已识别、验收方式可理解。并非每项工作都必须等所有条件完全满足才能开始，但未满足的条件应被显式记录，并说明由谁补齐。

退出条件则决定任务何时离开当前状态。团队可以约定代码完成但尚未验证时进入“待测试”，方案完成但尚未获得业务确认时进入“待评审”，而不是把它们统统标成“已完成”。流程列名可以因团队而异，退出规则比名称更重要。

4. 用停留时间识别异常，不要只盯着截止日期

截止日期能够提示任务是否可能逾期，但对于提前识别问题，任务在某个阶段停留多久同样重要。一个明天才到期的任务，可能已经因依赖卡住一周；一个截止日较远的任务，也可能因为没有下一步安排而一直无人推进。

可以按任务类型设定初步的停滞提醒，例如一般任务连续两个工作日没有更新时由负责人补充状态，外部依赖超过约定反馈时间时由项目经理升级处理。这些天数不是通用标准，应结合团队响应节奏、项目风险和任务粒度调整。

5. 限制在制工作时，先看系统约束再设数字

在制工作限制的目的，是让团队优先完成已经开始的工作，而不是机械限制个人努力程度。初次尝试时，可以观察团队整体同时推进的任务数、任务的平均等待时间，以及哪些工作经常被临时插入。再选择一个容易解释、可以复盘的限制值，运行一段时间后看是否减少排队，而非单看是否“遵守规则”。

如果工作必须等待外部评审，限制内部正在处理的任务并不能消除外部延迟。此时应把“执行中”和“等待外部反馈”区分开，避免等待中的卡片占用同一类执行容量统计，也要保留它对最终交付的影响记录。

五、具体案例与数据观察：把“都在做”改成可预测的流动

1. 情景案例：一个 12 人团队的交付看板

下面是一个情景模拟案例，用来展示管理方法，不代表真实客户数据。假设某 12 人团队同时承担产品调整、接口开发、测试验证和上线准备，原有看板只有“待办、进行中、完成”三列。项目周会上，团队发现 14 项任务里有 9 项处于“进行中”，其中 4 项实际在等外部反馈，2 项的验收条件还没有确定。

团队没有先更换工具，而是把任务重新分类：执行中的工作保留在“进行中”，外部等待增加“等待依赖”标记，等待内部评审的任务进入“待评审”，完成但尚未验证的工作进入“待验收”。同时，每张卡片补上负责人、下一步和必要的交付说明。目标不是增加流程层级，而是让不同情况触发不同动作。

2. 变化观察：看板改善后要看哪些数据

在模拟的四周观察期里，团队每周记录进行中任务数、阻塞任务数、从开工到验收的中位时间，以及状态信息完整率。假设中位时间从 10 个工作日降到 7 个工作日，不能直接得出“看板让效率提升了 30%”的结论：同期可能还发生了任务拆分、资源调整或需求范围变化。

更谨慎的解释是：交付周期的变化值得继续观察，同时要回看哪些任务类型缩短了、等待时长是否下降、返工是否增加。若周期变短却验收退回次数明显上升，团队可能只是更快地移动卡片，而不是更稳定地交付。

下图数据为情景模拟，用于示范如何看前后变化与配套指标，不是实证研究，也不是任何工具的效果承诺。实际复盘时，应保留任务类型和统计口径，避免把工作量不同的周期直接比较。

3. 把数据用于判断，不要让数据替团队下结论

如果阻塞任务占比下降，先检查是不是等待被解决，还是团队停止标记阻塞；如果周期缩短，检查是不是任务被拆得更小，或复杂任务被排除在统计之外；如果状态信息完整率提高，确认信息是否真实、是否能支持协调，而不是为了满足检查而填写。

团队每周不需要追踪几十个指标。起步时选择三个互补视角即可：一个看交付结果，例如交付周期中位数；一个看流程过程，例如各阶段停留时间；一个看质量或稳定性，例如验收退回率。数据口径固定下来后，再根据发现的问题补充指标。

4. 一张卡片的复盘模板

项目经理可以从延期任务中抽取一张卡片，按以下顺序复盘：任务何时进入进行中？进入前的条件是否齐备？第一次出现等待是什么时候？团队何时发现？阻塞由谁处理？是否有范围变化？最终验收是否一次通过？这比单纯问“为什么没有按期完成”更容易找到可以改进的流程节点。

• 卡片事实：记录状态变更时间、负责人、依赖项和验收结果。
• 问题分类：区分估算偏差、决策等待、资源冲突、需求变化和质量返工。
• 改进行动：只确定一至两项下一周期可验证的调整。
• 复查时间：约定在下一次复盘时检查措施是否有效。

六、从搭建到验收：项目经理可以照着执行的全流程

1. 第一步：选一个边界清楚的试点

不要一开始就把整个组织所有项目放进同一套看板。优先选择工作类型相对稳定、团队成员愿意参与、交付频率足够观察的项目。试点的目标不是证明某个工具好不好，而是验证团队能否持续更新状态、暴露依赖并依据看板处理问题。

试点前先写清楚范围：哪些任务进入看板，哪些暂时不纳入；由谁维护项目级规则；谁负责验收；遇到跨团队依赖时如何升级。范围清楚，才能避免试点过程被无关任务和临时需求冲散。

2. 第二步：定义最小工作流

可以从“待处理，进行中，待验收，已完成”开始，但这只是一个可调整的起点。若团队的工作经常因外部条件暂停，可以使用等待标记或单独状态；若交付必须经过安全评审、客户确认或发布检查，也可以增加相应阶段。

每个状态只需先写一条进入规则和一条退出规则。例如，“进行中”的进入规则是负责人确认范围并开始实质工作；退出规则是产物已提交给指定验收人。规则要能让两位不同成员对同一张卡作出相近判断。

3. 第三步：拆分任务并完善卡片

任务不应大到一个月都无法看到中间成果，也不应小到每个操作步骤都变成独立卡片。合适的任务粒度，通常是团队可以在一个可管理的时间窗口里推进，并能在过程中确认交付物或风险的工作单元。

卡片最低限度包含标题、负责人、完成标准和下一步。需要协调时再补充依赖、截止日期、优先级、风险或关联任务。字段是否保留，应看团队是否会据此采取行动，不必为了“信息全面”把卡片变成表单。

4. 第四步：约定更新规则与异常升级路径

团队需要约定谁在什么情况下更新状态。例如，任务进入新阶段时由执行人移动卡片；出现阻塞时及时添加原因、影响和需要的协助；计划日期变化时记录原因，而不是只改日期。更新规则越简单，持续执行的可能性越高。

异常升级也要具体。轻微等待可以由任务负责人跟进；跨团队依赖超过约定反馈时间，由项目经理协调；涉及范围、预算、合规或交付目标的变更，则按项目治理规则提交决策。所有问题都升级给项目经理，会让项目经理成为新的瓶颈。

5. 第五步：按异常优先级检查看板

日常检查不必逐张朗读卡片。可以先看阻塞和超期风险，再看长时间没有更新的任务，随后确认即将进入下一阶段的工作是否有容量。常规任务只要信息完整、没有异常，就不需要每天重复汇报同一件事。

同步会议的重点应是作出决定和解决依赖，而非把看板内容从头念一遍。可以要求成员会前更新卡片，会上只讨论需要协作的事项；如果所有卡片都要在会议中重新解释，通常说明异步信息维护或任务描述仍有问题。

6. 第六步：每个周期做一次小复盘

复盘不一定要等待项目结束。团队可以定期查看任务在哪个阶段积压、等待原因是否重复、哪些卡片长期没有下一步、验收退回是否集中在某类工作。一次复盘只改一两个最值得处理的规则，观察效果后再继续调整。

如果流程列不断增加，成员却仍然不知道该把任务放在哪里，说明列的定义可能不够清楚；如果每次复盘都发现相同的外部等待，却没有决策人和升级时限，问题不在看板设计，而在治理机制。复盘要把“卡片如何移动”和“谁能解决卡住它的问题”一起检查。

七、不同团队的行动建议与取舍：一套流程不能硬套所有项目

1. 小团队：优先减少规则负担

人数较少、成员沟通直接的团队，可以先用少量状态和简单标记。重点是确保每张进行中任务都有负责人、下一步和完成标准。没有必要为了显得规范，先建立复杂的角色审批和多层级报表。

小团队也要避免所有协作依赖口头同步。成员都在同一个办公室，不代表信息不会遗漏；当负责人请假、任务跨周或需要向其他团队交接时，卡片上的事实记录仍然重要。

2. 跨部门项目：优先呈现依赖和决策责任

跨部门项目中，任务可能卡在对方团队的排期、审批或交付物上。看板需要能标明依赖对象、所需输入、期望时间和升级路径。只记录“等待某部门”仍不够，最好说明“等什么、谁跟进、何时复查”。

这类项目的项目经理要避免把所有等待都归因于执行效率。某些卡点需要业务负责人调整优先级，有些需要管理层作资源决策。看板应帮助识别决策层级，而不是把治理问题转化为对一线成员的重复催促。

3. 远程或异步团队：优先制定更新时间规则

远程团队无法依赖随时口头询问，更新规则要更加明确。团队可以约定任务发生关键变化时立即更新，并在固定时间检查长期未更新卡片。这里的重点不是要求所有人每小时报一次进度，而是确保关键变化不必等到下一场会议才被发现。

异步协作还需要约定讨论记录放在哪里、最终决定如何标记、谁负责把讨论结果写回任务卡。如果信息散落在邮件、聊天和文档中，卡片上应保留结论和入口，而不是只写“见聊天记录”。

4. 高风险或强合规项目：以可追溯性换取一定速度

涉及生产环境、财务处理、隐私数据或合规审批的工作，可能需要更明确的审核、验证和授权阶段。额外步骤会增加流程时间，但如果遗漏审核会造成较大风险，这种成本可能是必要的。项目经理应明确哪些检查是强制门槛，哪些可以根据风险等级简化。

不应把所有任务都按最高风险流程处理。可以区分低风险的常规变更和高风险的关键变更，为不同类型定义不同的验收条件。否则，团队会习惯性绕开流程，导致看板上显示的状态与真实审批过程脱节。

5. 变化频繁的项目：保留调整空间，不要把计划当承诺

探索性工作、产品验证或需求快速变化的项目，早期任务范围可能会调整。此时看板更适合呈现当前假设、验证动作和阶段性结论，而不是用过度精确的日期制造确定性。重要的是记录调整原因，以及调整对范围、资源和交付目标的影响。

如果任务频繁被插入，可以设一个明确的临时需求入口和优先级决策人。没有入口规则时，团队会在看板外接收工作，旧任务仍显示“进行中”，新任务却不断挤占容量，最终看板无法解释团队实际在做什么。

八、工具与落地取舍：先定管理规则，再决定是否迁移平台

1. 什么时候继续用现有工具，什么时候考虑专用平台

如果团队人数不多、流程简单、跨团队依赖较少，现有表格或轻量工具可能已经足够。此时投入迁移、培训和权限治理，未必能换来相称收益。先把状态定义、卡片信息和更新责任跑顺，比立刻购买更多功能更重要。

当项目数量增加、多个团队共享工作流、权限隔离和审计要求变强，或者需要把需求、研发、测试和交付信息关联起来时，工具能力才可能成为明显约束。评估时应关注：能否支持团队自定义流程、能否追踪状态变化、权限是否适合组织结构、跨项目视图是否可用、数据导出和集成是否满足要求。

2. 中大型组织评估平台时，要把迁移风险算进总成本

对 100 人以上或跨部门协作较多的组织，评估项目管理平台不应只比较界面和功能清单，还要计算迁移数据、重建权限、培训成员、维护流程和处理历史记录的成本。一个功能丰富的平台，如果让团队无法保持数据一致，实际价值可能低于一套简单但被持续使用的流程。

如果组织正在比较 PingCode 一类面向中大型企业和百人以上组织的项目管理平台，可以把私有化部署能力、从既有研发管理环境迁移的支持程度，以及权限、审计和集成需求纳入验证清单。是否适合当前组织，仍应通过真实工作流试跑、数据迁移演练和安全评估判断；“支持迁移”不等于迁移零成本，“支持私有化部署”也不自动等于完全满足本组织的安全要求。

工具选型时，我不会把“国产替代”当成唯一决策理由，也不会把任何平台预设为适合所有团队。更可靠的做法是选一条真实流程，拿真实任务和权限配置做验证，检查状态迁移、通知、报表、导出、接口和异常处理是否符合实际，再决定是否扩大使用范围。

3. 迁移前先做工作流映射，不要只搬卡片标题

如果从旧系统迁移，先盘点状态、字段、权限、自动化规则、历史附件和关联关系。旧系统里同名状态未必代表同一工作阶段；直接照搬可能把过去的混乱一并迁入新平台。迁移前应确认哪些数据继续保留、哪些字段需要清理、哪些状态需要合并。

建议先选一个项目做试迁移，并由实际使用者验证几类典型任务：普通任务、阻塞任务、跨团队依赖、待验收任务和已关闭历史任务。确认记录能找到、权限正确、关键关联未丢失，再安排分批推广。这样比一次性全组织切换更容易控制风险。

4. 采用“最小规则、逐步加深”的推广方式

平台上线首周只要求团队稳定维护最关键的几项：状态、负责人、下一步和阻塞信息。等团队形成习惯后，再考虑增加自动化提醒、跨项目汇总或周期报表。功能可以逐步启用，管理规则也应根据团队反馈持续修订。

如果成员觉得更新看板是在做额外填表，先检查重复录入：是否已经在别处记录同一信息，是否可以通过集成减少重复操作，是否字段根本没有被管理动作使用。治理规则的目标是降低协作成本，不是增加看板维护本身的工作量。

九、最后总结：让每张进行中任务都能导向一个动作

1. 项目经理今天就可以做的五件事

1. 随机检查五张“进行中”任务，确认是否都有负责人、下一步和完成标准。
2. 把正在执行和等待外部输入的工作区分开，记录等待原因与跟进责任人。
3. 找出停留时间最长的三张卡片，判断它们卡在决策、依赖、范围还是资源。
4. 约定一条简单的进入规则和退出规则，并先在一个团队试行。
5. 每周复盘一个流程信号和一个交付结果，避免只看卡片数量或个人速度。

2. 最重要的管理取舍

看板越详细，不一定越有效；状态越少，也不一定越清楚。项目经理要在可见性和维护成本之间取平衡：只有当一个新状态、字段或指标能够改变团队的判断或行动时，它才值得留下。

我认为看板管理最值得追求的结果，不是所有卡片都按时移动，而是团队能更早看见工作为何停住，并且知道由谁、在什么时间、通过什么方式推动下一步。能做到这一点，“进行中”才不再是项目里的黑箱，而成为可观察、可讨论、可持续改进的工作过程。

3. 下一步从一次小检查开始

不必等到组织完成工具选型或流程改造后再行动。今天就选一个正在推进的项目，花 20 分钟检查当前“进行中”任务：有多少项没有下一步，有多少项实际在等待，有多少项没有验收标准。先把这三类信息补齐，再观察一周，团队通常就能更具体地讨论看板该怎么改。

当每张卡片都能回答“谁负责、下一步是什么、什么条件下算完成”，项目经理才真正从追问状态转向管理流动；效率提升也不再是标题里的承诺，而是团队能够持续观察和验证的结果。