进行中管理指南：产品经理如何做好看板，制度设计全流程

看板上最危险的信号，不是“没有任务”，而是每张卡片都有负责人、每一列都排得满满当当，却没人说得清哪些工作真正正在推进、哪些只是挂在“进行中”等待。产品经理要做好进行中管理，关键不是把看板画得更细，而是让团队就任务何时进入、怎样流转、遇到阻塞怎么办，以及什么条件下算完成，形成一套能执行、能观察、能调整的规则。

进行中管理指南：产品经理如何做好看板，制度设计全流程

一、先给结论：看板不是任务陈列墙，而是团队的流动规则

1. 看板的价值取决于规则，而不是列数

我判断一块看板有没有管理价值，通常不先数它有几列，也不先看颜色是否统一，而是追问三个问题：团队能不能看出工作卡在哪里？超过约定的工作量之后，大家知道怎么处理吗？一项工作从进入到完成，是否有明确的判断依据？如果这三个问题答不上来，看板更像任务列表，不是工作流管理机制。

看板可以把需求、设计、开发、测试、发布等活动呈现在同一视野里，但“可见”只解决了信息缺失的一部分。卡片显示“开发中”，并不意味着开发正在发生；它也可能在等待接口、等待业务确认，或等待某位关键同事有空。看板要呈现的是工作状态及其流动条件，而不只是任务所在的列。

2. 进行中管理要同时管理工作量、等待和承诺

“进行中”通常不只代表有人正在动手。团队实际工作里，它还可能包括被领取但尚未启动的事项、等待外部依赖的事项，以及已经完成主要工作但还未通过验收的事项。如果这些状态混在同一列，管理者很容易把等待误判为执行，把卡片数量误判为团队产能。

我会把进行中管理拆成四个可讨论的对象：在制品数量、工作流动时间、阻塞原因、优先级变更。它们彼此相关，却不能互相替代。限制在制品数量不能自动清除阻塞，标注阻塞也不能解决优先级冲突，缩短某一环节的耗时更不一定意味着整体交付更快。

3. 先定义完成，再倒推进行中的边界

如果团队对“完成”没有共识，前面每一列都会逐渐失真。产品需求的“完成”可能意味着验收通过并上线，也可能只意味着开发完成；这两种口径对应的周期时间、吞吐量和团队承诺都不同。搭看板时，我建议先把交付终点写清楚，再沿着工作实际发生的路径倒推状态。

这也意味着，产品经理不应单方面规定所有列名和卡片字段。产品、设计、研发、测试和相关业务角色都需要参与，至少要确认工作如何交接、哪些信息是交接前提、谁有权改变优先级。制度不是为了让团队服从一块看板，而是为了让协作中的默认规则显性化。

二、背景与真实场景：任务很多，不代表工作真的在流动

1. 一个常见的产品团队现场

下面用一个明确标注的情景模拟说明问题，不代表真实客户案例或行业统计。某产品团队有产品、设计、研发和测试成员，当前看板把任务分成“待办、进行中、测试、完成”四列。每周计划会结束时，团队看起来接手了不少需求；到了周中，产品经理却发现多个事项停在“进行中”，有的在等原型确认，有的在等第三方接口，还有的只是开发完成、尚未进入测试。

团队最初的直觉是再增加几列，把“进行中”拆成“设计中、开发中、联调中、待测试”。拆列能提高状态可见度，但如果没有写清每列的进入和退出条件，旧问题只会被切成更多小格子。卡片从一个模糊状态移动到另一个模糊状态，数据更细了，决策却没有变容易。

在这个情景里，真正值得先查的是：需求进入时是否具备可执行信息；未开始和正在执行的任务是否被混放；外部等待是否单独标记；测试资源是否成为持续瓶颈；插入的新需求是否挤掉了已有承诺。只有把原因分开，团队才能判断应该改规则、补资源，还是减少并行工作。

2. “满屏进行中”为什么会制造虚假的安全感

当每个人手上都有多张卡片时，管理者容易觉得工作分配充分，团队利用率很高。但对交付而言，任务被分配不等于任务正在完成。切换上下文、等待决策、依赖他人输入，都会让工作停在“有人负责”的状态里。看板上的忙碌感，可能掩盖了任务年龄不断增长的事实。

Little 定律给出一个有用的观察关系：在相对稳定的系统中，平均在制品数量约等于平均吞吐率乘以平均周期时间。它不是一条可以直接套出团队目标的公式，却提醒我们：如果吞吐率没有相应变化，长期增加在制品，通常会伴随更长的平均流动时间。需求类型、工作复杂度和系统稳定性不同，不能把这个关系误读为“所有团队都应该把任务数降到某个固定值”。

因此，我不会先替团队拍板说“每人只能做一件事”或“研发列最多放五张卡”。我会先观察工作量、任务年龄和交付节奏，再与团队一起试行限制。WIP 上限的意义不是惩罚超出数字的人，而是让超载成为需要共同处理的信号。

3. 先区分“看不见”与“做不动”

看板失效经常被归结为“大家不更新”，但这只是可能原因之一。如果状态无法代表真实工作，成员即使认真更新，管理者仍会得到错误信息；如果任务更新得很及时，却长期等业务决策，问题也不在状态维护，而在决策机制。

我会先区分两种情况。第一种是信息可见性不足，例如卡片没有负责人、验收标准和阻塞原因。第二种是流动能力不足，例如瓶颈环节处理容量不够、跨团队依赖无法及时响应、优先级不断改变。前者适合补齐最必要的信息和更新责任，后者需要调整工作入口、依赖处理和容量安排，不能只靠更换看板工具解决。

三、拆解常见误区：哪些做法会让看板越来越忙、交付越来越慢

1. 误区一：列越细，管理就越精确

把流程拆细有时是必要的，但每增加一列，也增加了状态维护、交接和解释成本。若团队说不清“待评审”和“评审中”的区别，新增状态只会制造新的争论。反过来，如果测试等待长期藏在开发状态里，细化工作流就可能揭示真实瓶颈。

我会用一个实用标准决定是否新增状态：这个状态是否代表独立的工作阶段、是否需要不同的处理动作、团队是否需要基于它作出不同决策？三项都没有明确答案，就先别加列。列的数量没有跨团队通用的标准，状态的决策价值才是判断依据。

2. 误区二：卡片移动了，就说明任务推进了

有些团队把“每天把卡片往右挪”当作看板运行良好的证据。实际工作中，卡片移动可能只是人员交接，甚至是为了让状态看起来更整齐。真正的推进要看任务是否完成了该阶段的工作、是否满足进入下一阶段的条件，以及交接所需信息是否齐备。

每个关键状态都应有进入条件和退出条件。例如，“待测试”可以要求开发自测完成、变更说明可用、测试环境具备；“完成”可以要求验收通过、必要文档更新、发布决策完成。条件不必写成长篇流程文件，但应能让不同成员对同一张卡片作出相近判断。

3. 误区三：设置 WIP 上限，就是要求每个人少接活

WIP 限制针对的是工作系统中的并行负荷，不是简单给个人加一道数量考核。若某列超限，管理者应该和团队一起判断：是否有任务可以协作完成、是否存在阻塞待升级、是否需要暂停新工作、是否因为紧急事项破例，以及破例带来的影响由谁确认。

如果上限设得过低，却没有团队协作和补位机制，成员可能把工作移到看板之外，形成隐藏在制品；如果上限过高，又容易退化为没有上限。较稳妥的做法是先观察当前分布，提出试行值，明确超限时的处理动作，再通过周期时间、任务年龄和吞吐变化复盘。试行值是团队假设，不是行业定律。

4. 误区四：每天逐人汇报，等于做好了看板管理

逐人轮流报“昨天做了什么、今天做什么”，容易把注意力放在个人活动上，却忽略工作如何流动。团队检查可以从任务出发，优先讨论最接近完成但仍有风险的工作、年龄较长的工作、阻塞事项和超限状态。这样更容易把协作资源投向系统瓶颈，而不是让每个人重复读一遍卡片。

管理者也要避免用日常检查制造“每张卡必须每天有变化”的压力。复杂工作可能需要数日才能完成一个阶段；关键是状态真实、风险可见、下一步明确，而不是每天都发生形式上的移动。

5. 误区五：用个人完成数量给团队排座次

吞吐量、周期时间和在制品年龄适合帮助团队发现流程问题，但不宜直接变成个人绩效排名。不同任务大小、复杂度、依赖数量和质量要求并不相同。若个人完成卡片数量成为目标，团队可能倾向于拆小卡片、挑简单任务，甚至把困难工作推给别人，最终指标变好看，系统交付能力却未必改善。

我更愿意把指标当作提问工具：为什么某类任务的等待时间上升？为什么某一阶段的工作年龄持续偏大？为什么平均周期变短，但返工或线上问题增加？指标先用来定位问题，再由团队检查原因，而不是直接判定谁做得好或不好。

四、专业判断逻辑：从真实工作流到可运行的制度

1. 先沿任务走一遍，而不是先画模板

我建议产品经理选取近期已经交付、取消或延期的几项工作，逐项还原它们实际经历的阶段。不要先把理想流程写出来，而要看需求从哪里进入、谁补充信息、哪些环节交接、哪里等待、哪些工作会返工，以及最终由谁确认完成。

这样做的价值在于减少“流程图上的工作”和“团队真正做的工作”之间的距离。若团队有多个产品线，或研发、测试资源共享，最好分别观察不同类型的工作，而不是把所有任务混成一条平均流程。不同任务类型可能具有不同的等待来源和交付路径。

2. 用进入、退出条件定义状态

状态设计可以先从最少集合开始。一个阶段如果没有独立的工作内容、没有明确的进入和退出条件，也没有对应的责任交接，通常不需要单独成为一列。比如“待澄清”是否独立，取决于团队是否需要专门跟踪补充信息；如果需求入口经常因信息不足而返工，这个状态就可能有管理价值。

建议团队为关键状态写一张简短的规则卡，至少包含状态含义、进入条件、退出条件、更新责任和超时或异常时的处理方式。规则不必追求法律条文般完整，能让新人理解、让团队在争议时有共同参照就够了。

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

阻塞标记不是目的。一个可用的阻塞记录，至少要让团队知道卡在哪里、影响什么、下一步由谁推进。可按团队特点记录阻塞类型，例如待业务决策、外部系统依赖、环境不可用、验收口径不清、资源冲突等。分类不宜过细，只有当分类会触发不同处理方式时，才值得保留。

我会要求阻塞卡片附上一个明确动作，而不只是写“被阻塞”。例如“需要业务负责人确认字段口径，由产品经理在本次优先级检查前发起确认”。这种表达把状态转为可执行事项，也让团队能够观察阻塞原因是否反复出现。具体升级时限应结合工作节奏、影响范围和团队约定，不建议未经验证就设一个对所有事项都适用的统一时限。

4. 用 WIP 上限建立超载后的协作动作

设置在制品上限前，先确定限制对象：它是限制某个阶段、某类工作，还是整个团队的活跃事项？如果把产品探索、紧急线上修复和常规迭代任务放在一起计数，数字可能失去解释力。必要时可以按工作类别设置不同通道，但通道越多，管理和比较也越复杂。

上限真正落地，需要写清“超出后怎么办”。例如团队暂缓从待办领取新任务，先处理接近完成的卡片；或由成员结对清理一个瓶颈阶段；或由负责人确认是否属于紧急例外，并记录被挤出的原任务。没有动作的上限只是看板上的装饰数字。

5. 把插单规则写成例外管理，而不是默认入口

产品工作难免有临时事项，但“随时插入”一旦变成常态，原有优先级就无法保持可信。团队需要明确谁能提出紧急请求、谁作最终决策、判断紧急的条件是什么、插入后原有承诺如何处理。若新任务进入却没有任务退出，团队承担的实际工作量就会不断扩大。

我会建议为例外保留可见记录，包括插单理由、决策人、受影响工作和后续复盘结论。这样做不是为了阻止变化，而是让变化的成本可见。若同类紧急事项反复发生，应该回头检查需求入口、容量规划或业务协同机制，而不是长期依靠个人加班吸收。

五、具体案例与数据观察：用情景模拟检验规则，而不是编造成功故事

1. 情景设定：共享测试能力导致卡片堆积

以下数据全部为情景模拟，用来展示观察方法，不是某个真实团队的结果，也不应当作行业基准。设想一个产品团队在连续四周内记录需求卡片：需求进入后经过产品确认、设计、开发、测试和交付；团队发现开发列并不拥堵，真正积压的是等待测试的事项，而“进行中”没有区分执行与等待。

团队先做两项小改动：将“待测试”从“开发中”中独立出来，并要求卡片进入测试前满足约定的自测与说明条件；同时对测试等待事项记录开始等待时间、阻塞原因和下一步处理人。试行期间没有增加测试人员，也没有声称工具本身提升了效率，重点是验证可见性和交接条件是否改变了工作流。

2. 前后对比应关注一组指标，而不是单一百分比

在这个模拟里，团队以四周为基线，再观察后续四周。周期时间按“团队承诺启动”到“验收完成”计算；吞吐量按每周完成并验收的工作项数统计；等待时间按进入待测试到开始测试的时间记录；返工比例按需要退回补充自测或验收信息的事项占比计算。

假设试行前四周，平均每周验收完成 8 项，平均周期时间 12 天，待测试等待中位数 4 天，因交接信息不齐而退回的事项占 25%。试行后四周分别观察到每周完成 9 项、平均周期时间 10 天、待测试等待中位数 2.5 天、退回占比 11%。这些数字只能说明这个模拟情境中的多项指标朝预期方向变化，不能据此断言规则必然导致变化，更不能把样本结果外推成所有团队的收益承诺。

如果同期需求难度下降、测试资源增加，或团队改变了任务拆分口径，这些因素都可能影响结果。因此，前后对比至少要保持任务范围、统计口径和观察周期尽量一致，并记录期间发生的重大变化。有用的数据不是能证明看板有效的数据，而是能帮助团队发现解释不通之处的数据。

3. 用在制品年龄识别“看起来正常”的老任务

平均周期时间适合回顾已经完成的工作，但未完成的卡片更需要关注年龄。假设团队通常在 10 天左右完成某类工作，一张已持续 18 天仍未完成的卡片，即使还没有计入最终周期时间，也已经是值得检查的异常信号。这里的 10 天仅为情景示例，不能替代团队对自身工作类型的基线判断。

看板可以通过任务年龄、阻塞标识和下一步动作，帮助团队在任务完成之前发现风险。产品经理可以优先检查年龄明显偏离同类工作分布的事项，而不是把所有卡片平均对待。对刚开始的工作，不必因为年龄短就忽视输入不完整；对已接近完成却长期等待的事项，也不要因为进度百分比很高就默认它没有风险。

4. 把数字变成复盘问题

数据复盘应当从“发生了什么”走到“系统为什么这样运行”。如果周期时间变长，先看是处理时间增加还是等待时间增加；如果吞吐量减少，判断在制品限制是否过紧、工作复杂度是否变化、瓶颈是否转移；如果返工减少，确认是交接条件更清楚，还是任务被拆得更小、统计范围发生了变化。

建议产品经理保留一份简洁的试行记录：试行假设、变更规则、统计口径、观察周期、同期变化、团队反馈和下一步决定。这样即使试行没有改善指标，也能得到信息：某个规则可能不适用于这类工作，或者真正的瓶颈并不在看板列上。试行失败不是浪费，未经记录的反复改动才容易浪费。

六、工具与规模选择：先选治理方式，再选承载工具

1. 小团队与跨部门组织，关注重点并不相同

小团队通常可以用较轻的方式试行：一块共享看板、少量状态、清楚的阻塞记录和固定复盘节奏。工具是否提供复杂权限、自动化和跨项目报表，未必是最先要解决的问题。先确认成员是否愿意共同维护规则，以及看板是否能准确映射真实工作。

当团队扩展到多产品线、多研发组，或组织规模达到 100 人以上时，管理复杂度通常不再只是卡片数量增加。跨团队依赖、权限边界、工作流差异、项目视图、历史数据迁移和统计口径一致性，都会影响看板能否持续使用。此时，选型应从治理要求和协作结构出发，而不是只比较单个页面的视觉体验。

2. 评估工具时，把规则、数据与组织要求放在一起

我会建议企业先准备一组真实工作场景，再拿候选工具验证，而不是只看功能清单。至少应包含：常规需求流转、紧急插单、跨团队依赖、阻塞升级、权限隔离、历史数据迁移、指标口径核对，以及离线或私有化环境的部署要求。

例如，PingCode可以作为中大型企业及 100 人以上组织评估项目管理平台时的候选之一。若组织确有私有化部署要求，或需要评估 Jira 平滑迁移，可将这些要求列入正式验证范围；是否适合，仍应通过迁移演练、权限与数据核验、关键工作流验证和实际用户试用来判断。“支持某项能力”与“适合某家企业落地”不是同一个结论。

涉及国产化替代时，也不宜把“替代”简化成界面相似或功能列表接近。需要核验数据导入导出、历史记录保留、权限模型、自动化规则、接口依赖、用户培训成本、运维能力与供应商服务边界。迁移前应选取代表性项目做小批量演练，检查任务关系、附件、评论、成员权限和状态映射是否符合预期。

3. 什么时候应该保留现有工具

如果团队的主要问题是状态定义混乱、插单无规则、卡片长期不更新，换工具通常不能自动解决这些问题。更稳妥的做法是先在现有环境中试行简化规则，确认工作流本身可运行，再判断工具是否限制了必要的权限、可视化、自动化或跨团队协作。

相反，如果组织有明确的私有化要求、迁移窗口、跨项目治理或审计需求，且现有工具无法满足，继续用表格或多套系统拼接也可能累积数据风险。此时应把迁移视为业务改造项目，设置负责人、验证样本、回退方案和用户培训计划，而不是把工作压缩成一次数据导入。

七、不同情况下的行动建议与取舍

1. 如果看板状态经常不准确

先不要急着增加自动提醒或要求成员每天汇报。选择一周做状态抽样：核对卡片当前状态、实际工作状态、更新时间和下一步动作。然后找出失真最严重的状态，检查是否因为定义不清、更新责任不明，或状态变化对成员没有实际帮助。

如果成员不愿更新，先询问更新是否重复录入、是否需要维护过多字段、是否能看到信息被团队使用。减少无效字段，明确由当前处理人更新关键变化，通常比单纯增加提醒更值得先试。自动化能降低重复操作，但不能替团队判定真实状态。

2. 如果“进行中”积压明显

先区分活跃处理与等待事项，再观察任务年龄、阻塞原因和各阶段积压。若等待集中在一个环节，团队应优先讨论该环节的容量、交接条件和外部依赖；若各环节都在积压，则可能是入口工作量超过整体交付能力，需要重新审视需求承诺和插单机制。

试行 WIP 限制时，不必一次限制所有列。可以挑选积压最明显的阶段，设定短周期试行和明确的超限动作。若上限导致大量任务留在列外、隐性工作增加，说明限制对象或规则设计有问题，应及时调整，而不是把遵守数字当成目标。

3. 如果业务优先级频繁变化

团队需要把“变化可以发生”与“变化不需要承担成本”区分开。建立一个明确的优先级决策入口：谁可以提出变化、由谁批准、紧急事项如何定义、原任务是否暂停或取消、变化是否影响已承诺的交付时间。决策规则越清楚，产品经理越不需要在每次插单时临场解释。

如果高优先级变更频繁到无法形成稳定观察周期，可以考虑单独设置紧急工作通道，并记录进入数量和占用容量。是否设置独立通道取决于紧急工作的性质与频率；通道太多会使团队难以管理，紧急事项也可能被包装成绕过正常优先级的捷径。

4. 如果团队正在从个人任务管理转向跨职能协作

不要只把成员名字从任务卡上删掉，也不要假设每张卡都必须由多人共同负责。可以保留明确的当前责任人，同时补充协作角色、依赖方和验收责任，让团队知道谁推动下一步、谁提供输入、谁确认完成。

这种情况下，更值得观察的是交接等待、阻塞时长和返工原因，而非个人卡片数。若同类交接问题持续出现，可以尝试统一交接条件或设置跨职能的短会检查；若问题来自组织权限或外部决策，日常同步只能暴露问题，仍需要正式升级路径。

5. 如果组织规模较大或准备迁移平台

先梳理必须统一的治理规则与允许保留差异的团队实践。企业可以统一状态术语、数据口径、权限底线和跨团队依赖规则，同时允许不同业务线保留必要的工作阶段。过度统一会迫使真实流程迁就模板；完全不统一又会让跨团队数据失去可比性。

迁移时优先选择代表性项目进行验证：既包括规则简单的项目，也包括依赖多、权限复杂、历史数据丰富的项目。确认导入结果、用户操作、报表口径和运维流程之后，再分批推广。若无法确定迁移失败时如何回退，说明迁移方案还没有达到可执行状态。

八、结尾：先让一张卡片说真话，再让整块看板变得有用

1. 从一个小范围试行开始

看板制度不必一次写成庞大的流程手册。下一步可以从一类近期反复积压的工作开始，和团队共同完成四件事：画出真实流转路径，为关键状态写明进入与退出条件，约定阻塞与插单处理方式，选择少量指标观察变化。随后设定一个团队能实际执行的复盘周期，保留有效规则，删除增加负担却没有帮助的要求。

试行时尤其要记录规则的适用边界。常规需求的 WIP 限制，不一定适合线上故障；某条产品线的状态设计，不一定适合探索性工作。看板规则可以有差异，但差异应当是团队有意识作出的选择，而不是同一组织里各自理解、互不兼容的偶然结果。

2. 独特的判断标准：看板有没有帮助团队更早采取正确动作

我不会用“看板是否整齐”“卡片是否每天移动”来判断制度是否成功。我会看团队能否更早识别超载，能否在任务真正逾期前发现阻塞，能否更透明地处理优先级变化，以及能否用同一套口径解释交付数据。如果看板让这些判断更及时、更一致，它就在发挥管理价值。

产品经理做好进行中管理，不是把每个人的工作都管得更细，而是让团队更早看见系统正在失去流动的地方。先从一张长期卡住的任务查起，确认它为什么没动、下一步由谁推动、哪些规则能避免同类问题再次发生。让一张卡片先说真话，比先画一张更复杂的看板更重要。