进行中管理指南：企业管理者如何做好看板，落地方案全流程

进行中管理最容易被误解成“把任务放到看板上”。但我在梳理企业团队的交付流程时反复看到：卡片颜色很整齐，不代表工作真的在流动；每天更新状态，也不代表管理者知道项目为什么停住。看板要解决的不是“任务有没有被展示”，而是从需求进入到交付完成，哪些工作正在消耗团队产能、在哪里等待、谁有权推动，以及管理者何时应该介入。本文给出一套从诊断、设计、试点到复盘的落地方法，并用明确标注的情景模拟数据说明如何验证效果。

一、核心结论：看板管理的目标是改善流动，而不是美化状态

1. 先定义“进行中”到底意味着什么

在许多团队里，“进行中”只是一个模糊状态：有人刚刚开始，有人等设计，有人等客户确认，还有人实际上已经做完、只差验收。这些工作被放进同一列，管理者看到的是一团绿色的“忙碌”，却看不到真正的阻塞。

我建议先把“进行中”定义为：工作已经满足进入执行的条件，并且有人正在为它投入可识别的时间或资源。如果任务只是排队等待外部输入、审批或环境，就不应继续伪装成正在执行；它应被标记为等待或阻塞，并注明等待对象、责任人和下一次跟进时间。

这个定义看似只是调整列名，实质上改变了团队对产能的理解。正在做的工作、排队等待的工作和被卡住的工作必须可区分，否则管理者会把“人很忙”误判成“流程很快”。

2. 管理者要盯流动信号，不要只盯完成数量

周报里“本周完成了多少项”是结果信息，却解释不了交付是否健康。一个团队可能完成了不少小任务，同时让几个高价值需求等待数周。更可靠的观察方式，是同时看工作在制数量、周期时间、阻塞时间、退回比例与承诺完成率。

看板不是绩效排名墙。如果团队担心卡片暴露问题，就会把任务拆得过细、提前标记完成，或者把等待隐藏在“进行中”里。管理者的首要责任不是追问谁拖延，而是确认系统是否让工作能持续向前。

以下图表是用于说明诊断思路的情景模拟，不代表行业平均水平。它展示了为什么只看完成量容易得出错误结论：完成数量相近时，周期时间和阻塞占比仍可能差异明显。

3. 先让管理动作改变，再考虑工具是否升级

看板工具可以帮助团队共享状态、记录变更、设置提醒与汇总数据，但它不会自动消除优先级冲突，也不会替管理者决定谁能打断当前工作。若职责、准入规则和阻塞升级机制没有建立，换工具通常只会把原来的混乱搬到新的界面。

因此，我通常建议管理者按这个顺序推进：先选一个有代表性的工作流，明确工作从哪里来、什么条件下进入执行、怎样算完成；再建立可执行的在制限制和阻塞处理规则；最后才确定需要哪些工具能力和报表。

二、背景与真实场景：看板为什么在“人很忙”的团队里失效

1. 典型场景是多个入口争夺同一批人

以一个产品与研发协作团队为例：产品需求从季度规划进入，客户问题通过支持渠道进入，合规事项由专项负责人提出，线上故障则直接打断开发。每类工作都有合理性，却都争用同一组设计、研发、测试和运维资源。

如果看板只展示“待办、进行中、已完成”，管理者只能看到任务总量，无法判断插单从哪个入口进入、谁批准了优先级变更，也无法知道一项工作在测试阶段等待了几天。团队于是不断切换上下文，管理者则通过会议追问进度，忙碌程度上升，交付预测却没有变准。

2. 看板暴露的是系统约束，不是某个人的态度

当某一列持续积压，第一反应不应是要求该环节“再努力一点”。积压可能来自上游一次释放太多工作，也可能是下游能力不足、验收口径反复改变，或关键角色只有一个人能处理。列内任务多是症状，系统约束才是原因。

我会先问三个问题：积压是否长期集中在同一列？任务进入该列后是否有明确的负责人和下一步动作？等待期间是否能观察到外部依赖或决策缺口？如果答案模糊，就先补充状态定义与阻塞信息，而不是立即追加人手。

3. 远程协作与跨部门依赖会放大信息延迟

当团队成员分布在不同地点、部门和管理链条中，口头同步很难完整沉淀。某项工作可能已经完成开发，却因安全评审、数据权限或客户确认停滞。若看板上没有明确的等待状态和责任归属，团队成员会重复询问，管理者也可能直到里程碑临近才发现风险。

因此，看板的信息颗粒度应服务协作，而非追求记录越多越好。对于每项工作，至少要能回答：当前负责人是谁、下一步是什么、何时可以判断是否逾期、遇到什么条件需要升级。对管理者来说，这几项信息通常比一大段状态说明更有用。

三、常见误区：列越多、卡片越细，不等于管理越精细

1. 把“进行中”做成一个超大容器

如果从需求分析到开发、测试、验收都堆在一个“进行中”列，管理者看不出工作走到哪一步。相反，若把每个动作都单独设列，团队又要花大量时间维护状态，稍有变化就需要调整卡片。

我建议以管理决策所需的信息划分流程，而不是按组织架构或个人习惯无限拆列。列的边界应能回答一个实际问题，例如“等待评审的工作有多少”“测试环节是否成为瓶颈”。如果某个状态既没有不同的责任机制，也不会触发不同的管理动作，它未必值得单独成为一列。

2. 把所有任务都塞进同一条泳道

功能需求、缺陷、紧急事件、合规任务的风险与处理路径不同。把它们混在一起，紧急工作可能挤掉长期重要事项；如果每种情况都设一条泳道，又会让看板复杂到无人维护。

分类应围绕真实的优先级策略。比如团队确实有紧急通道，就要限定适用条件、授权角色和并发上限；如果所谓“紧急”只是业务方更想先做，就不应使用特殊通道。一条不受约束的紧急泳道，本质上是一个绕开排队规则的入口。

3. 用个人任务数量推断个人效率

某人名下有八张卡片，不一定比只有三张卡片的人更低效。卡片规模可能不同，任务也可能处于等待外部反馈的阶段。单纯按个人任务数量评价，会鼓励成员把卡片拆小、把等待移出统计，最终损害数据可信度。

更稳妥的做法是用看板讨论系统状况：谁拥有下一步动作、哪些任务超过约定等待时间、什么依赖需要管理者协调。个人绩效需要结合职责、质量和具体贡献综合判断，不应由看板上的卡片数直接代替。

4. 只看平均周期，忽略长尾工作

平均数容易被少数超长任务拉动，也会掩盖大多数任务的实际体验。若多数任务在一周内完成，但少数跨部门事项等待一个月，平均周期会显著变长，却无法直接告诉团队风险集中在哪里。

建议同时观察中位数、分位数和长时间未完成的工作。中位数反映典型体验，较高分位数可揭示长尾风险，而在制任务年龄则能提醒团队哪些卡片正在变成“看板遗产”。不同指标需共同解释，不宜把一个数字变成新的考核口号。

四、专业判断逻辑：从工作流边界设计到管理规则

1. 先界定流程起点和终点

看板的第一项设计工作不是命名列，而是明确它管理的工作范围。起点可以是需求获准进入团队排队，终点可以是成果通过验收并可交付。若起点设得太晚，需求评估和等待时间会消失；若终点设得过早，测试、发布或客户确认的延迟就无法呈现。

我建议选择一个对业务有意义、团队能够控制或至少能够观测的终点。对软件交付而言，开发完成不一定等于交付完成；如果客户真正感受到价值的时点是上线或验收，管理者就需要让后续环节在流程中可见。

2. 用“进入条件”和“完成条件”消除状态争议

每个关键列都应写清楚什么情况下可以进入、什么情况下算离开。例如“待测试”不能只是开发者把卡片拖过去；它还应满足测试环境可用、构建版本可识别、验收条件已记录等基本要求。

这些条件不必一开始写成冗长制度。先找出最常发生争议的两三个状态，把条件写在团队看得见的地方；试运行后再根据退回原因修正。规则的价值不在文字完整，而在不同成员面对同一情况时能做出大体一致的判断。

3. 用在制限制迫使团队完成，而不是继续开工

在制限制（WIP limit）用于约束某个阶段同时处理的工作量。它不是为了让团队少做事，而是避免所有任务都开了头、却没有足够注意力把它们完成。对于瓶颈列，限制能提示团队优先协助清理已在队列中的工作，而不是把更多任务继续推入瓶颈。

起步时可以根据团队人数、任务复杂度与历史在制情况设一个试行上限，再通过两到四周的观察调整。限制过高，团队感受不到变化；限制过低，则可能让关键资源无事可做或让例外处理失控。规则应允许有记录的例外，但不能让例外成为常态。

4. 把阻塞变成可管理的事件

“阻塞”不应只是卡片上的红色图标。团队需要为阻塞记录原因类别、等待对象、提出时间、跟进责任人和下一次检查时间。原因类别可以从依赖、决策、环境、资料、人员、范围变更等常见来源开始，后续再按实际问题调整。

管理者要设定升级规则，例如阻塞超过约定时限仍无明确下一步，或影响关键承诺时，必须由负责人拉通相关部门。这样的规则让管理介入基于信号，而不是每天逐张追问所有任务。

5. 让指标与管理动作一一对应

指标如果不能触发行动，就只是装饰。周期时间变长时，要检查流程环节和等待；在制量超限时，要暂停继续拉入新工作并协助清理；退回比例上升时，要检查准入条件和验收口径；承诺完成率下降时，要复盘工作量、插单和估算偏差。

五、落地全流程：用小范围试点建立可复制的管理节奏

1. 第一步：选对试点，不要从全公司铺开

试点应当选择工作量稳定、交付链路可观察、管理者愿意参与且跨角色协作真实存在的团队。不要只挑流程最顺、最容易展示成果的团队；也不要一开始就挑危机最大、职责最混乱的部门，否则难以判断是看板设计问题，还是组织问题。

试点范围最好围绕一个完整工作流，而不是只覆盖某个职能小组。例如从需求确认到上线的一条产品交付链路，能让团队看到跨阶段等待；若只能覆盖开发环节，就要明确哪些上游和下游信息仍在范围之外。

2. 第二步：做基线记录，避免上线后凭感觉评价

在正式调整前，至少选取一个有代表性的观察窗口，记录任务规模、完成周期、在制量、阻塞情况、插单数量和返工原因。数据不完美并不可怕，关键是统计口径稳定，并清楚标明哪些数据来自系统记录、哪些来自人工回顾。

若历史数据缺失，可以先进行短期手工抽样，抽取不同类型的工作观察开始、等待、完成时间。不要把零散样本包装成普遍结论；将它们视为试点基线，用来发现流程中值得验证的假设。

3. 第三步：共同画出当前流程，再设计目标流程

让实际参与工作的成员一起把工作路径画出来，从需求进入开始，逐步标出评估、排队、执行、检查、验收和交付。重点记录真实发生的等待与返工，而不是管理制度中理想的流程。很多团队第一次梳理时会发现，正式流程图里根本没有“等业务补资料”或“等权限开通”这一段。

目标流程不应一味追求最短，而要能容纳必要的质量控制、风险审查和职责边界。每增加一个环节，就要问它具体降低什么风险、由谁负责、如何判断完成。如果没有明确答案，新增状态很可能只会增加维护成本。

4. 第四步：建立最小可行规则

试点初期建议先约定：工作类型、状态定义、负责人、准入条件、完成条件、在制限制、阻塞标记和升级时限。避免一次性制定几十条规则。规则越多，成员越容易把注意力放在合规填写，而不是推动工作完成。

同时明确谁可以调整优先级、谁可以批准紧急插入、插单后如何重新安排已承诺的工作。若优先级变更没有明确责任人，看板会准确记录混乱，却无法阻止混乱继续发生。

5. 第五步：运行每日协调与每周复盘

每日协调不应是每个人轮流汇报“我昨天做了什么”。更有价值的讨论顺序是：先看超限的列，再看最老的未完成工作，然后检查阻塞、承诺风险和需要跨团队决策的事项。会议围绕卡片流动，而不是围绕个人表现。

每周复盘则讨论更长周期的模式：哪一类工作最常等待？哪些环节反复退回？紧急插单是否挤占计划工作？在制限制有没有帮助团队更快完成？复盘结论必须落实为小幅流程调整，并指定负责人和验证时间。

6. 第六步：设定复核周期，决定扩展或修正

试点不是工具演示，而是管理假设的验证。经过约四到八周的稳定运行后，管理者可以比较基线与当前表现，检查数据口径是否一致、工作类型是否可比，并听取成员对维护成本和协作质量的反馈。

若周期变短但返工显著上升，不能简单宣布成功；若看板记录更完整，但阻塞处理没有变化，就需要改进管理机制，而非继续增加字段。只有当流程规则可理解、指标可解释、会议能触发行动，才适合复制到相邻团队。

下面的图表为情景模拟，用来展示试点阶段可追踪的路径。数值不是承诺值，也不是行业基准；企业应先用自己的基线替换，再评估改善是否来自流程变化而非任务类型变化。

六、具体案例与数据观察：用一条交付链路看清瓶颈

1. 情景案例：需求不少，真正卡住的是验证环节

假设一家约三百人的企业团队，产品、研发、测试和运维分属不同小组。原先的管理看板只有“待办、进行中、已完成”三列。管理者每周看到任务持续增加，研发同事表示自己一直在忙，业务方则认为交付慢。由于测试等待、环境准备和验收确认都被归到“进行中”，双方都无法解释延迟来自哪里。

团队试点后，将交付路径调整为“需求就绪、开发、待验证、验证中、待发布、已交付”，另设阻塞标记而非把所有等待状态塞进主流程。每张卡片必须有业务价值、验收条件、负责人和下一步动作；若需要外部确认，则记录等待对象和跟进日期。

2. 数据观察：先看时间花在哪里，再讨论要不要加人

以下为用于说明分析方法的情景模拟：在基线窗口中，团队观察到任务从进入执行到交付的周期中位数为十二天，其中开发约四天、待验证与验证约五天、其他等待约三天。团队最初以为研发能力不足，但拆分时间后发现，主要问题集中在验证排队和测试环境准备，而不是编码本身。

团队没有立刻增加开发人手，而是先统一提测条件、固定环境准备责任，并限制进入验证阶段的工作数量。之后的模拟观察显示，周期中位数降至八天，阻塞时间占比由约三分之一降至约五分之一；同时，退回比例没有下降，说明缩短周期并未自动改善质量，还需继续检查验收条件和缺陷来源。

这类数字的价值在于提出下一步问题，而不是用来证明某种工具必然有效。如果任务复杂度变化、团队规模变化或需求类型发生变化，前后对比必须做相应拆分。否则看起来像流程改善，实际可能只是后期交付了更简单的工作。

3. 复盘不只问“有没有变快”，还要检查代价

任何改善都可能伴随副作用。减少进入验证环节的工作，可能让任务在开发侧等待更久；压低在制量，可能让紧急事项有更明显的排队成本；缩短验收时间，也可能增加线上缺陷。因此，结果指标必须与质量、风险和成员负荷一起观察。

我会将试点复盘分为三层：流动结果看周期、在制和阻塞；质量结果看退回、缺陷和验收变更；组织结果看插单、跨团队等待及成员维护负担。只有三层信号方向基本一致，才适合把局部改善视为可扩展经验。

七、不同情况下的行动建议：按团队成熟度选择推进力度

1. 流程尚未稳定：先记录，不急着压指标

如果团队连“什么算开始、什么算完成”都没有共识，先建立最小状态集与责任规则。重点是让工作流真实可见，收集等待和返工的原因。此时过早设置严格的周期目标或个人效率排名，会促使成员修饰状态，而不是暴露问题。

这一阶段的管理者应多做流程观察：参加一次交接、抽查几张超期卡片、追踪一个阻塞事件从发现到解除的全过程。目标是确认数据能否代表现实，而非立即追求漂亮的改善曲线。

2. 工作流基本稳定：先限制在制，再解决瓶颈

如果状态定义相对一致，但多项工作长期未完成，重点应转向在制限制和瓶颈协作。团队可以从积压最明显的一列开始设试行上限，观察成员是否能通过结对、临时调配或优先处理老任务来改善流动。

若瓶颈来自单一审批人或共享环境，单纯要求执行人员加快没有意义。管理者要确认瓶颈是否可扩容、是否可以提前准备、是否存在替代路径，以及哪些工作必须由该角色处理。

3. 跨团队依赖复杂：先建立升级协议，再谈端到端时效

当工作经常等待其他部门，团队自身的看板只能覆盖一部分流程。此时要明确依赖的提出方式、响应时限、责任联系人和升级路径；必要时建立跨团队服务约定，让等待从“谁有空谁处理”变成可讨论、可复盘的协作规则。

端到端周期不能只归因于一个团队。管理者应区分可控执行时间、团队内排队时间和跨组织等待时间，再决定应该改流程、协调资源还是调整承诺。

4. 监管或交付风险较高：保留必要审查，不用“快”覆盖风险

金融、医疗、政务及其他受监管场景，某些评审与记录要求不是低效装饰，而是风险控制的一部分。看板的任务是让审查责任、证据和等待时间透明，而不是为了压低周期删掉控制点。

可以把必须遵守的控制条件设为完成标准，并记录风险评估、审批和回退原因。对于低风险与高风险工作，必要时采用不同路径，但应有明确的分类依据和授权边界。

八、不同情况下的取舍：看板设计没有放之四海皆准的最优解

1. 细颗粒度与维护成本之间的取舍

流程拆得越细，理论上越容易定位等待点，但成员维护状态的成本也越高。若状态变化频繁、责任人明确、每个阶段都对应不同管理动作，细分可能有价值；若团队需要每天花大量时间解释卡片该放哪一列，说明设计已经脱离工作本身。

建议先按“是否能触发不同决策”判断是否新增状态。若新增状态只是让报表更复杂，却没有不同责任、准入标准或管理动作，就先保留在现有阶段，用标签或阻塞原因表达差异。

2. 统一流程与团队自治之间的取舍

大型组织需要一定程度的统一，否则跨团队汇总和资源协调难以进行；但所有团队强制使用完全相同的流程，也可能忽视产品探索、运维响应和合规交付之间的差异。

更可行的做法是统一少数共通字段和指标口径，同时允许团队在具体状态、泳道和限制上做局部适配。组织应统一“怎样解释在制和周期”，不必强行统一每一个岗位的工作细节。

3. 透明度与心理安全之间的取舍

公开工作状态能减少信息差，但如果管理层把延迟数据直接用于惩罚，团队就会隐藏阻塞、修改开始时间或拆分卡片。透明度必须与公平使用数据的承诺同时建立。

管理者可以明确：试点阶段的流动数据主要用于发现系统问题；涉及个人贡献的判断需要结合工作难度、职责与质量证据。这个边界不是纵容低效，而是避免把诊断工具变成不完整的考核代理指标。

4. 自建流程与专业平台之间的取舍

小团队、流程简单且合规要求不高时，轻量表格或现有协作工具可能足够。随着组织规模、项目数量、权限边界、审计要求和跨团队依赖增加，团队往往需要更稳定的流程配置、权限管理、数据统计和集成能力。

以 PingCode 为例，若组织属于中大型企业，或团队规模达到百人以上，评估时不应只看卡片能否拖动，而应重点验证多团队协作、权限控制、流程配置、统计口径、系统集成及管理成本。其是否适合具体组织，仍应通过真实流程试点和需求清单验证，不应仅凭产品介绍作结论。

对于有数据边界要求的企业，可以把私有化部署纳入评估条件，同时核验部署架构、运维责任、升级方式、备份恢复和安全审查。若团队正在考虑从 Jira 平滑迁移，应先抽样检查项目结构、工作项字段、权限规则、历史记录和集成依赖，再制定迁移演练与回退方案。国产替代是否适合，最终取决于功能覆盖、迁移风险、服务能力和总体拥有成本，而不是单一标签。

5. 短期交付压力与长期改善之间的取舍

在重大上线或客户承诺临近时，团队可能需要短期集中处理特定事项。但若持续以紧急模式运行，长期工作会不断被推迟，技术债与流程债也会累积。管理者应把应急机制设计成有限、可追踪的例外，而非默认工作方式。

每次例外都应记录谁批准、挤占了什么工作、影响了哪些承诺，以及事后是否需要补偿资源。这样既能处理真实紧急事项，也能让组织看到“紧急”背后的隐性成本。

九、如何判断工具与看板方案是否适合企业

1. 先用场景清单筛选，不以功能数量做决策

采购或升级前，建议准备一份真实场景清单，而不是只收集功能名称。清单应包含跨部门工作流、权限隔离、历史数据迁移、汇总报表、外部系统联动、私有化要求、审计留痕和高峰期使用情况。

让业务负责人、流程负责人、信息化团队和一线成员分别验证自己的场景。管理者关注能否看到风险与产能，执行人员关注维护是否顺手，技术与安全团队关注部署、集成和治理边界。任何一方的需求都不应被界面演示代替。

2. 迁移评估要关注数据语义，不只是导入成功率

数据从旧系统进入新系统，不代表工作方式已经迁移。字段名称可能相同，含义却不同；历史状态可能无法一一对应；自动化规则、权限继承和通知机制也可能产生变化。迁移前应整理字段映射、状态映射、用户与权限映射及需要保留的历史数据范围。

建议先挑选一个代表性项目进行演练，重点检查工作项关系、附件、评论、权限、历史变更和报表口径。验收标准应包括用户是否能继续完成关键工作，而不只是系统是否显示“导入完成”。

3. 计算总体成本，而非只比较单项报价

企业看板方案的成本通常包含软件许可或服务费用、部署与集成、迁移、培训、权限治理、运维和持续配置。若工具便宜但需要大量人工维护，长期成本可能更高；若功能完整但团队使用门槛高，实际采用率低也会侵蚀投资回报。

试点期间可以记录每周维护看板的人工时间、跨团队信息追问次数、报表整理耗时和流程改动所需时间。将这些数据与方案费用、风险控制能力一起看，才能判断工具是否真正降低了管理成本。

4. 用验收问题取代“看起来很先进”的演示

演示时建议直接拿团队的真实流程和样例数据验证：能否识别超限列？能否追踪阻塞责任与时长？不同团队是否能有适度差异？管理者能否从汇总下钻到具体工作项？变更权限是否符合组织要求？

对每个问题都记录“通过、部分满足、未满足”和后续成本。若关键能力需要大量定制，应评估长期升级和维护责任；若流程本身尚不稳定，则先不要把复杂配置当作解决方案。

十、下一步怎么做：把看板从一次上线变成持续管理机制

1. 本周先完成三件事

• 选定一条实际工作流，写清楚工作从哪里进入、何时算交付。
• 抽样检查当前任务，标出真正执行、等待外部输入和被阻塞的工作。
• 选择三到五个能触发管理动作的指标，记录统计口径和基线来源。

2. 接下来一个月验证规则是否改变了行为

试行过程中，重点不是要求每张卡片字段齐全，而是检查团队是否开始主动处理超限、及时升级阻塞、减少无依据插单，并且能解释周期变化。若规则没有改变行为，就要检查规则是否可执行、管理者是否支持，或流程边界是否选错。

每周复盘应保留简短记录：发现了什么模式，采取了什么动作，谁负责验证，何时重新评估。不要把复盘写成流水账；几条有明确责任与验证时间的改进项，胜过一份无人跟进的长报告。

3. 决定扩展前设置停止条件

试点若出现数据失真、团队维护负担明显上升、质量恶化或紧急机制被频繁滥用，应暂停扩展并先修正设计。承认方案需要调整并不意味着试点失败；没有停止条件，才容易把局部问题复制到更多团队。

扩展时优先复制原则和验证方法，而不是照搬全部列名。新团队可以沿用工作流边界、阻塞管理和指标解释方式，再按自身职责调整具体状态。这样既保留组织级可比性，也避免把一套流程误当成唯一正确答案。

做好看板的关键，不是让每张卡片都更勤快地移动，而是让管理者能区分执行、排队与阻塞，并用规则和资源决策减少无效等待。下一步不妨从一条真实流程开始：先画出现状、记录基线、约定最小规则，再用几周数据验证瓶颈是否真的改变。只有当看板让团队更早发现问题、让管理者更准确地介入，它才从“状态展示板”变成了企业可持续改进的管理机制。