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

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

一个项目看板上有 18 张卡片都标着“进行中”，负责人却说不清其中几项正在产出、几项在等审批、几项已经停滞，这不是看板不够漂亮，而是“进行中”没有被定义成可执行的流程。项目负责人真正需要的，不是再加几列状态，而是让每张卡都能回答三个问题：现在卡在哪里、下一步由谁采取什么行动、什么条件满足后才算完成。

一、先讲核心结论：看板管理的重点不是状态，而是流动

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

我判断一块看板是否具备管理价值，通常不会先看它有多少列、用了几种颜色，而是先抽一张“进行中”的卡片，检查团队能否说清它为什么在这里。任务负责人已经开始实际工作、必要输入已经具备、交付结果已经明确，这些可以构成进入条件；结果通过约定的验收标准，则可以构成退出条件。

如果团队对“进行中”的解释只是“有人接手了”或“已经排进计划”，状态就会混合执行、等待、讨论、审批和暂挂。看板表面上显示任务很多，实际上无法辨别工作流是否顺畅。状态应当描述工作所处的阶段，而不是描述大家对任务的感觉。

2. 指标是流程的探测器，不是人的评分器

项目负责人需要指标，但不需要把所有指标都做成员工排名。周期时间变长，可能是任务拆分过粗，也可能是等待评审、外部依赖增加；吞吐量下降，也可能是团队正在处理高复杂度事项。一个数字只能提示“值得检查”，不能自动证明“谁做得不好”。

我建议先围绕流程选择少量指标：在制品数量、周期时间、吞吐量、阻塞任务数与阻塞时长，再根据项目特点补充超期任务或准时交付率。指标越多，不代表管理越精细；若每项指标都没有明确口径，只会增加解释成本。

3. 先让异常可见，再讨论优化

看板的第一阶段目标不是立刻提速，而是让隐藏的等待、重复返工和优先级切换浮出水面。流程问题被稳定记录之后，团队才有条件判断应该减少并行、补足输入、调整评审方式，还是改变任务拆分粒度。先建立可信的过程数据，再谈效率改善；没有基线，就很难判断改动是否有效。

二、为什么“进行中”最容易变成模糊地带

1. 一列状态里常常装着几种完全不同的工作

在跨职能项目里，“进行中”经常同时容纳设计制作、等待产品确认、排队代码评审、缺少测试环境、供应商未回复等状态。这些工作都没有完成，但它们需要的管理动作并不相同。正在制作的任务可能需要专业支持；等待确认的任务可能需要负责人推动决策；环境缺失则可能需要协调资源。

如果这些情形都留在同一列，负责人看到的只是一个总数，无法知道工作是在被处理，还是在等待别人。最实用的改法通常不是无限新增列，而是保留清晰的主流程，再用阻塞标记、等待原因和下一步行动补足差异。

2. 任务越大，状态停留时间越难解释

“完成新版结算流程”可能横跨需求澄清、规则确认、设计、开发、测试和上线；若整个项目只建一张卡，它可能在“进行中”停留数周，却没有办法定位具体卡点。相反，如果把每个极小动作都拆成一张卡，团队又会把大量时间花在维护看板上。

任务拆分的实用标准是：一张卡应有明确的交付结果，能指出负责人和下一步，并且能在团队认可的时间尺度内检查进展。这里没有适用于所有团队的固定工时门槛。关键是卡片粒度要足以暴露等待和交接，而不是把工作切得越碎越好。

3. 进度报告往往晚于真实状态变化

不少团队在周会上才集中更新看板，于是卡片显示的状态并不代表此刻的工作状态。一个任务周二已经受阻，周五才被标记；负责人周三完成交付，周会后才移动到完成列。这样的数据仍然能做粗略的回顾，却不适合用来判断当前拥堵位置。

因此，团队应约定“状态发生变化时更新”，并给未变化的任务设置定期核查节奏。更新不必写成长篇日报，但至少应包含事实、阻碍和下一步。看板数据的价值取决于更新是否接近事件发生时间，而不取决于填了多少字段。

三、把流程规则写清楚：状态、卡片和更新节奏

1. 按真实交接设置列，不要照抄模板

刚开始使用看板的团队，可以从“待开始，进行中，待评审或验收，已完成”这样的简化流程起步。只有当评审、审批或测试确实形成独立等待队列时，才值得拆出单独状态。每新增一列，最好都能对应一种不同的管理动作；若移动到新列并不会改变谁负责、下一步做什么，那这一列未必有存在价值。

跨部门项目还可能有“等待业务确认”“等待外部交付”等状态，但不应为了展示所有组织角色而把流程切成十几列。状态过多会增加维护负担，也容易让团队围绕“卡片放哪一列”争论，而不是解决任务本身。

2. 给“进行中”设定明确的准入条件

进入“进行中”至少需要回答几个问题：预期结果是什么，谁对结果负责，必要输入是否就绪，当前是否确实开始投入执行。对于依赖审批、账号权限、数据或其他团队交付的任务，若关键条件尚未具备，可以留在待开始，或标注为等待状态，不要为了让计划显得积极而提前开工。

准入条件不是增加一道形式审批，而是避免“接了任务却无法开始”的隐形排队。项目负责人可以让团队用两到四周试运行条件，再观察有多少任务因为前置条件不清而返工或暂停，之后再决定是否调整规则。

3. 把“完成”定义为可检查的交付

“已经做完”是一个主观判断，“完成了可复核的交付物并满足验收条件”才是可以共同检查的规则。比如，一项设计工作不能只以文件已上传为完成，还要明确是否经过约定评审；一项开发任务也不一定以代码提交为完成，可能还需要测试通过或部署验收。

完成标准应与任务类型匹配。若每种工作都强制用同一套验收条件，容易把流程变成负担；但如果完全没有标准，负责人就无法解释周期时间从哪里结束，也无法区分“已交付”和“已提交待验收”。

4. 任务卡片至少要支持一次管理判断

卡片不是项目文档的替代品，但至少应让负责人快速判断当前风险。基础字段可以包括任务名称、预期结果、负责人、当前状态、进入当前状态的日期、目标日期、依赖或阻塞原因、下一步行动。团队不必一次填满所有字段，应优先保留真正会触发决策的信息。

任务：完成结算异常提示改版
预期结果：用户提交失败时能看到原因和处理指引

负责人：项目成员甲

状态：等待业务确认

进入当前状态日期：10月6日

阻塞原因：异常文案尚未确认

下一步行动：业务负责人于10月8日前确认文案

目标验收日期：10月11日

上面的日期和任务均为示意。它的重点不是格式，而是把“等待中”变成可追踪的事件：等待什么、由谁处理、何时检查。若卡片只写“处理中”，即便颜色醒目，也无法帮助项目负责人安排行动。

5. 约定状态更新和阻塞升级方式

建议采用事件驱动更新：状态改变时立即更新，出现阻塞时记录原因和下一步；对于连续数日无变化的卡片，再通过例会或异步提醒核查。具体间隔要结合任务节奏确定，不能把某个固定天数当成所有团队的标准。

阻塞升级也需要边界。例如，超过团队约定的等待时间仍未获得决策，卡片负责人先提醒依赖方；再未解决，则由项目负责人协调优先级或升级决策。升级机制的目标是消除障碍，不是给卡片贴上红色标签后等待问题自行消失。

四、关键指标怎么选：从数字回到管理问题

1. 在制品数量：同时开工是否过多

在制品数量（WIP）指某一时点处于执行中的工作项数量。它能帮助负责人观察团队是否把过多任务同时推入执行。若 WIP 持续增长，而完成量没有相应变化，可以进一步检查是否存在优先级频繁切换、任务依赖未解决、评审排队或人员被多项目分散等情况。

WIP 上限没有通用的正确数字。小团队、长周期研发任务和高频服务请求的工作形态不同，不能简单套用一个固定上限。更稳妥的做法是从当前实际负载建立基线，再试着降低一个小幅度，观察周期时间、阻塞和完成节奏是否改善。

2. 周期时间：从开工到达到完成定义用了多久

本文将周期时间定义为：任务进入“进行中”至达到约定完成条件之间的时间。团队必须固定起点和终点，否则不同月份或不同项目的数据不可比较。若某类任务从开始执行到提交评审算结束，另一类任务却统计到最终上线，汇总出的平均值便没有清晰含义。

周期时间可以看中位数，也可以观察较慢任务的分布。平均值容易被少数超长任务拉高，中位数更适合描述常见体验；但如果只看中位数，尾部长期滞留的任务可能被掩盖。负责人应结合任务类型和分布一起判断，而不是只追逐一个更小的数字。

3. 吞吐量：固定时间内完成多少工作项

吞吐量是在固定时间窗口内达到完成定义的工作项数量。它适合观察团队交付节奏，例如每周完成多少个可比任务，但不能直接代表价值或个人产能。一个团队把大任务拆成更多小卡片，吞吐量可能上升，实际交付价值却未必增加。

因此，吞吐量要与任务类型、交付结果和拆分规则结合看。若卡片粒度发生变化，应在看板上注明规则调整，否则前后数据看起来像效率变化，实际可能只是计数单位变了。

4. 阻塞数量与阻塞时长：等待成本在哪里发生

阻塞任务数说明当前有多少工作无法按计划继续；阻塞时长则帮助判断等待是否正在扩大。比起只统计阻塞总量，我更建议记录阻塞原因的类别，例如待决策、待评审、外部依赖、环境资源或需求变化。原因分类能帮助负责人识别反复出现的系统性障碍。

阻塞时长并不等于某个人造成的延误。等待可能来自职责不清、决策机制复杂、资源冲突或信息不完整。讨论指标时，先问“哪类等待反复出现”，再问“需要谁采取什么行动”，比直接追问“为什么还没做完”更容易得到可执行的答案。

5. 超期和长期未更新任务：识别承诺与信息风险

超期任务是超过目标日期仍未达到完成定义的工作；长期未更新任务则是超过团队约定的检查周期，卡片没有新的事实进展。两者不完全相同：任务可能未超期但已经多日无更新，也可能按期更新却明确显示预计延期。

阈值应与团队工作节奏相适配。高频运营事项和跨团队的大型交付不适合使用同一个未更新天数。项目负责人可以先把阈值设为提醒条件，而不是自动处罚条件，待积累一段时间的记录后再调整。

6. 准时交付率：读懂计划兑现情况，不做简单归因

准时交付率可以定义为：统计窗口内按承诺日期达到完成条件的任务数，占该窗口内到期任务总数的比例。统计前要约定承诺日期如何记录、范围变更是否重设日期、取消任务是否纳入分母。口径不一致时，团队之间的百分比没有可比性。

准时交付率下降值得关注，但不自动等于团队执行变差。新需求插入、验收口径变化、外部依赖延迟都可能影响结果。负责人应同时查看变更、阻塞和任务复杂度，避免用单一比率把流程问题归咎于执行者。

7. 指标先少后多，且每项指标都要对应问题

刚启用看板时，优先选择三到五项指标就足够：WIP 用于观察并行负载，周期时间用于观察交付流动，吞吐量用于观察完成节奏，阻塞时长用于发现等待成本。超期和准时交付率可以作为补充，但前提是日期口径已经稳定。

每项指标都应绑定一个管理问题和一个可能动作。例如，阻塞时长上升时，按原因分类并指定协调人；周期时间拉长时，检查任务拆分和评审队列；WIP过高时，讨论先完成已有工作还是继续接新任务。没有对应动作的指标，只会成为定期汇报中的装饰。

五、具体案例：一张长期停留的卡片，怎样变成可处理的问题

1. 情景背景：不是任务没做，而是交接没有被看见

以下是一个用于说明方法的模拟案例，并非真实企业的绩效数据。某产品团队正在推进结算异常提示改版，一张任务卡在“进行中”停留了 11 天。周会上，执行成员说设计已完成；业务同事表示文案还没有确认；测试人员则认为测试环境未准备好。

如果只看状态，负责人可能会把它理解成“执行慢”；但实际发生的是三段工作被装进一张卡片，且不同依赖没有明确的责任人。此时直接要求执行者加快速度，并不能缩短等待，反而可能造成未经确认就继续制作，之后再返工。

2. 先还原事件，再决定是否拆卡

负责人先检查卡片的状态日期和更新记录，确认任务在进入执行后完成了设计，但随后等待业务文案确认。测试环境准备则属于后续验证条件，不应和文案决策混成一个模糊阻塞。团队据此把后续工作拆分为“确认异常文案”“完成提示实现”“准备测试环境”“验证异常场景”几个有明确交付物的工作项。

拆分之后，每张卡都记录负责人、依赖和下一步行动。等待业务确认的任务由业务负责人负责确认时间；环境准备由测试协调人跟进；实现任务在文案确认后开始。项目负责人不必持续追问“进度怎么样”，而是检查决策节点是否按约定发生。

3. 用指标定位流程问题，而不是给任务贴标签

在这个模拟案例里，11 天的停留时间本身不足以说明问题。负责人还需要看卡片在各阶段停留多久：实际设计用了几天，等待文案用了几天，环境准备是否与设计并行，评审有没有排队。若大部分时间都耗在等待确认，改进方向应是明确决策责任和响应期限，而不是要求制作环节提速。

如果同类任务反复等待文案确认，团队可以在开工条件中增加“关键文案已确认”，或让业务方更早参与需求澄清；若只有这张卡遇到临时变更，则无需立即修改整个流程。一次异常可以先处理个案，重复出现的异常才是流程规则需要调整的证据。

4. 如何判断一次改动是否有效

调整流程后，不要只看“卡片移动得更快”。可以在约定观察窗口内比较相似类型任务的周期时间分布、等待确认时长、返工次数和按期验收情况。如果等待时间下降，但返工显著增加，说明团队可能只是更早开始了尚未准备好的工作，不能把它视为整体改善。

对于样本很少的团队，几个任务的波动可能主要来自偶然因素。负责人应把数据和具体事件一起复盘，不要因为某周完成量增加就宣布规则成功，也不要因为一个任务延期就立即推翻流程。规则调整要有观察窗口，也要明确撤回或继续的判断条件。

六、不同情况下的行动建议：看见信号之后做什么

1. WIP高、完成量不升：先暂停新增工作

如果执行中的任务持续增加，而完成量保持平稳，优先检查团队是否频繁切换任务、是否有大量依赖未就绪，或者评审环节是否积压。可以短期试行“先完成一项，再接下一项”的团队约定，也可以在关键阶段设置适合自身工作形态的 WIP 上限。

这不等于一律拒绝新需求。若新需求确实更重要，负责人应明确替换哪项现有工作、哪些承诺随之调整。若只增加新卡而不说明优先级变化，旧任务会继续占用注意力，计划也会失去可信度。

2. 周期时间变长：先按任务类型和阶段拆开看

周期时间上升时，不要先把所有任务放在一起求平均。先按工作类型、团队、阶段或依赖类别分组，观察究竟是需求澄清、开发、评审还是验收环节拉长。不同类型任务的天然复杂度不同，混合统计可能掩盖真正的流程变化。

如果主要增加来自评审等待，可以检查评审容量和排期；如果来自任务执行本身，可以复核拆分粒度、验收标准和需求稳定性；如果来自返工，则需要回到输入质量和评审时点。数据给出定位线索，具体原因仍需通过任务记录和团队访谈确认。

3. 阻塞时长反复上升：明确依赖的责任人和升级路径

依赖任务不应只写“等其他团队”。卡片应记录依赖对象、需要的具体输入、期望时间、当前联系人和延误后的升级方式。项目负责人还可以按阻塞原因汇总一段时间的情况，识别是个别协作失误，还是审批链过长、资源分配冲突等重复问题。

如果依赖方并非项目团队直接管理，负责人要把等待风险提前纳入计划，而不是到交付期限临近才升级。越早暴露外部依赖，越有机会调整顺序、并行准备或重新协商承诺。

4. 卡片长期未更新：先核实工作事实，再讨论纪律

长期未更新可能是负责人忘记维护，也可能是任务没有明确下一步、实际工作难以拆解，或更新流程本身太繁琐。项目负责人可以先询问“最近发生了什么、当前阻碍是什么、下一步何时发生”，再判断需要提醒、补充协助还是改进任务定义。

如果团队依靠重复催更才能获得基本状态，问题可能不只是个人习惯，也可能是看板没有融入日常协作。应减少重复填报，让状态变化直接体现在项目工作流中；否则维护负担越高，数据越容易在关键时刻失真。

5. 准时交付率下降：先检查承诺是否稳定

准时交付率下降时，先查看统计窗口内是否有范围变化、紧急插单、外部依赖和验收口径调整。若承诺日期不断被修改，团队可能是在用更新日期掩盖计划偏差；若承诺不变但外部输入频繁延迟，解决重点则应放在依赖管理和风险缓冲。

负责人可以把“计划变更次数”和“延期原因”作为辅助观察项，但不要把每次变化都当成失误。产品需求探索期与稳定交付期的计划属性不同，前者需要容纳学习和调整，后者则需要更严格地管理承诺。

七、工具、团队规模与管理成本：什么时候需要升级做法

1. 小团队可以从轻量规则开始，不必先买系统

如果团队人数不多、任务关系简单、协作成员都能及时看到同一块看板，先用共享表格或轻量看板验证流程规则，往往更容易发现真实问题。此时关键不是工具功能是否全面，而是团队是否能持续更新状态、使用同一套指标口径，并定期把异常转成行动。

但当项目数量增多、多个团队共用资源、权限和审计要求提高时，手工维护会出现重复录入、状态不同步、跨项目统计困难等成本。升级工具之前，先列出已经遇到的具体管理障碍，避免因为功能多而迁移，却仍然沿用含糊的状态定义。

2. 中大型组织要重点评估跨团队治理能力

对于 100 人以上组织，或同时运行多个复杂项目的企业，项目看板不仅要展示任务，还要支持不同团队之间的协作规则、权限边界、项目组合视图和稳定的数据口径。评估时可以重点确认：能否按组织流程配置状态，能否追踪依赖和变更，管理者能否跨项目查看风险，数据导出与权限控制是否满足内部要求。

PingCode可作为此类团队评估项目管理平台时的一个候选对象。其产品定位面向中大型企业及 100 人以上组织，提供私有化部署能力，并支持从 Jira 平滑迁移等场景。实际选型仍应通过需求清单和迁移演练验证：字段、工作流、权限、附件、历史记录及报表能否按预期承接，不能仅凭产品宣传判断适配程度。

3. 私有化部署与迁移能力要放进总成本一起看

有些组织因为数据治理、网络隔离或内部合规要求，需要评估私有化部署。此时除了确认部署方式，还要核查升级维护责任、备份恢复、监控告警、身份认证、访问审计和故障响应机制。部署在自有环境并不意味着后续运维成本消失，反而需要明确谁负责平台生命周期。

从 Jira 等既有平台迁移时，所谓平滑迁移不能只看任务是否导入。应选取一个小范围项目做试迁移，逐项核对状态流转、字段映射、用户与权限、附件、评论、历史记录、自动化规则和报表口径。国产替代也不是单纯换一套界面，而是确认平台能否满足功能、数据治理、集成、运维和团队采用成本等综合要求。

4. 工具选型应围绕管理问题，而不是功能清单

工具对比时，可以把候选方案放进真实工作流演练：新增一项需求、标记依赖、发生阻塞、调整负责人、提交验收、生成周期统计。观察一线成员完成这些动作需要多少步骤，管理者能否快速找到超期和长期未更新任务，历史数据是否能支持复盘。

如果团队的主要问题是状态定义不清，再先进的报表也只会更快地产生不可靠数据。如果主要问题是跨团队可见性不足，单机维护的表格可能已经不够。选择工具前先写出需要解决的决策场景，再用场景验证工具，而不是反过来根据功能目录重写管理流程。

八、不同情况下的取舍与上线步骤

1. 追求快速上手，还是追求完整治理

如果团队人数少、流程变化快，优先选择少量状态、少量字段和低维护成本，先让规则跑起来。此时牺牲部分自动化与跨项目报表，换取成员愿意使用，通常更实际。若组织已经有多团队协作、权限隔离和审计需求，则需要接受前期配置和治理成本，以换取一致的流程视图。

两种选择没有绝对高下。关键是不要把小团队复杂配置当成专业，也不要把大组织的治理需求简化成一张共享表。管理方式应随协作规模和风险要求变化。

2. 追求更细的数据，还是降低维护负担

细分到每个阶段，能更精确地定位等待发生在哪里；但每次移动卡片都需要额外判断，成员可能开始绕过流程。字段越多，理论上可以分析的维度越丰富，实际数据完整度却可能下降。建议先采集直接影响决策的字段，再依据复盘发现补充字段，而不是一次性把所有可能信息都设为必填。

如果团队长期漏填某字段，应先确认它是否真的触发决策。若没有管理用途，就删除；若确实重要，就优化填写时机、自动带入数据或简化选项，而不是只要求成员提高自觉。

3. 追求指标可比，还是保留任务差异

跨团队比较有利于发现整体风险，但任务类型、复杂程度和依赖条件不同，简单排名会造成错误激励。一个团队可能通过拆小任务提高吞吐量，另一个团队则承担大型交付；如果只比完成卡片数，结果很难说明谁创造了更多价值。

更稳妥的做法是先在同一团队、相近任务类型和一致统计口径下看趋势，再谨慎开展横向对比。管理层可以关注流程异常和承诺风险，不宜把单一指标直接绑定个人绩效。

4. 一周内可以启动的最小实践

1. 选定一个真实工作流。从近期有交付压力、协作关系清楚的项目开始，不要一开始就覆盖所有部门。

2. 定义状态规则。为每个状态写清进入条件、退出条件和主要责任角色，优先把“进行中”“阻塞”和“完成”说清楚。

3. 整理在手任务。检查负责人、预期结果、依赖和下一步行动；无法说明下一步的任务先标记出来，不要用模糊进度掩盖。

4. 建立简单基线。记录当前 WIP、周期时间、吞吐量和阻塞时长的口径及初始值，并注明数据从何时开始、覆盖哪些工作项。

5. 安排一次短复盘。先看哪些卡片停留最久、等待原因是否重复，再选择一项规则做小幅调整。

6. 设定回看时间。观察调整后的变化，并检查是否带来返工、维护负担或其他副作用，不要只看一个漂亮的结果数字。

5. 上线前检查清单

• 每个状态是否有团队共同理解的进入和退出条件？

• “进行中”是否能区分实际执行与等待？

• 每张关键任务卡是否有负责人、结果、依赖和下一步行动？

• 周期时间、吞吐量和准时交付率是否有明确统计口径？

• 阻塞原因是否能帮助负责人采取行动，而不只是显示风险颜色？

• 团队是否约定状态更新节奏和阻塞升级路径？

• 指标是否用于改善流程，而不是脱离任务背景给个人排名？

• 若需要更换平台，是否已经用小范围试迁移验证字段、权限、历史数据和报表？

九、结语：不要问看板有多少卡，先问工作如何流动

1. 让看板从展示工具变成决策工具

项目负责人看板入门的关键，不是把所有工作涂上颜色，而是建立一套能持续回答问题的管理语言：任务何时可以开工，阻塞由谁处理，什么结果才算完成，哪些等待正在重复发生。状态定义让团队看到工作所处阶段，卡片规范让信息足以支持行动，指标则帮助负责人判断流程是否出现异常。

我更愿意把“进行中”看作一段需要被观察的路，而不是一个可以长期停留的标签。若一张卡在这个状态停得太久，正确的第一步不是责问执行者，而是还原它经历了什么：有效工作、等待、交接、返工分别占了多少，下一步又由谁推动。

2. 下一步从一条规则和一次复盘开始

先选一个团队真实使用的项目，把“进行中”的准入条件、完成条件和阻塞更新方式写下来，再连续观察一段时间。初期只盯少量指标，记录口径与例外情况；发现同类问题重复出现，再调整流程或评估工具是否需要升级。

一块有效的看板，不是让管理者更快看到谁落后，而是让团队更早看到工作为什么停住，以及怎样共同把它推向完成。