看板进行中全流程：研发团队实操方法与一文讲清

研发看板上最容易误导人的，不是“待办”有多少，而是“进行中”看起来很忙，交付却没有变快：卡片停在开发中几天没人推动，代码写完后排队等评审，测试发现问题又退回开发。要把看板真正用起来，关键不是多画几列，而是把一项工作从进入进行中、暴露阻塞、完成验证到交付复盘的规则说清楚。

一、先讲结论：看板管理的重点是工作流，不是卡片数量

1. 看板首先要回答三个问题

我判断一张研发看板是否有用，通常先看三个问题：什么条件满足后，工作可以开始；工作开始后，团队怎样发现它正在等待或受阻；什么条件满足后，团队才承认它已经完成。三个问题都能在板面和团队规则中找到答案，看板才不只是任务清单。

“进行中”也不应被当成一个可以无限容纳工作的状态。它代表团队已经投入了时间、注意力或资源，但工作尚未交付。进行中任务越多，越需要确认其中有多少在实际推进，有多少只是等待评审、测试、外部反馈或其他团队的输入。

2. 先让工作流真实，再谈工具配置

研发团队可以从一条最小工作流开始，例如“待澄清，就绪，开发中，评审中，测试中，待发布，已完成”。这只是示例，不是标准答案。若团队没有独立的发布环节，就不必为了看起来完整而增加“待发布”；若评审经常形成瓶颈，就应让评审状态在板面上可见。

核心原则是：每一列都要对应可识别的工作状态，并且团队知道工作在什么条件下进入、在什么条件下离开。如果两列的含义说不清，或者卡片放进某列后没人知道下一步是什么，这列多半没有管理价值。

3. 用流动结果检验看板，而非用板面整齐度验收

列名统一、卡片颜色漂亮、字段齐全，都不能单独证明交付变好。更有意义的观察是：任务从开始到完成是否更可预测，阻塞是否更早暴露，返工是否更容易定位，团队是否减少了同时开工但迟迟不收尾的工作。

二、为什么“进行中”容易堆积：从真实场景看工作流断点

1. 卡片启动了，但开始条件并不完整

常见场景是需求刚被提出，研发就先把卡片拖进开发中。后来才发现验收条件不明确、接口依赖尚未确认，或者设计稿仍在修改。卡片虽然已经开始计时，实际开发却断断续续。此时问题不在工程师“推进不够快”，而在于团队把尚未准备好的工作当成了可执行工作。

因此，“就绪”状态应承担筛选作用。进入开发前，至少应确认工作目标、验收条件、关键依赖和优先级。对于探索性工作，不必假装所有细节都能提前确定，但要明确本轮探索要回答什么问题、何时回看结果。

2. 工作完成了一个环节，却没有人接住下一环节

开发完成后等待代码评审、评审后等待测试、测试后等待业务验收，这些等待都可能被藏在一个宽泛的“进行中”列里。团队成员看到卡片仍在处理中，却无法判断延迟是因为正在编码，还是已经交接出去但无人处理。

我更倾向于把“正在做”和“正在等”区分开。可以增加“评审中”“待测试”等列，也可以在同一列中使用等待标记，但必须让等待的原因、接手人和下一步动作看得见。分列还是标记不是重点，重要的是等待不再隐身。

3. 临时插单不断打断原有工作

生产故障、客户问题和紧急合规事项确实可能打断计划。真正的问题不是团队存在紧急工作，而是所有新需求都被称为紧急，且没有明确的插单规则。结果是旧任务停在进行中，新任务陆续开工，团队同时承担多项工作，却没有足够连续时间完成任何一项。

建议团队为紧急工作约定入口、决策人和容量边界。例如明确什么事件可以越过正常优先级、由谁批准、被挤出的工作如何重新排期。没有这些边界，“紧急通道”很容易变成另一条不受管理的待办队列。

4. 示例推演：看起来忙碌的板，可能只是交接排队

下面是一组用于说明诊断方法的情景模拟，不代表某个真实公司的实测数据。假设一个团队在周五检查 24 张尚未完成的卡片，其中 9 张正在开发，6 张等待评审，5 张等待测试，4 张被外部依赖阻塞。表面上有不少开发活动，进一步拆开后却能看到，超过一半的卡片并不处于主动处理环节。

面对这种情况，直接要求开发“再快一点”通常不是有效的第一步。更应先检查评审和测试的接收能力、交接是否有明确责任人，以及外部依赖是否有升级路径。工作流的问题要在工作流中寻找，而不是用个人催办来遮盖。

三、拆解常见误区：看板为什么会变成另一种汇报表

1. 误区一：列越多，管理越精细

把流程拆得很细，未必能让信息更清楚。若一张卡片每天在“开发中”“代码检查”“待合并”“合并后验证”之间切换，而团队没有基于这些状态采取不同动作，新增列只会增加维护成本。

我会用一个简单问题检验是否需要新列：当卡片进入这一列时，谁需要做什么不同的动作？如果答案只是“状态看起来更详细”，就先不要增加；如果该状态会触发专门的接手人、服务时限或阻塞升级动作，拆列才可能有意义。

2. 误区二：卡片移动了，工作就向前了

拖动卡片是记录状态变化，不等同于完成了工作。需求尚未澄清就进入开发、代码尚未可运行就标为开发完成、测试未通过却移动到已完成，都会让板面看起来流畅，实际交付却出现返工或延期。

每次状态变化都应有可观察的依据。例如，“进入评审中”意味着变更已提交并满足评审入口要求；“进入测试中”意味着测试环境和必要材料已就绪；“已完成”则要符合团队事先约定的完成定义。

3. 误区三：把“进行中”当作个人工作量证明

同时拥有很多进行中卡片，不一定代表产出高，也可能代表频繁切换、依赖过多或工作被拆得过细。看板数据首先描述工作系统，不能只凭卡片数量给个人排绩效名次。

如果团队将卡片数量直接用于个人考核，成员可能倾向于把工作拆成更多小卡片，优先挑容易完成的事项，或者迟迟不暴露阻塞。指标一旦改变行为，数字即使变漂亮，也可能离改善真实交付越来越远。

4. 误区四：设定在制品限制，就是强行限制工程师工作

在制品限制的目的不是让成员无事可做，而是让团队减少“开了很多头，却没有完成”的情况。限制可以按整条工作流设置，也可以针对容易拥堵的环节设置；应由团队根据实际容量和历史观察逐步试行，而不是直接套用一个固定数字。

当某列达到限制时，团队的默认动作应是协助推进已有工作、处理阻塞或完成交接，而不是立刻继续开启新任务。当然，线上事故或法规要求等情况可能需要例外；例外要记录原因并复核，而不是悄悄突破限制。

5. 误区五：每日同步就是逐张念卡片

如果会议只是每个人汇报“昨天做了什么、今天做什么”，看板很容易沦为汇报投影。更有效的同步方式是从右向左看板：先看接近完成但仍未交付的工作，再看最老的进行中卡片，最后讨论谁能帮助它们跨过阻塞。

同步的目标是做出行动决策，而不是复述板上已经看得到的信息。可以在会后记录责任人和下一步动作，但不必要求成员为每张卡片重复填写同一段状态说明。

四、专业判断逻辑：从一张卡片到一条可控的研发工作流

1. 先定义工作项，再决定拆分粒度

卡片太大，几天甚至几周都没有可见进展；卡片太小，成员每天都在维护和移动卡片，却难以反映有意义的交付。拆分的目标不是让每张卡都一样大，而是让团队能看出可验证的进展，并尽量降低长期不可见的风险。

我会检查一个工作项是否能清楚回答：它要解决什么问题、怎样验收、依赖什么条件、谁负责推动。若其中某一项完全无法回答，应该先补足信息，或把工作拆成“调查、决策、实现”等具有不同目标的事项。

2. 建立进入规则：准备好再拉入，不用开工替代澄清

团队可将进入开发的条件写成轻量清单，而不是新增复杂审批。比如：目标和验收条件可理解；必要设计或技术方案已具备；关键依赖已确认或有明确处理计划；当前工作量在团队容量范围内。

探索性、故障处理和日常维护工作不一定满足完全相同的条件。规则应允许合理差异，但差异要被明确命名。把所有例外都塞进普通需求流程，最后往往会导致规则无人遵守。

3. 建立退出规则：完成定义要覆盖真实交付边界

“开发完成”与“工作完成”不是同一个概念。团队需要决定评审、测试、文档、部署、业务验收分别属于哪一段流程，并在看板上明确责任交接。否则开发成员可能认为任务结束，测试或发布成员却认为它尚未达到可接手条件。

4. 把阻塞变成可管理对象

阻塞标记不能只写“卡住了”。至少应记录阻塞原因、等待对象、发现时间、当前责任人和下一步动作。外部依赖若无法由团队直接推动，也要明确谁负责升级、何时调整计划。

我建议把“阻塞”与“普通等待”区分开。普通等待可能是符合流程的排队，例如进入评审队列；阻塞则意味着当前工作无法继续，且需要额外决策或协助。两者混为一谈，团队会难以区分正常交接和真正的风险。

5. 用老化任务优先发现风险

平均周期时间容易掩盖少数长期停滞的任务。团队可以观察每张未完成卡片已经在当前工作流中停留多久，优先讨论明显偏离团队通常交付节奏的项目。这里不需要一开始就设定行业阈值，先用团队自身的历史数据建立参照更稳妥。

例如，可按工作类型分别观察周期时间分布，而不是把小型缺陷、跨团队功能和探索性任务混在一起比较。工作项差异较大时，一个总平均数可能让小任务的改善掩盖大型任务的恶化。

五、具体案例与数据观察：用情景模拟看懂如何诊断

1. 模拟团队与观察口径

以下案例是为了演示看板诊断过程而构造的情景模拟，并非真实企业案例，也不是行业基准。假设一个 12 人的产品研发小组，包含产品、研发、测试等角色，连续观察四周；将每周完成的工作项、在制品数量和卡片停留情况作为内部改进信号。

团队最初发现，卡片不断进入开发，评审和测试却没有同步接收。于是团队先不改工具，也不要求所有人加班，而是做三项调整：减少同时启动的工作、公开等待状态、规定评审和测试的接手动作。下表中的前后数值仅用于演示如何记录观察结果，不能当作通用改善承诺。

2. 先看过程变化，再看结果变化

这组示意数据里，最值得注意的不是每周完成数量从 7 项变成 8 项，而是等待时间缩短、阻塞记录更完整。若只追求完成数量，团队可能会把大任务拆得更碎，制造短期好看的数字；若能同时解释工作项口径、等待过程和返工情况，数据才更有诊断意义。

团队应在试行前固定统计口径。例如，周期时间从“进入开发”还是“进入就绪”开始计算；完成量是按卡片数还是按业务工作项数统计；被取消的需求是否纳入。口径改变时，要在图表和复盘记录中注明，否则前后数据不可直接比较。

3. 如何避免把相关变化误判成因果

如果某周完成量增加，可能来自工作项变小、需求难度下降、人员临时增加，也可能来自流程确实更顺畅。仅凭“调整前后有变化”不能证明调整就是原因。更可靠的做法是记录同期发生的变化，并在一段时间内观察相同工作类型的趋势。

对于小团队，数据的作用不是做复杂统计，而是让讨论更具体。与其争论“测试拖慢了进度”，不如查看工作项在测试队列停留多久、哪些类型最容易返工、等待通常由什么原因引起。数据不替团队做决定，但能减少凭印象互相归责。

六、指标怎么选：让看板数据服务于流程改进

1. 周期时间：回答工作从开始到完成用了多久

周期时间通常用于观察一个工作项从约定起点到完成所经过的时间。起点必须一致，例如可以选择进入开发，也可以选择进入团队承诺的工作范围；终点应与完成定义一致。不同团队的起止口径不同，数据不宜直接横向比较。

不要只看平均值。中位数、分位数以及未完成工作项的年龄，往往能补充平均值遗漏的信息。如果少数跨团队任务特别长，平均数会受其影响；若只看已经完成的卡片，又可能忽略仍在板上老化的高风险工作。

2. 吞吐量：观察团队一段时间内完成了多少工作

吞吐量可以按每周或每个迭代统计完成的工作项数量，但统计单位要尽量稳定。把一个功能拆成十张卡片后，完成数可能上升，并不代表用户获得了十倍价值。吞吐量适合观察团队自己的变化，不适合在没有工作项口径说明时作为不同团队的排名依据。

3. 在制品数量：观察尚未完成的并行工作

在制品数量反映某一时点或某个阶段里尚未完成的工作规模。数量增加时，团队可以检查是否有过多任务同时启动、是否存在优先级频繁变化、是否有交接环节容量不足。它本身不是越低越好，团队还要考虑服务承诺、工作类型和不可避免的突发事件。

4. 阻塞与老化：补上未完成工作的风险视角

完成数据天然只描述已经结束的工作，阻塞和老化数据则帮助团队看见仍未结束的风险。可统计阻塞原因类别、等待时间、超过团队预期范围的工作项数量，但要确保这些记录用于解决问题，而不是用于给个人贴标签。

如果团队刚开始使用看板，不建议一口气追踪十几种指标。先选一个流程问题，配一到两个过程指标和一个结果指标；确认数据能帮助做决策，再增加其他观察项。

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

1. 新建立看板的团队：先从最小可用流程开始

如果团队还没有统一的工作流，先画出现有工作怎样从提出走到交付，不要先挑一套完整模板。选一条常见工作类型，定义必要状态、基本进入条件和完成定义，再运行一段时间，记录哪些状态经常被跳过、哪些列长期堆积。

此阶段的取舍是：宁可流程简单但团队愿意维护，也不要一次性配置大量字段、自动化和指标。规则先能执行，才能基于实际问题迭代。

2. “进行中”积压明显的团队：先停新开，再清理流动障碍

如果板上有大量长期未完成工作，团队可以临时把注意力转向收尾：确认每张卡片是否仍然必要、是否被阻塞、下一步由谁推进。适当减少新工作进入，优先处理评审、测试或跨团队交接队列，通常比再开一轮任务更容易看清瓶颈。

取舍在于短期新功能启动速度可能下降，但团队能换来更清楚的工作状态和更少的并行切换。若存在必须处理的紧急事件，应通过约定的例外通道进入，并明确它对现有工作的影响。

3. 维护型或支持型团队：把突发工作纳入流程，而非假装可预测

维护团队的工作常包含故障、咨询和小型改动，若所有事项都被塞进同一套长周期计划，板面会持续失真。可以区分计划工作、紧急事件和服务请求，分别记录入口、响应要求和完成标准，同时保留统一的全局视图。

这类团队的取舍是，流程分类会增加少量管理成本，但能避免临时工作完全挤占计划任务却不留痕。不要为了维持计划完成率，把真实发生的突发工作排除在数据之外。

4. 跨团队依赖多的组织：管理交接，不只管理团队内部动作

跨团队交付要在卡片上标明依赖方、交付物、期望时间和升级路径。若依赖团队使用不同的流程工具，可以通过固定同步机制或接口约定维护状态，但应避免要求每个团队重复录入大量相同信息。

对于人数较多、流程复杂的组织，工具需要支撑权限、项目间视图、流程配置和数据汇总等治理需求。若正在评估 PingCode，可将其作为面向中大型企业及 100 人以上组织的项目管理平台候选之一；具体能力、授权范围与适用版本应以供应方当前资料和实际演示为准。

如果组织有数据隔离或部署环境要求，可进一步核对 PingCode 的私有化部署方案；如果团队计划从 Jira 迁移，也应先验证字段映射、附件、历史记录、权限和工作流等迁移范围。所谓“平滑迁移”不应只看任务能否导入，关键是迁移后的流程、权限和历史数据是否满足业务要求。是否属于合适的国产替代选择，应通过试点和需求清单评估，而不是仅凭一句产品定位决定。

取舍上，中大型组织需要更强的权限治理和跨项目视图，但配置自由度越高，流程标准化和维护责任越重要。工具可以承载规则，不能替团队决定谁负责接手、怎样验收以及阻塞如何升级。

5. 数据敏感或合规要求高的团队：先定部署与治理边界

选择平台前，先梳理数据分级、部署位置、账号权限、审计要求、备份恢复和外部集成边界。私有化部署也不等于所有合规要求自动满足，仍需核对运维责任、升级策略、访问控制和故障恢复安排。

取舍是部署与治理方案可能增加采购、实施和运维成本，但能让风险边界更清楚。应以真实需求清单做验证，避免为了“功能齐全”采购超出团队能力范围的方案。

八、从试行到稳定运行：用四步把规则变成日常动作

1. 第一步：限定试点范围，建立当前状态基线

先选一个团队、一类工作或一条相对完整的交付流试行。记录当前主要状态、常见等待点、在制品数量和完成定义，不需要一开始追求精确到小数点的指标。基线的目的是让团队知道之后比较的是什么。

2. 第二步：约定卡片信息和状态规则

确定卡片最少需要的信息，例如标题、负责人、验收条件、优先级、依赖和当前下一步。每增加一个字段，都应能说明它帮助谁做什么决策；没人使用的字段要及时删掉，避免看板变成表单仓库。

3. 第三步：每天处理流动问题，每周复核系统问题

日常同步聚焦老化工作、阻塞和需要协助的交接；周期复盘则讨论队列在哪些环节形成、规则是否造成无效等待、插单是否挤压计划工作。把当周能执行的小改动写清负责人和检查时间，不要把复盘变成无行动的讨论会。

4. 第四步：小步调整，并确认没有把问题转移到别处

例如，评审等待缩短后，还要看评审质量、返工率和测试队列是否恶化；减少在制品后，也要检查关键工作是否被长期留在待办。局部指标变好，有时只是瓶颈转移，不等于端到端交付整体改善。

可将试行节奏设置为团队能够稳定复盘的周期，但不必承诺固定几周就一定提升效率。每次调整只改变少数规则，保留观察记录，团队才更容易判断哪些改变有帮助、哪些只增加了流程负担。

九、总结：看板不是把工作摆出来，而是让工作更容易完成

研发看板的价值不在于状态列有多少，也不在于每个人每天更新了几次。它真正解决的是：团队能否看见工作正在什么环节、为何等待、谁来接手，以及什么条件下可以对外承诺完成。

如果你的团队正准备改造看板，下一步不必先换工具或重做全部流程。先抽出一周，挑选一类典型工作，盘点进入进行中的条件、最常见的等待点和真实完成定义；然后选一个最影响交付的断点，试着让它可见、可跟进、可复盘。

我最看重的判断标准是：看板是否帮助团队更早发现“工作为什么没有完成”，而不是更熟练地解释“工作为什么还在进行中”。把注意力从开工数量转向完成流动，从个人催办转向系统改进，看板才会从一块状态展示板，变成研发团队持续交付和改进的工作机制。