看板如何做好进行中？跨部门团队流程优化与操作步骤

看板里的“进行中”越满，团队未必越忙，也可能只是越难交付：一张卡片可能正在被处理，也可能在等需求方补资料、等另一个部门确认，或者已经没人记得它为什么停在这里。做好“进行中”，关键不是把卡片搬进一列，而是让每项工作都有进入条件、当前责任人、下一步动作，以及卡住后的处理路径。

一、先给结论：“进行中”必须是一套规则，不只是一个状态

1. 先定义任务凭什么进入

我判断“进行中”是否有效，首先看一件事：团队能不能回答为什么这张卡片现在开始做。开始条件至少应包括需求信息够用、执行责任人明确、必要依赖已确认、交付标准能被理解。若这些条件缺失，卡片只是被提前启动，不代表工作真正具备了开工条件。

例如，设计团队收到“优化注册页面”的任务，但没有目标用户、页面范围、验收口径，也没有确认由谁提供文案。此时把卡片拖进“进行中”，只是把待确认问题藏进了执行阶段。更稳妥的做法是先留在待启动状态，列出缺失信息和责任人，满足开工条件后再进入进行中。

2. 再定义任务凭什么离开

“进行中”需要明确的出口。任务可能已经完成，也可能等待外部输入、遇到阻塞、进入验收，或发现范围变化需要重新确认。若所有情况都被留在同一列，管理者看到的只是一个模糊的总量，无法判断团队是在执行、等待还是求助。

我通常建议先不要急着增加很多状态列，而是先约定几个明确动作：完成后进入验收或完成；等待外部输入时标记等待对象和检查时间；遇到阻塞时写明阻塞原因、需要的决策和升级对象。只有当某类状态需要不同的负责人或管理动作时，才值得单独设列。

3. 用四个问题判断“进行中”是否可管理

• 为什么开始：进入条件是否满足，缺少的信息是否已被显式记录？
• 谁在推进：是否有一位当前责任人，而不是只写一个部门名称？
• 下一步是什么：卡片上能否看出下一项可执行动作及其负责人？
• 何时需要干预：等待多久、停滞多久或遇到什么风险时，需要复查或升级？

这四个问题都能回答，“进行中”才是一个可管理状态。若回答不了，优先修规则和信息，而不是先换看板工具。

二、为什么跨部门任务特别容易卡在“进行中”

1. 状态显示的是流程位置，不等于真实工作情况

一个常见误解是：任务在“进行中”，就代表有人正在持续处理。实际跨部门工作里，卡片可能早已离开执行者的手，却仍停在进行中，因为发起方认为已经交出去了，接收方却还没确认收到；也可能执行者在等审批，但看板没有等待状态。

因此我会把“任务状态”和“责任状态”分开检查。任务处于哪个流程节点是一回事，当前由谁采取下一步动作是另一回事。对跨部门协作来说，后者往往更能解释任务为什么停滞。

2. 交接双方对“交付完成”的理解不同

市场团队把活动需求发给设计团队，可能认为交接在文件发出时就完成了；设计团队则可能认为，素材尺寸、渠道规格和审批人确认后才算接收。若卡片没有写清交付物和接收标准，双方都可能觉得自己已经做完，任务却没有任何一方真正负责推进。

我建议把交接拆成两个动作：发出方提交可检查的交付物，接收方确认信息足以继续工作。发出方不能仅凭“已发送”就把责任移走；接收方也不应在条件不完整时默认接收。这个双向确认，比单纯多加一个“已交接”标签更有用。

3. 多头开工会让“进行中”看起来很忙，交付却变慢

团队成员同时承担许多任务时，工作会在不同任务之间频繁切换。每张卡片都显示进行中，但每张卡片实际推进的时间很少。此时问题未必是某个人不努力，而可能是团队把太多工作同时推入执行阶段，导致优先级冲突、等待增加和完成时间延长。

可以用在制品限制，也就是 WIP 限制，控制团队或某个流程阶段同时开展的任务数量。它不是惩罚，也不是要求所有人空等，而是提醒团队先协助完成已有工作，再决定是否接收新任务。

4. 模拟观察：先拆解停滞原因，再决定改哪条规则

下面是一个用于演示诊断方法的模拟样本，不是行业调查数据。假设一个由产品、设计、研发、测试和运营组成的跨部门团队，抽查两周内 40 张处于“进行中”超过 3 个工作日的卡片。把原因分组后，团队才有依据判断该优先改善需求入口、交接还是并行量。

三、常见误区：看板变复杂了，协作却没有变清楚

1. 误区一：把所有工作都塞进“进行中”

当团队不知道如何表示等待、阻塞、验收和返工时，最容易把它们全部留在进行中。结果是这个状态覆盖太多含义：有人在写方案，有人在等数据，有人在等待审批，还有人已经交付但等验收。列名看上去统一，实际管理语义却已经分裂。

处理方法不是立刻拆成十几个状态，而是先统计停滞卡片的主要原因。如果几种情况需要不同负责人、不同升级机制或不同复查频率，才考虑拆分状态；如果只是补一两个字段就能解决，则不必增加列。

2. 误区二：认为字段越多，信息越透明

一张卡片如果要填写十几个必填字段，团队可能开始复制粘贴、随便填或绕过看板。卡片信息应服务于协作判断，而不是复刻所有业务文档。对多数跨部门任务，优先保证任务目标、当前责任人、交付标准、依赖方、下一步动作和风险信息可读。

详细需求文档、设计文件或审批材料可以放在卡片关联的位置，不必全部抄进卡片。我的判断标准很简单：如果某个字段不能帮助团队判断“谁做什么、何时交接、卡住怎么办”，就应评估它是否真的需要成为必填项。

3. 误区三：只看任务数量，不看任务年龄和等待时间

“进行中”有 20 项，不一定比有 10 项更差。任务复杂度、团队规模和工作类型不同，单看数量容易产生误判。更有诊断价值的观察是任务在某一阶段停留多久、等待输入多久、卡片多久没有更新，以及从接收到验收经历了几个交接节点。

这些指标应主要用来发现流程瓶颈，不宜简单用于给个人排名。复杂任务的周期本来可能更长；如果团队用一个统一的时长要求所有人，成员可能会为了让数字好看而频繁改状态，反而降低数据可信度。

4. 误区四：把超时直接解释为个人不积极

任务超时只是一个结果信号，不是原因说明。它可能源自需求反复变化、依赖团队未交付、审批人缺席、优先级临时切换，或开始时估计不足。将所有超时归到执行者身上，短期看似有问责，长期会让成员倾向于隐藏风险、推迟暴露阻塞。

更可靠的复盘顺序是先问“什么条件没有满足”，再问“哪个动作可以改变结果”。只有当信息、授权、优先级和依赖都清楚，而承诺动作仍反复未执行时，才适合进一步讨论个人履责问题。

5. 误区五：以为工具能替团队决定规则

项目管理平台可以承载状态、提醒、权限、关联关系和报表，但工具不会自动定义什么叫准备就绪，也无法替组织决定谁有权调整优先级。上线前如果没有统一规则，工具只会更快地把不一致暴露出来，甚至把混乱固化成表单和审批流程。

如果组织在评估平台，可把 PingCode 纳入候选范围，特别是需要支持中大型企业或 100 人以上组织协作的场景。若评估要求包括私有化部署或从 Jira 平滑迁移，应将这些列为采购核验项，要求供应方演示迁移范围、字段和工作流映射、历史数据处理、权限验证及切换回退方案；平台能力不能代替流程设计，也不应仅凭宣传描述作出决定。

四、专业判断逻辑：用状态、责任、限制和异常构成闭环

1. 先写状态定义，再决定看板要几列

我会先让团队为每个状态补全一句规则：“当什么条件满足时，任务进入这个状态；满足什么条件时，任务离开这个状态。”如果两种情况的进入条件、责任人和下一步动作都相同，它们可能不需要分成两列；如果处理方式不同，状态拆分才有管理价值。

这张表只是规则讨论的起点，不是标准模板。若团队流程简单，可以把等待或验收做成标签和字段；若等待状态需要独立升级、验收需要独立责任人，拆列通常更容易暴露真实队列。

2. 把责任写成“一个当前负责人”，而不是一串部门

跨部门任务经常同时涉及提出方、执行方、审批方和接收方。它们都可能有责任，但一张卡片在某个时点仍应有一个明确的当前推进人。部门可以作为协作对象或责任团队，但不能替代个人或明确角色作为行动主体。

这并不意味着所有工作都由一个人独自完成，而是明确“谁负责让下一步发生”。例如，等待法务意见时，业务负责人仍可能负责跟踪意见是否返回；一旦法务开始审查，法务审核人负责审查动作。责任随着节点变化，卡片上的下一步责任也应随之更新。

3. 用 WIP 限制管理并行量，先试行再调整

我不建议未经观察就规定一个看似精确的团队上限。可以先记录团队当前在制任务数、每周完成数和任务等待时间，再选择一个可解释的试行限制。试行期间，当数量达到上限时，默认优先完成已有工作、清除阻塞或协助交接，而不是无条件再开新任务。

团队级限制适合优先级需要共同协调的跨职能工作；列级限制适合某个阶段特别容易排队，例如评审或测试；个人级限制则要谨慎，因为容易被误用为个人绩效指标。对于紧急插单，应有明确的例外入口，并说明插入后哪项工作被延后，避免所有新需求都被称为“紧急”。

4. 阻塞信息要能导向行动

“卡住了”不是足够的信息。阻塞记录至少应说明四件事：阻塞原因、需要谁提供什么、由谁跟进、何时复查。必要时再补充影响范围，例如会不会影响后续上线节点或其他团队的排期。

例如，与其写“等待产品确认”，不如写“等待产品负责人确认移动端是否纳入本次范围；项目协调人于周三复查；若未确认，开发按已确认的网页范围继续，移动端排入下一次评审”。这类描述让团队知道卡片还有没有可执行的工作，而不是把所有责任都压在“等待”两个字上。

5. 用不同周期的检查处理不同风险

日常看板检查适合处理当天的阻塞和交接；每周复盘适合检查任务老化、WIP限制和反复返工；月度或阶段复盘则适合评估状态设计、需求入口和决策机制。把所有事情都塞进每日会议，团队会疲于汇报；只做月度复盘，很多阻塞又会拖得太久。

检查时不要逐张卡片读一遍。可以优先关注接近或超过复查时间的阻塞项、长时间没有下一步动作的任务、超出在制限制的阶段，以及多次被退回的交付。看板会议的目标是决定下一步动作和责任人，不是让每个人重复讲述卡片上已经写明的信息。

五、用一个跨部门案例把规则走完

1. 示例场景：一次新客户注册流程改版

以下是一个用于说明操作方法的模拟案例，不对应特定企业。产品团队发起注册流程改版，涉及产品、设计、研发、法务、数据和运营。任务目标是调整注册页面和引导内容，但各团队的交付依赖不同：产品确认范围，法务检查文案，设计输出稿件，研发实现，数据团队确认埋点，运营最终验收活动文案。

如果只用“待办，进行中，完成”三列，很多关键问题会被隐藏：设计是否拿到了完整文案，法务是否确认条款，研发实现后由谁核对埋点，运营是否接受最终内容。团队需要的不是更多卡片颜色，而是把这些依赖转成可交接的条件。

2. 任务进入进行中之前，先完成最小开工检查

1. 明确目标：写清要改善的用户环节和本次范围，暂不确定的部分标记为待决策项。
2. 确认负责人：每张执行卡片设当前推进人，其他团队成员作为协作方或验收方记录。
3. 写明交付物：例如页面稿、前端实现、法务意见、埋点清单或运营文案。
4. 确定验收方式：写明由谁验收、按什么标准检查，避免交付后才争论“是否完成”。
5. 核对依赖：若关键输入尚未准备好，先进入待启动或等待输入，不用“进行中”掩盖未满足条件。

这一步会让任务启动看起来慢一点，但它能降低启动后反复补信息的概率。团队不必追求所有未知都消失，只需区分哪些未知可以边做边澄清，哪些未知会导致返工或让任务无法继续。

3. 交接时使用“提交，确认，接手”动作

设计完成初稿后，设计负责人提交可检查的页面稿，并在卡片中列出待确认点；产品负责人确认页面范围和交互逻辑；法务负责人确认涉及条款的内容。只有接收方确认交付物可进入下一步，卡片才转入后续执行或验收状态。

若接收方认为材料不完整，不要只把任务退回并写“信息不足”。应标明缺少的具体信息、补充责任人和复查时间。这样既能让发起方知道怎么补，也能避免任务在部门之间来回移动却没有任何可验证的改变。

4. 阻塞时先判断能否继续部分工作

假设法务审核尚未完成，但研发可以先搭建不涉及文案和条款的页面框架。此时不必让整个项目停下，也不能假装全部任务都正常推进。可以把受影响的卡片标记为等待法务确认，同时拆出不受影响的实现任务，明确它们的范围边界。

拆卡的原则是让工作可独立完成、独立验收，而不是为了让看板看起来更活跃，把一个任务切成大量无法独立交付的小卡片。若拆分后仍然依赖同一项决策，最好保留关联关系，并让团队看到共同的阻塞源。

5. 用模拟数据看流程改动是否值得

下面的数据是情景模拟，目的是示范团队如何比较改规则前后的过程表现，不应被理解为普遍效率提升承诺。假设同一团队分别观察两轮相近工作，第一轮没有明确交接确认和等待复查时间，第二轮增加了最小开工检查与双向交接。比较时应尽量控制任务类型和复杂度，否则前后差异可能来自工作难度，而非流程改变。

6. 平台只承载流程，不替流程背书

如果团队要从表格、群聊和多个系统迁移到统一平台，应先挑选一条端到端流程试运行，例如“需求提出，确认，设计，研发，验收”，而不是一次性把所有部门的全部流程搬过去。试点中要验证字段是否够用、状态是否容易理解、提醒是否有效、权限是否合适，以及管理报表能否回答真实问题。

对需要私有化部署、已有 Jira 数据或多团队协作的组织，PingCode 可以作为评估对象之一。评估时不只看迁移入口是否存在，还要逐项核验项目结构、字段、工作流、附件、历史记录、权限、用户映射和自动化规则能否按组织预期迁移。迁移测试应包含样本数据、业务用户验收和回退方案；“支持平滑迁移”应落实为可验证的范围和验收标准，而非一句口号。

六、根据不同团队状态选择行动方案

1. 进行中任务少，但任务常常突然卡住

优先检查进入条件和依赖信息，而不是先收紧 WIP。若卡片一开始就缺少需求、数据或审批条件，限制并行量只能减少同时暴露的问题，并不能修复入口质量。建议抽查最近一批停滞任务，归类缺少的输入，再把高频信息变成开工检查项。

这一类团队尤其需要明确发起方的责任。需求方提交任务时，应至少说明目标、范围、期望交付和可联系的确认人。若需求还在探索阶段，可以单独标记为探索工作，避免把不确定任务当作已经具备执行条件的交付任务。

2. 任务数量很多，成员频繁切换工作

优先试行 WIP 限制和优先级排序。选一个最容易观察的阶段开始，例如设计评审、代码评审或测试，不必第一天就限制所有部门。达到上限后，团队先讨论如何完成或解除已有任务，再决定是否接收新工作。

如果有固定的紧急事项，应定义谁有权插单、插单后原任务如何调整、团队如何记录被延后的工作。没有这套机制时，WIP限制很快会被“临时例外”掏空。限制本身不应成为拒绝合理需求的借口，而应帮助团队把容量与承诺说清楚。

3. 任务总在部门交界处停留

优先改善交接协议，而不是要求各部门“加强沟通”。每一类高频交接都要约定提交内容、接收人、验收条件、退回理由和复查时点。先选最常发生争议的一种交接，例如市场到设计、产品到研发或研发到测试，写出可检查的最小标准。

如果交接经常因为审批而停滞，还应区分“等待执行”与“等待决策”。决策等待需要明确决策人和截止时间；执行等待需要明确接手人和预期处理顺序。两者混在一起，会让团队误以为所有延误都只是排期问题。

4. 任务长期不更新，但团队认为工作仍在推进

不要立刻把卡片更新时间变成绩效要求。先询问哪些工作无法在看板上表达，例如实验过程、线下沟通或外部供应商等待。之后再决定是否用“下一步动作”或“下次检查时间”补充信息，减少无意义的频繁更新。

如果卡片没有更新但实际一直在推进，说明团队的记录动作与工作节奏不匹配；如果卡片长期没有动作，也没有人能解释原因，才需要进一步检查责任归属、任务优先级或管理机制。更新时间是预警信号，不是工作成果。

5. 团队刚开始使用看板，流程还没有共识

从小范围、低风险、能观察完整交接的一类工作开始。先定义少量状态和必要字段，试运行一到两个工作周期，再根据真实问题改规则。不要先设计完美流程图再要求所有人照做，因为实际的等待、返工和例外，往往只有运行一段时间才会显现。

试点时应记录规则变更，而不是每周随意改列名和字段。每次修改都说明遇到什么问题、预期改善什么、观察哪些信号。这样团队能够分辨流程改善是否有效，也能避免看板反复重做却没有形成稳定习惯。

七、取舍要讲清楚：速度、透明度和维护成本不可能同时无限增加

1. 状态列更细，还是操作负担更轻

增加状态列能让等待、审核和返工更显眼，但每多一个状态，就多一项理解、维护和培训成本。若某个状态没有独立责任人、复查机制或决策动作，它可能只是把同一件事换个名字。反过来，如果等待审批长期占据大量任务，单独呈现等待队列通常值得。

决策时可以问：把这一状态单独拿出来，团队是否会采取不同动作？如果答案是否定的，先用标签或字段；如果答案是肯定的，再考虑独立状态或列。

2. WIP 越低越好吗

WIP 过高会造成切换和排队，过低则可能让团队容量利用不充分，尤其在工作依赖不同专业人员、任务无法互相替代时。团队要追求的不是最低在制数量，而是在可接受的等待、交付节奏和应急空间之间取得平衡。

因此，上限应经过观察和试行。若上限长期触发，检查是否任务拆分不合理、资源瓶颈集中在少数角色，或优先级频繁变化；若上限从不触发，也要确认设定是否过宽，还是团队当前工作量确实较少。数字只是调节信号，不是目标本身。

3. 透明度越高越好吗

看板的可见性应服务协作，不等于所有信息对所有人公开。涉及客户资料、个人信息、商业敏感内容或受限审批的任务，需要按组织权限设计展示范围。可以公开状态、负责人角色和交付依赖，同时把敏感附件放在受控位置。

同样，公开停滞任务是为了尽早获得帮助，而不是制造羞耻感。若团队把红色阻塞标记变成问责工具，成员很可能延迟标记，导致看板最需要呈现的信息反而消失。

4. 指标越多越好吗

团队可以观察周期时间、阶段停留时间、交接等待时间、返工比例、阻塞次数和超期任务占比，但不必全部作为日常考核指标。指标太多会增加采集和解释成本，还可能诱导团队优化数字而不是优化交付。

我建议先为每项指标写清定义、统计周期和使用目的。例如“交接等待时间”从发出交付物到接收方确认开始计时；若不同任务类型差异明显，就分组观察，不直接横向比较。指标应引出问题和行动，而不是停留在报表展示。

5. 平台迁移越快越好吗

集中迁移可以减少多套系统并存时间，但一次性迁移所有数据、工作流和自动化规则，风险也更集中。团队需要在切换速度与业务连续性之间取舍。对流程复杂、权限严格或历史数据重要的组织，分阶段迁移和用户验收往往比单次快速切换更稳妥。

评估包括 PingCode 在内的项目管理平台时，可以用同一套业务场景做演示和验证：任务如何进入、跨部门如何交接、阻塞如何升级、数据如何导出、权限如何继承、迁移失败如何回退。平台的私有化部署、Jira 迁移等能力是否适合组织，应以实际部署方案和测试结果为准，不能只看功能名称。

八、上线检查清单：用两个周期检验“进行中”是否变清楚

1. 第一个周期：只验证规则能不能执行

第一轮不要急着判断效率是否提升，先确认团队是否真的能按约定操作。可以用一张简短检查表，覆盖进入条件、负责人、下一步动作、交接确认和阻塞信息。若规则写得很好，却没人知道什么时候更新状态，说明规则还不够贴近工作现场。

• 任务进入进行中前，是否能说明需求信息和开工条件？
• 每张进行中卡片是否有一个明确的当前推进人？
• 卡片上是否能看出下一步动作，而不只是任务描述？
• 等待外部输入时，是否写明对象、责任人和复查时间？
• 交接是否由接收方确认，而不是发出方单方面标记？
• 达到 WIP 上限时，团队是否知道应该先做什么？

检查表的目的不是增加审批，而是找到最常失效的规则。若所有任务都要开会逐项确认，流程可能设计得太重；若重要信息反复缺失，则可能是入口条件没有被落实。

2. 第二个周期：检查过程指标是否解释了瓶颈

第二轮可以选择三到五个过程指标，观察趋势而不是追求漂亮数字。建议至少包含一个等待类指标、一个流动类指标和一个质量类指标，例如交接等待时间、任务在制数量和交付后退回比例。指标口径要保持一致，任务类型差异较大时应分组。

图表中的对比应配合具体卡片复核。若等待时间降低，但返工上升，可能团队只是更快地接走了不完整任务；若在制数量减少但交付周期变长，可能上限设置过严或关键角色出现瓶颈。任何单一数字都不足以说明整个流程已经改善。

3. 用一次短复盘决定保留、调整或撤销规则

复盘时我会把规则分成三类：确实减少了误解或等待的，保留；产生额外填写负担但没有带来管理价值的，简化；试行后暴露出更大问题的，调整或撤销。流程规则应由实际工作验证，不应因为已经写进手册就被永久保留。

最终的目标不是让每张卡片都完美，也不是让看板状态永不变化，而是让团队能尽早发现“工作已经停了但没人知道”“任务交出了却没有人接”“新工作不断进入但旧工作无法完成”这些风险，并知道由谁采取下一步动作。

我对“进行中”的核心判断是：它不是任务开始后的停车场，而是团队对正在消耗的协作容量作出的承诺。下一步可以先抽查最近两周停留时间最长的 10 张卡片，把它们按等待输入、需求不清、并行过多、决策延迟和其他原因分类；再选出最常见的一类，试行一条进入规则、一条交接规则和一个复查动作。让团队先把最常发生的卡点说清楚，再决定是否拆状态、加字段或更换平台。