看板进行中教程：项目经理协同管理，避坑指南

看板上“进行中”任务越多，项目未必推进得越快。更常见的情况是：任务卡片看起来都有人负责，项目经理却说不清哪些正在产出、哪些在等反馈、哪些已经卡住。看板进行中管理的关键，不是把任务从一列拖到另一列，而是让团队对“何时开始、谁来推进、遇到阻塞怎么办、什么条件算完成”形成共同约定。

一、先讲结论：进行中不是任务的收纳箱

1. 看板状态要能回答管理问题

我判断一个看板是否可用，不先看它有几列、颜色多不多，而是看项目经理能不能用它回答三个问题：当前工作实际卡在哪里？哪项阻塞会影响后续交付？下一步由谁在什么时候采取什么行动？如果看板只能展示“任务尚未完成”，它更像一张电子清单，还没有承担协同管理的作用。

“进行中”尤其容易失真，因为它经常被用来装下所有未完成任务：刚开始做的、等业务方确认的、依赖其他团队的、已经超期的，甚至是暂时没人继续处理的。它们的实际处境不同，却被压成同一个状态，项目经理看到的是数量，团队需要的却是原因和行动。

我的核心建议是：先把状态定义清楚，再决定是否增加字段或工具功能。最小可用的任务信息通常包括主责人、预期交付、当前下一步、依赖对象和更新时间。只有当团队能依靠这些信息减少反复确认，增加字段才有意义。

2. 先区分状态、阻塞和优先级

三者经常被混为一谈。状态描述任务在流程中的位置；阻塞描述工作为什么暂时无法推进；优先级描述团队应该先处理什么。一个任务可以处于“进行中”，同时被标记为“等待外部确认”，它也可能优先级很高。把三件事塞进状态名称里，容易让流程越来越复杂。

团队规模较小时，可以用标签或简短备注呈现阻塞；跨团队依赖多、协作链路长时，再考虑单独设置“等待”状态或结构化字段。不要为了看起来规范，把每一种异常都新建一列。列越多并不自动意味着信息越清晰，关键是团队能否一致地使用它们。

二、为什么“进行中”经常失真：从日常协作看问题

1. 任务开始条件不清，接单就被当成开工

项目会上有人说“我来跟”，卡片就被拖到进行中。但此时可能还没有确认交付标准、输入材料、审批人或依赖接口。几天后项目经理看到状态没变，才发现任务其实没有进入可执行阶段。卡片状态因此记录了“有人接手”，却没有记录“工作真正开始”。

我通常建议团队把“开始处理”定义成可检查的动作，而不是口头承诺。例如，负责人已确认目标和交付物，必需的输入已拿到，下一步工作可以实际开展。如果缺少关键前置条件，任务仍留在待办，或明确标注等待原因。这样可以减少虚假的进度感。

2. “进行中”里藏着等待，活跃工作量被高估

开发完成后等待验收、文案提交后等待法务确认、方案提交后等待客户反馈，这些任务都可能停留在进行中。若不标出等待对象和跟进时间，团队会误以为任务仍在持续消耗执行者的工作时间，实际却是流程中的交接或外部等待。

等待本身并不一定代表管理失败。真正的风险是等待无人负责：没有人确认对方是否收到、没有约定何时跟进、没有明确超时后的升级办法。此时项目经理应优先检查交接机制，而不是简单催执行人“再快一点”。

3. 多项工作同时启动，完成速度却没有同步提高

当团队同时开很多任务，每个人都可能有多项工作处于进行中。切换上下文、等待评审、补充信息和临时插单会挤占连续工作时间。看板上的进行中数量因此增加，但已完成的交付未必增加。项目经理若只盯着“大家都很忙”，容易错过真正的系统问题：工作启动得太多，完成得太少。

下面是一组情景模拟数据，用于说明并行工作量增加时可能出现的现象，不是行业统计，也不代表任何团队的实际结果。假设团队规模、任务难度和需求流入保持大致相同，只调整同时进行的任务上限。

4. 状态更新晚于真实工作，会议只能补账

如果成员只在周会前集中更新卡片，看板就会变成会议材料，而不是协同现场。项目经理看到的信息已经过时，风险可能在更新前就发生了。更好的做法不是要求每个人频繁填表，而是约定哪些变化必须及时更新：负责人变化、进入等待、关键交付完成、预计日期改变、出现影响里程碑的阻塞。

更新频率应与任务变化速度匹配。稳定、周期较长的工作不需要每小时更新；但关键路径上的依赖变化不能等到周会才被发现。管理规则越贴近实际决策需要，成员越容易持续维护。

三、先定义流程：让“进行中”有清晰边界

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

状态名称本身不够。团队需要能判断一项任务什么时候进入、什么时候离开。下面是一套可调整的示例流程，适用于需要交接、评审或验收的项目。实际项目不必照搬，尤其是单人工作流或高度探索型任务，可以采用更精简的状态。

“等待”是否单独作为一个状态，要看它是否影响项目决策。如果等待任务经常需要项目经理协调、升级或重新排程，单独呈现通常更容易发现积压。如果等待只是短暂且可预测的交接，使用阻塞标记和跟进日期可能更轻量。

2. 让任务卡片围绕交付，而非围绕活动

“开会讨论”“持续跟进”“继续开发”很难判断何时完成，也不容易验收。任务卡片应尽可能表达可检查的交付物，例如“提交两套方案并由业务负责人选定一套”。任务粒度不必越小越好，拆分的目的应是让负责人、依赖和验收更明确，而不是把工作切成大量无人能独立验证的碎片。

我会让团队先检查每张进行中卡片能否用一句话回答：“这项工作完成时，我能看到什么结果？”如果答案只是“做完了某些事情”，通常需要补充交付物或完成标准。对探索型工作，可以把阶段性产出定义为实验结论、风险清单或决策建议，而不是强行承诺最终答案。

3. 限制并行工作量，但不要照抄固定数字

WIP 限制，也就是对同时进行的工作设置上限，能帮助团队把注意力放在完成而非启动上。不过，上限不是越低越好，也没有适用于所有团队的统一数字。人员技能、任务周期、紧急支持、外部等待和工作类型都会影响设定。

一个务实的试行方法是：先记录一到两周当前进行中任务数、每周完成数、阻塞情况和临时插单，再选择一个团队愿意遵守的试行上限。试行期间关注两个变化：有没有更多任务真正完成？等待和切换是否减少？如果限制导致关键工作无法启动，检查是否把“活跃执行”和“等待外部反馈”混算了，或者上限确实过低。

下图仍为建议试行基准，不是统计结论。它展示可用于团队讨论的观察维度，而不是规定某个上限必然产生某种结果。

四、项目经理怎样用看板推动协同

1. 检查看板时先看异常，再看普通进度

逐人逐卡片念状态很容易把协同会议变成报数。更有效的顺序通常是先看影响交付的异常，再决定是否需要讨论普通任务：

1. 先看阻塞和超期：哪些任务无法推进，原因是否明确，是否有人负责解决？
2. 再看关键依赖：某项任务的延迟会不会影响其他团队、验收节点或里程碑？
3. 再看进行中数量：是否有任务已经启动却没有下一步，或多个任务争抢同一位关键成员？
4. 最后看近期交付：接下来一段时间哪些成果需要验收，验收人是否有时间处理？

这个顺序的价值在于把讨论从“每个人做了什么”转到“整个工作流下一步怎样更顺畅”。如果某项任务状态正常、负责人清楚、没有外部依赖，就不必占用会议大量时间复述卡片内容。

2. 阻塞卡片必须包含下一步动作

只打上“阻塞”标签，团队仍然不知道谁该行动。项目经理可以要求阻塞信息至少包含四项：阻塞原因、需要谁提供什么、当前跟进人、下次检查时间。对于影响关键里程碑的阻塞，还要明确何时升级、升级给谁，以及有哪些可替代路径。

3. 依赖管理要有“请求，确认，交付”闭环

跨团队依赖常常不是没人做，而是请求没有被明确接收。需求方以为已经提出，提供方以为还在讨论，项目经理则在截止日期临近时才发现双方理解不一致。看板上应记录依赖事项、提供方、需要的交付物、承诺时间和确认人。

当依赖尚未确认时，不应把预期日期当成承诺日期。项目经理可以把计划标为待确认，并同步评估两种情况：按期收到依赖时如何推进，未按期收到时哪些工作可以并行、哪些里程碑需要调整。这样做不是增加文书，而是把风险提前暴露给有决策权的人。

4. 会议围绕决策，不围绕看板逐项朗读

每日同步、每周项目例会或阶段评审没有唯一正确频率。对变化快、依赖密集的团队，短频沟通可能有帮助；对稳定项目，频繁开会则可能增加中断。项目经理应根据风险变化速度安排沟通，并在会上处理卡片无法自行解决的问题。

如果团队每次会议都需要重新解释卡片，说明问题可能不在会议时长，而在任务描述、状态定义或更新习惯。可以先试行两周：会前由负责人更新关键变化，会上只讨论阻塞、取舍和需决策事项；会后将决策、责任人和时间写回任务卡片。

五、常见避坑：表面上更规范，实际更难协作

1. 把所有未完成任务都塞进进行中

错误做法：只要任务没完成，就留在进行中。后果：真正执行、外部等待和暂停工作混在一起，项目经理无法识别有效工作量。调整方式：保留清晰的状态边界，为等待、阻塞或暂停增加足够的可见信息，并约定什么情况下需要重新排程。

2. 一张卡片承担多个独立交付

错误做法：把需要不同负责人、不同时间验收的事项合并成一张大卡片。后果：卡片状态只能反映其中一部分工作，延期原因也无法定位。调整方式：在交付目标、负责人或验收方式明显不同的情况下拆分任务；如果它们只是同一成果的连续步骤，可以保留一张卡片并记录检查点。

3. 只更新状态，不写下一步

“进行中”只能说明某种流程位置，不能代替行动计划。成员可能仍然忙碌，但其他人不知道他下一步需要完成什么，也不知道何时能确认结果。至少要让关键任务能看出最近一个可验证动作，例如“提交初稿”“完成联调”“等待验收反馈”。

4. 把看板当作个人绩效排行榜

如果团队担心暴露风险会被责备，成员往往会延迟标记阻塞，或者把不确定状态维持在“进行中”。这样一来，看板看着平稳，项目风险却被隐藏。项目经理应优先利用看板识别流程障碍、资源冲突和决策延迟；个人绩效判断需要结合工作难度、依赖条件和实际贡献，不能简单用卡片数量替代。

5. 为每个例外都新增状态和字段

当团队发现一种特殊情况，就立刻新增一列、一个标签或一个必填字段，看板很快会变成维护负担。新增信息前先问三个问题：它是否会影响决策？是否能够用现有字段表达？是否经常发生到值得固定管理？如果只是偶发情况，备注和临时协商可能更合适。

6. 只盯截止日期，不看等待和返工

延期日期是结果信号，不一定是原因。任务晚了，可能是估算偏差，也可能是需求反复、验收排队、依赖迟到或工作被插单打断。只要求负责人补一个新日期，可能只是把风险向后移动。复盘时应记录延期原因类别，并区分团队可控因素与外部约束。

一个有用的诊断方式是看“进入进行中以后，时间花在哪里”。下图为情景模拟的工作日构成，只是帮助团队建立分类观察框架。它不表示典型项目的真实比例。

六、一个可复用的看板案例：从“满屏进行中”到可行动

1. 情景设定：一次跨部门发布任务

假设一个团队要在既定窗口发布新功能，参与方包括产品、研发、测试、运营和业务验收。看板上有十几张卡片都显示进行中，项目经理每天私聊负责人确认进度。这个例子是为了演示诊断方法而构造的情景，并非真实企业案例，也不应被理解为普遍统计。

初步检查后发现，卡片大致混有四类情况：正在制作交付物；已提交但等业务确认；依赖测试环境修复；因插入需求而暂停。原先一列“进行中”掩盖了四种不同的管理动作。项目经理无法通过卡片判断该催执行、找验收人、协调环境，还是重新确认优先级。

2. 调整步骤：先澄清责任，再处理状态

1. 筛出影响发布窗口的任务：不先重做整个看板，而是标记关键路径和必须验收的交付物。
2. 为进行中的卡片补充主责人和下一步：协作者可以有多人，但每张关键卡片只指定一个对最终推进负责的主责人。
3. 把已交付待反馈的任务单独呈现：补充验收人、反馈期限和逾期升级方式。
4. 把环境问题记录为阻塞：写明影响范围、处理责任人和备用方案评估时间。
5. 重新确认插单优先级：由有决策权的人确认新增工作替换什么，而不是默认团队无限扩容。

这样调整之后，项目经理的工作从“逐个问谁在做什么”转成处理具体协同动作：协调验收资源、确认环境修复时点、安排替代测试路径、推动插单取舍。看板本身没有魔法，改变的是信息是否能指向责任和决策。

3. 用可观察指标验证，而非凭感觉宣布成功

试行前后可以对比同一口径的几项数据：进行中任务数量、每周完成数量、阻塞时长、待验收时间、返工次数和关键节点按期情况。不要只比较“卡片少了多少”，因为减少卡片可能是任务被合并、隐藏或未更新，并不代表交付改善。

下表给出一个示意数据框架。数值仅用于展示如何组织复盘，不是该案例的真实测量结果，更不能作为效率提升承诺。真实团队应先明确统计周期、任务范围和“完成”的定义，再填写自己的记录。

如果试行后进行中任务减少，但完成量没有变化，可能只是任务启动被推迟，也可能是团队正处理更复杂的工作。此时要检查任务组合和依赖，而不是马上判定看板调整失败。数据的价值是提出更好的问题，不是替项目经理做结论。

七、工具与流程怎么取舍：先满足协同，再考虑规模

1. 小团队优先减少维护成本

如果团队人数不多、依赖关系简单、工作周期短，轻量看板可能已经足够。优先统一状态、负责人、交付标准和阻塞记录，不必一开始建设复杂审批、自动化规则或多层级报表。工具越重，若没有稳定的使用习惯，就越容易出现“系统里一套、实际沟通一套”的双轨问题。

小团队的关键取舍是信息完整度与更新成本。可以先选少量必填信息，只在关键任务上补充风险和依赖。若一个字段无人根据它作判断，也没有人维护，就应重新评估是否需要保留。

2. 多团队协作时优先明确权限和依赖视图

当多个部门共用项目计划，问题通常不止是任务数量增加，还包括不同团队对状态、优先级和完成标准的理解不一致。此时应先梳理谁能创建任务、谁能调整优先级、谁负责跨团队依赖，以及里程碑数据从哪里汇总。

规模化管理不等于所有团队都使用完全相同的流程。可以统一少量跨团队规则，例如关键依赖的记录方式、里程碑定义、风险升级路径；团队内部的具体状态则允许在共同框架内保留差异。统一过度会让流程不贴地，完全不统一又会让汇总失去可比性。

3. 选择工具时验证场景，不要只看功能清单

以 PingCode 这类面向中大型企业及百人以上组织的项目管理平台为例，评估重点不应止于是否有看板，而要验证权限、跨团队协作、报表、部署要求、迁移路径和日常维护成本是否符合组织实际。厂商资料提及其支持私有化部署及 Jira 平滑迁移；涉及具体版本、迁移范围、历史数据完整度、插件兼容性和实施周期时，应以当前官方资料和实际验证为准。

私有化部署可能满足组织对环境、数据和内部流程的要求，但也会带来部署、升级、备份和运维责任。迁移工具可以降低重复录入成本，却不意味着原系统中的字段、权限、工作流和自动化规则会不经整理地一一对应。所谓国产替代是否合适，应通过业务场景验证，而不是只凭“能迁移”或“功能类似”下结论。

在正式选型前，我建议拿真实但已脱敏的流程做小范围验证：挑选一个跨团队项目，检查一张任务卡如何从提出走到验收；测试阻塞是否能暴露、负责人变更是否有记录、关键数据能否按管理口径汇总。至少确认导入导出、权限边界、备份恢复、升级责任和迁移验收标准，再扩大使用范围。

4. 试点和全面推广之间要有明确门槛

试点不是展示功能的演示，而是用来验证团队能否持续维护状态、管理动作是否因此改变。可设置一个短周期试点，提前写清楚验证问题：任务信息是否更及时？阻塞是否更早暴露？跨团队依赖是否更好追踪？如果只有页面更整齐，却没有减少重复询问或改善决策，说明流程或使用方式还需要调整。

下图是一个建议的试点验证路径，节点和周期可按组织情况修改，不是行业统一标准。它强调先验证工作流，再扩大覆盖面，避免一次性迁移后才发现规则不适配。

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

1. 如果团队任务少、依赖简单

先采用精简状态，例如待办、进行中、待验收、已完成，并约定进入和离开条件。每周检查一次状态定义是否被一致使用，重点观察卡片是否有负责人和下一步。此时不必追求完整的指标体系，避免管理成本超过协同收益。

取舍上，接受少量信息通过口头沟通补充，但不要把关键决定只留在聊天记录里。如果任务涉及承诺日期、验收意见或范围变更，应写回卡片或项目记录，避免后来无法还原。

2. 如果任务经常被外部依赖卡住

重点建设依赖清单和阻塞处理机制。每个依赖应有提供方、请求内容、期望日期、确认状态和升级方式。看板上可把等待状态单独展示，让团队看见工作并非都在内部执行。

取舍上，独立“等待”状态能提高可见性，但也可能让工作流变复杂。若等待种类少、持续时间短，阻塞标记和下次跟进日期可能已经够用；若等待长期影响排程和资源安排，单独状态通常更利于管理。

3. 如果临时需求频繁插入

明确插单入口和决策人，并要求每次新增高优先级工作时同步回答：它要替换什么？会影响哪个交付？是否需要额外资源？没有替换关系的“紧急事项”往往会造成隐性并行扩张，所有任务都标成高优先级，最后等于没有优先级。

取舍上，严格限制插单有助于计划稳定，但对事故响应、合规整改等真正紧急事项不够灵活。更好的规则是区分可预测需求与紧急事件，为后者设置明确授权和复盘，避免例外逐渐成为常态。

4. 如果团队规模扩大到多部门、多项目

先统一管理口径，再选工具和配置平台。定义组织级的关键字段与汇总方式，同时允许团队根据工作类型保留必要差异。对于涉及部署、数据隔离和既有系统迁移的场景，应把安全、运维、迁移验证纳入选型，而不是只比较看板界面。

取舍上，统一标准便于组合视图和管理汇总，但可能压缩团队灵活度；完全分散则更贴合局部工作，却难以比较风险和协调资源。通常值得统一的是跨团队承诺、依赖、里程碑和风险升级规则，而不是每个团队的所有操作细节。

5. 如果看板数据常常过时

先查更新为什么没有发生，而不是立刻增加提醒。可能是状态含义不清、更新步骤太多、成员不知道何时需要更新，也可能是管理者只在会议上看板。把更新要求绑定到真实事件，例如提交评审、转入等待、预计日期变化，通常比要求定时重复填报更可持续。

取舍上，自动化可以减少重复劳动，但规则复杂后也可能制造错误状态。先明确触发条件和异常处理，再考虑自动流转；涉及验收、范围变化或责任转移的关键节点，保留人工确认往往更安全。

九、结语：把“进行中”变成可行动的信息

1. 下一步从一次小复盘开始

看板进行中管理不需要从重建整个流程开始。项目经理可以先抽查十张进行中任务卡，逐张确认：是否有唯一主责人？是否写清交付物？下一步是什么？是否存在外部等待？若阻塞，谁负责跟进、何时复查？这次检查往往能迅速暴露状态定义和协作边界上的问题。

接下来选一个项目试行两周：统一“进行中”的进入条件，给阻塞任务补齐责任人与下一步，记录完成量、等待和返工等少数观察项。复盘时先看数据口径是否可靠，再判断流程是否需要调整，不要因为短期数字波动就急于推广或否定。

2. 真正有用的看板，会让问题更早出现

看板的价值不在于让所有卡片看上去整齐，而在于让团队更早发现交付风险，并知道由谁采取什么行动。如果进行中任务越来越多，先别急着催人；检查工作是否启动过量、等待是否被隐藏、依赖是否没人确认、插单是否没有取舍。状态真实、责任清楚、阻塞可处理，项目经理才有条件把协同从追进度变成解决问题。

下一步可以从团队现有看板开始，不急着换工具或增加字段：先写下一条“进入进行中的条件”，再抽查五到十张卡片，补上负责人、交付物和下一步。用一次小范围复盘确认这些信息是否真正帮助决策，然后再决定要不要扩展流程。