看板进行中教程：研发团队效率提升，避坑指南

看板进行中教程：研发团队效率提升，避坑指南

研发看板上“进行中”任务越多，团队不一定越忙，交付也不一定越快。一个常见场景是：开发、代码评审、测试、等待依赖都挤在同一列，卡片看起来不断增加，成员却说不清哪些工作正在推进、哪些只是排队。要让看板真正帮助团队提效，关键不是多加几列，而是定义清楚“进行中”的含义、任务如何流转，以及拥堵时团队具体采取什么行动。

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

1. 看板的重点是看清工作怎么流动

我判断一块研发看板是否有用，通常先不看颜色、图标和列数，而是问三个问题：每张卡片当前处于什么工作阶段？它为什么还停在这里？团队下一步能做什么？如果这三个问题答不上来，看板即使填得很满，也可能只是把原来的口头汇报换成了卡片。

“进行中”应该描述工作所处的流程状态，而不是成员是否忙碌。开发人员正在处理一项任务，不代表这项任务已经进入团队约定的开发阶段；一张卡片显示“进行中”，也不表示它此刻有人在持续推进。状态要对协作有用，就必须能被不同成员按同一规则理解。

2. 效率提升来自瓶颈更早暴露，而不是卡片移动更快

看板不是鼓励团队把卡片尽可能往右拖。真正值得关注的是：工作是否在等待、等待发生在哪一段、等待是否可以被消除。若任务从开发移到了评审，却在评审区停了很久，只看“开发完成数”容易产生进展良好的错觉；把评审等待明确显示出来，团队才能决定是否需要集中处理评审积压。

因此，搭建看板时要同时设计状态、流转规则和异常处理方式。只有状态而没有规则，大家会各自解释；只有规则而没有日常检查，问题仍然会藏在卡片后面；只有检查而没有行动，会议就会变成逐人报进度。

下面的数量是为了说明看板拥堵可能出现在哪里而设定的情景模拟，不代表行业基准。它展示的重点不是某个团队应该达到的固定数值，而是工作停留时间和任务堆积往往需要放在一起观察。

二、先还原真实场景：研发任务为何会堆在进行中

1. 状态名称往往跟不上团队实际流程

团队刚开始使用看板时，常见做法是直接采用“待办、进行中、已完成”三列。这个简化流程对任务量少、协作简单的团队未必有问题；但当开发、代码评审、测试、发布由不同角色接力完成，“进行中”就可能把多个性质不同的状态塞在一起。

同一张“进行中”卡片，可能代表工程师正在写代码，也可能代表代码已经写完、等待评审；还可能是评审通过后等待测试环境，或测试发现问题后返回修改。这些情况需要的协作动作完全不同。若不拆开或不增加明确标记，负责人就很难判断团队是缺少开发容量，还是被评审、测试或外部依赖拖住。

2. 任务卡片显示的是承诺，不是工作日志

另一类常见问题是状态只在例会前更新。卡片上的“进行中”可能早已不符合实际，但因为没人明确负责更新，成员仍然把它当作周报标签。此时，管理者看到的是滞后的记录，团队讨论也容易围绕“谁没更新”展开，而不是处理真正的交付障碍。

我更建议把更新规则设计得足够轻：状态变化时更新；发现阻塞时补充原因和下一步动作；每日检查时只优先核对停滞、阻塞和即将触及限制的卡片。不要要求成员为了“看起来完整”填写一长串没人会使用的字段。

3. 多任务并行会把等待包装成进度

假设一名工程师同时接手四项任务，三项都已经“开工”，但每项每天只得到一小段注意力。看板上可能出现三张进行中卡片，实际却没有任何一项稳定接近完成。任务切换、上下文恢复、临时求助和依赖等待都会占用时间，但这些成本通常不会直接显示在卡片上。

这里需要谨慎：并行任务多并不自动证明团队低效，紧急支持、探索性工作和跨团队依赖都有合理存在的情况。真正的判断依据是任务是否持续流动、并行数量是否造成可观察的等待，以及团队有没有能力说明每项工作的下一步。

三、常见误区：看板越复杂，不代表管理越成熟

1. 把所有工作都放进一列，误以为这样更简单

列少不一定有问题，问题是不同状态混在一起后，团队无法采取不同动作。如果评审等待和开发中的任务都需要同一类处理，合并列可能更省维护成本；但如果评审积压需要安排评审人、测试等待需要协调环境，把它们混在一起就会损失决策信息。

判断是否拆列，不要先争论“行业标准有几列”，而要问：拆开以后，团队是否会因此采取不同动作？如果答案是否定的，先不拆；如果答案是肯定的，再考虑把这个阶段独立显示。

2. 把列拆得过细，卡片更新反而成了负担

从需求澄清到部署上线，每一步都可以独立建列，但列数增加会带来维护成本。成员需要判断任务是否真的发生状态变化，也要理解每列的边界。若状态之间几乎没有区别，卡片就会频繁跳转，数据看似精细，团队却没有获得新的行动依据。

对多数团队而言，状态粒度应由管理动作决定，而不是由流程图能画出多少步骤决定。一个阶段是否值得单独成列，至少要满足以下条件之一：它有独立负责人；它存在需要单独处理的排队；它有不同的完成标准；或团队经常需要针对该阶段进行决策。

3. 把 WIP 限制当成个人上限或惩罚线

WIP（在制品）限制的作用，是让团队看见同时进行的工作过多时发生了什么，促使团队协作处理拥堵。它不是简单限制某个成员“最多只能做几件事”，更不应该成为追责的单一依据。若超限后管理者只要求大家清卡片，卡片可能被匆忙改状态，真实问题反而更难发现。

我建议先从团队层面的阶段限制开始试验，并把超限处理写成协作规则：暂停接新任务、优先帮助最接近完成的工作、安排评审或测试支援，必要时联系外部依赖方。具体数字要通过团队容量与近期任务观察调整，不存在一个适用于所有研发团队的最佳值。

4. 用单一指标给个人排名

周期时间、吞吐量、在制品数量都能提供线索，但它们不适合脱离上下文直接评价个人。任务规模、风险、依赖数量、紧急插单和工作类型不同，简单按完成卡片数排名会鼓励拆分行为，甚至让成员避开复杂任务。

指标更适合回答流程问题：哪一段等待变长了？某类任务是否总在特定阶段受阻？团队接收新工作是否超过完成能力？如果指标开始被用于个人奖惩，成员可能会优先优化数字，而不是优化端到端交付。

四、专业判断逻辑：先定规则，再定列和数字

1. 从近期真实任务中提取流程，而不是从模板开始

准备改造看板时，我会先抽取近期已完成和仍在进行的任务，查看它们实际经历了哪些环节。不要只问团队“通常怎么做”，还要核对任务记录、评审过程、测试反馈和发布依赖。人们描述的流程往往是理想路径，卡片里暴露出来的才是实际路径。

建议先抽样十到二十项近期任务作为讨论材料。这个数量只是便于工作坊讨论的示例，不是统计学上的固定样本要求。对每项任务记录实际阶段、进入时间、离开时间、等待原因和交接对象，再识别反复出现的停滞点。

2. 用“谁能采取什么动作”决定是否拆分状态

我常用一个简单判断：如果卡片从当前阶段进入下一阶段，团队需要不同的人、不同的完成条件或不同的处理策略，就有理由考虑拆分；如果只是换了一个称呼，却没人因此采取不同动作，拆分的价值就有限。

例如，“开发中”与“代码评审中”可能由不同角色负责，团队也可能需要安排评审容量，因此拆成两个状态有助于发现交接等待。反过来，如果小团队的开发者和评审者经常是同一批人，且拆列没有带来新的协作动作，保持较粗粒度并用卡片标签记录细节，可能更合适。

3. 设定进入、离开条件，减少状态解释偏差

每个关键状态都应写清楚进入条件和离开条件。以“开发中”为例，进入前可以确认需求范围、负责人和验收标准已经明确；离开前则要确认代码已提交、必要的自动化检查已通过，并且满足团队约定的交接条件。具体条件应与团队工程实践一致，不要把建议清单机械复制成强制流程。

下面是一个可以按团队实际情况修改的示例。重点是把容易争议的边界写出来，而不是追求流程文档篇幅。

4. 用统一口径理解周期时间和吞吐量

周期时间通常指一项工作从团队约定的起点到终点所经过的时间；吞吐量则是某个统计周期内完成的工作项数量。团队必须先说清起点、终点、工作项范围和统计周期，否则不同阶段的数据不可直接比较。

在流程相对稳定的情况下，平均在制品数量、吞吐量和平均周期时间之间可以帮助团队理解工作流的关系。一个常用的关系表达是：平均在制品数量约等于平均吞吐量乘以平均周期时间，前提是统计边界、时间单位和流程口径一致。它不能被当成对单个任务的准确预测，也不能代替团队检查异常波动。

如果团队刚开始量化，我建议先选一项最关心的流程问题，再挑少量指标。例如，若问题是“任务总在评审前后等待”，先观察评审阶段的在制品数量和停留时间，而不是一次性建立十几个仪表盘。

五、示例推演：一个“进行中”堆积团队如何调整

1. 先描述场景，不把模拟数据包装成行业结论

下面用一个虚构的研发团队做推演，所有数字均为情景模拟，不代表真实企业案例或普遍效果。团队有八名研发成员，过去一个月看板上长期有十多项任务处于“进行中”，成员反馈任务并不少，但版本交付节奏仍然不稳定。

复核二十项近期任务后，团队发现：部分卡片处于开发，部分已经提交评审但没有明确评审人，还有几项在等待测试环境；另有几张卡片超过一周没有更新，评论里写着“等接口”“待确认”，却没有责任人和复查时间。这些问题不是通过再加一列“处理中”就能解决的。

2. 先分类卡片，再讨论流程瓶颈

团队没有马上规定每个人只能接手一项工作，而是把现有卡片按实际状态重新归类：准备中、开发中、评审中、测试中、阻塞。阻塞不是新的业务阶段，而是覆盖在卡片上的异常标记；卡片仍需保留它原本所处的阶段，方便团队判断问题发生在哪里。

接下来，团队为阻塞卡片补充三个字段：阻塞原因、下一步负责人、下次复查时间。对于“等待外部确认”，负责人不是简单写“产品”，而是写明需要谁联系谁、要得到什么确认。这样一来，阻塞信息从模糊备注变成可以跟进的行动。

3. 两周观察以发现问题为目标，而不是证明方案成功

团队尝试在评审阶段设置试验性限制，并在每日短会中优先处理最接近完成的任务。两周后，不先宣称效率提升，而是核对：评审等待是否减少？阻塞是否更快被发现？是否有任务被迫滞留在列外？成员更新状态花费的时间有没有明显增加？若结果不理想，下一步是修订规则，而不是把试验当成失败或强行推广。

示例数据表中的前后变化是为了展示应如何设计观察口径。真实团队使用时，应保留任务范围、统计区间、样本数量和异常事件说明，避免把短周期波动说成长期改善。

4. 复盘时把结果拆成事实、解释和下一步

复盘不要把“评审卡片少了”直接等同于“交付更快”。先确认发生了什么，再讨论可能原因，最后决定是否继续试验。比如，评审积压减少可能是评审安排改善，也可能是新任务进入减少；周期时间没有明显变化，也可能是测试环境成为新的瓶颈。

较稳妥的复盘记录包含三部分：数据事实、团队解释、下一轮行动。若解释存在多种可能，先做一个可验证的小调整。例如只改变评审责任分配，观察相同口径下的评审停留时间，而不是同时调整列名、WIP限制、任务拆分方式和会议流程。

六、不同团队情况的行动建议：从最影响交付的问题开始

1. 团队刚开始用看板：先采用少量状态和明确规则

新团队不必一开始就建复杂工作流。可以从“准备就绪、进行中、评审或验证、完成”起步，按实际情况合并或拆分。更重要的是让全员知道每列代表什么、谁负责更新、任务何时可以进入下一列。

开始后的头两周，优先检查是否出现状态争议、卡片漏更新、阻塞无负责人等问题。若大家仍然无法一致判断卡片处于哪个状态，先澄清定义，不急着讨论仪表盘和绩效指标。

2. 团队任务总堆在“进行中”：先找等待发生的位置

把“进行中”里的卡片按开发、评审、测试、外部依赖等实际情况分类，观察哪一类最常停留。接着问：任务是否已具备进入条件？等待是否有人负责推进？团队能否减少新任务进入，优先完成接近交付的工作？不要仅凭卡片总数决定限制值。

如果开发中任务多但大部分每天都有进展，问题可能不是并行过多；如果很多任务都等同一个评审人或测试环境，重点应是消除共享资源瓶颈，而不是要求开发人员“更快完成”。

3. 团队跨角色交接频繁：考虑显式展示关键等待环节

当开发、评审、测试和发布由不同角色负责，且交接等待影响明显时，把关键环节拆开通常更有助于协作。每个环节应对应可执行动作，例如评审积压达到团队约定时，调整评审排班或暂停承接新工作；测试环境不可用时，明确协调人和复查时间。

但若拆列导致成员频繁维护、状态难以判断，团队可以先用标签、泳道或阻塞标记表达细节。选择什么视觉方式并非重点，关键是团队能否识别问题并采取一致行动。

4. 紧急任务多：把例外流程说清楚

研发团队通常会遇到线上问题、合规要求或关键客户事项。看板不需要假装这些工作不存在，而应明确紧急任务如何进入、谁能调整优先级、原有工作怎样处理，以及紧急结束后如何恢复正常流程。

如果所有任务都被标成紧急，优先级就失去了区分能力。团队可以定期复核紧急任务的来源和数量，判断它们是合理例外、计划不足，还是某类质量问题反复造成的返工。

5. 任务大小差异明显：分层看待工作类型

一个小型缺陷和一个跨模块改造的周期时间不能简单放在同一组里比较。团队可以按工作类型分别观察，或先把任务拆成可验收、可交接的小单元。拆分的目的不是让卡片数增加，而是让任务在一段时间内有清晰的完成边界。

探索性研究、基础设施改造和常规功能开发也可能需要不同的流转方式。若工作类型差异很大，可以用泳道区分，但不要因此建立多个互相矛盾的完成口径。

七、取舍与工具选择：先定流程，再看功能是否匹配

1. 简单团队与复杂组织需要不同程度的治理

小团队、任务类型相近、交接较少时，一块轻量看板可能足够。增加审批字段、复杂权限和多个工作流，反而会让协作变慢。相反，在多部门、多产品线、权限隔离和审计要求较强的组织里，过于简单的工具可能难以支撑流程一致性、跨团队依赖和统计口径治理。

选工具时，我会先确认团队需要管理的工作流边界，再评估工具能否支持状态配置、权限管理、依赖关联、历史记录、数据导出和组织级管理。工具功能再丰富，如果团队没有明确状态定义，也不会自动生成有效的协作机制。

2. 100人以上组织要额外检查治理和迁移成本

当使用者超过百人，问题往往不只是“能不能拖动卡片”，还包括不同团队的工作流如何保持适度一致、权限如何管理、数据如何汇总，以及工具变更是否影响日常交付。试点时应覆盖不同角色和不同流程，而不只找一支熟悉工具的团队做演示。

例如，PingCode主要服务中大型企业及100人以上组织。若团队正在评估这类平台，可以把需求拆成三类验证：研发工作流是否可配置；组织级权限、协作和汇总能力是否满足治理要求；私有化部署、数据管理和迁移计划是否符合企业约束。产品能力可作为评估起点，最终仍应以试点环境和合同范围确认。

对于已有 Jira 使用基础、正在评估迁移的团队，PingCode支持 Jira 平滑迁移这一能力可以纳入候选验证，但“平滑”不等于无需准备。应先盘点项目、字段、状态、权限、历史记录、自动化规则和集成，再用代表性项目做映射测试，明确哪些内容可直接迁移、哪些需要改造、哪些必须人工核对。国产替代也不是只比较界面，而要评估数据、部署、服务支持、生态集成和长期运维。

3. 私有化部署、平滑迁移与功能丰富度都要看具体条件

私有化部署可能更符合组织对数据边界、网络环境或运维治理的要求，但也意味着企业需要明确部署资源、升级责任、备份恢复、监控和支持机制。不要只把“可私有化”视为采购勾选项，还要问清版本升级由谁执行、故障如何处理、数据如何备份和恢复。

迁移项目也应先定义验收标准。比如关键项目能否保留所需字段和状态映射，权限能否按预期配置，历史数据是否满足查询要求，常用报表是否能复现。工具更换后的首要目标不是把所有旧配置一字不差搬过去，而是保留业务连续性，同时去掉已经无人使用的流程负担。

八、上线前检查与结尾：让看板成为团队的行动界面

1. 上线前用一张卡片走完流程

不要只在会议室里确认流程图。挑一张真实任务，从准备、开发、评审、测试到完成完整走一遍，观察卡片在每次交接时是否清楚、状态是否容易判断、阻塞是否能被标记。如果团队在某个节点争论“到底算不算完成”，就先修订该状态的条件。

• 每一列的含义是否能被团队成员用同一套话解释？
• 任务进入和离开“进行中”是否有可检查的条件？
• 评审、测试或外部等待是否能被单独识别？
• 阻塞卡片是否记录了原因、负责人和复查时间？
• 出现拥堵时，团队是否知道要暂停什么、优先协助什么？
• 状态更新是否足够轻量，成员能否在实际工作发生时维护？
• 使用的周期时间、吞吐量等数据是否有统一口径？

2. 先试运行，再调整，不要一次性重做所有流程

建议先选择一个团队和一条相对稳定的工作流，试运行两到四周。这个时间范围是便于安排复盘的实践建议，不是适用于所有组织的硬性标准。试运行期间只重点观察少数问题，例如评审等待、阻塞可见性或状态更新成本，并记录任务范围、异常情况和规则变更。

如果发现看板有效，逐步推广时也要保留团队差异；如果发现流程维护负担过重，就合并价值不大的状态或简化字段。不要因为已经投入配置成本，就坚持使用没有帮助的列和指标。

3. 最后的判断标准不是卡片有多漂亮

一块成熟的看板，不一定有最多的列、最密的指标或最复杂的自动化。它应该让团队更快发现工作停在哪里，更清楚谁能推动下一步，也能在复盘中区分真实改善与短期波动。看板“进行中”的价值，不在于证明每个人都很忙，而在于让等待、依赖和优先级冲突更早变得可见。

下一步可以先抽查十张近期任务卡：逐张确认它们当前的真实阶段、停留原因和下一步动作。若团队无法一致回答，就从这些卡片暴露出来的问题开始调整状态定义，再用一段短周期验证改动。与其先追求一套看起来完美的看板，不如先让一张卡片的流转变得准确、透明、可行动。