进行中最佳实践：产品经理看板入门指南，常见问题

进行中最佳实践：产品经理看板入门指南，常见问题

产品看板上有 18 张卡片标着“进行中”，但团队没人能马上说清哪几张正在推进、哪几张在等反馈、哪几张已经悄悄停了两周，这不是看板不够漂亮，而是“进行中”没有管理含义。对产品经理来说，看板的关键不在于任务分了多少列，而在于每张工作项能否持续流动、停滞时能否看出原因，并触发下一步行动。

一、先说核心结论：“进行中”是风险信号，不是进度装饰

1. 看板首先要让工作流动起来

我建议把看板理解为一套团队共同遵守的工作规则，而不是一块电子白板。列名只是表面，真正有用的是每列代表什么、什么条件下可以进入、满足什么条件才算离开，以及卡住时由谁采取什么行动。

一张卡片从“待处理”移到“进行中”，并不等于项目自然前进了。它可能正在设计、开发或验证，也可能只是在等待决策、接口、数据、评审或外部团队。若这些不同情况都挤在同一列里，管理者看到的是一幅“大家很忙”的图，团队却得不到可靠的协作信息。

2. 产品经理要盯的是流动，不是卡片数量

产品经理通常不是每张卡片的执行者，却经常负责需求澄清、优先级协调、跨团队依赖处理和交付预期管理。看板对产品经理的价值，主要是让这些工作状态可见：工作是否开始、是否有下一步、是否等待别人、是否已经偏离原定顺序。

一条实用判断是：如果“进行中”列不能帮助团队回答“接下来做什么、谁来推动、卡在哪里”，这列就只是状态标签，不是管理工具。因此，建立看板时不必先追求列多、字段全或图表丰富，先让少数规则可执行，通常比堆出完整模板更重要。

3. 先观察四类流动信号

在团队讨论看板时，我会先看四类信号：同时进行的工作是否过多、工作项在列中停留多久、工作项是否按预期完成、阻塞原因是否能被识别。它们比“今天更新了多少张卡片”更接近团队实际交付情况。

Kanban Guide（看板指南）将 WIP（在制工作量）、吞吐量、工作项年龄和周期时间列为重要的流动指标。它们描述的是流程状态，不是个人绩效分数。团队可以用这些信号发现流程问题，但不能脱离工作类型、任务规模和团队约定，直接拿数字给个人排位。

二、从真实场景开始：为什么“进行中”最容易失真

1. 一张卡片可能藏着多个工作阶段

设想一个产品团队正在准备新的企业权限能力。需求已经进入开发，但研发需要等接口方案，设计正在补充异常状态，产品经理还在确认角色边界。团队若把整件事放进“进行中”，看板上只有一个状态，却掩盖了至少三种不同的等待与推进情况。

这时，问题未必是需要立刻增加“待接口”“待设计”“待产品确认”等很多列。先要判断：这些阶段是否会改变协作方式、责任人或管理动作。如果不同状态需要不同的人采取不同动作，才有理由拆分或添加阻塞标记；如果只是为了把流程画得更细，拆列反而会增加维护负担。

2. 任务开始不代表任务在持续推进

不少团队用“有人接手”作为进入“进行中”的条件。这个做法适合团队规模较小、任务交接简单的场景，但在跨职能协作中容易出现误判：负责人已经认领任务，却没有明确下一步；任务也许要等另一个团队排期，但仍长时间显示为“正在做”。

我更倾向于把“进行中”定义为：工作已经开始，并且当前存在可执行的下一步。如果当前唯一动作是等待外部输入，应明确标记等待对象、发起日期和跟进时间。这样做不一定要求创建新状态，但必须让等待可见。

3. 堆积不一定是执行者不努力

进行中任务变多，常见原因包括需求同时启动太多、工作项范围过大、评审和验证排队、外部依赖没有约定反馈时间，或者优先级频繁变化。直接催负责人“加快速度”，可能只会增加切换和沟通成本，并不能消除瓶颈。

我会先问：最近完成的工作有没有减少？最老的进行中任务停在哪一步？等待是否集中在某类角色或环节？如果卡片都停在同一个审核节点，问题更可能在流程容量或决策机制，而不是每个执行者都恰好变慢。

三、拆解常见误区：状态列越细，不一定越专业

1. 误区：照搬一套固定列名就能搭好看板

“待办，进行中，已完成”很容易上手，但未必足够；“需求分析，设计，开发，测试，上线，复盘”看起来更完整，也未必适合每个团队。列的数量应该来自真实交接和决策节点，而不是来自一张通用模板。

如果一列没有清晰的进入条件和离开条件，团队成员会按自己的理解拖动卡片。例如，有人把“开发完成”算作完成，有人认为还要通过验证；看板上的完成率就无法代表同一件事。先统一口径，再决定是否需要拆列。

2. 误区：所有进行中任务都必须有一个人负责到底

跨职能工作往往需要产品、设计、研发、测试或运营共同参与。若把“负责人”理解为唯一执行者，卡片会让协作关系变得模糊；若所有参与者都被写成负责人，又可能没人对下一步负责。

更稳妥的做法是区分最终推进责任人与协作者。前者负责说明下一步、维护状态、发现阻塞；后者负责完成具体协作事项。职责可以因团队流程而异，但卡片上应能找到一个明确的推进联系人。

3. 误区：有阻塞就必须把卡片移出进行中

“阻塞”描述的是工作不能按当前计划继续，不一定意味着工作没有开始。有些团队保留原状态并添加阻塞标记，有些团队会设置“等待外部输入”或“待评审”状态。两种方式都可行，关键是团队能否快速区分“正在执行”和“当前无法推进”。

如果团队选择单独设置等待列，应避免把等待列当成任务的长期归宿。卡片最好写清等待对象、开始等待的日期、约定的下一次跟进时间，以及满足什么条件后可以回到主流程。

4. 误区：WIP 限制就是给个人规定最多做几件事

WIP 限制的目标是帮助团队减少过度并行、推动已有工作完成，而不是把它变成个人工作量上限或排名工具。过度并行会增加切换、交接和等待，尤其当团队同时启动大量需求，却没有足够的设计、研发或验证容量时，进行中列会越来越像一个长期停车场。

限制可以先从团队或某个流程阶段开始，而不是直接给每个岗位定死数量。确定限制时要考虑团队人数、工作项大小、专业角色容量和紧急任务规则；上线后还要观察它是否改善了流动，不能把某个固定数字当作行业标准。

5. 误区：周期时间短，就一定做得更好

周期时间受到工作项大小、统计起止点、任务类型和团队流程影响。若团队把大需求拆成许多很小的卡片，数字可能变短，但用户实际得到的价值未必更快。若为了缩短周期而跳过必要验证，短期指标改善还可能增加返工。

指标的价值在于提出更好的问题，而不是给出脱离上下文的结论。看到周期时间变长，可以追查等待或范围变化；看到吞吐量下降，可以检查是否有大项占用容量；这些都只是调查线索，不能仅凭单项指标判断团队表现。

四、专业判断逻辑：一张卡片如何进入、停留和离开“进行中”

1. 先规定进入条件，而不是先讨论颜色

进入“进行中”前，至少要能回答三个问题：这项工作要交付什么？当前推进责任人是谁？第一步具体做什么？如果目标仍未澄清、关键依赖完全未知，或者没人能指出第一步，先放在待澄清或待准备区域通常更诚实。

这不意味着每个任务都要在开始前写成完整规格。规则应服务于团队，而不是制造审批门槛。小型、低风险工作可以采用轻量约定；高风险或跨团队工作则可能需要更多依赖信息和验收条件。

2. 再明确离开条件，让“完成”可检查

离开“进行中”不应只依赖执行者主观感觉。产品需求可能需要完成约定的交付物、通过必要验证，并由约定角色确认；内部研究任务则可能以结论记录和决策建议作为完成条件。不同工作类型可以有不同完成定义，但同类工作应尽量一致。

如果团队把“开发完成”“待验收”和“已上线”混为一谈，管理者就很难判断承诺的是代码交付、业务验收还是用户可用。必要时可以把阶段分开；如果这些阶段不影响协作，只需在完成标准中说清楚即可。

3. 为阻塞信息设置最低可用字段

阻塞标记本身不够。建议至少记录“阻塞原因、依赖对象、开始日期、下一次跟进时间”。这样产品经理能区分“正在等待”与“没人跟进”，也能在每日同步或异步更新中直接讨论需要谁做什么。

卡片字段不宜无限扩张。团队可以把信息分成两层：所有工作项都需要的最低字段，以及高风险、跨团队或需审批工作才填写的补充字段。字段越多，如果没有明确用途，越容易变成形式化填写。

4. 用工作项年龄触发检查，不要只靠会议催进度

工作项年龄是当前未完成工作从进入约定起点以来经过的时间。它与周期时间相关，但观察对象不同：周期时间通常用于回看已完成工作；工作项年龄用于关注仍未完成的卡片。团队可以设置提醒阈值，但阈值应基于自身历史和交付预期，不宜从别的团队直接照搬。

当一张卡片超过团队约定的观察范围，产品经理可以按顺序排查：目标是否变化、下一步是否明确、责任人是否有容量、是否依赖其他团队、是否等评审或决策、是否需要拆分。排查重点是找到阻断流动的条件，而不是把所有延迟归因于个人执行。

五、用一个团队案例看规则如何落地

1. 案例背景：卡片总数没变，等待问题却被看见了

下面是一组情景模拟数据，用于展示诊断方法，不代表某家企业的实际绩效。假设一个 12 人的产品交付小组，产品、设计、研发和测试共同处理一个工作流。原看板只有“待办、进行中、已完成”三列，团队周会上经常发生这样的对话：“这项还在做”“具体卡在哪里？”“要再问一下负责同事。”

团队没有先换工具，而是先对过去两周的工作项做了轻量分类：标明下一步、等待对象、进入进行中的日期，以及是否发生范围变化。结果发现，卡片并非都在执行环节停滞；其中一部分等接口确认，一部分等产品决策，还有一些因为工作项过大，连续多个工作日都没有可检查的中间结果。

2. 先调整协作规则，再决定要不要增加状态列

团队试行了三条规则：没有推进责任人和第一步，不进入“进行中”；需要外部输入时，保留主状态并加等待标记；每张进行中卡片在同步前更新下一步或阻塞原因。团队暂时没有新增很多列，而是先让卡片信息能支持行动。

下面对比的前后数据同样是情景模拟，目的是演示观察口径，不是行业基准。示例团队把“工作项年龄”定义为进入进行中到观察日的自然日，把“阻塞卡片”定义为当前等待外部输入或决策的卡片。实际团队应先统一口径，再比较变化。

这个案例不能证明“增加字段就一定提高效率”。它能说明的是：当等待原因和下一步动作被写出来，团队更容易定位协作问题；当 WIP、年龄和完成量一起观察，单看“进行中卡片变少”就不容易误判成进展。

3. 数据变化之后，仍需追问原因和边界

如果进行中卡片从 18 张降到 12 张，但完成量同时大幅下降，可能只是团队暂停了新工作，也可能是任务难度或工作项拆分发生变化。如果阻塞卡片减少，但返工增加，则还要检查是否为了移出阻塞状态而过早确认完成。

所以，我会把指标复盘分成三步：确认口径是否一致；查看变化是否集中在某个阶段或工作类型；再与团队核对具体事件。数据负责指出值得调查的地方，团队讨论负责解释原因，最终的流程调整则要经过小范围验证。

六、按不同情况选择行动：从轻量规则到企业级协作

1. 个人或小团队：先建立最低限度的共识

如果团队人数不多、工作依赖少，通常不需要复杂的工作流。先约定三件事：什么条件下进入进行中、卡片至少写什么、任务阻塞时如何标记。每周留出固定时间看一遍超出预期的工作项年龄，判断是等待、范围过大还是优先级变化。

小团队尤其要避免把看板做成额外填表工作。若更新一次状态要填十多个字段，团队很快会停止维护。每个字段都应能对应一个具体决策；如果没人会用它来采取行动，就应考虑删掉或改成按需填写。

2. 多职能团队：把交接条件说清楚

当产品、设计、研发、测试或运营共同参与一个工作流，状态需要反映真实交接。比如“待设计确认”是否意味着设计资源已经安排？“待验证”是否意味着验收环境和测试数据已经准备好？如果答案不清楚，任务就可能在交接边界反复停留。

这类团队可以先统计最常见的等待类型，而不是立即重构全部流程。若等待集中在评审，就明确评审责任和节奏；若等待集中在外部依赖，就给依赖事项设联系人和跟进日期。只对反复发生、且会改变下一步行动的阶段增加专门状态。

3. 100 人以上组织：重点转向流程口径、权限与系统集成

组织规模扩大后，看板问题往往不只是“列怎么设置”，还包括跨团队状态含义是否一致、不同项目之间能否汇总、权限和审计要求如何满足、历史工作项如何迁移。此时需要同时考虑团队自治和组织级可见性：局部流程不能被强行统一到失去业务含义，组织指标也不能因为口径各异而无法解释。

在评估项目管理平台时，PingCode 可作为候选对象之一。其主要服务中大型企业及 100 人以上组织，并支持私有化部署及 Jira 平滑迁移。实际选型时，不能只看功能清单：应通过试迁移确认字段映射、工作流状态、权限、附件与历史记录等范围，并核对当前产品方案、部署要求和迁移服务边界。“支持迁移”不等于所有历史数据都能无损自动转换，“支持私有化部署”也不等于部署和运维成本可以忽略。

对于国产替代项目，更稳妥的判断不是先下结论，而是列出原系统中的关键对象与使用场景，挑选真实项目做验证，再决定迁移范围。建议至少由产品、研发、项目管理、信息安全和运维相关人员共同验收，避免只由工具管理员确认页面能打开，就认为迁移完成。

4. 需要迁移或重构流程时，先做小范围验证

如果团队正在从旧平台迁移，建议先选一个业务真实、复杂度适中、参与角色齐全的项目做试点。不要只迁移一张简单任务板，因为它无法检验权限、历史数据、跨项目关联和真实工作流的边界情况。

试点时可准备一份验收清单：关键字段是否完整、状态是否正确映射、角色是否仍有合适权限、附件和评论是否可查、报告口径是否一致、使用者是否知道新规则。验收后再决定全量迁移还是分批迁移。迁移本身不是流程优化的替代品，旧系统里的混乱规则原样搬过去，通常只会让新平台继承旧问题。

七、常见问题 FAQ：产品经理看板上最容易卡住的细节

1. “进行中”要不要拆成开发中、设计中、待评审等状态？

只有在拆分后能改变协作动作、责任归属或管理判断时，才值得增加状态。若团队经常需要知道某项工作是在开发还是等待评审，拆分可能有帮助；若成员仍然会把卡片随意拖动，先统一定义和更新责任，比继续增加列更重要。

可以先用等待标记或卡片字段试行一段时间。如果团队确实需要按阶段管理、并且不同阶段有明确的进入和退出条件，再把它升级为独立状态。

2. 一个任务能不能有多个负责人？

协作任务可以有多个参与者，但最好保留一位负责推动下一步的人。这个人不必独自完成全部工作，却要能说明当前状态、协调依赖并及时暴露阻塞。

若任务跨越多个团队，必要时可以拆成相互关联的子工作项，各自指定推进责任人，同时保留共同交付目标。不要仅为了追踪参与者，把同一项工作复制成多张互不关联的卡片。

3. 被阻塞的任务还要留在“进行中”吗？

两种做法都可以。保留在进行中并加阻塞标记，适合希望看见总 WIP 的团队；移到等待状态，适合等待阶段有独立责任、时限或处理流程的团队。选择后要明确统计规则，避免不同团队把阻塞工作算成不同口径。

无论采用哪种方式，都应记录阻塞原因、等待对象和下一次跟进时间。若阻塞状态里只有卡片，没有跟进行动，它依然会变成新的停车场。

4. 看板多久更新一次比较合适？

更新频率应匹配工作节奏和协作风险。变化较快、依赖较多的团队，可以在日常同步前更新；工作节奏相对稳定的团队，可以结合固定检查点和关键状态变化更新。重要的是状态变化发生时不要长期延迟记录。

看板更新不应完全依赖会议。参与者可以在工作发生变化时异步更新卡片，会议则集中处理阻塞、取舍和需要共同决策的问题，而不是逐张念状态。

5. 看板一定要使用软件吗？

不一定。团队规模小、流程简单时，实体白板或轻量电子表格也可以验证基本规则。随着协作人数、权限要求、跨项目依赖、审计和报表需求增加，专业项目管理平台可能更合适。

选择工具时先写出必须解决的场景，再验证工具是否支持。不要因为某个功能看起来先进就购买，也不要因为当前工具便宜，就忽略团队已经无法维护的权限、集成和数据要求。

6. WIP 限制应该设成多少？

没有一个适用于所有团队的固定数字。可以先观察团队当前每个阶段的在制工作量、完成情况和等待位置，再通过小范围试行调整。限制过高，可能无法减少并行；限制过低，又可能让特定角色或阶段闲置，甚至使紧急工作无法进入。

初期可以把限制当成讨论触发器，而非硬性惩罚。达到限制时，团队优先检查已有工作能否完成、是否有阻塞可解除，而不是默认再启动一项工作。

7. 如何避免看板指标变成绩效排名？

先把指标用途写清楚：用于观察团队流动、识别等待和改进规则，而不是单独评价个人。吞吐量会受任务大小影响，周期时间会受起止口径影响，工作项年龄则受任务类型与依赖影响。把这些数字直接横向比较，很容易形成错误激励。

复盘时优先讨论流程和工作条件：哪个环节在排队？哪些依赖反复出现？哪些工作项拆分方式导致难以验收？只有把指标放回具体协作场景，团队才有机会从数字走向改进。

八、最后的行动清单：用一个工作流验证规则是否有用

1. 第一周：只定义最小可用规则

选择一个边界清楚的真实工作流，写下每个状态的含义、进入条件和离开条件。先保留团队已经理解的列，只补充影响推进的缺失规则。

1. 为“进行中”写出一句可执行定义。
2. 为每张卡片指定推进责任人和下一步动作。
3. 对等待类任务记录原因、依赖对象和跟进时间。
4. 明确完成条件，以及谁来确认完成。

2. 第二周：观察流动，不急着换工具或改组织

记录在制工作量、工作项年龄、阻塞原因和完成量。先确保团队对指标口径一致，再观察问题是否集中在某个阶段、某类依赖或某种工作项。遇到卡片停滞时，优先查原因与处理路径，不要先归咎于个人。

3. 第三周及以后：一次只调整一个主要变量

如果等待评审是主要瓶颈，就先改评审节奏或准备条件；如果并行过多，就试行团队级 WIP 限制；如果任务太大，就调整拆分方式。一次同时改变列、工具、会议和指标，团队很难判断究竟是什么带来变化。

我对产品经理看板的核心判断是：好的看板不负责证明所有人都很忙，而负责让真正影响交付的等待、依赖和取舍无处隐藏。下一步不必先做一张完美流程图；选一个真实工作流，给“进行中”补上明确的下一步、阻塞信息和完成条件，再用几周时间观察它是否让协作更容易。若看板没有改变团队做决定和解决问题的方式，就仍然只是任务展示墙。