看板如何做好进行中？研发团队协同管理与操作步骤

研发看板里，“进行中”列最容易显得忙，也最容易失真：卡片很多，团队却说不清哪些工作正在推进、哪些只是等待评审或环境、哪些已经数天没有下一步。要把“进行中”管好，关键不是增加状态列，而是约定任务何时进入、谁负责推进、阻塞如何暴露、何时才算离开这一列。下面我会从规则、任务粒度、在制品限制和日常协作几个层面，拆解一套可以先小范围试行的做法。

一、先给结论：把“进行中”当作一项团队约定

1. “进行中”不是任务的装饰标签

我判断一个研发看板是否可用，通常不会先数状态列有多少，而会看一张卡片进入“进行中”后，团队是否知道它代表什么。若有人认为“分配给我了”就算开始，有人认为“代码已经写了”才算开始，那么同一列里的卡片实际处在不同阶段，管理者看到的数量就难以解释。

因此，“进行中”应当是一条可执行的工作规则，至少说明三件事：任务满足什么条件才能进入；进入后由谁负责下一步；完成或等待时要怎样流转。规则越清楚，卡片状态越能支持团队协作，而不是变成每个人各自理解的进度标签。

2. 管理目标是让工作流动，而不是把列填满

我不建议把“进行中卡片越少越好”当成目标。研发工作存在评审、测试、跨团队依赖和突发故障，不同任务的风险与协作路径也不一样。真正需要关注的是：工作是否有明确的推进动作，阻塞是否被看见，团队是否能把已开始的工作完成并交付。

所以，衡量“进行中”管理是否有效，要同时观察任务停留时间、阻塞原因、完成情况和团队协作成本。仅凭某一天列里的卡片数量，既不能判断效率，也不适合直接评价个人表现。

3. 先统一状态语义，再谈工具配置

团队可以先用一句话定义“进行中”：工作项已满足开始条件，负责人正在执行可验证的下一步，并且当前状态与实际工作一致。这句话不是唯一标准，但它能作为讨论起点。每个团队再根据开发、评审、测试和发布流程，把具体进入条件与退出条件写清楚。

看板工具可以帮助展示状态、责任人和阻塞信息，却不能替团队决定什么叫“开始”。先讨论协作规则，再配置列、字段和提醒，通常比先搭一张复杂看板、之后再要求团队适应更稳妥。

二、为什么“进行中”会失真：常见场景与误区

1. 任务被分配后立即进入“进行中”

任务分给了工程师，不代表工程师已经开始处理。需求还未澄清、依赖服务尚未开放、测试数据没有准备好时，卡片即使显示为“进行中”，工作也可能没有可执行的下一步。时间一久，团队看到的是“有人负责”，而不是“工作正在流动”。

我会把“负责人已确认”和“工作已开始”分开看待。前者说明责任归属，后者说明执行状态。如果工具流程简单，可以保留“待办”和“进行中”两列，但约定只有实际开始处理才移动卡片；如果等待较常见，再考虑用阻塞标记或等待状态表达原因。

2. 一张卡片装进了多个阶段

“完成某模块改造”可能同时包含需求澄清、接口设计、编码、联调、测试和发布。只要其中一个环节卡住，整张卡片就像没有变化；其他协作者也很难判断问题发生在哪里。任务过大时，列上的一张卡不再代表一个容易观察的工作单元。

拆分的目的不是把工作切成很多微小步骤，而是让团队能识别交付结果、责任交接和依赖关系。若卡片拆得过细，更新状态本身会成为负担；若拆得过粗，风险和等待会被藏在卡片内部。合适的粒度，应当让团队在一次协作检查中能回答“下一步是什么”。

3. 等待被误当成执行

开发完成后等待代码评审、测试环境或外部团队确认，任务可能仍停留在“进行中”。这并不一定是错误：有些团队会把整个工作流阶段都放在同一列。但如果等待时间较长，且无法区分主动执行与外部等待，团队就很难判断瓶颈是在开发能力、评审容量还是依赖响应。

我的建议不是遇到等待就新增一列，而是先判断等待是否频繁、是否影响决策。如果等待只是偶发，用阻塞标记、原因和跟进日期可能足够；如果它构成稳定且重要的流程阶段，再考虑单独表达。状态列越多，信息越细，但维护成本也越高。

4. 把“多开任务”误认为“推进得快”

成员同时打开很多任务，短时间内看起来每张卡都有人处理，但注意力切换、依赖协调和交接都会增加。尤其是任务未完成就持续接收新工作时，团队可能不断产生“开始”的记录，却迟迟没有完成闭环。

这不意味着所有并行工作都应该禁止。线上故障、紧急安全修复和有严格时限的事项，可能需要打断原计划。关键是把这类例外显式化，并约定它如何影响当前工作，而不是让所有工作都以“紧急”为由进入执行列。

三、把规则写到卡片上：任务准入、退出和阻塞处理

1. 设定进入“进行中”的准入条件

我建议先选择少数几条真正影响开工的条件，不要把流程变成审批清单。一个可讨论的起点是：任务目标和验收方式足够清楚；主要负责人已确认；关键依赖可用，或依赖风险已被明确接受；团队确实开始执行某个具体动作。

不同任务类型可以有不同准入条件。需求开发可能需要验收口径和接口约定；线上问题可能先要完成影响范围判断和临时处置；技术债任务则可能要说明要降低的风险或维护成本。把所有工作硬套同一份字段清单，反而会让大家为了填字段而填字段。

2. 写清退出条件，不让“差不多完成”留在列里

任务何时离开“进行中”，取决于团队如何定义完成。对于开发环节，代码提交可能是退出条件；对于端到端交付，则可能还要通过评审、测试或部署验证。一个看板可以按团队需要表示整体工作流，也可以只展示开发环节，但必须让列名和退出规则相互一致。

我会避免用“开发完成”这种容易产生歧义的描述，改成可检查的结果，例如“变更已提交并通过约定的代码评审”或“验收项已验证，交接信息已补齐”。这不是要求每个任务都写长篇说明，而是确保交接时接手人知道什么已完成、什么仍待处理。

3. 让阻塞信息能触发行动

只给卡片加一个红色标记，未必能解决阻塞。有效的阻塞信息至少应回答：卡在哪里、影响什么、由谁跟进、下一次何时检查。若依赖方尚未回应，跟进动作可以是发起确认；若环境缺失，可以是指定负责补齐环境的人，而不是把卡片无限期留在原处。

阻塞原因可以用团队语言分类，例如需求待澄清、外部依赖、评审等待、环境问题、资源冲突。分类不必过多；先让团队能区分“谁可以推动”和“需要升级处理”的情况，比建立一套精细但无人维护的分类体系更重要。

4. 责任归属与多人协作要同时说清

复杂研发任务往往由多人协作，责任人不等于唯一执行者。我的做法是给每张工作项明确一个主要跟进责任人，再通过协作者、子任务或评论记录其他参与者。这样既保留协作空间，也避免出现“大家都参与，所以没人确认下一步”的情况。

如果任务转交给评审、测试或另一个团队，卡片的负责人是否更换，应由团队工作流决定。无论采用哪种方式，都要明确接手确认机制。单纯把名字改掉，却没有通知和确认，可能让卡片看似已交接，实际上仍无人接手。

四、任务粒度与 WIP：控制并行，不照搬固定数字

1. 用“能否看见下一步”判断任务是否过大

我不会仅凭任务预计工时判断卡片是否过大。更实用的问题是：团队在日常协作中能否说明它现在在哪个环节、接下来交付什么、谁需要参与。如果一个工作项只能用“还在做”解释，而且几次检查都没有可验证变化，就值得检查是否需要拆分或暴露隐藏依赖。

拆分方式可以按可交付结果、系统边界、风险验证或协作交接来做。例如，一个新功能可以先拆成接口契约确认、关键路径实现、异常场景验证等工作项，但前提是这些项能形成可独立观察的结果。若拆分后每张卡都只是“做一小段代码”，没有明确价值或验收点，拆分就可能过头。

2. WIP 限制是团队调节器，不是个人配额

在制品限制（WIP）用于约束某个流程环节同时承载的工作数量，帮助团队发现“开始太多、完成太少”的状况。它不应被理解为每个人最多做几张卡，也不应简单变成管理者控制个人工作量的硬指标。

我通常建议团队先观察实际流动，再讨论是否设置限制。看板上哪些环节经常积压？哪些卡片在等待？评审或测试的可用容量是否与开发输入相匹配？如果瓶颈在评审，单纯限制开发列并不能自动解决评审容量不足，但可以提醒团队减少新任务进入、优先协助完成已有工作。

3. 通过试行数据调整，而不是套用“标准配额”

WIP 数值没有脱离上下文的通用答案。团队规模、任务类型、轮值安排、依赖数量和工作流设计都会影响合适范围。为了避免把猜测写成规则，可以先做短周期试行：记录超限频率、任务停留时间、阻塞情况和完成量，再讨论限制值是否让协作更顺畅。

若限制值长期被突破，先问原因，而不是先责备成员。可能是紧急事项例外没有定义，也可能是任务拆分不合理、工作入口失控，或限制值不符合真实容量。限制值的意义是促使团队作出选择：先完成已开始的工作，还是明确接受新增工作的代价。

4. 超出 WIP 限制时，先处理存量再决定是否接新任务

超限不应只触发一个警告，而应引出具体动作。团队可以优先检查是否有卡片已经完成却未移动、是否有人能帮助解除阻塞、是否可以完成评审或测试交接、是否有低优先级工作应暂停。若确实要插入紧急事项，要记录它打断了什么，以及原有任务如何恢复。

一条实用原则是：新增工作进入之前，先说明它的紧急性和代价；已有工作暂停之前，先明确恢复责任。这样能减少“大家都在做新任务，旧任务却无人收尾”的隐性积压。

五、日常协作怎么做：从卡片更新转向流动检查

1. 团队检查优先看“工作”，不是逐人报流水账

站会或协作检查时，可以从最接近完成、最久未更新或存在阻塞的工作项开始。讨论的问题是：这张卡下一步是什么？是否需要协作者？有没有等待依赖？是否应该暂停新工作？这样的顺序把注意力放在任务流动上，而不是让每个人轮流念一遍昨天做了什么。

如果团队规模较大，可以按服务、子团队或工作流分组检查。重要的是会议中出现的决定要回到卡片上，例如责任人、下一步和复查时间。否则会议里解决了问题，几天后看板仍保留旧状态，大家会再次讨论同一件事。

2. 约定关键状态更新时点

不需要每隔几小时更新一次卡片，但关键变化发生时应及时记录：工作实际开始、负责人交接、进入等待、阻塞解除、验收完成。团队可以约定在这些节点更新状态或补充评论，让看板尽量接近真实工作，而不是依赖月底集中补录。

若状态更新总是落后，先检查更新动作是否太繁琐、卡片是否过多，或团队没有理解更新的协作价值。增加提醒可能暂时有效，但若每次更新都要填写一长串信息，最终会形成机械操作和虚假数据。

3. 阻塞卡片要有跟进节奏

对阻塞任务，我建议明确下一次检查时间，而不是只写“持续跟进”。例如，依赖团队尚未回复，就约定何时再次确认；测试环境待修复，就指定环境问题的负责人和升级路径。等待期间是否需要把卡片移到单独状态，取决于团队能否从标记和字段中清楚识别它。

团队还可以定期归纳阻塞原因。如果同类依赖反复出现，重点就不只是催办某一张卡，而是改善接口约定、环境准备、评审容量或跨团队交接机制。看板的价值在这里不止是显示“谁卡住”，也能帮助定位流程中的重复摩擦。

4. 不把卡片数量当成个人绩效代理

不同工作项的复杂度、风险、协作成本并不相同。一位工程师手上卡片少，可能正在处理复杂故障；另一位卡片多，可能负责多个短小支持事项。只比较卡片数量或“进行中”时长，容易诱导拆卡、抢简单任务或延迟暴露困难。

如果团队需要评估流程，应先看系统层面的趋势与约束，再结合工作背景讨论。个人反馈可以围绕协作、风险处理和交付质量展开，不应把看板当作自动生成的绩效排名工具。

六、案例推演：一个“进行中”列堆满的研发团队如何调整

1. 先把案例边界说清楚

下面是用于说明操作方法的模拟场景，不是某家企业的真实客户数据，也不是公开行业基准。假设一个由开发、测试和产品协作的研发小组，当前“进行中”列有12张卡片，其中一些在等待评审，一些依赖环境，还有几张卡片超过一周没有明确更新。

团队的第一反应可能是加一列“阻塞中”，或要求所有人每天更新进度。但我会先抽查卡片，确认这12张卡片分别代表什么、谁负责、最近一次可验证动作是什么。只有知道问题来自任务规模、等待依赖还是状态口径，才有必要决定要不要改看板结构。

2. 用卡片审查找出问题类别

模拟检查后，团队发现：部分卡片只是已分配但尚未开工；几张卡片把开发与测试合并在一起；还有几张卡片实际在等待评审，却仍显示为执行中。这个结果提示，问题并非单一的“大家更新不及时”，而是准入条件、任务粒度和等待表达同时存在缺口。

我会把问题分成可立即修正和需要试验两类。可立即修正的包括补全负责人、下一步和阻塞原因；需要试验的包括是否拆分大任务、是否单独表示评审等待、WIP 限制设在什么范围。先修复信息缺口，再调整流程，比较容易分清变化的影响。

3. 试行两周，关注多个结果而非单一数字

团队可以先试行两周：明确进入“进行中”的条件；将确实等待的任务加上原因和跟进时间；对停留较久的卡片检查是否需要拆分；新任务进入前，先讨论已有工作是否能完成或解除阻塞。此时不宜宣称“效率提升了多少”，而应记录任务是否更容易交接、阻塞是否更快被看见、卡片是否更贴近真实状态。

为避免把模拟案例误读成真实统计，下表中的数值仅用于展示复盘口径。团队实际应用时，应替换为自己的时间范围、样本和统计定义。

这组推演最重要的不是卡片从12张降到9张，而是团队能解释每一次变化。若卡片减少只是因为把工作项移到另一列，实际交付并未变化，那么看板只是换了呈现方式。反过来，即使卡片数量没下降，只要等待被识别、责任人和下一步更明确，协作信息也可能已经改善。

4. 复盘时用证据决定保留什么

两周后，团队可以检查三类证据：第一，状态是否比之前更贴近实际；第二，阻塞是否更快被分配跟进动作；第三，任务完成与交接是否更顺畅。若新增状态让大家更容易判断工作位置，就保留；若团队很少使用、维护负担又明显，可能用阻塞标记和责任字段更合适。

在这个过程中，我会避免把单一周期的数据解释成因果结论。任务类型变化、紧急需求、人员休假和外部依赖都会影响结果。看板改造适合采用小范围试验，记录变化，再决定是否扩展到其他团队。

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

1. 小团队、流程简单：先用最少规则跑起来

如果团队规模不大，任务依赖少，且成员能直接沟通，通常不必一开始就配置很多状态。先约定待办、进行中、完成的含义，再补上负责人、验收说明和阻塞信息。是否增加评审中、测试中等状态，应看团队能否从中得到更好的交接判断。

这种做法的优点是维护成本低、上手快；代价是一些中间阶段的信息可能不够细。若团队经常需要等待多个角色，或工作在不同环节反复积压，再逐步增加能够支持决策的状态，而不是预先把所有可能阶段都做成列。

2. 多团队协作、依赖较多：优先把等待与责任显式化

跨团队工作中，“进行中”容易掩盖接口确认、环境准备、设计评审等依赖。此时比起增加个人进度字段，更应明确依赖方、请求时间、期望响应和升级路径。必要时，把稳定且持续的等待环节单独表示，让团队知道工作当前是在执行还是排队。

代价是看板的信息结构会更复杂，跨团队成员也需要遵守同一套交接约定。若只有一个团队维护卡片，其他依赖方既不确认也不更新，单独设一列未必能解决问题。先约定谁维护依赖状态、如何确认接手，再考虑工具上的自动化。

3. 线上支持与产品研发混在一起：为例外留出明确入口

线上故障和客户支持可能打断计划内研发。若它们都直接插入普通“进行中”列，团队很难判断计划工作为何停滞。可以设置紧急事项的标识、优先级或独立泳道，并记录被打断的原工作项和恢复责任。

这样做的收益是紧急工作更可见，代价是团队必须承担优先级取舍：新增紧急事项意味着哪些计划工作延后？若不记录这个代价，紧急通道很容易变成默认入口，最终所有任务都被标记为高优先级。

4. 研发组织较大：规则要统一底线，保留局部差异

中大型研发组织可能需要跨团队查看任务流动，也可能有多种研发流程。我的判断是，统一的应是最基本的信息语义，例如责任归属、阻塞说明、状态更新原则和指标口径；不必强求所有团队拥有完全相同的状态列和 WIP 数值。

统一过少，跨团队协作时无法理解彼此状态；统一过多，局部团队会为了符合模板而维护不适合自己的流程。更稳妥的方式是先规定最低要求，再允许团队说明工作流差异，并定期检查这种差异是否影响交接和管理判断。

八、数据复盘与工具选择：先定义问题，再看功能

1. 先统一指标口径

看板数据只有在定义一致时才有解释价值。周期时间要说明从哪个状态开始计时、在哪个状态结束；吞吐量要说明按何种工作项统计；老化任务要说明多久算需要复查；阻塞时间要说明暂停期间是否计入周期。口径不同，两个团队的数字就未必可比。

我建议先从少数指标开始：观察已完成工作项的周期时间分布、各流程阶段的积压、较长时间未更新的任务，以及阻塞原因。不要一开始就追求仪表盘上有很多数字。一个能够触发具体讨论的指标，通常比一页无人解释的图表更有用。

2. 指标用于发现流程问题，不直接替代判断

周期时间变长，可能是依赖等待增加，也可能是任务变复杂；吞吐量下降，可能与工作项粒度、人员安排或线上事件有关。数字提示值得调查的方向，但不能自动告诉团队原因，更不应直接被解释为某个人变慢。

复盘时可以把数据和卡片样本放在一起看：先找出变化明显的时间段或环节，再抽查实际工作项，确认是等待、返工、评审容量还是任务范围变化。这样的“指标加案例”方法，比只比较月度总数更容易找到能改变的流程因素。

3. 用工具承接规则，不让工具替代规则

当团队需要跨项目追踪、权限治理、历史数据迁移、私有化部署或统一报告时，工具选择会影响落地成本。PingCode可作为中大型企业及100人以上组织评估项目管理平台时的一个候选对象；其私有化部署与Jira平滑迁移能力，也可能与有部署和迁移要求的团队相关。

但“适合组织规模”不等于“自动解决进行中管理”。选型时，我会要求团队用真实工作流验证：状态是否能按团队规则配置；阻塞信息能否被责任人和协作者看见；迁移后字段、附件、权限和历史记录是否完整；报表口径能否解释；管理员维护成本是否可接受。若这些关键条件不满足，再多功能也不一定适合。

4. 做迁移和部署评估时，先列出不可丢失的信息

从旧系统迁移时，团队往往关注任务标题和状态，却容易忽略评论、附件、关联关系、权限、历史变更和自定义字段。迁移前应抽取代表性项目做试迁移，分别检查进行中任务、已完成任务、跨项目依赖和特殊流程，避免上线后才发现关键上下文丢失。

私有化部署也需要把基础设施、备份恢复、升级维护、权限管理和安全审查纳入评估。选择本地部署或云端服务，取决于组织的数据治理、运维能力、合规要求和总体成本，不宜把单一部署方式概括为所有团队的最优解。

九、七步落地清单：先试行，再扩展

1. 盘点当前状态与真实工作

把现有状态列出来，抽查近期任务，标注每张卡实际在做什么、谁在跟进、下一步是什么。不要先假设列名表达的就是实际流程，卡片的真实情况往往能暴露状态规则与团队习惯之间的差距。

2. 写出“进行中”的进入和退出条件

用团队成员都能理解的短句说明什么时候开工、什么时候完成。先解决最容易产生分歧的边界，例如已分配是否算开工、等待评审是否仍在执行、代码完成是否代表交付完成。

3. 检查卡片粒度和责任归属

挑选长期没有变化、描述过于宽泛或涉及多团队的工作项，判断是否需要拆分、补充验收条件或指定主要跟进人。目标是让下一步可见，不是把每个工作动作都做成一张卡。

4. 约定阻塞信息和跟进方式

确定哪些情形需要标记阻塞、必须记录哪些信息、由谁推动以及何时复查。若等待较少，可以先用标记和字段；若等待是稳定流程阶段，再评估是否单独设置状态。

5. 观察瓶颈后试行 WIP 规则

先观察哪个环节经常积压，讨论限制范围和例外处理，再试行一个团队认可的数值。复盘时关注超限原因、完成工作和等待变化，而不是把数值本身变成考核目标。

6. 把协作检查聚焦在工作流动

从阻塞、老化和接近完成的工作项开始，确认责任人、下一步和交接状态。会议决定要及时反映在看板上，否则团队会在下一次检查时重新发现同一个问题。

7. 按周期复盘并保留有效规则

用统一口径观察周期时间、完成量、老化任务和阻塞类型，抽查卡片解释数据变化。若某项规则增加了维护成本，却没有改善可见性或协作决策，就应调整或删除，而不是因为“流程看起来更完整”而保留。

十、结尾：看板的价值在于让下一步变得清楚

1. 不要把“进行中”治理成一场状态清理

把旧卡片移动到正确列，只能改善一时的画面；如果进入条件、责任交接和阻塞处理没有约定，几周后同样的问题还会回来。真正的改进是让团队能用一致的方式解释卡片为什么在这里、谁在推动、下一步何时发生。

2. 从一条工作流和一小批卡片开始验证

下一步可以选一个协作最频繁、问题最明显的团队，抽查十几张正在处理或长期停留的卡片，写出进入条件、退出条件和阻塞处理规则，再试行一到两个复盘周期。重点观察工作是否更容易交接、等待是否更快暴露、团队能否解释数据变化。

我对看板“进行中”的核心判断是：状态不是进度的替身，而是团队下一步行动的约定。当每张卡片都能回答“现在由谁推动、接下来做什么、遇到什么情况需要协助”，看板才从展示任务的页面，变成真正支持研发协同的工作系统。