看板如何做好进行中？产品经理落地方案与操作步骤

看板如何做好进行中？产品经理落地方案与操作步骤

如果一张看板上有十几张卡片都停在“进行中”，但没人能准确说出哪些正在推进、哪些在等人、哪些已经卡住，那么问题通常不在团队更新不勤，而在“进行中”这个状态没有被定义。产品经理要做的，不是再加一列或多催几次，而是让每张卡片进入、停留和离开这个状态时，都有团队共同认可的规则。

一、先给结论：把“进行中”从状态标签改成工作规则

1. 看板能不能管好，先看卡片是否能回答四个问题

一张处于“进行中”的卡片，至少应该让团队看懂：谁在推动、当前做到哪一步、下一步是什么、有什么因素可能让它无法继续。若看板只能显示“有人领了任务”，却无法呈现这些信息，它反映的只是任务被认领，不是工作正在流动。

我建议产品经理先把“进行中”拆成四项最小规则：进入条件、当前责任人、阻塞标记、离开条件。先把这些规则说清楚，再决定是否拆分“开发中”“待测试”等状态。状态列是界面，规则才是流程。

2. 先治理流动，再考虑状态要不要变多

团队常把看板问题理解成“列不够细”，于是从“待办，进行中，已完成”扩成需求分析、设计、开发、联调、测试、验收等一长串状态。但如果没人依据这些状态采取不同动作，新增列只会增加更新成本，并不会自动提高透明度。

判断一列要不要存在，可以问：卡片进入这列后，团队是否需要执行一种不同的动作？如果答案是否定的，通常不必单独设列；如果这列能暴露等待、交接或质量检查等具体问题，再考虑拆分。

3. 把“完成一张卡”放在“开更多卡”之前

管理进行中的核心，不是尽可能多地启动工作，而是避免团队同时开太多任务，导致每件事都只前进一点。产品经理可以推动团队约定在制品限制（WIP），但限制的目的不是压个人产出，也不是拿来打分，而是提醒团队：当前工作已经多到可能影响交付流动。

一条实用的规则是：当进行中的数量达到上限，团队先讨论怎样帮助已有工作完成或解除阻塞，而不是继续把新任务拖进来。这样看板才能从“任务展示墙”变成协作决策工具。

二、为什么“进行中”容易失真：从一张拥堵的看板说起

1. 卡片被认领，不等于工作已经开始

常见情形是需求刚进入迭代，负责人先把卡片拖到“进行中”，但验收标准还没对齐、设计稿没有确认、外部接口也未准备好。卡片看起来已经启动，实际却没有进入可执行状态。

此时如果团队把“进入进行中”理解成“有人接手”，产品经理就很难分辨真实产能与排队数量。等到评审或交付临近，才发现卡片虽然在动，关键前置条件却一直没完成。

2. 一个状态装进了多种完全不同的情况

“正在开发”“等设计反馈”“等外部团队开接口”“已开发完但还没交测试”，如果都叫“进行中”，看板就失去了区分能力。这些卡片都没完成，但下一步动作、负责人和风险并不相同。

这也是为什么单纯看“进行中有多少张”容易得出错误结论。数量偏高可能意味着任务过多，也可能意味着某个交接点积压，或者少数卡片长期被外部依赖卡住。要找原因，必须进一步看卡片在哪个环节停留、停留多久、谁负责推进。

3. 更新状态变成了汇报动作，而不是协作动作

如果团队只在站会前更新看板，状态就容易变成“给管理者看的进度报告”。卡片上写着“处理中”，但没有下一步、阻塞原因或需要谁协助，团队仍然要靠口头追问来拼出真实进度。

我会把看板检查重点从“有没有更新”转向“更新之后能不能采取行动”。一条有用的更新通常会让协作方知道下一步怎么接，而不只是证明某人今天做过工作。

下图为示意数据，用来说明“卡片总量”与“卡片可解释程度”是两件事。假设一组团队对 12 张进行中卡片进行盘点，只有 5 张写清下一步、责任人和阻塞情况，优先改进的就不是增加看板列，而是补足协作信息。

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

1. 误区一：把“进行中”当成任务已被领取

如果进入条件只是“有人认领”，团队就会把等待准备、等待输入和实际执行混在一起。领取任务适合记录负责人，但不一定代表工作已经进入交付流程。产品经理要推动团队区分“准备开始”与“已具备开工条件”，具体状态是否需要单独成列，应由团队的管理需求决定。

可执行的做法是先定义最少的准入检查：需求目标是否明确、验收条件是否可理解、关键依赖是否已确认、当前责任人是否清楚。不是每项工作都要设置复杂审批，而是要识别那些一旦缺失就会造成返工或等待的必要信息。

2. 误区二：用拆分状态代替定位瓶颈

把“进行中”细分成很多列，确实可能让流程更可见，但也会带来维护成本。特别是团队规模较小、角色交叉较多时，一张卡片可能频繁跨列移动，成员花时间更新状态，却没有因此获得新的决策信息。

拆列前先验证管理目的：团队是否需要知道卡片在设计、开发还是测试阶段？不同阶段是否有不同的交接条件？是否有人会根据这些信息调整资源或处理等待？如果没有明确答案，先保留较少状态，用卡片字段或标签记录必要信息通常更轻。

3. 误区三：把 WIP 上限当作每个人的工作配额

WIP 限制针对的是团队流程中的同时工作量，不适合简单地按人数分配成“每人最多做两张卡”。任务规模、复杂度、协作人数和依赖情况不同，卡片数量并不能直接代表个人负荷。

如果上限被用作个人考核，成员可能会拆小任务、隐藏工作或避免主动协助别人。更健康的做法是把超限当作团队共同信号：看看是否有卡片可一起完成、是否存在等待资源、是否可以暂缓新工作，或是否需要重新排序。

4. 误区四：用固定天数定义所有团队的超时

“超过三天就算异常”听起来简单，但不同类型的工作、不同依赖和不同协作节奏，等待时间差异很大。未经验证地统一阈值，可能让正常工作被误报，也可能让真正停滞的任务在阈值内被忽视。

更稳妥的方式是先观察团队自身的工作节奏，按工作类型或阶段设定提醒规则。提醒的意义不是自动判定责任，而是促使团队检查：任务是否仍在推进、预计何时更新、是否需要协助或重新安排。

5. 误区五：产品经理亲自追每张卡片

产品经理的职责是帮助团队把目标、优先级、验收条件和跨角色依赖讲清楚，而不是成为所有任务的催办中心。若每张卡片都要等产品经理询问才更新，说明流程依赖个人记忆，而不是由团队共同执行。

产品经理可以推动规则建立、协调跨团队阻塞、澄清产品决策，并定期检查规则是否有效。卡片的日常状态维护则应由最了解当前工作的人负责，具体责任可以由团队结合角色分工确定。

四、专业判断逻辑：先看流动，再决定列、限制和提醒

1. 用“进入，推进，退出”检查状态是否定义完整

一列状态如果只有名字，没有进入与退出条件，就很容易被不同成员按不同理解使用。产品经理可以和团队一起回答三组问题：什么情况下卡片进入进行中？处于该状态时，谁负责维护进展？满足什么条件后可以离开？

例如，团队可以约定：卡片只有在验收条件明确、关键输入准备好且责任人确认后，才进入进行中；完成约定的工作并提供下一环节所需信息后，才转到下一状态。每个团队的细节可以不同，关键是让规则能指导真实交接。

2. 用“是否支持决策”判断要不要拆列

如果卡片停留在某个环节会触发不同动作，例如需要设计评审、接口联调或测试验收，那么单独呈现该阶段可能有价值。反过来，如果团队只想知道任务是否已启动，不需要追踪中间环节，拆列未必划算。

我建议用一个简单的成本判断：新增状态带来的可见性，是否大于状态维护和解释的成本？新增一列后，团队能否更早发现等待、调整交接或重新分配工作？如果不能，就先不加。

3. 用卡片老化和阻塞情况辅助判断，不只看数量

进行中数量是某一时点的快照，卡片老化情况则帮助团队观察工作是否长时间停留。对每张卡片，可以记录进入当前状态的日期、最后一次有效进展、下一步动作和阻塞原因。这里的“有效进展”不一定是状态改变，也可以是关键输入到位、评审完成或风险解除。

老化提醒需要配合工作类型解释。一个复杂任务停留时间较长，不必然有问题；但如果卡片没有下一步、没有更新，也没有已知原因，就应该进入团队检查，而不是默默留在看板上。

4. 用团队试行值确定 WIP 上限，不套用万能公式

WIP 上限没有脱离团队背景的通用最佳数字。起步时可以观察：团队目前同时推进多少工作、哪些卡片常常等待、同一成员是否频繁切换任务、交接处是否形成堆积。随后选一个团队有能力执行的试行值，观察一段约定周期，再决定调整。

如果团队不确定从哪里开始，可以把当前进行中数量作为观察基线，而不是马上设定严厉上限。先记录超限时发生了什么、团队采取了什么动作、哪些卡片因此得到帮助。比起精确到某个数字，能否在超限时改变行为更重要。

5. 用可行动的字段替代冗长的状态说明

卡片信息不必写成日报。对协作最有用的内容通常是下一步、负责人、阻塞原因、需要谁协助以及预计何时再检查。字段越多不一定越透明；如果一个字段没人更新或无法引发行动，可以删减。

下面的情景模拟展示两种团队在同一周内的卡片流动差异。它不是效率基准，而是说明同样的任务总量，如果团队只持续开工，完成数和阻塞数可能不会改善；如果开始优先处理已有工作，流动结构可能更健康。

五、落地操作步骤：产品经理如何从现状盘点走到团队试行

1. 先盘点当前看板，找出卡片停滞的位置

不要先改工具配置。先选取一个具体团队或一条工作流，盘点进行中卡片：当前所在阶段、负责人、最近一次有效进展、下一步、是否依赖外部输入。观察时不必追求复杂报表，目标是找出最常见的停滞类型和信息缺口。

如果团队不方便完整回看历史，可以先做一次当下快照，再在接下来一段约定周期内记录状态变化。重要的是让观察范围固定，例如同一团队、同一类工作，不要把不同流程的数据混在一起解释。

2. 和协作角色一起定义最小准入条件

产品、设计、研发、测试或其他协作角色，对“可以开始”的理解可能不同。产品经理可以主持一次短会，逐项确认：缺少什么信息会导致返工？哪些依赖必须先确认？哪些条件可以在执行过程中补齐？目标是找到最少且必要的准入条件，不是把所有风险都前置成审批门槛。

规则可以写在看板说明或团队约定中，并用一张实际卡片演练。如果成员看到规则后仍不知道怎样判断，就继续把抽象词换成可观察事实。例如，把“需求足够清晰”改成“目标用户、预期结果和验收方式已写明”。

3. 明确责任分工和阻塞处理路径

状态规则要同时说明谁更新卡片、谁处理决策、谁跟进外部依赖。产品经理可以负责产品范围、优先级和验收口径的澄清；执行负责人维护工作进展；跨团队依赖则约定具体跟进人。避免把“阻塞”变成只贴标签、不采取行动的装饰。

建议每张阻塞卡片至少写清三件事：卡在哪里、需要谁提供什么、下一次何时检查。若无法确定解决日期，也要明确下一次获取信息或升级协调的时间，避免卡片长期无人过问。

4. 先试行 WIP 规则，不急着一次性全组织推广

选一条工作流做小范围试行。记录开始时的进行中数量、卡片老化情况、阻塞原因和团队切换工作的体验。试行期间，若达到团队约定的上限，先不接新工作，优先讨论完成已有任务、协助阻塞任务或重新安排优先级。

试行值可以根据观察逐步调整。若上限过低，团队可能频繁无事可做或等待不必要的协作；若上限过高，限制又无法提醒团队降低并行工作。调整时要说明依据，并观察调整之后团队是否真的改变了协作行为。

5. 把日常检查变成解决问题的短会

站会或流程检查不必逐人汇报“昨天做了什么”。可以按卡片流动来检查：有哪些卡片正在接近完成？哪些卡片停留时间异常？有哪些依赖需要协调？是否达到 WIP 上限？这能让讨论围绕系统中的工作，而不是围绕个人表现。

对无法当场解决的问题，明确负责人和下一步检查时间后继续讨论其他卡片。若一个问题每次都在会议中重复出现，产品经理应考虑调整依赖流程或规则，而不是要求成员每天重复汇报同一障碍。

6. 复盘规则是否有效，再决定保留、修改或删除

试行结束后，检查规则有没有让卡片更容易进入、推进和交接；阻塞是否更早被看见；团队是否知道超限后怎么做；状态维护是否带来额外负担。如果只增加了录入工作，却没有让任何决策变清楚，就应简化字段或撤掉无用状态。

复盘要看过程指标，也要听协作角色的反馈。完成数量可能受到任务大小、临时工作和依赖影响，不能单独作为结论。可以同时观察周期、阻塞、卡片老化和返工情况，再结合具体卡片核查原因。

1. 选择一条工作流，记录进行中卡片的数量和状态。
2. 梳理卡片进入、推进、离开进行中的必要条件。
3. 为阻塞卡片补上原因、跟进人和下一次检查时间。
4. 选择试行 WIP 规则的范围和复盘周期。
5. 复盘流动变化与维护成本，保留有用规则，删除无效规则。

以下为一个月度情景模拟，用于帮助团队理解为什么要同时观察流动、阻塞与卡片老化。数值仅用于演示复盘结构，不是行业均值或效果承诺。

六、案例推演：同一组任务，规则如何改变团队的下一步

1. 情景设定：小型跨职能团队的看板拥堵

以下是一个明确的情景模拟，不对应真实客户或真实团队数据。假设一个跨职能团队有产品、设计、研发和测试成员，当前看板上有 12 张进行中卡片，其中 3 张等待设计确认，2 张等待外部接口，另有几张卡片没有写明下一步。

团队原先把卡片被负责人认领视为进入进行中。于是，卡片一旦被认领就离开待办区，但部分任务因为输入不足无法实质推进。每次同步会上，成员逐张解释进度，会议时间用在补信息，而不是协调阻塞。

2. 第一轮调整：先补信息，不先增列

产品经理与团队先约定，卡片进入进行中前要满足三项条件：预期结果和验收方式可理解；关键输入已确认或明确由谁补齐；当前负责人知道下一步动作。团队没有马上增加大量流程状态，而是在卡片上增加简短字段：下一步、依赖、跟进人。

对于已进入进行中但暂时无法执行的卡片，团队先标记阻塞原因，并判断它是短暂等待、外部依赖，还是需要退回补充信息。这样做的价值不在于卡片看起来更整齐，而是让团队能区分“正在做”和“等条件”。

3. 第二轮调整：超出并行工作量时先协作完成

团队随后根据当时的工作量约定一个试行上限。这里不把具体数字写成普遍推荐值，而是由团队结合成员可用时间和当前任务特征确定。达到上限后，团队不再默认启动新卡片，而是先看现有工作是否可以通过协作完成、解除等待或拆解下一步。

例如，研发成员完成一部分工作后，可以协助定位另一张卡片的接口问题；产品经理可以推动尚未明确的验收口径；测试成员可以提前参与风险较高任务的验证讨论。重点不是让每个人随意跨职能，而是让资源优先用于降低流程中的阻塞。

4. 用案例数据看变化时，先说明口径和边界

为了演示复盘方式，假设团队在调整前后各观察两周，并记录进入进行中的卡片数、完成数、阻塞数和老化卡片数。以下数字为情景模拟，目的只是说明该看哪些变化，不代表任何特定团队的真实结果。

这个例子最重要的不是“完成数增加了几张”，而是团队开始能解释卡片为什么启动、为什么等待、接下来由谁处理。若完成量上升却伴随返工增加，规则仍需调整；若阻塞卡片减少只是因为卡片被移出看板，改善也只是表面现象。

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

1. 团队规模小、角色经常交叉：优先用轻规则

小团队可能一个人同时承担多个角色，工作流不一定需要拆得很细。建议先保留少量状态，用卡片字段表达负责人、下一步和阻塞原因。只有当团队反复遇到同一类交接问题，且知道新增状态要支持什么动作时，再拆分流程。

这种做法的优势是维护成本低，适合流程简单、协作关系稳定的团队；代价是看板对中间环节的可视化较弱。若管理者需要追踪不同阶段的等待，就要通过标签、字段或定期盘点补足信息。

2. 多团队协作、依赖频繁：优先把交接和等待显式化

当工作需要跨团队交付，最值得治理的往往不是“谁的任务最多”，而是交接输入、等待对象和决策时限。团队可以设置专门的等待标记或状态，但应明确等待由谁跟进、对方需要提供什么、多久后重新检查。

这类团队的看板状态可能更细，但要避免把每个部门都变成一条孤立泳道。若一张卡片跨越多个团队却没有统一责任人，单纯增加列数仍无法解决“谁负责推动下一步”的问题。

3. 工作类型差异大：分流管理，不用一个时限管所有卡片

紧急故障、常规需求、探索性任务的工作节奏可能不同。把它们放在同一套超时阈值和 WIP 限制下，容易造成误报或优先级冲突。团队可以通过工作类型、泳道或明确的优先级规则区分处理方式，但要让例外可见，避免所有任务都被标成“紧急”。

取舍在于：分类越多，管理精度可能越高，但维护和争议也会增加。建议先从确实需要不同响应方式的工作类型开始，定期检查分类是否改变了资源安排或交付决策。

4. 合规或审批环节多：保留必要控制，但把等待责任写清楚

某些工作必须经过安全、法务、质量或其他审批，不能为了追求卡片流动而跳过控制。产品经理要区分“必要等待”和“无人负责的等待”：前者是流程要求，后者是管理缺口。

如果审批时间较长，可以明确提交条件、审批责任人、补充材料要求和复查节奏。看板要呈现流程真实状态，但不应把等待都包装成团队成员正在执行的工作。

5. 任务规模差异明显：先统一拆分口径，再比较数量

一张卡片可能是半天的文案调整，也可能是多周的复杂改造。直接用卡片数量比较个人或团队产出，会掩盖任务规模差异。若团队需要观察流动，可以先把卡片拆到足以看清下一步、又不至于碎片化的程度，并保持相似工作之间的口径相对一致。

并非所有任务都要拆成相同工时。探索性工作可能更适合设置阶段性问题和时间盒，而不是假装一开始就能精确估算。产品经理应根据任务不确定性选择管理方式，并把例外说明清楚。

6. 行动取舍表：先选最能解决当前问题的机制

八、最后的检查清单：让规则轻、可执行、可复盘

1. 每周看板检查的六个问题

• 进入进行中的卡片，是否满足团队约定的开工条件？
• 每张卡片是否有清楚的下一步和当前责任人？
• 等待或阻塞是否明确标出原因、跟进人和复查时间？
• 进行中数量达到约定上限时，团队是否知道先做什么？
• 看板新增的状态和字段，是否真正支持了不同决策？
• 规则是否减少了追问和交接误解，还是只增加了维护负担？

2. 复盘时同时看结果、过程和副作用

结果层可以看完成的工作、交付周期和返工；过程层可以看阻塞、卡片老化、工作启动与流出；副作用则要看会议是否变长、字段是否无人维护、成员是否为了满足上限而拆碎任务。任何单一指标都不足以证明看板治理有效。

尤其要谨慎解释“完成数”。如果两周内完成卡片变多，但任务整体变小、质量问题增加，不能简单得出效率提升的结论。产品经理应抽查卡片类型和实际交付结果，把数字变化放回业务背景中判断。

3. 从一条规则开始，而不是从一次全面改造开始

如果团队目前最明显的问题是卡片停滞，就先补阻塞处理规则；如果最明显的问题是任务启动后反复退回，就先定义准入条件；如果大家都在做很多事但完成困难，再试行 WIP 限制。一次只改最影响流动的一两个环节，更容易看清变化来自哪里。

产品经理真正要推动的，不是让所有团队使用同一张模板，而是建立一套能被团队理解、能在协作中执行、也能根据证据调整的工作约定。规则有效时，成员不需要靠追问才能知道卡片发生了什么；规则无效时，团队也能通过复盘及时删改。

做好看板“进行中”，关键不在于把状态切得多细，而在于让每张卡片都能说明自己为什么在这里、下一步由谁推动、什么情况下可以离开。下一步可以从现有看板抽取一组进行中卡片，逐张检查准入条件、下一步、阻塞和责任人；找出最常见的一个缺口，和团队试行一条规则，再用实际卡片复盘它是否值得保留。