进行中管理方法大全：研发团队看板制度设计落地清单

研发团队看板上，“进行中”列越长，不一定代表团队做得越多；它也可能意味着任务入口没有门槛、并行工作失控，或阻塞没人负责。进行中管理的关键不是多加几个状态，也不是每天追问进度，而是明确任务何时能开始、团队同时能承接多少工作、卡住后谁来处理，以及什么条件才算真正完成。

我设计研发看板制度时，会先检查工作流有没有可执行的规则，再讨论工具怎么配置。本文提供一套从状态定义、WIP（在制工作）限制、阻塞升级，到试运行和复盘的落地方法。文中的团队案例与数字均为情景模拟，用于说明分析方式，不代表行业基准；各团队应以自己的流程数据验证。

一、先讲结论：进行中管理管的是工作流，不是卡片数量

1. 看板不是任务展示墙，而是团队的工作约定

一张卡片移入“进行中”，意味着团队已经为这项工作投入了注意力、协作能力和交付容量。若任何人都能随时把任务推进进行中，团队就很难分辨哪些工作已经承诺、哪些工作只是排队等候，也无法判断新任务插入会挤占什么。

所以制度至少要回答四个问题：什么条件满足后才能开始？团队允许多少工作同时进行？遇到阻塞时怎样记录和升级？任务满足什么条件才可以离开进行中？这四个问题没有答案时，看板即使状态很多，也只是把混乱可视化。

2. 先治理“开始”，再治理“完成”

不少团队习惯盯着任务何时完成，却很少限制任务何时开始。结果是需求持续流入，团队不断接新活，已经开始的工作却在评审、测试、依赖或决策环节排队。此时要求个人“加快进度”，往往无法消除系统中的等待。

我更倾向于先问：团队为什么同时做这么多件事？如果进行中的任务超过团队实际可处理的容量，新增任务不一定能更快交付，反而可能增加切换、沟通和等待。管理重点应从“每个人是否忙碌”转向“工作能否持续流动”。

3. 一套能执行的制度要有规则、例外和复盘

规则负责定义日常动作，例外负责处理紧急需求和外部依赖，复盘则判断规则是否有效。只写“限制进行中任务”，没有超限时的处理办法；只写“及时更新看板”，没有维护责任人；只写“发现阻塞要处理”，没有升级路径，都容易让制度停留在口号。

• 规则：进入条件、退出条件、计数口径、责任角色。
• 例外：紧急任务、生产故障、跨团队依赖和暂停工作如何处理。
• 复盘：观察等待、阻塞、老化和完成情况，决定保留或调整哪些规则。

二、背景和真实场景：为什么“任务都在做”却仍然交付不稳

1. 看板上的进行中，可能混合了不同含义

在一个常见的研发协作场景里，开发者把正在写代码的事项放进“进行中”，测试人员把等待测试环境的事项也放进去，项目负责人则把刚分派、尚未澄清需求的事项标记为进行中。表面上大家使用同一列，实际上描述的是开发、等待和计划三种不同状态。

这会造成一个重要误差：团队以为自己有很多任务正在推进，实际其中一部分只是在等待依赖，另一部分还没有开始。若不能区分“正在加工”和“等待处理”，管理者就很难判断团队是容量不足、流程卡住，还是任务准备不充分。

2. 延期常常发生在状态转换处，而不只是任务执行中

一项工作可能在开发阶段只用几天，却在需求确认、代码评审、测试环境准备或发布审批中等待更久。若团队只记录“开始时间”和“完成时间”，但不记录状态停留和阻塞原因，就会把所有延迟统称为“开发进度慢”，进而采取不匹配的措施。

例如，评审任务堆积时，单纯增加开发并行数可能让进入评审的工作更多；测试环境不稳定时，催开发提前完成也未必缩短交付周期。有效的看板需要让等待发生在哪里、由什么条件触发、下一步由谁负责，都能被看见。

3. 不同团队的“进行中”边界并不相同

维护型团队可能把缺陷响应、线上故障和小型需求放在一条工作流里；平台团队可能大量依赖其他团队提供接口、权限或测试环境；产品研发团队则可能把需求澄清、开发、评审、验证和发布分成多个阶段。状态设计不能从模板直接抄答案，应从任务实际经过的路径开始。

我建议先找最近完成的一批工作，倒推它们真正经过了哪些环节，再观察那些延期或返工的工作在哪里停留。看板应尽量对应可观察的工作阶段，而不是对应组织架构、岗位名称或会议名称。

三、常见误区：看板列更多，不代表管理更细

1. 把所有信息都变成状态列

有些团队会增加“阻塞中”“紧急”“待外部确认”“高优先级”等列，试图把每种情况都展示出来。但状态、优先级、阻塞原因和责任人回答的是不同问题，混在同一条横向流程里会造成状态膨胀：一张卡片既要表达工作阶段，又要表达风险等级和处理方式。

建议把工作阶段放在主流程，把阻塞、优先级、依赖和负责人作为卡片字段或标签。只有当某种状态确实代表一段需要独立管理的工作流程，且团队会据此采取不同动作时，才值得单独设列。

2. 设了WIP上限，却不定义计数规则

“每个状态最多五项”听起来明确，实际仍有许多问题：按主任务还是子任务计数？跨团队任务计入哪一方？阻塞任务算不算？紧急故障是否占用名额？没有统一口径时，同一个限制会被不同成员解释成不同规则，最终变成看起来有限、实际上可以绕开的数字。

WIP上限不是为了让团队少做事，而是让并行工作显性化，并推动团队优先完成已经启动的工作。若团队在上限下持续出现无法解释的积压，应该检查流程瓶颈、任务拆分和资源依赖，而不是只把限制数调大。

3. 把“站会”变成逐人汇报

如果每天的会议都按成员逐一回答“昨天做了什么、今天做什么”，看板容易沦为汇报背景板。更有效的讨论顺序通常是从最靠近完成的工作开始，再检查超限、阻塞、即将老化和优先级冲突，最后确定需要谁协助。

这种顺序把焦点放在工作而非个人表现上。它也减少了“每个人都说自己很忙，但没有人知道团队整体卡在哪里”的情况。会议的价值不在于卡片逐张朗读，而在于推动任务跨过下一个工作节点。

4. 用卡片数或个人吞吐量给人排名

卡片大小、复杂度、风险和协作成本往往不同。一个人完成十项小修复，不一定比另一个人推动一项跨团队架构改造贡献更大。如果把卡片数直接当作个人绩效，就可能诱导团队拆小任务、挑容易的工作，或避免接手难以量化的协作事项。

看板指标更适合用于观察流程和团队容量。它可以帮助团队发现等待时间变长、返工增加或工作入口失控，但不能脱离工作类型、交付质量和上下文，简单地把指标转化为个人排名。

5. 把阻塞卡片移到角落，认为问题已经处理

把卡片拖到“阻塞”列只是暴露问题的开始，不是解决问题的结果。阻塞卡片必须至少带有原因、负责人、下一步动作和复查时间。否则“阻塞中”会成为新的长期停放区，团队能看见问题，却没人知道谁该采取什么行动。

还有一种相反做法：阻塞后立即从WIP计数中剔除。这可能低估系统中的真实在制工作。究竟是否计入，应按制度明确；更重要的是，阻塞不能因为改变计数方式就从团队视野中消失。

四、专业判断逻辑：从流程边界到进入、退出和容量规则

1. 先画真实工作流，再决定状态列

梳理流程时，我会从一项工作承诺开始，跟踪它直到团队认可的完成点。每个状态都应描述可观察的工作阶段，不要把“某人正在做”当作一个完整的流程定义。团队可以把开发、评审、测试和发布拆开，也可以因工作规模或组织结构而合并。

判断一个阶段是否值得单独成为状态，可以问三个问题：它是否有明确的进入和退出条件？团队是否需要在此处采取不同的协作动作？它是否经常形成独立等待或积压？若三个问题都答不上来，新增状态可能只会增加维护负担。

2. 明确完成标准，避免“卡片完成、用户价值未交付”

研发团队的完成标准不一定等于上线，但至少要把“完成”的边界讲明白。例如代码合并、自动化测试通过、文档更新、发布审批、灰度观察，各自是不是该任务的完成条件，应按团队的交付责任确定。

若发布由另一团队负责，可以在当前看板明确交接条件和接收方，而不是把任务标成完成后就失去追踪。若发布属于本团队职责，则不能以代码提交替代完整交付。边界清楚，周期时间和完成数量才有可解释性。

3. 设定WIP限制前，先定义计数口径

团队可以按流程列、子团队或整个交付系统计数，但必须能回答“谁在什么范围内负责这个上限”。按列设置上限更容易暴露局部瓶颈；按团队整体设置则更容易约束并行承诺。两种方式并不冲突，但不要在没有说明的情况下混用。

计数口径还要处理父子任务、跨团队工作和阻塞项。比如团队可规定父任务不重复计数，只计实际流转的工作项；跨团队事项由交付责任团队和依赖方分别维护关联状态；阻塞项仍保留在原阶段并标记阻塞，避免任务从流动视图中消失。

4. 用超限动作取代机械拦截

达到WIP上限后，新工作不应自动进入进行中。团队可以先判断是否有人能协助快完成的事项，再处理阻塞、评审积压或验证队列；确有紧急任务时，指定批准人、记录原因，并说明它挤占了哪项既有工作。

例外规则的质量，不看团队是否从未使用例外，而看例外是否有记录、是否可复盘、是否逐渐变成常态。若紧急插入频繁发生，问题可能不是成员不守规则，而是入口优先级、容量规划或故障分类机制需要重新设计。

5. 看状态停留和等待原因，不只看总周期

团队可将周期时间定义为工作进入约定的开始状态到完成状态之间经过的时间，但必须统一起止点。进一步看不同阶段停留时间，可以判断时间花在开发、评审、测试还是外部等待上。若任务类型差异明显，最好分类型观察，不要把小修复和大型改造混为一组。

指标应服务于调查，不直接替代解释。周期时间变长，可能源自需求复杂度变化、依赖增多、人员调整或发布策略改变。先找出变化发生在哪个阶段，再决定改动流程、增加协作能力，还是调整任务拆分方式。

五、具体案例与数据观察：用一组模拟数据演示怎么诊断

1. 先描述团队边界，避免拿数字脱离上下文

以下例子设定为一个12人的研发小组，在同一产品域维护需求与缺陷，任务会经过开发、评审和验证。团队原先没有统一的WIP口径，成员可根据个人判断启动工作，紧急问题也常通过即时沟通插队。这里的数字是用于演示诊断过程的模拟数据，不应当作行业平均值或成效保证。

模拟团队在开始调整前，观察到进行中任务中同时存在实际开发、等待评审、等待测试环境和需求待澄清等状态。团队没有立即增加人手，而是先把状态定义和阻塞字段补齐，并约定新工作须先确认依赖、负责人和可用容量。

2. 把“任务很多”拆成可验证的原因

模拟观察的四周里，团队记录了每项工作的开始日期、完成日期、所在状态、阻塞原因和最后更新时间。初步复盘发现，影响交付的不只是开发时间：评审等待、环境准备和不清晰的任务入口也占据了可观的日历时间。

在这个例子中，团队先做了两项调整：一是把等待评审与等待验证从开发中拆出，二是规定进行中任务必须有负责人和下一步。这样做并没有让任务自动变快，但让团队能够判断工作是在执行、排队还是缺少输入。

3. 观察改进是否来自流程，而不是口径变化

调整前后对比时，最容易犯的错误是只看“进行中任务变少了”或“完成任务变多了”。如果团队把卡片拆得更细、延后登记开始时间，或把阻塞项移出看板，数字都可能改善，但实际交付未必改善。

因此，我会要求试点团队保留相同的数据定义：什么状态算开始、什么条件算完成、同类工作如何拆分、阻塞如何记录。对比时也要标注需求类型和异常事件，例如集中发布、生产故障或人员轮换，避免把短期波动包装成制度成效。

4. 从模拟数据中得出的只是下一步问题

如果评审等待缩短，但整体周期时间没有变化，下一步要检查验证或依赖环节；如果WIP下降但完成量同步下降，则要判断是否是承接量不足、任务拆分改变，或试运行过度收紧；如果阻塞数量不变但阻塞时长下降，说明暴露数量不是唯一值得关注的结果。

管理数据真正的价值，不是给制度“打分”，而是缩小调查范围。团队应从数据提出可检验的问题，再通过一到两个周期的观察确认原因。不要仅凭一张前后对比图就断言某项制度带来了确定比例的效率提升。

六、不同情况下的行动建议：先处理当前最影响流动的环节

1. 如果“进行中”长期堆积，先检查入口和容量

先抽取一段时间内进入进行中的工作，检查是否具备清楚的优先级、负责人、依赖和验收条件。若大量工作在这些条件尚未明确时就启动，应先建立轻量的准备度门槛，而不是立刻给每个状态设更低上限。

随后观察团队同时进行多少项工作，以及新任务插入时原有承诺如何处理。若紧急事项从不挤出旧工作，团队就会不断累积承诺。制度应要求说明新任务的优先级依据，以及它替代、推迟或暂停了什么。

2. 如果开发完成但评审排队，处理协作瓶颈

评审等待高时，先看评审责任是否集中在少数人、提交材料是否完整、评审批次是否过大，以及团队是否明确响应时限。可以安排轮值评审、拆分评审范围或优先处理接近完成的工作，但要避免把评审者变成新的单点瓶颈。

如果评审频繁退回，应进一步区分是代码质量、需求变化、规范不一致还是评审准备不足。缩短等待只是一个维度；如果为了赶时间降低评审质量，返工和线上风险可能上升。规则应该同时约束速度和必要的质量检查。

3. 如果任务经常等待测试或环境，明确依赖责任

等待测试环境时，卡片上应记录环境责任方、申请或排队时间、预期可用时间和替代方案。若环境由其他团队维护，需要明确跨团队的协调人和升级渠道，不能只在每日会议上重复“还在等环境”。

如果验证资源长期成为瓶颈，可以评估自动化、环境共享、测试数据准备和发布窗口安排，但先确认等待是否真的源于资源不足。需求准备不充分或测试范围不断变化，也可能造成看似相同的等待现象。

4. 如果紧急任务频繁插入，重新治理入口优先级

紧急事项需要快速响应，但“紧急”不能仅由提出者的语气决定。团队可规定紧急级别、审批角色、影响范围和回顾方式，并记录插入事项对原计划的影响。如果例外长期占据大量容量，应该把它作为工作类型纳入计划，而不是持续当作意外。

线上故障与一般需求也不一定适合共用同一套WIP规则。团队可以设置独立的应急容量或值班路径，但应定期核对实际使用情况。预留过少会反复打断计划，预留过多则可能闲置；具体做法应由历史工作量和业务风险共同决定。

5. 如果团队规模较小，优先用口头规则和简洁字段

小团队不一定需要复杂的审批层级或大量指标。先规定状态含义、责任人、阻塞原因和紧急插入方式，再用短周期复盘确认规则是否够用。制度设计的目标是减少沟通歧义，不是制造额外的行政流程。

如果团队成员经常跨多个项目工作，单项目看板可能无法解释真实容量。此时要明确任务在哪个视图计数，避免成员在多个看板分别承诺工作，却没有任何地方能看到总负荷。

七、不同情况下的取舍：规则越多，不一定越有效

1. 状态细致与维护成本之间要做取舍

状态列更多，可能让等待环节更清楚，也可能增加卡片维护负担。若成员不清楚何时移动卡片，或看板状态在实际工作中没人更新，细致程度就失去了价值。状态拆分应以能触发不同管理动作、能帮助判断瓶颈为依据。

一个实用的检验办法是观察连续几个工作周期：团队是否使用每个状态？是否能据此采取不同动作？若某列长期没有卡片，或卡片进入后没有人跟进，可考虑合并、改名或重新设计规则。

2. 紧密限制与应急弹性之间要做取舍

限制过松，团队容易不断启动新工作；限制过紧，可能让突发故障和重要机会无法及时处理。不能只追求低WIP，也不能把所有意外都变成例外。团队需要明确哪些情形可以突破常规限制、谁有批准权，以及突破后如何恢复正常秩序。

如果业务具有频繁故障响应、合规时限或客户承诺，预留应急容量可能比追求满负荷更合理。若工作稳定、需求变更少，则可以更严格地控制并行承诺。取舍依据应来自业务风险和工作结构，而不是套用统一数值。

3. 透明管理与监控感之间要做取舍

看板公开任务状态和阻塞，有助于减少信息不对称；但如果指标被用于单纯排名，成员可能隐瞒阻塞、选择容易的任务，或延迟更新状态。管理者应解释数据用于改进工作系统，而非把卡片数直接当成个人价值判断。

这并不意味着放弃责任。每张进行中任务仍应有负责人和下一步动作，只是责任的重点在于推动工作、主动暴露风险和协作解决问题，而不是要求个人对无法控制的依赖结果承担全部责任。

4. 工具配置与制度设计之间要分清先后

工具可以帮助团队设置状态、字段、权限、提醒、报表和迁移数据，但工具默认配置不等于管理制度。先讲清团队要如何工作，再评估工具是否能承载规则；若先照着软件功能创建流程，团队可能为了适配界面而改变工作定义。

例如，PingCode可作为中大型企业及百人以上组织评估项目管理能力时的一个产品实例；其产品信息提及私有化部署和 Jira 平滑迁移等能力。采购前仍应核对部署范围、迁移字段映射、历史数据处理、权限模型、集成边界和实施成本，并通过试点验证是否符合组织要求。工具适配应服务于流程，不应替代流程决策。

5. 指标完整度与团队负担之间要做取舍

刚开始试运行时，不必一次采集所有指标。先选能回答当前问题的少数信号：如果怀疑并行过多，就观察在制工作和任务老化；如果怀疑评审瓶颈，就观察评审等待和退回；如果怀疑依赖阻塞，就记录阻塞时长和原因分类。

当数据采集增加了大量手工录入，团队却没有据此做出任何调整，就要重新审查数据价值。指标只有在定义稳定、更新成本可接受、能支持具体决策时，才值得保留。

八、落地清单：用四周试运行建立可持续的看板制度

1. 第一周：还原真实工作流和问题基线

选择一个边界清楚的团队或项目试点，访谈实际执行者，跟踪近期已完成和延期的工作。先记录工作真实经过的环节、常见等待点、紧急插入来源和信息缺失类型，不要先把组织流程图当作事实。

• 选定任务范围和观察周期，约定哪些工作项纳入看板。
• 统一开始、完成和阻塞的定义。
• 记录各状态的工作数量和停留时间。
• 收集成员认为最常见的等待原因。

2. 第二周：写清状态定义和最低字段

将工作流压缩到团队能够维护的状态数量，为每个状态写明进入条件、退出条件和主要责任角色。卡片字段先保留必要信息，例如优先级、负责人、依赖、阻塞原因、下一步和目标日期；不需要为了看起来完整而强制填入无助于决策的内容。

同时写明“已完成”的条件。若某任务需要跨团队交付，记录交接对象和接收条件；若需要上线后观察，则把观察责任和退出标准说清楚，不要让任务在完成与未完成之间长期含混。

3. 第三周：试行WIP限制、超限动作和例外规则

根据基线观察提出一个便于执行的试行上限，不把它包装成通用标准。说明计数范围、阻塞项处理方式、跨团队任务归属和紧急事项批准路径。上限的目的不是让成员停工，而是让团队优先处理已经开始的工作，并及时暴露系统瓶颈。

超限时，先检查能否共同推进临近完成事项，再检查评审、测试和依赖阻塞。若决定接入紧急工作，要记录它的业务理由及对既有承诺的影响。这样后续复盘才能判断例外是合理的突发情况，还是入口规则失效。

4. 第四周：检查规则效果并只调整少数事项

试运行结束时，不要只问“大家喜不喜欢新看板”。应同时核对规则是否被使用、卡片信息是否可信、阻塞是否更早暴露、任务等待是否发生变化，以及是否增加了难以承受的维护成本。

每次复盘尽量只调整少量规则，并记录调整原因和观察期限。例如，如果评审等待仍高，先明确评审轮值和材料要求；若阻塞原因分类仍混乱，先统一分类与责任字段。一次改动太多，团队就很难知道哪项变化真正有帮助。

5. 发布前检查：制度是否足以支持明天的工作

• 每个看板状态是否有明确含义，而非只有一个名称？
• 任务进入进行中前，是否确认了优先级、负责人和关键依赖？
• 每个状态是否有可以判断的进入条件和退出条件？
• 团队是否统一WIP计数范围，并说明子任务和跨团队事项如何处理？
• 超限时是否有具体动作，而不是只提醒成员“注意控制”？
• 阻塞卡片是否有原因、责任人、下一步和复查时间？
• 紧急事项是否有分级、批准角色和对原计划影响的记录？
• 完成标准是否与团队实际交付责任一致？
• 指标是否用于发现流程问题，而不是简化为个人排名？
• 是否约定了试运行周期、复盘人和规则变更记录方式？

如果以上问题中有多项无法回答，先不要急着上线复杂报表。把最影响当前交付的两三条规则补齐，选一个团队试行，再用真实工作样本检查规则是否能被持续执行。

九、最后的判断：好的进行中管理，让工作更容易完成，而不是让人看起来更忙

1. 先看流动，再看忙碌

研发团队需要的不是一张把每个人安排得满满当当的看板，而是一套能发现承诺过量、等待过久和责任不清的工作系统。进行中任务越多，越不能只靠更频繁地催进度；团队要先确认是否有能力把已经启动的工作完成。

2. 先让规则可观察，再谈效果提升

状态定义、WIP口径、阻塞信息和完成标准，构成了可以观察和复盘的基础。没有稳定定义，前后数据就无法比较；没有责任和下一步，阻塞就无法推进；没有例外机制，规则也无法覆盖真实业务。

3. 下一步从一次小范围试运行开始

建议先选一个工作流，抽取近期任务，画出真实状态，写清进入与退出条件，再试行容量限制和阻塞升级。试点期间只保留少量能回答具体问题的指标，并记录规则变化。看板制度不是一次性写完的文件，而是团队对如何开始、如何协作、如何完成工作的持续约定。