进行中管理指南：管理层如何做好看板，入门指南全流程

进行中管理指南：管理层如何做好看板，入门指南全流程

如果一个团队每周都在更新任务状态，管理者却仍说不清哪些工作真正受阻、为什么延期、下一步需要谁决策，那么问题往往不是“看板列得不够多”，而是看板没有把工作流变成可行动的信息。做好进行中管理，不是盯着每个人有多忙，而是帮助工作顺利流动：看见等待、控制并行、及时清障，再用结果复盘规则是否有效。

一、先给结论：看板管理的是流动，不是忙碌

1. 看板不是任务陈列墙

我判断一块看板是否真正发挥作用，通常不先看颜色、卡片样式或字段数量，而是看管理者能否依据它回答三个问题：什么工作正在推进，什么工作停住了，停住之后谁能采取什么行动。若看板只能回答“每个人手里有几项任务”，它更像一张可视化清单，而不是进行中管理机制。

一张有用的看板，至少让团队看见工作从提出、准备、执行、评审到完成的真实路径。每个状态都应代表一个可观察的事实，而不是模糊的感受。“进行中”如果同时包含等待需求确认、正在开发、等外部审批和待测试，管理者就无法判断拥堵发生在哪个环节。

2. 管理者的重点是清障、取舍和规则

管理层不需要每天逐张卡片催问，也不应把看板当作个人忙闲排行榜。更有价值的管理动作包括：决定冲突事项的优先级、协调跨团队依赖、补足关键资源、明确工作进入流程的条件，以及推动团队复盘长期等待的原因。

我更愿意把看板理解为“组织工作流的共同界面”：团队负责更新事实，管理者负责让事实变成决策。如果信息更新后无人处理阻塞，团队很快会认为维护看板只是额外劳动；如果管理者利用信息清除障碍，看板才会进入日常工作。

3. 先设一个管理目标，再决定看板长什么样

搭建看板之前，先选一个具体问题，例如跨部门事项经常等反馈、重要工作长期排队、承诺日期反复变化，或测试环节积压。目标越具体，越容易决定应当展示哪些状态、需要记录哪些信息，以及试运行后该观察什么。

不建议一开始就同时追求“提高效率、强化协同、提升透明度、优化绩效”。这些词听起来都正确，却不能直接指导设计。把目标缩到一个流程和一个主要痛点，通常比一次性建成覆盖全公司的大看板，更容易得到可信反馈。

二、为什么任务都在做，进度仍然不可控

1. 管理者看到的是任务，团队经历的是等待

很多团队的周报里，事项看起来都处于“进行中”，但实际状态可能完全不同：有人正在产出，有人等业务确认，有人等设计评审，还有人已经完成工作，只是等待另一个团队接手。若这些情况挤在同一列，管理者看到的是一片繁忙，团队承受的却是不同类型的等待。

这也是进度询问容易变得频繁的原因。管理者没有足够的流程信息，只能逐项追问负责人；负责人则需要在会议、即时消息和表格之间重复解释。追问次数变多，不一定表示管理更严格，也可能说明工作状态没有以低成本方式被共同看见。

2. 并行事项太多，完成工作反而变慢

同时启动许多任务，常常会让团队产生“每件事都在推进”的感觉，但注意力切换、依赖等待和反复交接都会增加。这里需要区分“在做的事项多”和“完成的事项多”：前者描述当前负载，后者描述已经交付的结果，两者不能互相替代。

当团队持续开始新工作，却很少优先完成已有工作时，管理者应先检查在制品是否过多、优先级是否频繁变化、不同角色之间是否存在排队，而不是马上要求所有人加快个人速度。局部加速并不必然带来整体交付改善。

3. 交接和审批是常被低估的流程环节

工作流程中的停顿，未必发生在执行任务的人手上。需求等待决策、设计等待业务确认、交付等待验收，都可能让事项长期停在一个表面正常的状态。若看板只记录“负责人”和“截止日期”，这些等待就会被折叠成一个难以解释的延期结果。

因此，管理层设计看板时应留意“谁正在做”和“工作正在等什么”之间的差别。必要时，可以把等待外部输入、待评审或待验收设置为明确状态，也可以使用阻塞标记记录原因。选择哪一种做法，应取决于等待是否足以改变管理决策。

三、常见误区：看板为什么会越做越重

1. 直接照搬“待办、进行中、已完成”三列

三列可以作为试点的起点，却未必能解释团队的实际交接。假如事项常卡在评审、外部确认或测试，三列结构会把不同问题混在一起。反过来，列越多也不必然越清楚；如果每个人对状态含义理解不同，复杂流程只会增加维护成本。

我的判断原则是：只有当一个阶段具有不同的责任人、进入条件、退出条件或管理动作时，才值得考虑单独呈现。若新加一列不会改变任何人的行动，它可能只是增加状态名称，而没有增加管理信息。

2. 把所有任务都标成最高优先级

当每项工作都是“紧急”或“最高优先级”，看板便失去排序功能。优先级不应由谁声音最大决定，也不应只依赖任务提出者填写。管理者需要说明排序依据，例如客户承诺、合规要求、业务影响、依赖关系和错过窗口的代价。

如果重要工作不断被临时事项打断，可以在看板上明确“紧急插入”的规则：谁有权批准、被插入的工作会挤出什么、是否需要同步调整原有承诺。没有取舍规则的优先级标签，容易变成催办信号。

3. 把在制品限制变成个人考核红线

在制品限制的用途是帮助团队控制同时推进的工作，暴露排队和阻塞，不是要求某位成员手上的卡片永远不能超过固定数量。若管理者把它直接用于个人考核，成员可能会拆分、隐藏或绕开工作项，结果看板数字更整齐，实际协作却更不透明。

限制值也不存在适合所有团队的通用答案。工作复杂度、团队分工、外部依赖和需求变更频率都会影响合理范围。更稳妥的做法是从当前负载开始观察，提出试行规则，再依据完成情况和阻塞变化调整，而不是先设一个看起来精确的数字。

4. 把更新看板等同于完成管理

看板更新得很勤，并不能证明管理有效。需要留意的是更新之后发生了什么：阻塞是否有人接手，跨团队问题是否进入决策，逾期事项是否重新评估承诺，反复出现的等待是否促使团队修改规则。如果答案是否定的，团队只是在维护状态，而没有改善流程。

另一种常见问题是字段越来越多。负责人、计划日期、实际日期、优先级、风险、业务线、标签、工时、说明……每新增一个字段，都应问一句：谁会基于它采取行动？若没有明确用途，就先不要要求所有事项填写。

• 症状：状态长期不变。先核实实际工作是否停住，再判断是更新习惯、定义不清还是确有阻塞。
• 症状：卡片信息很完整，但会议仍靠口头补充。检查关键信息是否能帮助下一步决策，而不是只满足汇报格式。
• 症状：任务都按时关闭，业务结果却没有改善。重新审视工作项是否与目标相关，以及“完成”的定义是否过于宽松。

四、专业判断逻辑：从真实流程设计看板

1. 先确定边界：什么工作应该上板

看板不一定要承载团队所有活动。适合纳入的工作，通常具有明确的交付目标、可识别的负责人或协作关系，并且需要跟踪其状态变化。临时沟通、无法拆分的长期职责、纯粹的信息备忘，未必都需要变成卡片。

管理者应先回答三个问题：这类工作从哪里进入流程，什么情况算正式开始，满足什么条件才算完成。入口和完成标准不清，常常比缺少看板工具更容易造成争议。对过大的事项，要拆到团队能识别下一步和交付结果的粒度。

2. 按工作状态建列，不按组织架构建列

流程列应该描述工作当前处于什么阶段，而不是把部门名称横向摆满屏幕。若一个事项经过需求、设计、开发和验证，按部门分列可能看起来符合组织结构，却不容易表示它是在等待、评审还是实际执行。

画流程时，我会从最近完成的一批真实事项回溯：每项工作经过哪些步骤，在哪些地方交接，哪些阶段经常返工，哪些等待需要管理者介入。先画出现状，再讨论目标流程，能减少把理想路径误当现实的风险。

3. 给状态定义进入条件和退出条件

同一个“待评审”状态，可能有人理解为已经提交，有人理解为评审已经排期，还有人理解为评审完成但仍待修改。状态名本身不足以保证一致理解。看板规则应说明什么条件下工作进入该列，谁负责推进，以及什么结果允许它离开。

规则不需要写成长篇制度。可以在列说明中用简短句子讲清进入条件、责任角色和完成证据。例如，“待验收”表示交付物已提交、验收责任人已确定；通过标准、退回方式和反馈期限则在团队约定中补充。

4. 把阻塞信息写成可行动的问题

一个红色标记如果只说明“有风险”，还不足以帮助管理者决策。建议至少补充阻塞原因、需要谁提供什么支持、影响哪项工作，以及希望何时得到处理。这样的信息可以减少会议里从头复述背景的时间。

同时要定义升级路径。团队可自行处理的事项，由工作负责人协调；跨部门资源冲突由相关负责人解决；影响承诺或目标的事项，再升级到决策层。所有问题都上升到管理层，会造成新的队列；没有升级规则，则关键障碍可能一直留在原地。

5. 根据目的选择观察指标

不同目标需要不同观察方式。想理解交付节奏，可关注一段时间内完成的工作项数量；想发现流程拥堵，可关注工作从开始到完成的时间分布；想减少反复等待，则需要记录阻塞原因和等待时长。单独看一个平均值，容易掩盖少数长期滞留事项。

指标定义需要保持一致。例如，周期时间是从团队约定的哪个起点开始，到哪个完成状态结束；被暂停、撤销或等待外部反馈的工作如何记录。工作类型差异较大时，不宜不加区分地横向比较。指标适合用来提出问题，不适合脱离背景直接给个人贴标签。

五、案例推演：一个跨职能团队怎样发现瓶颈

1. 先说明案例口径，避免把示例写成行业数据

下面用一个虚构的产品交付团队说明诊断过程。团队有12人，涉及产品、设计、开发和测试，试点持续6周。文中的任务数量、耗时和变化均为情景模拟，用于演示看板如何辅助判断，不代表任何企业实际成绩，也不应被当作行业基准。

试点前，团队每周都更新任务表，但“进行中”事项长期偏多。管理者通过回顾近期工作发现，开发阶段并非唯一瓶颈：不少事项在需求确认和评审阶段等待，测试也常因交付批次集中而积压。团队决定先跟踪工作状态、阻塞原因、进入和完成日期，不急着计算复杂绩效分数。

2. 把“进度慢”拆成可以验证的问题

第一周，团队把近期事项按真实阶段重新归类，并补充阻塞原因。结果发现，一部分任务并非执行慢，而是负责人不确定需求是否已批准；另一部分卡片标为“开发中”，实际已经完成编码，只是等待评审。此前看板把工作状态和等待状态混在一起，使得团队很难判断应由谁采取下一步行动。

团队随后增加“待确认”和“待评审”两个状态，并写明进入条件。对于外部依赖，卡片记录所需输入、责任方和希望响应日期。这个变化没有增加新的管理层级，却让会议讨论从“这项怎么还没好”转向“缺少哪项确认、由谁协调”。

3. 试行在制品限制，而不是追求漂亮的数字

第二周起，团队尝试限制关键执行阶段同时推进的工作项。限制值不是照搬某个方法论的固定数字，而是参考当时的队列和团队可用能力提出，再在复盘中调整。出现空闲时，团队优先协助完成接近交付的事项，而不是立刻启动新任务。

这种试行也暴露了副作用：如果一项工作被复杂依赖长期阻塞，单纯限制该列会让其他工作无法进入，团队需要先判断是该清除依赖、暂时暂停事项，还是重新排序。限制因此是一种讨论机制，不是自动优化按钮。

4. 看结果时同时观察数量、时间和原因

在模拟的6周记录中，团队每周完成的事项数量从波动较大逐渐变得相对稳定；从开始到完成的中位时间有所下降，长期阻塞事项也变少。需要注意，这种变化可能同时受到工作类型、人员安排和需求规模影响，因此不能据此声称看板单独造成了提升。

我会优先核对变化是否有具体流程解释：等待确认是否缩短，评审队列是否变薄，还是团队只是选择了更小的工作项？若没有解释路径，数字只能说明发生了变化，不能证明为什么变化。试点报告应把数据口径、样本范围和可能干扰因素一起交代。

5. 复盘时保留反例，防止只讲成功故事

并非所有结果都改善。模拟试点中，临时插入事项仍会打乱原有顺序，外部评审等待也没有完全消失。团队最终调整的不是单一看板列，而是规定插入事项需要说明业务理由，并同步讨论被延后的工作；对评审则设置固定检查时段，同时保留紧急事项的例外处理路径。

这个案例的重点不是“加几列就提高效率”，而是看板帮助团队定位工作为什么停住，再把问题交给有能力处理的人。若管理者只展示前后数字，不交代工作类型、规则变化和异常事项，读者很难判断做法能否迁移到自己的团队。

六、从零启动：用小范围试点验证规则

1. 选一条具体流程，不要先覆盖全组织

优先选工作量稳定、参与角色明确、问题已经被团队感知的流程。例如，一个产品交付链路、内部审批流程或客户问题处理流程。不要只因为某条流程“重要”就选它；如果目标不清、负责人不愿参与，试点可能变成一次被动填报。

试点范围应足够小，能在有限时间内回顾多个工作项；也不能小到只有一两个事项，无法观察排队和异常。确定范围时，写明哪些工作进板、哪些工作暂不纳入，以及试点期间由谁维护规则。

2. 用近期工作反推真实状态

找一批近期完成或仍在推进的事项，逐个回顾实际经历。记录它经过的阶段、交接对象、等待原因、返工位置和完成条件。不要先开会设计一套“理想流程”再要求团队照做，因为真实工作往往会经过临时确认、外部审批或紧急变更。

回溯的目的不是追究谁造成延期，而是判断哪些状态值得被看见。若不同事项路径差异很大，可以先聚焦一类工作；硬把所有工作压进同一套流程，可能使看板既复杂又失真。

3. 搭建最小可用看板并说明规则

初版只保留足以推动协作的状态和字段。每张卡片通常需要能识别工作内容、责任人、优先级、当前阶段、下一步和必要依赖。对于管理者真正需要的状态信息，应优先保证可读；背景材料可链接到原始文档，不必把所有细节复制到卡片里。

列规则要简短、明确，并让实际参与工作的人共同确认。工作项如何进入，何时算开始，怎样判断完成，阻塞时如何记录，紧急事项如何插入，这些约定比选择哪种颜色或卡片样式更影响日常采用。

4. 先运行，再决定是否加限制和指标

开始阶段先观察队列、等待和交接，不必立刻设置严格限制。团队知道现状后，再挑选一个最拥堵或最容易出现多开工作的阶段，试行在制品限制。每次只改少数规则，方便辨别变化可能来自哪里。

若要设置限制，提前约定超限时怎么办：是暂停新工作、邀请同伴协助、处理阻塞，还是由管理者重新排序。没有超限后的行动约定，限制数字容易沦为墙上的装饰。

5. 设定复盘节奏并保留调整记录

日常查看关注当前阻塞和下一步，周期复盘关注流程变化与规则有效性。会议多久一次，应由工作节奏、依赖风险和团队协作方式决定，不需要把某个固定频率当成普遍答案。重要的是每次查看都能导向明确动作，并避免同一事项在会议中重复汇报却无人跟进。

每次调整规则时记录日期、原因和预期变化。例如，团队决定增加“待业务确认”状态，是因为需求确认时间无法区分；试行后要检查这一状态是否让责任更清晰，还是只是多出一个长期不动的列。这样才能避免无意中不断叠加规则。

1. 选定一个工作流程，并明确试点边界。
2. 回顾近期事项，画出实际流转路径。
3. 确定工作项粒度、入口条件和完成条件。
4. 搭建精简看板，补充必要的责任与依赖信息。
5. 观察阻塞和排队，再小范围试行限制或规则调整。
6. 复盘变化、记录例外，并决定保留、修改或撤销哪些做法。

七、管理者如何开会、清障和复盘

1. 会议从工作流开始，而不是从个人逐项汇报开始

查看看板时，可以从最接近完成的事项、超出正常停留时间的事项和明确阻塞项开始。团队先讨论“什么需要帮助才能继续”，再讨论新工作是否有必要进入。这样的顺序能避免会议变成按人头轮流报进度，也能把注意力放到完成工作而非不断启动工作上。

如果事项没有风险、没有依赖、也不需要决策，通常不必在会上重复读卡片。看板本身已经承载的事实，可以留给成员会前查看；会议时间更适合处理冲突、确认取舍和指定下一步负责人。

2. 用四个问题推动事项前进

• 这项工作当前真正处于什么状态？是否只是看板没有更新？
• 若工作没有前进，等待的具体输入、决定或交付是什么？
• 谁有能力解除阻塞，最迟需要在何时采取行动？
• 为推进这项工作，是否需要暂停、延后或重新排序其他事项？

这组问题有意把“责任人是谁”放在问题背景之后。负责人当然重要，但如果障碍来自审批权限、依赖团队或冲突优先级，仅仅追问负责人不会自动消除原因。管理者应把个人执行问题与流程约束区分开。

3. 让阻塞升级有边界

不是所有停顿都要交给高层处理。团队能通过协作解决的事项，应留在团队层面；跨部门优先级、资源调配或政策边界问题，再交由有决策权的管理者。升级时应附上事实、影响、备选方案和所需决定，避免管理层收到一条没有上下文的“需要协调”。

管理者也要及时关闭已解决的问题：更新状态、确认下一步和责任人，并将重复出现的阻塞纳入流程复盘。若相同问题每周都要现场救火，说明组织可能需要修改规则或接口，而不是持续依赖某位管理者临时介入。

4. 指标复盘看趋势，也看分布和例外

完成数量、周期时间和阻塞时长各自回答不同问题。完成数量告诉团队某段时间交付了多少工作项；周期时间反映工作从约定起点到完成所经历的时间；阻塞时长帮助识别等待对流程的影响。它们需要统一口径，且应与事项类别一起解读。

平均值可能被少数极端事项拉高或拉低。团队可以同时查看中位数、范围或长期未完成事项，进一步了解典型工作与异常工作是否发生变化。任何指标都不应在没有背景的情况下直接变成绩效排名，尤其是事项大小和外部依赖明显不同的团队。

八、不同组织情境下的做法与取舍

1. 小团队、工作类型相对稳定

小团队通常可以从简洁流程开始，优先让工作目标、负责人、阻塞和下一步清楚可见。若成员能直接沟通，可能不需要复杂审批列或大量字段。与其花时间搭建精细指标，不如先验证大家是否使用相同的状态定义。

取舍在于，流程太简单会掩盖真实等待，流程太复杂又会让维护成为负担。可以先观察哪些状态经常引发误解，再决定是否拆分；不要因为其他团队有更多列，就认为自己的看板也必须同样复杂。

2. 中大型组织、跨部门依赖较多

当团队跨越多个部门，管理重点往往从单个团队的任务进度转向依赖关系、决策边界和资源冲突。此时需要明确谁能更新哪些信息、阻塞如何升级、跨团队工作如何交接，以及不同流程的指标是否可以比较。

组织规模变大后，看板规范确实更重要，但统一并不等于所有团队使用完全相同的流程列。可以统一状态定义、数据口径和协作规则，同时允许不同业务流程保留必要差异。否则，统一模板可能牺牲实际可用性。

3. 工作高度不确定或紧急事项多

探索性工作、客户响应或突发事件较多的团队，固定计划容易被打断。看板仍然可以帮助暴露正在处理的事项和资源占用，但必须保留变化机制：哪些事项可插入、由谁批准、插入后哪些承诺要重新评估。

如果组织把所有变化都当作例外，却从不记录例外，就无法判断计划频繁失效的原因。记录插入次数、来源和被推迟的工作，比在看板上反复标注“紧急”更有助于管理者做取舍。

4. 强监管、敏感数据或部署条件有要求

选工具时，除易用性外，还要核对权限、审计、数据存储、部署方式、集成和迁移成本。工具功能与组织要求之间的差异，可能比界面是否精致更影响长期采用。对敏感信息，先确认哪些内容能够进入系统，再设计卡片字段和访问范围。

迁移也不只是导入任务名称。需要核对历史状态如何映射、用户和权限是否对应、附件与评论是否保留、报表口径是否改变，以及旧系统在什么时间停止更新。若没有迁移演练，数据看似搬过去了，实际工作流可能已经断开。

5. 评估工具时，把适配度放在宣传语之前

对于中大型企业或百人以上组织，评估项目管理平台时，我会先核对组织规模下的权限治理、流程配置、协作与报表能力，再验证部署、安全和现有系统衔接是否符合要求。工具能够配置很多功能，不等于团队必须一次性启用所有功能。

以 PingCode 为例，若团队把它纳入候选，可以围绕私有化部署、从 Jira 平滑迁移等需求逐项做验证，并通过试点检查历史数据、权限模型、流程映射和日常使用体验。产品能力和具体方案应以当前官方资料、合同约定及技术验证为准；“国产替代”也不应被理解为对所有组织都唯一适用，最终要比较安全要求、迁移风险、团队习惯、实施成本和长期维护能力。

九、常见取舍：什么时候该简化，什么时候该加规则

1. 状态含义模糊时，优先拆分状态

若“进行中”中混有执行、等待、评审和外部依赖，且这些状态需要不同的人采取行动，可以考虑拆开。拆分的目的不是追求细节，而是让责任和下一步清晰。拆完后如果没人能解释某一列改变了什么行动，就应重新合并。

2. 维护成本高时，优先删字段

如果团队持续抱怨填报，却没有人依据字段做决策，先删除无用字段，再评估是否需要自动化。自动化可以减少重复操作，但不能替代对状态定义、数据责任和异常处理的约定。错误规则被自动化后，只会更快地产生错误信息。

3. 在制品持续增长时，先查入口和优先级

在制事项越来越多，不一定意味着团队需要更强的个人催办。先看新工作进入速度、临时插入比例、事项拆分方式和等待来源。若每个部门都能独立启动工作，却没有组织层面的排序机制，单个团队即使控制在制品，也可能不断接收新的上游需求。

4. 交付变快但质量变差时，暂停单一速度目标

周期缩短若伴随返工、投诉或验收退回增加，就不能简单判断看板“有效”。此时应回到工作定义、质量标准和交付后反馈，检查团队是否为了缩短周期而提前关闭事项。速度、质量和可预测性需要放在同一组讨论里，而不是选一个最好看的数字作为结论。

5. 管理层只需要汇总视图时，保留团队操作层

管理层可以需要跨团队视图，但不应为了汇总方便而抹平每个团队的实际流程。较好的做法是确定少量共通信息，例如目标、阶段、风险、依赖和预计完成区间，同时保留团队完成工作的操作细节。汇总视图服务于决策，不应取代团队看板。

十、下一步怎么做：先验证一个管理假设

1. 把“想做看板”改写成可检验的问题

不要从“我们需要一个看板”开始，而要写成“我们怀疑评审等待让重要工作停滞，但目前无法区分执行时间和等待时间”。这句话包含问题、原因假设和信息缺口，能帮助团队选择试点范围，也能避免把工具采购误当成管理目标。

2. 设定观察范围，不预先承诺效果

选定一类工作，记录当前状态、阻塞原因和必要的时间点，并约定复盘周期。提前说明这是为了验证流程假设，不是用来评判个人。若之后发现主要问题并非评审等待，就调整判断，而不要为了证明最初的想法而只挑有利数据。

3. 让每次复盘都产生一个明确决定

每轮复盘结束时，确认哪些规则保留、哪些规则调整、谁负责推进，以及何时回看结果。也可以明确决定暂时不改变什么，并说明理由。管理改进不要求每次都增加新制度；有时减少字段、停止无效会议或暂缓扩张范围，就是更合适的行动。

进行中管理的独特价值，不是让所有工作看起来井然有序，而是让组织有能力更早发现“为什么没有完成”，并据此做出取舍。从一条真实流程开始，先让等待和阻塞可见，再让看板上的事实进入决策；当团队发现看板确实能帮助清障，它才会从状态表变成管理工具。

下一步可以选一条近期反复延期的工作流程，回看十几项真实工作，标出它们经过的阶段、等待和返工点。用这些事实搭建最小版本看板，试运行后再决定是否增加限制、指标或系统能力。先验证问题，再扩展工具与制度，通常比先追求一张“完整看板”更稳妥。