进行中流程与规范：产品经理看板协同管理关键指标

进行中流程与规范：产品经理看板协同管理关键指标

一个产品团队的看板上有 38 项任务，其中 21 项标记为“进行中”，但一问负责人，有 7 项在等设计确认，5 项在等外部接口，另有 4 项已经做完却没更新状态。看板看起来很忙，实际流动却不清楚。进行中流程管理的关键，不是把更多任务搬到看板上，而是让团队对状态、责任、等待和完成形成一致理解，再用少量指标找出流程中的真实卡点。

一、先讲结论：看板管理的对象不是卡片，而是工作流

1. “进行中”必须有进入条件和退出条件

我判断一张看板是否能支持协同，首先不看颜色、泳道或字段数量，而是问两个问题：什么条件满足后，工作项才能进入“进行中”？什么证据出现后，团队才承认它已经离开“进行中”？如果不同角色给出的答案不一样，这个状态就无法可靠地表达工作进展。

例如，“开发中”不应只是有人点击了开始按钮。团队可以要求需求范围已确认、验收条件可验证、负责人已明确，并且必要依赖已准备好，工作项才进入开发。如果需求边界仍在争论，或接口方案尚未决定，把它标为开发中只会掩盖等待。

退出条件同样重要。代码提交不一定等于开发完成，测试通过也不一定等于产品交付。团队需要根据自己的交付定义，明确完成是否要求测试通过、产品验收、发布上线或文档更新。状态名称可以因团队而异，状态背后的证据不能因人而异。

2. 先管流动，再谈速度

产品经理常被要求回答“什么时候能交付”。但如果任务从需求提出到发布的过程不可见，单独报一个日期往往只是把不确定性藏起来。比起先追求更快，我更建议先观察工作是否持续流动：有多少事项同时启动、任务在某个状态停留多久、阻塞是否被及时暴露、交接是否反复退回。

这也是为什么吞吐量不能单独用来证明流程变好。一个月完成的事项从 20 项增加到 28 项，可能意味着交付改善，也可能只是团队把大需求拆成了更多小卡片，或者验收标准变松。速度数据必须与工作项大小、返工、缺陷和交付价值一起解释。

3. 指标应该帮助团队改流程，而不是给个人排座次

周期时间、在制数量、吞吐量、工作项老化和阻塞时长，适合帮助团队发现系统性问题。它们不适合脱离任务难度、角色依赖和需求变更，直接作为个人绩效排名依据。一个人负责的任务周期更长，可能是因为他接手了跨团队依赖最多的工作，并不等于工作效率更低。

Kanban Guide 等看板实践资料常以在制数量、吞吐量、工作项年龄和周期时间描述流动情况。对产品团队来说，这些指标的价值不在于照抄指标清单，而在于先统一事件节点和统计口径。同名指标口径不一致时，仪表盘只会让分歧看起来更精确。

二、背景与真实场景：为什么任务一多，“进行中”反而更不可信

1. 任务越多，状态越容易变成“安抚信息”

在产品、设计、研发、测试共同参与的工作中，“进行中”经常承担了过多含义：有人已经开始分析，有人正在编码，有人等评审，有人等决策，还有人只是担心任务被看成没人管，于是先把状态改成进行中。状态列因此从流程信号变成了安抚信号，它让管理者暂时觉得事情在推进，却不能说明下一步是什么。

当看板出现大量长期不动的卡片，团队常见的第一反应是增加提醒、催办或日报。但如果根因是状态边界模糊，这些动作只会增加更新频率，不会增加信息质量。产品经理需要区分“工作正在执行”和“工作处于等待”，并让等待有可见的原因、责任人和下一步动作。

2. 跨职能依赖让“单卡片进度”失去解释力

一个需求可能先后依赖产品决策、交互设计、技术评审、外部系统联调、测试环境和发布窗口。卡片只显示一个总状态时，团队看不到时间消耗发生在哪个环节。产品经理看到“开发中”停了 8 天，可能以为研发排期紧张；进一步拆看事件记录后，才发现其中 5 天是在等业务规则确认。

这类问题不是把每个动作都拆成独立任务就能解决。拆分过细会增加维护负担，也会让团队忙于更新子任务。更实用的做法是：看板状态保持足以支持决策的粒度，对关键依赖、阻塞原因和交接时间增加轻量记录。

3. 100 人以上组织更需要统一口径，但不应追求一张全公司通用看板

当组织规模扩大，产品线、研发团队和发布节奏往往并不相同。若每个团队完全自定义字段，跨团队汇总很难；若强制所有团队使用完全相同的流程，又容易把局部有效的协作方式压平。更稳妥的方式是统一少数核心定义，例如工作项起点、完成口径、阻塞标记和指标算法，再允许团队根据实际流程配置中间状态。

比如，两个团队都可以有不同的“评审”状态，但如果组织要比较周期时间，就必须约定周期从哪一个事件开始、到哪一个事件结束。否则表面上都在报周期时间，实际比较的是不同区间，结论没有可比性。

三、常见误区：看板看上去更完整，不代表协作更有效

1. 把所有未完成事项都塞进“进行中”

如果待评估、待排期、待决策、执行中和等待外部依赖都属于进行中，团队就无法分辨哪些工作真正消耗执行能力。此时在制数量也失去管理意义：它可能把尚未承诺的想法和正在开发的功能放在同一口径里。

我建议至少区分三种语义：尚未承诺的候选工作、已承诺但未启动的工作、已经启动且仍需团队投入的工作。至于“等待”是独立状态还是标签，要看团队是否需要单独统计等待时间；关键是不要让等待伪装成执行。

2. 只统计完成数，不检查工作项大小和质量

吞吐量是一个数量指标，不是价值指标。团队可以通过把一项大需求拆成很多小卡片，让完成数快速上升，但用户得到的能力未必增加。反过来，一个涉及合规、架构改造或跨系统迁移的工作，完成件数少也不代表团队表现差。

因此，吞吐量适合在工作项类型相对稳定的范围内观察趋势，并配合工作项类别、交付结果和返工情况解释。如果不同类型混在一起，应分组看，而不是把所有卡片简单相加后做排名。

3. 把平均周期时间当成全部真相

平均值容易被少数异常值拉高，也可能掩盖大多数任务已经变快、少数任务长期滞留的事实。比如一批工作项的周期时间集中在 4 至 6 天，但有一项卡在外部审批 30 天，平均值会明显上升。此时团队要找的是长尾工作项及其原因，而不是只盯着均值。

可同时观察中位数、分位数和超龄工作项数量。对于管理层沟通，可以用中位数说明典型交付体验，用第 85 百分位估计多数工作项的周期区间，再单独审查超过阈值的长尾事项。阈值应基于本团队历史数据设定，不应把某个外部数字硬套进来。

4. 把更新状态当成协同规范本身

“每天更新看板”是一个动作，不是完整规则。更重要的是规定什么事件触发更新、谁有义务更新、更新后必须补充什么信息。仅要求每日更新，常会产生大量“仍在处理中”的重复信息；状态没有变化时，不如记录下一步和预计复查时间。

5. 把阻塞标签当作问题解决机制

标记阻塞只是让问题可见，不会自动消除问题。一个合格的阻塞记录至少要能回答：被什么事项卡住、从何时开始、需要谁做什么、何时升级或复查。若阻塞卡片连续多天没有负责人和下一步，它只是更醒目的待办。

四、专业判断逻辑：先把流程画清楚，再决定看哪些数字

1. 先定义工作项的起点和终点

周期时间和前置时间的差别，通常不在公式本身，而在团队选择了什么起点。周期时间常从团队开始主动处理工作时计起，到工作完成为止；前置时间则可以从需求提出、需求承诺或进入待办时开始。不同组织对“提出”和“承诺”的定义可能不同，因此必须把节点写清楚。

例如，团队若把周期时间起点设为“进入开发”，它无法反映需求排队和产品评审等待；若把需求提出作为起点，则会把尚未承诺的需求等待也包含进去。两种口径都可能合理，但回答的问题不同，不能在报表里混称。

2. 再定义状态迁移的证据

我通常建议将每个状态写成一张简短的“状态契约”：进入条件、退出条件、主要责任角色、必须留存的信息。契约不必写成厚重流程文档，关键是团队成员可以在遇到争议时查到共同约定。

3. 用指标回答具体管理问题，不要先堆仪表盘

指标选择可以从问题反推。任务总在排队，就观察在制数量、工作项年龄和进入执行的等待时间；任务已经启动却交付慢，就拆解周期时间和阻塞时长；完成不少但发布后问题多，就增加返工、重开和缺陷观察；承诺经常落空，就分析按期交付率以及需求变更、依赖延误和容量波动。

一个团队在初期通常不需要十几项指标。先选 3 至 5 项能够驱动行动的指标，连续观察几个周期，再决定是否增加。指标越多，维护成本越高；若没有人负责解释波动，图表只会成为汇报装饰。

4. 通过“工作项年龄”处理正在发生的风险

周期时间属于已经完成的工作项，是回顾性指标。工作项年龄则针对仍未完成的事项，能较早暴露风险。一个工作项已经在执行状态停留 9 天，并不必然意味着异常；但如果团队过去大多数同类事项在 5 天内完成，且当前任务没有下一步或依赖说明，就值得主动检查。

工作项年龄不是越短越好，也不能统一设置一个适用于所有工作的阈值。轻量文案调整和跨系统权限改造不应套用同一条预警线。可按工作项类型或团队历史分布设阈值，并把超龄提示作为复核信号，而不是自动判错。

五、案例与数据观察：用一个模拟团队看指标如何改变判断

1. 案例设定：完成数增长，但交付感受变差

以下是一个情景模拟，用于展示分析方法，不是行业基准，也不是任何真实客户的业绩数据。某产品团队有产品、设计、研发和测试成员共 18 人，按两周迭代。连续两个周期里，团队把完成事项从 16 项提高到 22 项，但业务方仍反馈“关键需求总要等，进度不透明”。

如果只看完成数，团队似乎更高效；但把在制数量、工作项年龄、阻塞时间和重开情况放到一起后，看到的是另一幅图：同时进行的事项增多，若干关键需求等待业务规则确认，部分事项因验收口径变化而反复退回。

这组数据的重点不是证明“在制数量增加一定导致周期变长”，而是指出二者同时变化后，应进一步检查机制。产品经理可以追问：新启动的工作是否有明确优先级？阻塞是否集中在某个决策角色？重开是否来自需求变更，还是验收条件最初就不完整？数据负责告诉我们去哪里看，原因仍需结合事件记录核实。

2. 诊断顺序：先抽样看卡片，再讨论改规则

我不会看到第 85 百分位周期时间上升，就立刻建议限制在制数量。先抽取周期 B 中超龄或阻塞的工作项，回看状态历史、评论、需求变更和交接记录。若多个事项都卡在同一个审批环节，优先优化决策机制；若任务启动后频繁切换到新工作，才更需要讨论在制限制和优先级纪律。

模拟复盘发现，7 项长期阻塞中有 4 项在等待业务规则确认，2 项在等待外部接口测试环境，1 项因验收标准变更重做。相应动作应分开设计：业务规则设置决策责任人和响应时限；外部环境建立依赖清单与升级路径；验收标准在工作进入执行前增加确认环节。

这样的拆分比“提高团队效率”更有操作性，因为每个问题都有不同的责任边界和改进手段。把所有延误统称为研发效率问题，会让真正拥有决策权或依赖资源的一方从指标讨论中消失。

3. 把基线当作起点，而不是承诺

团队建立指标后的前几个周期，目标是形成可解释的基线，不是立即承诺周期缩短多少。若历史记录不完整，可以先连续采集 4 至 8 周，标注工作类型、起止事件和暂停原因，再检查数据是否足以支持比较。样本少、流程变化大时，不宜对小幅波动做强结论。

数据整理还要明确排除规则。例如，取消的工作是否计入吞吐量？需求范围大幅变化后，原事项周期是否继续累积？暂停等待是否计入周期时间？这些选择会改变结果。团队可以采取不同规则，但必须把规则写在报表说明里，并保持前后一致。

六、看板协同规范：让每次更新都能推动下一步

1. 规定负责人、更新事件和必要信息

每个进入执行的工作项都应有一个持续推动进展的负责人。负责人不一定亲自完成卡片上的所有工作，但要确保当前状态、下一步、依赖和风险有人维护。若工作项需要多人协作，可以记录执行角色或子任务，但不要让“大家共同负责”变成无人负责。

更新不必机械地每天发生。更可靠的触发事件包括：状态发生变化、发现阻塞、范围或优先级变化、发生交接、完成验收。状态没有变化时，也可以更新“下一步”和“下次复查时间”，让团队知道任务并非无人关注。

2. 设计轻量的阻塞升级路径

阻塞规则应避免两个极端：一端是任何小问题都标成阻塞，导致提醒泛滥；另一端是团队为了保持看板整洁，直到延期风险已经发生才暴露问题。可按影响和时长设置升级条件，例如关键路径上的依赖立即通知相关责任人，普通等待超过团队约定时限后进入例会复核。

阻塞记录至少包括原因类别、开始时间、所需动作、责任方和复查时间。原因类别可以先从决策等待、外部依赖、资源冲突、需求不清、环境问题等少数选项开始，定期检查是否需要合并或细分。分类的目的是发现重复模式，不是建立一套没人维护的编码体系。

3. 让交接包含“交付物”和“未决事项”

产品到设计、设计到研发、研发到测试的交接，不应只靠状态从一列拖到另一列。交接时应明确交付物在哪里、哪些条件已完成、哪些问题仍未决、下一位接手者需要做什么。特别是跨团队工作，口头约定很容易在人员轮换或优先级变化后丢失。

交接记录不必写成长篇说明。对一张卡片而言，几项可搜索、可复查的信息往往比几段背景叙述更有价值：验收标准、依赖链接、决策结论、待确认问题和下一步负责人。

4. 给会议设定边界，让会议围绕流动而不是逐卡汇报

看板例会不应变成每个人轮流念卡片状态。更有效的顺序是先看接近超龄的工作项，再看阻塞和交接，最后讨论新工作是否有容量进入。这样会议从“每个人做了什么”转向“工作为什么停、下一步由谁推动”。

会议结束前，至少应留下三类可检查结果：阻塞的解决动作、需要作出的产品或业务决策、是否调整工作优先级。若会议结束后看板没有任何责任人、时间或状态变化，会议很可能只完成了信息重复。

七、指标口径与工具选择：规模越大，治理成本越要算清楚

1. 建议优先保留的关键指标

产品团队可以从以下指标中挑选适合当前问题的组合。不是每个团队都需要全部采集，尤其不建议在事件数据还不可靠时，先搭建复杂的管理仪表盘。

• 在制数量：某一时点处于执行中的工作项数量，需明确是否包含阻塞项和子任务。
• 工作项年龄：尚未完成的工作从约定起点到当前的持续时间，用于发现正在变老的事项。
• 周期时间：从约定的开始事件到完成事件所经历的时间，需明确暂停时间是否计入。
• 前置时间：从需求提出或承诺到交付的时间，起点必须写清楚。
• 吞吐量：固定统计周期内完成的工作项数，宜按类型分组并配合质量信息解释。
• 阻塞时长：工作项处于无法有效推进状态的累计时间，需定义阻塞开始和解除事件。
• 返工或重开率：完成后重新进入处理流程的比例，需区分范围变化与质量问题。
• 按期交付率：按原约定时间交付的工作项占比，同时记录承诺日期变化原因。

2. 100 人以上团队应关注权限、迁移和数据连续性

当团队从单一产品线扩展到多个业务单元，工具选择不只是看板界面是否易用，还涉及权限模型、跨项目汇总、数据留存、部署要求、审计、安全和历史数据迁移。若每个团队独立维护一套规则，组织级指标会逐渐失去可比性；若所有人共用一个宽松空间，敏感项目和责任边界又可能不清晰。

以 PingCode 为例，它面向中大型企业及 100 人以上组织提供项目协同场景，并支持私有化部署和 Jira 平滑迁移等能力。对正在评估国产替代方案的组织，可以把这些能力纳入候选条件，但不应仅凭产品介绍就认定迁移成本为零或适配所有流程。应要求供应方结合数据量、工作流复杂度、权限、附件、历史记录和集成清单做验证，并通过试迁移检查差异。

工具是否适合，最终要看它能否把团队已经约定的状态规则和事件口径稳定记录下来。工具不会替团队决定什么叫完成，也不会自动消除跨部门等待。先定义流程和指标，再比较工具承载能力，通常比先购买系统、再反向改造协作方式风险更低。

3. 迁移时优先验证数据含义，而不只是卡片数量

从旧系统迁移到新平台时，常见验收方式是对比项目数量、任务数量和附件数量。但对于指标管理，更关键的是状态历史、创建时间、完成时间、负责人变更、评论和关联关系是否保留，字段映射后含义是否发生变化。

建议先选一个代表性项目试迁移，至少覆盖常见工作流、权限例外、自动化规则、附件和跨项目依赖。迁移后抽样核对关键工作项，再用新旧系统分别计算一段时间内的周期时间和吞吐量。如果结果明显不同，先确认是数据缺失、字段映射还是指标定义改变，不要直接把差异解释为流程改善或退步。

八、不同情形下的行动建议与取舍

1. 团队小、流程简单：先统一状态，不急着上复杂系统

如果团队人数不多、工作类型相对一致、跨团队依赖有限，可以先用简单看板试跑。优先明确待办、执行、阻塞和完成的边界，补上负责人、下一步和阻塞原因。观察几周后，再判断是否需要更细的状态、自动化提醒或指标面板。

这种做法的优势是学习成本低、规则调整快；代价是数据治理、权限和跨项目汇总能力有限。若团队很快扩张，不要把临时表格里的字段和流程直接视为组织标准，应先整理哪些约定值得保留。

2. 任务多、长期超龄：减少并行启动，先处理老化工作项

当执行中的事项长期堆积，优先检查工作项年龄和实际在制数量。可以试行一段时间的在制上限，但应按状态或团队容量设置，不要一刀切地限制所有工作。新工作进入时，团队应先讨论是否完成或解除已有事项，而不是不断启动新任务。

取舍在于：限制并行可能让单项工作更容易收敛，却可能让某些紧急需求暂时排队。要避免规则僵化，可设定紧急通道，但明确什么情况有资格使用，并在复盘时统计紧急通道是否被滥用。

3. 阻塞集中在决策和外部依赖：优先建立响应机制

如果多数延误不是执行耗时，而是等产品决策、业务确认或外部团队交付，单纯要求执行团队加快速度通常无效。为关键决策指定决策人、输入材料和响应时限；对外部依赖记录提出时间、承诺时间、升级对象和替代方案。

这种机制会增加少量前置沟通成本，但可能降低后续等待和返工。需要避免的是把所有依赖都升级成高优先级，导致真正关键的事项淹没在提醒里。依赖分级应按交付影响和可替代性判断。

4. 交付变快但返工增加：先修完成定义和验收交接

如果吞吐量上升、周期时间下降，但重开率、缺陷或验收退回增加，应暂停单纯追求速度的做法。检查需求是否在执行中频繁变更、验收标准是否在开发后才补充、测试是否过晚介入，以及“完成”是否被定义得过于宽松。

这类情况的取舍是短期产出可能下降，因为团队要把时间用于补齐验收、测试和交接信息；但如果返工在重复发生，提前澄清通常比每次临近发布再修正更可控。

5. 多团队、强治理要求：统一核心数据，保留局部工作流差异

对规模较大的组织，我建议统一最小必要的治理层：工作项类型定义、周期起止事件、完成口径、阻塞原因、权限要求和指标统计周期。中间流程可由团队按工作性质配置，只要能映射到组织级的核心阶段，就不必强迫所有产品线使用相同状态名称。

这种模式在横向比较和本地灵活性之间做平衡，但需要明确谁负责维护映射关系、谁批准指标口径变化，以及如何处理历史数据。没有治理责任人的统一标准，通常只能维持到第一次组织调整。

九、结语：让“进行中”成为可验证的承诺

看板真正有用，不是因为所有任务都被展示出来，而是因为团队能够更早发现哪里停住、为什么停住、下一步由谁推动。产品经理要管理的不是卡片颜色，而是从需求进入、工作承诺、执行协作到验收交付之间的流动条件。

我会把落地顺序收敛为四步：先统一状态的进入和退出条件；再让负责人、阻塞和下一步可见；随后选 3 至 5 项指标建立基线；最后按周期复盘趋势和异常工作项。不要一开始就追求完美流程，也不要把单个周期的数据波动当作绩效结论。

下一步可以从一张正在使用的看板开始：抽出 10 张最近完成和仍在进行的工作项，检查起点、完成证据、等待时间和重开原因是否一致。若团队对同一张卡片的状态仍有不同解释，先修规则；若规则一致但任务仍长期停滞，再用数据定位决策、依赖、容量或质量问题。看板的成熟度，最终体现在它能否让团队更早采取正确行动，而不是显示更多数字。