看板如何做好进行中？实施团队数据分析与操作步骤

看板上的“进行中”越堆越满，未必是团队不努力，常见原因反而是任务进入条件不清、等待工作被藏在同一列、多人同时开工却没人负责推动。要把“进行中”管好，重点不是催卡片移动，而是先定义什么工作能进入、怎样识别停滞、数据异常后由谁采取什么动作。本文给出一套从状态规则、数据口径到试运行复盘的操作方法，并用明确标注的情景模拟演示如何判断团队卡在哪里。

一、核心结论：把“进行中”当作工作流来管理

1. 先管流动，再看卡片数量

看板中的“进行中”不是一个天然统一的状态。同一个列名，可能装着正在编写方案的任务、等待评审的任务、依赖外部团队的任务，也可能装着已经暂停、但没人更新状态的任务。如果这些情况混在一起，团队看到的只是卡片堆积，却看不见堆积是怎样形成的。

我判断“进行中”是否管理有效，会先检查三个问题：团队成员是否对进入条件有一致理解；等待和阻塞是否能被看出来；每张卡片在停滞时是否有人负责推动下一步。三个问题的答案如果都是否定的，单纯增加报表或提醒频率，通常只会让大家更勤快地更新状态，却未必让工作更顺畅。

核心判断是：进行中事项的数量只是表面信号，任务从开始到完成的流动过程才是管理对象。团队要做的不是让卡片尽量少，而是减少没有明确价值的并行工作、缩短可避免的等待，并让无法避免的等待变得可见。

2. 指标要对应动作，不能只用来打分

“在制事项数”能帮助团队发现同时启动了多少工作，但它本身不能说明这些工作是否重要，也不能解释任务为什么没完成。“停留时间”能帮助发现异常，但任务复杂度、审批要求和外部依赖都可能影响时长。因此，指标只能提出调查问题，不能代替原因判断。

我建议每个指标都配一个可执行的问题。例如，在制事项突然增加，就检查新任务是否不断插入；阻塞时长变长，就查等待的对象和交接环节；完成量下降，则先确认是否因为工作难度变化、需求返工或团队可用时间减少。能推动一次具体排查或流程调整的指标，才值得长期保留。

二、先还原真实场景：为什么“进行中”容易变成任务仓库

1. 看板列名一样，实际含义可能完全不同

一个团队把任务移入“进行中”，代表负责人已经开始实际处理；另一个团队只要任务被分配，就会移入该列；还有团队会把等待评审、等待客户反馈都留在“进行中”。表面上看，三块看板结构相同，数据却不是同一口径，横向比较没有意义，纵向趋势也可能被状态更新习惯改变。

例如，团队把“等待安全评审”留在进行中，报表会把评审排队时间算入执行时间。如果下个月把评审单独拆成一列，执行时间可能明显缩短，但这未必代表工作本身变快了，只是计时边界发生变化。状态定义调整前后，必须保留口径变更记录；否则趋势图会把流程变化和统计变化混为一谈。

2. 一张卡片长期不动，常见原因不止一种

任务长时间停在一列，有可能是范围过大，没人能在短周期内完成；有可能是等待某个评审或外部输入；也可能是优先级频繁变化，负责人被要求先做新事项。还有一种更隐蔽的情况：任务其实已经完成了，但卡片没人更新。每种原因的解决方式都不同，因此“提醒负责人尽快处理”不应是唯一动作。

在实施团队里，外部依赖尤其容易被误读。交付人员可能已完成自己的工作，却在等客户确认、环境开通或其他团队提供接口。如果所有等待都显示为“执行中”，管理者就会看到一个很大的工作池，却无法分辨团队正在做什么、正在等什么。

3. 过多并行工作会掩盖真正的优先级

当新需求不断进来，团队可能习惯先把每项任务都放进进行中，认为这样可以表示“都在推进”。但启动不等于推进。任务一旦分散到多人、多条依赖和多个优先级上，团队就更难判断哪项工作应该先完成、哪里需要协作、谁有能力接手新的紧急事项。

我会把“进行中堆积”视为需要进一步检查的信号，而不是直接定性为流程失败。要看增加的是正在实际执行的工作，还是排队和等待；要看新增卡片是否挤压了已有任务；还要看团队是否有明确的“先完成还是先开工”规则。没有这些背景，单看列里的卡片数容易得出错误结论。

三、常见误区：看起来更精细，不一定更可管理

1. 把“进行中”拆成很多列，却没有改变团队行为

为了看清细节，有些团队把看板拆成“开发中”“自测中”“待评审”“联调中”“待验收”等多个阶段。这可能有帮助，但前提是每一列都代表一种团队能识别、也能据此采取动作的状态。如果成员只是在任务变动时机械地换列，却没人处理排队问题，多几列只是多了维护成本。

判断要不要拆列，可以问两个问题：这类等待是否经常发生；团队是否会因看见它而采取不同动作。如果答案都是肯定的，单独呈现可能有价值。如果某列几乎没有任务、也不会引发不同处理方式，考虑合并，或先用标签标记等待原因。列的数量应服务于协作决策，而不是看板看起来有多细。

2. 给所有团队规定相同的在制上限

在制限制可以帮助团队控制同时启动的工作，但没有一个适用于所有团队的固定数字。任务大小、工作类型、人员分工、跨职能依赖和紧急事项比例都会影响合理上限。对任务粒度小、交接稳定的团队有效的规则，套到需要多人协作、周期较长的实施项目上，可能让看板出现“卡片不许进入，却没人知道该如何处理”的僵局。

如果打算设置限制，先观察现有工作如何流动，再做小范围试行。限制可以按团队、工作阶段或工作类型设置，不一定要按个人分配。遇到紧急任务时，也应提前定义例外流程，避免团队为了绕过限制而把新工作藏在其他列或另建看板。

3. 把周期时间当成个人速度排名

周期时间通常用于描述一项工作从团队定义的开始事件到完成事件所经过的时间。它适合观察团队整体的流动变化，但不等同于个人工作时长，也不适合在任务大小和依赖条件不同的情况下直接比较个人表现。

如果一项任务的周期变长，先检查工作类别、任务范围、等待时间和返工情况。若团队把这一数字直接变成绩效指标，成员可能会倾向于接容易完成的工作、拆出数量更多但价值更低的任务，或者提前移动卡片来缩短统计时间。指标一旦诱发与真实交付相反的行为，就失去了诊断价值。

4. 只看平均数，忽略长尾和少数异常卡片

平均停留时间很容易理解，但可能掩盖少量长期停滞的任务。比如，大多数事项两三天完成，少数事项因为审批或依赖卡了很久，平均值只略微上升，团队却可能已经错过关键交付节点。反过来，少量复杂任务也可能抬高平均值，不能据此认定所有工作都变慢了。

在看均值之外，我更建议同时查看中位数、较长周期区间和具体异常事项。统计分布告诉团队“多数工作大致怎样”，异常列表则帮助团队找到“哪些工作需要现在介入”。两者应结合使用，不宜用一个概括性数字取代逐项排查。

四、专业判断逻辑：先统一定义，再读数据，再查原因

1. 为每个状态写下进入条件和离开条件

“进行中”规则不必写成长篇制度，但至少要回答：什么事件发生后，任务才算开始；任务完成到什么程度，才可以离开该状态；等待外部输入时是否留在当前列；暂停工作如何标记。最好让实际执行任务的人参与讨论，避免规则只符合管理报表、不符合日常操作。

例如，团队可以约定“开始处理”才进入进行中，而不是分配负责人时就进入；提交评审后转到单独的评审状态；若依赖未就绪，则标记等待并记录依赖方。具体规则不是通用标准，重点是所有参与者能按相同方式使用，且看板能体现真实工作状态。

2. 先定计时边界，避免指标口径漂移

记录周期时间前，要确定开始点和结束点。例如，开始点可以是任务进入“进行中”的时间，结束点可以是交付完成或验收通过的时间。两种结束事件回答的问题不同：交付完成关注团队内部产出，验收通过则还包含客户或下游确认时间。团队不能不说明边界，就把两者称为同一个周期。

还要决定如何处理暂停、返工、退回和重复打开。若等待时间是团队想改善的对象，通常不应将其从整体交付周期中悄悄排除；若要分析实际执行时间和排队时间，可以分开记录，并同时保留从开始到交付的端到端时间。关键是口径明确、前后一致、结论对应正确的时间范围。

3. 用组合信号定位，而不是单指标定罪

例如，进行中事项数量增加，同时完成量没有变化，可能提示并行工作过多或下游排队，但还要检查任务难度与需求变更。若阻塞数量上升、阻塞时间也延长，则更应优先检查依赖处理、审批路径和协作响应。若完成量降低，但任务中位周期稳定，也可能只是当期接收了更少或更复杂的工作。

我会先提出待验证的解释，再找卡片和工作记录核对，而不是看图后立即宣布原因。管理者可以抽查几项异常任务，询问负责人“现在具体在等什么”“下一步动作是什么”“需要谁协助”。这类问题比单纯问“为什么还没完成”更容易暴露实际流程问题。

4. 区分“等待”与“阻塞”

等待不一定意味着流程故障。评审、客户确认或批次发布本来就可能需要排期；阻塞则通常意味着某个必要条件缺失，任务在当前状态下无法按预期推进。团队可以把等待标成一种状态或标签，把阻塞定义为需要协助、决策或升级的情形。

我建议阻塞记录至少包含三个信息：阻塞原因、下一步动作、负责推动的人。只写“已阻塞”并不足够，因为它没有告诉团队如何解除障碍。原因可以简化为若干常见类别，但不要把分类复杂到每次更新都要花很多时间。

五、情景模拟：从一周看板数据追到可行动的原因

1. 先说明示例边界，不把模拟数据包装成实绩

以下案例是为了演示分析路径而设置的情景模拟，不是某个真实团队的调查结果，也不是行业平均值。假设一家实施团队由产品顾问、交付人员和技术支持共同处理客户配置与验收工作，团队统一以“实际开始处理”作为进入进行中的时点，以“客户验收完成”作为交付结束点。

团队在连续四周的复盘中发现，进行中事项一度从14项增加到19项，按周完成的事项却没有同步增长。负责人最初认为大家执行不够快，但抽查卡片后发现，部分任务已完成团队内部配置，却仍在等待客户确认；另一些任务则因评审安排集中在周末前，形成短时排队。

2. 用卡片级信息验证初步判断

如果只看“进行中事项数”与“完成事项数”，团队只能知道流动出现偏差，不能知道偏差从何而来。进一步把任务按当前状态拆分后，团队发现等待评审和外部依赖的事项占了较大部分。再看阻塞记录，若干事项都依赖相同的客户环境信息，说明问题可能不是执行人手不够，而是依赖输入确认得太晚。

模拟数据中的关键不是具体数量，而是排查顺序：先看总量变化，再按状态和阻塞原因分组，最后回到具体任务核实。团队没有因为“完成量下降”就要求所有成员加快处理，而是重新安排评审时段，并在任务进入执行前确认客户环境信息是否齐全。

表中数字是情景模拟。第2、3周的进行中事项逐步增加，而完成量没有明显跟上；第4周新进入事项减少、完成量增加，期末在制事项下降。这个变化值得继续观察，但不能仅凭一周结果就宣称流程改进成功，还要确认任务难度、需求结构和统计口径是否保持可比。

3. 将分析结论转为小规模动作

这个团队没有立即重画整张看板，而是先做了三项低成本调整：评审前设置固定的可用时段；任务进入执行前确认环境信息是否具备；对等待客户输入的事项增加依赖方和下一次跟进时间。这样做的优点是动作直接对应发现的问题，也更容易判断是否有效。

下一轮复盘时，团队应检查等待评审事项是否减少、依赖类阻塞是否提前出现、已完成事项是否能顺利验收。若完成量提高但返工也增加，说明速度不是唯一需要关注的结果；若阻塞时长下降，却增加了大量前置确认工作，则要评估新增成本是否值得。复盘不是证明方案正确，而是检验方案带来的收益和代价。

六、实施团队的操作步骤：先轻量试行，再按证据调整

1. 召集真正使用看板的人，画出当前流程

不要先从理想流程图开始。让执行者把一项工作从提出、澄清、处理、评审到交付的真实过程讲出来，特别记录工作在什么地方等待、谁能让它继续。管理者、交付人员和协作方对“任务什么时候开始”可能有不同理解，这些差异正是需要先解决的口径问题。

流程图不必追求复杂。可以用纸面、白板或团队已有的项目管理平台，先写出关键状态和转移条件。遇到少见但重要的例外，先记录下来，不必为了覆盖所有可能性，把主流程切得过细。

2. 定义状态，给等待和阻塞留出可见位置

每个状态写一句简短定义，并说明进入或离开的条件。团队可以从现有列开始，只在有明确管理价值时增加状态。若评审等待频繁且需要安排容量，可以单独呈现；若外部依赖种类很多，可以先用标签和原因字段区分，不一定马上新增多列。

阻塞规则应避免含糊。建议写清楚什么情形算阻塞、需要记录哪些信息、何时需要升级。比如，任务因缺少外部输入无法继续时，标记阻塞并写明责任协作方和下一次跟进时间。不要把普通排队都标成阻塞，否则团队很快会对这个标签失去敏感度。

3. 选择最少但有用的数据字段

实施团队常见的问题不是字段太少，而是字段过多导致没人维护。初期可以只保留任务类别、负责人、当前状态、进入时间、阻塞原因和下一步动作等字段。只有在团队确实会使用某项信息做判断时，才考虑增加字段。

工作类型差异较大时，可以先用少量类别区分，例如配置、培训、集成、验收。分类的目的是避免把完全不同的任务混成一个平均值，不是要求每张卡片填写复杂的业务背景。字段能否自动记录也值得考虑：如果状态时间能由工具自动保留，就不要让成员重复手工登记。

4. 建立团队自己的起始基线

先连续观察一段覆盖正常工作节奏的时间，记录在制事项数、各状态停留时间、阻塞原因和完成量。具体观察多久取决于工作周期：事项周转较快的团队可以较早发现趋势，交付周期较长的团队则需要覆盖足够多的任务进出，不要只凭几张卡片定规则。

建立基线时，不必先设“正确答案”。先确认数据是否完整、成员是否按同一规则更新、任务类别是否能区分。如果数据质量不稳定，优先修正状态定义和更新习惯，而不是急着画复杂仪表盘。基线的价值是帮助团队比较自身变化，不是拿来和未经核实的行业数字对标。

5. 先试行在制限制，不要一开始就用硬指标约束个人

团队可以先观察工作启动后是否长期堆积，再讨论限制新工作进入的方式。限制对象可以是某个团队或阶段，也可以按工作类别分别试行。设置时要明确：当上限达到，团队是优先协助完成已有工作，还是允许经过协商的紧急例外；否则限制会变成表面规则。

可以先把限制作为讨论触发条件，而不是惩罚线。例如，超过团队约定的数量时，先暂停低优先级新开工，安排成员协助推进接近完成或存在阻塞的事项。若团队发现工作类型差异过大，就需要重新分组或调整限制，不应要求成员通过拆卡、转列来满足数字。

6. 让日常同步围绕异常和协作，而不是逐卡汇报

每日或固定频率的同步，不必让每个人从头到尾复述手上的所有任务。更有效的议程通常围绕三类事项：接近完成、停留异常、需要他人协助。提问可以聚焦“下一步是什么”“当前依赖谁”“是否需要调整优先级”，避免会议变成对个人工作量的逐项盘点。

对于停留较久的任务，先确认状态是否准确，再讨论原因和责任动作。若只是卡片没有更新，补充状态即可；若是评审排队，则协调评审安排；若是需求不清，则安排澄清。不同原因对应不同动作，会议纪要要记录责任人和跟进时间，而不只是记录“继续关注”。

7. 固定复盘规则变更，并记录结论

看板规则不要每天变，也不要搭好以后长期不动。团队可以选择适合自身节奏的复盘频率，每次重点检查数据口径、阻塞类别、限制规则和执行负担。若调整状态定义或计时边界，记录生效时间和变更原因，避免历史趋势被误解释。

一条有效的复盘记录至少包括：观察到的现象、核实过的原因、决定采取的动作、负责人以及下次检查的信号。比如，“评审等待增加”是现象，“评审集中在每周末”是待验证原因，“增加每周两次短评审时段”是行动；后续再看等待时长和返工情况，而不是只确认会议是否召开。

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

1. 任务简单、周转快：控制维护成本

如果任务规模较小、状态变化频繁，过多列和字段会让更新成本超过它带来的判断价值。建议优先保持流程简洁，用少量状态呈现关键转移，把阻塞原因作为轻量标签或备注。重点观察进行中事项是否持续增加、完成是否稳定、异常事项是否能及时被团队看见。

这类团队可以接受部分细节不进入结构化报表，前提是日常协作仍能解决问题。若每次换列都要填一串字段，成员可能会延迟更新，最终产生看起来精确、实际不可信的数据。取舍原则是：先保留能触发行动的信息，暂缓收集只用于展示的信息。

2. 多团队交接频繁：增加交接状态和责任边界

当任务需要多个团队依次处理，交接等待通常会影响整体周期。此时可以考虑把关键交接点独立呈现，并明确交出方、接收方、必要输入和接收确认条件。只写“已提交”并不表示对方已经接手，交接状态应反映双方都能理解的事实。

增加交接可视性会提高维护成本，也可能让看板变得更复杂；但若交接延迟反复造成交付风险，这种成本通常值得评估。团队可以先只拆最常发生或影响最大的交接点，不需要把所有部门的内部步骤都放进同一张看板。

3. 依赖客户或外部组织：把外部等待纳入计划，而非全部归为团队执行时间

客户确认、环境准备、权限开通等事项往往不由实施团队单方面决定。建议明确记录依赖方、提出请求的时间、约定反馈时间和下一次跟进动作。对外部等待的管理目标，不一定是让等待消失，而是尽早暴露、降低临时发现的风险，并让项目计划反映现实。

取舍在于跟进频率和协作成本。过于频繁地催促可能损害协作关系，过久不跟进则会让依赖事项悄悄拖延。团队应按风险和交付节点安排跟进，并区分“等待对方提供输入”与“团队内部没有明确责任人”。

4. 任务差异很大：分组分析，避免被平均数误导

同一团队可能同时处理简单配置、复杂集成和高风险验收。如果把这些任务合并计算平均周期，复杂事项会抬高整体时长，简单事项的大量完成又可能掩盖少数高风险任务。可以按工作类型、交付阶段或依赖特征分组，但类别数量要克制，确保每组仍有足够事项用于观察。

分组会提高分析解释力，也会减少每组的数据量。样本很少时，团队应把数字当作线索，结合卡片逐项核对，不要制造看似精确的结论。若某类工作每个周期只有一两项，描述实际案例往往比计算平均值更有帮助。

5. 组织规模较大：优先统一口径和权限，再谈汇总看板

多团队协作时，各团队可能使用不同流程、字段和工作粒度。此时直接汇总进行中数量，容易把不同含义的卡片加在一起。规模较大的组织应先明确哪些指标需要统一，哪些流程允许团队保留差异；同时确认谁可以查看、修改和解释数据，避免总览看板变成脱离上下文的排名表。

组织级汇总能帮助发现跨团队依赖和资源瓶颈，但会增加数据治理、配置维护和推广成本。若团队流程还不稳定，先在代表性团队中验证定义，再逐步扩大范围，通常比一次性要求所有团队采用同一套细节更稳妥。选择某项目管理平台时，也应评估流程配置能力、权限管理、历史数据可追溯性和迁移成本，不能只看图表是否丰富。

八、复盘自查：判断看板是否真的管住了进行中

1. 看状态是否代表事实，而不是管理愿望

随机抽几张进行中卡片，请负责人说明当前实际状态、下一步动作和正在等待的对象。如果卡片显示“进行中”，但负责人只能回答“还在跟进”，说明状态信息可能不足。如果任务已经完成却长期没有移出，说明更新机制或责任边界需要调整。

2. 看数据是否能引出具体问题

检查团队每周查看的图表，能否引出明确的调查方向。若报表只展示总数、均值和趋势，却没有人据此检查异常卡片，可能是指标过多或缺少责任机制。相反，如果每项数据都能对应一个具体问题和后续动作，报表即使简单，也可能更有价值。

3. 看改进是否减少等待，而不只是加快状态更新

优化后，不要只看卡片移动次数是否增加。还要检查任务是否更少地等待评审和依赖、异常是否更早暴露、返工是否增加、团队用于更新看板的时间是否过多。如果数字改善伴随着工作质量下降或成员维护负担显著增加，就要重新评估方案。

4. 看团队是否能解释异常，而不是只报告数字

当完成量下降或在制事项增加时，团队应能说清楚发生了什么、哪些原因已经核实、哪些仍是猜测、接下来准备做什么。如果每次复盘都停留在“数据不好看”，说明看板还没有形成从观察到行动的闭环。

九、结语：别急着让卡片动起来，先让团队看见工作为何停住

做好看板中的“进行中”，不是把每张卡片都推得更快，而是让真实状态可见、让等待有原因、让异常有负责人。状态规则解决口径问题，组合数据帮助发现信号，卡片级核查负责验证原因，团队行动和后续复盘则决定改进是否真的有效。

团队下一步可以从一个小动作开始：选一周时间，抽查进行中卡片，标出正在执行、等待和阻塞三类状态，记录每项停滞的下一步动作。先用团队自己的数据找到最常见的一个瓶颈，再试一项低成本调整。看板的价值不在于把工作展示得更整齐，而在于让团队更早发现该一起解决的问题。