进行中流程与规范：项目经理看板入门指南关键指标

进行中流程与规范：项目经理看板入门指南关键指标

项目看板上有 27 项工作显示“进行中”，但本周只完成了 4 项，这不一定说明团队效率低，却足以提醒项目经理：只看任务状态，往往看不出工作是否在流动。真正有用的看板，要能回答三个问题：工作堆在哪里、为什么停住、接下来谁采取什么行动。本文用一组明确标注为情景模拟的数据，拆解进行中流程的定义、关键指标、解读方法与落地规范。

一、先看核心结论：指标不是装饰，而是决策入口

1. 看板首先要呈现工作流，而不是堆满数字

我判断一张项目看板是否有用，不先数上面有多少张卡片，而是看管理者能不能从一个异常信号，顺着看板找到具体事项、停留阶段、阻塞原因和下一步动作。如果看板只能告诉我“有 27 项进行中”，却不能解释其中哪些需要关注，它只是状态墙，不是管理工具。

项目经理入门阶段，优先追踪五类信息：进行中工作量、完成吞吐量、周期时间、未完成事项的停留时长，以及阻塞项。这些信息相互补充：工作量说明同时开了多少工作，吞吐量说明完成流速，周期时间描述已完成工作的过程，停留时长帮助识别尚未完成的风险，阻塞信息则把异常转成协调任务。

这五类指标不是一组可以直接套用的绩效评分。它们的价值在于形成连续判断：先看到工作堆积，再检查哪个环节变慢，随后追问原因，最后确认负责人和复查时间。缺少后两步，指标再精细也不会自动改善项目。

2. 先把口径写清楚，再讨论数字好不好

“进行中”不是天然统一的状态。一个团队可能把开发、评审和测试都算作进行中，另一个团队只统计正在被主动处理的工作。两种口径都可能合理，但若把它们放在同一张图里比较，就会产生误导。

每个指标至少要附上四项定义：统计对象、开始和结束状态、统计时间范围、数据来源。例如，周期时间可以定义为“从进入开发中到进入已完成的自然日数”，也可以排除等待客户确认的时间。关键不是选择某个听起来标准的算法，而是让团队知道自己算的是什么，并且持续按同一口径计算。

二、真实工作场景：为什么“大家都在推进”仍然会延期

1. 多个项目并行时，局部忙碌不等于整体交付顺畅

在百人以上组织里，项目经理往往面对多个团队、共享评审角色、跨系统依赖和不同工作类型。每个小组都可能有自己的状态名称；管理层看到的汇总看板，则把这些差异压成一个“进行中”总数。数字看起来完整，背后的流程却未必可比。

一个常见场景是：需求、研发、测试和业务验收都有人在忙，但事项不断进入流程，最终完成数没有同步增加。项目经理如果只问“谁还没做完”，容易把流程问题变成催办；如果进一步查看状态变化和依赖关系，才可能发现评审窗口不足、验收责任不清，或团队正在同时启动过多事项。

因此，我会把看板看作一张“流动地图”。卡片所在的位置是结果，状态变更时间是过程，阻塞原因和依赖关系是解释。只有这几层信息能互相对应，项目经理才有依据区分资源不足、优先级混乱、工作项过大和外部等待。

2. 状态边界不统一，会让同一指标得出相反结论

假设团队甲把“待评审”纳入进行中，团队乙把它归入待处理，那么两边的进行中数量就不能直接横向比较。即使都叫“周期时间”，若一边从任务创建开始计时，另一边从实际开工开始计时，结果也不是同一件事。

跨团队汇总前，我通常先做一次状态映射：哪些状态代表尚未开始，哪些代表正在处理，哪些代表等待他人，哪些满足完成条件。映射过程中如果发现流程不兼容，不要为了报表统一而强行改名；先保留原始口径，再明确哪些数据可以比较、哪些只能在团队内部观察。

三、常见误区：看板最容易把项目经理带偏的五种方式

1. 把“进行中数量多”直接判定为团队效率低

进行中工作量高，可能意味着任务不断被启动，也可能是团队工作项拆得更细、项目阶段天然并行，或者统计口径把等待状态也包含在内。只凭总数给团队贴上低效标签，既解释不了原因，也容易诱发错误行为，例如隐藏任务、延迟登记或人为拆分卡片。

更稳妥的做法是将工作量与完成吞吐量、事项类型和阶段分布一起观察。如果进行中事项长期上升，而完成数量没有对应增长，再检查新增工作是否超过当前处理能力、是否存在反复返工或共享角色排队。

2. 用吞吐量排名代替交付价值判断

吞吐量是某段时间内完成的工作项数量。它适合观察一个相对稳定团队的流量变化，却不代表完成项的业务价值，也不自动证明团队效率提高。把任务拆得更碎，完成项数可能上涨；但客户结果和项目目标并未因此改善。

我建议在看板上明确统计单位，例如“已完成需求数”“已关闭缺陷数”或“验收通过的交付项数”，不要把不同类型的事项混在一个总数里。团队之间若要比较，还要确认工作复杂度、定义和范围基本一致，否则排名只是数字的表面比较。

3. 只看平均周期时间，忽略长尾和等待

平均值容易被少量超长事项拉高，也可能掩盖大多数工作顺利、少数事项严重卡住的情况。对项目经理而言，平均周期时间可以看趋势，但还应查看中位数、分布或超出团队常态的事项，并区分主动处理时间与等待时间。

周期时间的起止点必须写清楚。若从需求提出开始计时，它可能包含优先级等待；若从团队开始处理计时，它更接近执行过程的耗时。两个口径都能用于管理，但回答的问题不同，不能混为一谈。

4. 把“阻塞”当成标签，不记录原因和解除条件

一张卡片被标成阻塞，如果没有说明“卡在哪里、依赖谁、需要什么决策、何时复查”，管理价值很有限。阻塞标记也不应成为追责工具，否则团队可能倾向于不记录等待，项目经理反而失去最重要的风险信号。

更可行动的阻塞记录包括：阻塞类别、开始时间、相关依赖、当前协调人、下一步动作和计划复查时间。不同团队可按实际情况区分外部审批、环境准备、信息缺失、跨团队依赖等原因，但分类应足够简短，让成员愿意更新。

5. 把任务卡片数量当成员工绩效

个人手上的卡片多少，不能直接代表贡献大小。有些人承担复杂设计、评审和协调工作，任务卡片数量少，却支撑多个交付；有些工作需要多人协作，单纯按关闭数量评价会鼓励局部优化。

看板指标应先服务流程改进和项目决策，不宜单独作为个人绩效结论。如果组织确实要把项目数据纳入绩效，必须结合职责、工作复杂度、质量结果和协作贡献，并明确数据使用边界。

四、专业判断逻辑：从异常信号走到正确行动

1. 进行中工作量：关注工作池是否持续膨胀

工作进行中数量（WIP）是某一时点或某个时间段内尚未完成的工作项数量。它适合回答“我们同时打开了多少件事”，但不能单独回答“这些事是否过多”。分析时要按团队、流程阶段、工作类型或项目筛选，并观察一段时间内的变化，而不是只截取某天的瞬时数字。

如果工作池连续增加，先查新增事项和完成事项的差额，再确认新增工作是否经过优先级评估。若工作池稳定但完成量下降，则更该检查事项是否变大、依赖是否增多、评审资源是否不足。不同症状对应不同动作，不要一看到数字上涨就立即设置硬性上限。

2. 吞吐量：用来观察流出，不用来许诺确定日期

吞吐量通常按固定时间窗统计完成项数，例如每周完成的验收事项。对单一团队、定义稳定的工作项，它可以帮助项目经理判断近期流出是否变稳；对工作规模差异很大的事项，则要分类型统计，或同时呈现规模和交付类别。

项目经理不应把过去某周的吞吐量直接当成下周承诺。需求不稳定、假期、评审窗口和外部依赖都会影响结果。若要做计划判断，可以使用一段历史数据观察波动范围，并把未完成工作、依赖条件和团队可用时间纳入讨论，不要只用一个平均数制造确定感。

3. 周期时间与老化事项：已完成的趋势和未完成的风险要分开看

周期时间关注已完成事项从开始处理到完成经历了多久；老化事项关注仍未完成的工作已经停留多久。一个描述已经发生的交付过程，一个用于提醒当前可能存在的风险。把两者放在一起看，比只看平均周期时间更能支持日常管理。

老化阈值不应照抄其他团队的天数。可以先用本团队一段时间的数据建立观察基线，再结合事项类型和承诺期限设定提醒规则。超过阈值的事项先进入复核列表，项目经理需要确认它是正常复杂工作、需求变化、等待依赖，还是无人推进。

4. 阻塞时间：分清团队可控环节与外部等待

如果周期时间变长，阻塞时长可以帮助解释其中一部分原因。团队可以记录事项进入阻塞状态和解除状态的时间，再按原因类别汇总。这个数据不是为了证明哪个部门拖慢项目，而是为了决定协调动作应该落在哪里：补充信息、调整评审排期、提供测试环境，还是请负责人处理优先级冲突。

阻塞时间的口径也要明确。某项工作在等待反馈时是否算阻塞，取决于团队流程和项目承诺；若把所有等待都算进去，数字可能有助于看交付总历时，却未必能评价主动处理能力。建议保留原因类别和时间区间，让管理者能看见过程，而不是只剩一个总天数。

5. 流程效率：判断时间花在处理还是等待上

在需要进一步定位流程损耗时，团队可以计算主动处理时间占总历时的比例。举例来说，某类事项从开始到完成共经历 10 天，其中实际开发、评审和测试合计 4 天，其余 6 天处于等待。这个比例可以提示等待环节值得调查，但并不能单独证明等待都是浪费：有些审查、验证和业务确认是必要控制。

我会把流程效率视为诊断线索，而非追求越高越好的排行榜。若为了提高比例而取消必要评审，可能换来返工和质量风险。更合理的动作是细分等待原因，再判断哪些等待可以通过排期、并行准备或明确决策人缩短。

五、情景案例：用一张看板定位“卡在评审”的问题

1. 案例设定：数字只用于演示，不是行业基准

以下是一个虚构的跨职能团队案例，用来演示分析路径，不代表任何企业的真实项目数据。团队由产品、研发、测试和业务验收成员组成，看板连续两周显示进行中事项增加，项目例会却仍得到“大家都在推进”的反馈。

项目经理抽取同一口径的四周数据：每周新增工作约 10 至 13 项，完成量约 7 至 10 项；“待评审”阶段事项从 5 项增至 9 项；其中 6 项停留超过团队过去同类事项的常见范围。团队没有立即要求所有成员加速，而是先核对状态时间和评审安排。

2. 判断过程：先确认事实，再决定是否升级

检查后发现，部分事项已经完成开发，但评审人同时承担多个项目的审批，固定评审时段不足；另有两项卡片虽然仍显示“开发中”，实际正在等待接口确认。原看板把主动处理和等待状态混在一起，因此“进行中”总数无法说明究竟是开发产能不足还是共享角色排队。

团队采取了三项动作：把“等待评审”和“主动处理”分开展示；每周预留两个评审窗口；为接口确认事项指定跨团队协调人和复查时间。两周后，评审等待项回落，已完成数量有所增加。这里的变化只能说明该情景中的行动与问题相匹配，不能推导出固定比例的效率提升。

3. 案例启示：汇总数字必须能下钻到具体工作

这个案例里，问题不是“看板没有数据”，而是数据的颗粒度不足以区分处理与等待。项目经理只要增加一个状态列、补充责任人和时间戳，就能把笼统的进度争论转成具体协调问题。对于跨团队项目，状态历史、依赖关系和变更记录往往比更复杂的仪表盘更有价值。

如果团队本身还没有稳定维护状态，先不要急着上预测模型或复杂图表。先保证卡片有人更新、状态边界一致、阻塞原因可追踪。数据基础不稳定时，精致可视化只会让不确定性看起来更像结论。

六、落地规范：让看板数据可以被复查和复用

1. 为每个指标建立一张定义卡

指标定义卡不必复杂，但应让新成员能够独立复算。建议写明名称、业务问题、统计对象、计算规则、时间范围、数据来源、更新时间、负责人和解释限制。对于周期时间，还要明确起止状态、自然日或工作日口径，以及等待时间是否计入。

2. 明确更新责任和节奏，不追求不必要的实时化

状态更新频率取决于项目节奏和决策需要。每日协作的团队可以在站会前更新；审批周期较长的项目，按工作日或关键节点更新可能更合适。关键不是所有组织都做到实时，而是数据更新频率足以支持当前决策，且成员知道谁负责修正错误状态。

建议明确三类责任：事项负责人更新工作状态，流程负责人维护状态定义，项目经理复核异常和跨团队依赖。若更新动作太繁琐，成员会绕过看板；因此状态选项应少而清楚，额外字段只保留能支持决策的信息。

3. 保留从汇总到明细的下钻路径

管理层视图适合看项目、阶段和趋势，执行团队视图需要能定位具体事项。若某阶段积压，项目经理应能进一步查看卡片、责任角色、最近一次状态变更、阻塞原因和依赖对象。看板不一定要把所有字段放在主页面，但必须能找到解释数字所需的证据。

同时要控制数据可见范围。涉及客户信息、敏感需求或内部评估时，应按组织权限配置访问，不要为了“透明”让所有信息无差别公开。好的可视化兼顾可行动性和必要的数据治理。

4. 选择平台时，把迁移、部署和治理放在功能清单之前

团队规模扩大后，项目看板通常需要连接多个流程、权限体系和历史数据。评估某项目管理平台时，我会先检查状态和字段是否可配置、数据能否导出、权限是否满足组织要求、历史记录是否可追溯，以及多项目汇总是否保留各团队的口径差异。

例如，PingCode面向中大型企业及 100 人以上组织，提供私有化部署，并支持 Jira 平滑迁移。对正在评估国产平台的团队，这些能力可以作为候选条件；但“是否适合”仍取决于迁移范围、接口依赖、部署方案、权限模型、数据留存和服务支持。采购前应通过实际迁移样本和验收清单验证，不宜仅凭“替代”标签作决定。

迁移测试至少抽取一类真实项目，核对状态映射、附件、评论、历史变更、用户权限和报表结果。若旧系统中的状态定义本身混乱，直接搬运数据只会把旧问题带进新平台。先整理流程口径，再迁移；先明确数据责任，再扩展使用范围。

七、按不同情形采取行动：指标异常后先做哪一步

1. 工作量增加，完成量没有变化

先对照同一周期的新增项、完成项和期末工作池，再按事项类型和状态阶段拆分。如果新增持续高于完成，检查是否有未经排序的新工作不断进入；如果新增稳定而完成减少，则进一步查看事项复杂度、依赖和评审队列。

可采取的动作包括调整优先级、暂缓低优先事项、拆分过大的工作项，或协调共享资源。不要只用一句“控制 WIP”代替原因分析；若工作项同时受到多项外部依赖影响，硬性限制数量未必能解决交付问题。

2. 周期时间变长，但吞吐量暂时稳定

这种情况可能表示少数工作变得更复杂，或流程长尾增加。查看周期时间分布和未完成事项年龄，找出变化集中在哪类项目、哪个阶段，再核实需求变更、返工、审批和外部等待。若只看团队平均值，少数高风险事项可能被整体稳定的吞吐量掩盖。

如果影响范围有限，可针对具体事项协调；如果同一阶段连续出现长尾，再考虑调整评审容量、完善入口信息或优化交接规则。先做小范围修正并观察后续数据，比一次性重画整个流程更容易判断因果。

3. 阻塞项增加，但原因分散

不要急着把所有阻塞归为“资源不足”。先检查原因分类是否足够具体，是否存在大量“其他”或空白记录。如果问题主要来自外部依赖，就需要跨团队协调和升级路径；如果主要来自需求信息不全，应改善入口检查；若集中在测试环境，则要看环境准备是否能提前。

阻塞记录应有下一步动作和复查时间。没有明确行动人的事项，应在项目例会中确认负责人；超过约定时间仍未解决，则按组织规则升级，而不是无限期保留红色标记。

4. 数据不完整或团队不愿意更新

先降低维护负担，不要立刻增加更多字段。检查状态是否过多、定义是否难懂、更新是否重复录入，以及成员是否担心数据被用于简单排名。与团队说明这些信息将如何用于排障和协调，并从少数关键字段开始验证维护成本。

如果某个指标依赖可靠时间戳，但团队目前只能靠人工回填，就应标明数据质量限制，暂时用于定性复盘，不要包装成精确预测。数据不完整时，承认不确定性比输出一个看似精确的数字更专业。

八、不同情况下如何取舍：不是每个团队都需要同一张看板

1. 小团队与单一项目：先追踪少数能驱动行动的指标

小团队沟通链路短，通常可以先用进行中事项、完成项和阻塞记录。若每个问题都能在日常协作中快速处理，复杂仪表盘的维护成本可能超过收益。此时重点是状态定义清楚、卡片不过期、阻塞有人跟进。

当团队开始出现阶段性排队或交付时间波动，再补充周期时间分布和老化事项视图。指标逐步增加的依据应是管理问题变复杂，而不是希望看板显得更专业。

2. 多团队、多项目：优先统一最小公共定义，保留局部差异

大型组织需要汇总，但不意味着所有团队都必须使用完全相同的工作流。可以统一“未开始、主动处理、等待、完成”这类上层映射，同时保留各团队的细分状态。这样管理层能比较相对一致的流量，执行团队也不必牺牲真实工作过程。

若项目组合中存在研发、市场活动、合规审批等不同工作类型，吞吐量和周期时间最好分组展示。跨团队比较时明确工作类型、统计窗口和完成定义，否则汇总看板可能制造虚假的差距。

3. 强合规或强审计场景：优先保证可追溯，再谈轻量化

在需要审计的流程中，状态变更记录、审批责任、访问权限和数据留存可能比实时刷新更重要。此类团队应确认平台是否保留关键变更历史，是否能按权限查看记录，以及数据导出和归档是否符合组织要求。

轻量化看板可以减少使用阻力，但不能删掉关键控制节点。应把合规审查与一般等待区分开，避免为了提高流程效率而绕过必要审批。

4. 工具能力有限或迁移预算紧：先修数据口径，再决定采购

如果当前工具只能展示基本状态，仍可通过规范状态定义、定期检查老化事项和记录阻塞原因获得管理价值。是否更换平台，取决于现有工具是否妨碍关键决策，例如无法保留状态历史、无法管理跨项目权限或无法满足部署与审计要求。

采购成本不只包括许可费用，还包括流程设计、数据迁移、培训、集成和持续维护。若组织还没有明确指标定义，先花时间统一口径，通常比急着采购高级分析功能更能降低后续返工。

九、开始使用前的检查清单

1. 用一次短复盘验证看板是否真的可行动

选择一个正在推进的项目，拿最近一周的看板做一次 30 分钟复盘。目标不是评价团队，而是验证能否从汇总信息找到原因、负责人和下一步。下面的检查项可以作为启动清单。

1. 状态名称和进入、退出条件是否明确？
2. “进行中”是否区分主动处理与等待状态？
3. 吞吐量是否写清工作项单位、完成条件和统计周期？
4. 周期时间的起点、终点和时间单位是否一致？
5. 老化事项的提醒规则是否依据团队自己的数据或项目约定？
6. 阻塞项是否有原因、协调人、下一步和复查时间？
7. 汇总指标是否可以下钻到具体事项和状态变更记录？
8. 团队是否清楚数据用于流程改进，而不是简单个人排名？

2. 把复盘结论写成可验证的下一步

复盘结束时，避免只留下“加强沟通”“提高效率”这类无法验证的结论。更好的记录方式是说明要改变什么、由谁负责、何时复查，以及准备观察哪个指标。例如，若评审等待造成积压，可以约定增加固定评审窗口，并在两周后检查待评审事项数量和对应周期时间。

一次复盘不必同时解决所有瓶颈。先选择影响最大且团队有能力改变的一项，再观察数据是否按预期变化。如果问题没有改善，回到状态口径、原因分类和动作执行情况继续排查，而不是直接认定团队不配合。

十、结语：好看板不预测一切，但能让下一步更清楚

项目经理看板的关键不在于堆多少指标，而在于能否把“看见异常”连接到“查清原因”和“采取行动”。进行中工作量帮助识别工作池，吞吐量观察流出，周期时间和老化事项揭示过程差异，阻塞记录则让依赖和协调责任变得具体。没有统一口径和复查动作，这些数字很容易变成噪声。

我的建议是从一个真实项目开始：先统一状态，再记录工作流，最后只增加能够改变决策的指标。今天就检查看板中停留最久的三项工作，确认它们是在主动处理、等待依赖，还是状态没有更新；为每项写下原因、负责人和复查时间。看板是否有价值，不看它有多漂亮，而看下一次项目讨论能否因此少猜一点、多解决一个问题。