进行中流程与规范：项目成员看板流程优化关键指标

项目看板里最容易误导人的，不是“未开始”，而是“进行中”：卡片越堆越多，成员看起来都很忙，交付却没有变快。优化这段流程，不能只加一列状态或催任务，而要先说清哪些工作算进行中，再用在制品数量、周期时间、吞吐量和阻塞情况找出等待发生在哪里。下文会给出可直接试行的规则、计算口径和一组明确标注为情景模拟的数据；这些示例用于说明诊断方法，不代表行业基准或真实客户结果。

一、核心结论：优化的对象是工作流，不是卡片移动速度

1. 看板优化先解决三个问题

我判断一个项目看板是否真正发挥作用，通常先看三件事：团队是否对状态含义有共同理解；每张进行中卡片是否有明确的下一步；管理者能否从数据中发现工作流里的等待、阻塞和过载。若这三件事没有建立，增加状态颜色、提醒通知或汇报频率，往往只是让问题显示得更勤，并没有让工作更顺畅。

因此，进行中流程的优化顺序应当是先统一规则，再观察流动，最后调整容量或协作方式。看板不是把任务从左往右拖动的展示板，而是团队对工作如何进入、如何推进、何时完成的一份可见约定。

2. 指标必须能触发行动

一项指标如果只出现在月报里，却不会改变团队下一步怎么做，它对流程优化的价值有限。例如，WIP（在制品数量）偏高时，要追问团队是否同时启动了过多工作、是否有大量任务在等评审；周期时间拉长时，要看长时间停留集中在哪一列、任务类型是否发生变化。指标本身不是答案，而是检查现场的入口。

我建议先用五类指标建立最小观察集：WIP、周期时间、交付周期、吞吐量、老化任务或阻塞时间。它们分别回答“同时做多少”“做完花多久”“从需求到交付等多久”“一段时间完成多少”“哪些工作停得太久”。不同指标覆盖的流程区间不同，不能彼此替代。

3. 不要把流程指标变成个人排名

周期时间长，不必然说明负责人执行慢；任务可能在等待评审、客户确认、测试环境或跨团队依赖。吞吐量高，也不等于交付价值高；简单任务数量多，可能掩盖少数关键任务长期未完成。流程指标更适合发现系统性摩擦，而不是给个人贴效率标签。

如果管理者把“每人完成数”直接用作绩效排名，成员可能会倾向于拆小任务、优先挑简单事项，或不愿及时标记阻塞。短期报表可能更好看，复杂工作和真实等待却更难被发现。流程优化要观察团队交付系统，而不是把卡片数量当作个人产出代理值。

二、为什么“进行中”最容易失控

1. 一列状态装进了不同性质的工作

不少团队把“已开始处理”“等待他人回复”“待代码评审”“待测试”“因外部依赖暂停”都放在同一列。表面上看，任务状态很简单；实际却把正在加工与排队等待混成一类。负责人打开看板时，很难判断哪些工作需要继续推进，哪些工作需要协调资源，哪些卡片只是忘记更新。

这会直接影响指标解释。若团队把等待评审也算进“进行中”，WIP看起来偏高，未必意味着成员启动过多；若等待状态完全不记录，周期时间看起来可能正常，却低估了从开始到交付的真实耗时。解决方式不是追求状态列越多越好，而是把对决策有用的差异显性化。

2. 项目成员的工作节奏并不相同

软件研发、市场活动、内部流程改造和客户交付，任务大小、审批链和外部依赖都不同。一个团队可能每天处理大量短任务，另一个团队一周只完成少数跨部门事项。如果直接比较两组团队的任务数或周期时间，很容易把工作性质差异误判为流程效率差异。

所以，横向比较前要先分层：至少区分任务类型、优先级或工作规模中的一项。若任务规模差异明显，可以先比较同类工作；若分类成本太高，则先观察同一团队自身的趋势，不急于排名。流程数据的首要用途是看变化，而不是制造一个看似精确的跨团队名次。

3. “忙碌”与“流动”不是一回事

成员手上有很多卡片，可能意味着投入积极，也可能意味着工作切换频繁、等待时间长、优先级不断变动。对交付来说，关键并不是每个人是否始终有任务，而是工作能否持续通过流程节点，最终形成可验收结果。只问“大家是不是都满负荷”，通常会错过真正影响交付的瓶颈。

在实际诊断中，我会把“正在做”和“已经承诺但尚未做”分开看，也会追问任务从开始到完成之间经历了几次等待。团队若同时启动太多工作，可能短期看起来利用率高，但每项工作都更难获得连续注意力。这里的目标不是让成员空闲，而是减少已启动工作中不必要的排队和切换。

4. 看板规则缺位时，工具无法替团队做判断

软件可以记录状态、时间戳和负责人，也可以提醒超期任务；但“什么情况下可以进入进行中”“阻塞多久需要升级”“完成是否包含验收”属于团队规则，不能指望工具自动替代共识。工具配置得越复杂，规则越含糊，成员越容易把看板当作填报任务。

对于中大型组织，尤其是百人以上、跨团队协作较多的环境，统一定义和权限治理更重要。比如采用支持私有化部署、能够承接既有项目数据迁移的项目管理平台时，仍要先确认状态映射、历史数据质量、权限范围和迁移后的指标口径。以 PingCode 为例，若组织将其纳入候选工具评估，可把私有化部署、从 Jira 平滑迁移的适配情况列入验证项；这类能力应结合当前产品文档、迁移方案和组织实际测试确认，不能只凭功能描述推断流程一定会改善。

三、先制定“进行中”规则，再谈指标

1. 明确进入条件和完成条件

“进行中”不应只是成员想起来时选择的状态。进入条件要说明任务何时正式占用团队处理能力；完成条件要说明什么结果才算离开该阶段。以项目任务为例，进入前可以要求需求目标、负责人、验收方式和依赖信息基本明确；离开时则确认交付物已完成，并满足约定的评审或验收条件。

规则不必写成厚重的制度文件。通常一张短清单就够，但成员必须能在实际工作中回答：这项工作现在由谁推动？下一步是什么？什么情况可以转状态？缺少其中任意一项，卡片就容易成为静态记录，而不是协作工具。

2. 将处理、等待和阻塞区分开

团队可以根据工作特点，把“进行中”拆成较有用的子阶段，例如“处理中”“待评审”“待验证”；也可以保持主看板简洁，另用阻塞标记或等待原因字段补充信息。选择哪种方式，取决于成员是否能及时更新，以及这些差异是否会改变管理动作。

我通常不建议一开始就把每个细节变成一列。状态过多会增加维护成本，成员要花更多时间判断该拖到哪里。如果等待类型只需用于复盘，可以先用标签或字段记录；如果等待节点需要独立负责人和时限，则可以考虑单列展示。只有当一个分类会带来不同动作时，才值得成为正式状态。

3. 设定阻塞标记与升级机制

阻塞不是“任务进展不顺”的泛称，而是当前责任人无法通过合理行动继续推进，需要外部决定、资源或依赖交付。团队应约定阻塞的识别条件、记录字段、负责协调的人，以及何时升级。没有升级规则的阻塞标签，只会让问题变得可见，却未必有人负责解决。

阻塞时间也要明确计时口径。可以从标记为阻塞的时点开始，直到依赖解除或任务恢复处理；若组织选择暂停某类计时，应在团队内统一说明。不要一部分成员暂停计时，另一部分成员持续计时，否则看似精确的数据其实无法比较。

4. 保持卡片字段精简但可行动

每张进行中卡片至少要能看见负责人、当前阶段、下一步动作和必要依赖。对于需要管理层协调的任务，再补充阻塞原因、等待对象和期望响应时间。任务类型、优先级、计划日期等字段是否必填，应由实际决策需要决定，避免把看板变成信息采集表。

若填写一项字段之后，没有人会据此采取行动，也不需要用它做统计，通常就不该强制所有成员维护。字段过多不仅增加更新负担，还会让关键信息淹没在大量选项中。规范的价值是降低协作歧义，而不是提高表单完成率。

5. 为不同工作类型保留必要差异

统一口径不等于所有团队只能使用完全相同的流程。跨团队组织可以统一核心术语和指标定义，同时允许具体状态按工作类型扩展。例如需求分析与客户交付可以共享“进入工作、完成、阻塞”的原则，但具体评审节点可能不同。治理重点是让数据可解释，而非强行让所有任务走同一条路径。

四、五类关键指标：看什么、怎么计算、不能说明什么

1. 在制品数量：团队同时承接了多少工作

WIP是某一时点处于约定工作区间内的任务数量。若团队把“处理中”和“待评审”都纳入进行中，就必须一直沿用这一口径；否则，前后变化可能只是统计范围改变。团队也可以分别观察处理中WIP与等待中WIP，让执行负荷和协作等待不再混为一谈。

WIP持续上升而完成量没有同步增加，值得检查是否有过多任务同时启动、优先级是否频繁切换、评审容量是否不足。不过，WIP增加也可能是项目进入集中交付阶段或工作类型发生变化。它是风险信号，不是单独就能证明过载的结论。

2. 周期时间：开始处理之后多久完成

周期时间（Cycle Time）通常按任务进入约定的实际处理阶段起算，到满足完成条件时结束。团队必须明确具体起点和终点。例如从进入“处理中”开始，还是从进入“进行中”主列开始；完成时是交付给下游，还是验收通过。不同定义算出来的结果不能直接混在一起。

统计时不要只看平均值。少数超长任务会拉高平均数，而多数任务的常态可能完全不同。中位数能反映中间位置，较高分位数则有助于观察长尾风险。分析时还要按任务类型或规模分组，避免把简单修复与大型跨团队工作放在一起得出一个缺乏解释力的数字。

3. 交付周期：需求进入到结果交付经过多久

交付周期（Lead Time）关注的区间通常比周期时间更长，可能从需求被接收、承诺或正式排入流程开始，到最终交付为止。它能暴露需求在“尚未开工”阶段的排队时间，帮助团队发现只看执行阶段看不到的问题。

交付周期的起点最容易产生争议。若从客户提出需求开始，有些请求可能尚未评估；若从团队承诺开始，则前期排队不会被包含。两种口径都可以使用，但必须标清所回答的问题，并在趋势比较中保持一致。

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

吞吐量通常按固定周期内满足完成定义的工作项数量统计，例如每周完成多少项。它适合观察团队交付节奏是否稳定，但任务数量不代表价值，也不代表复杂度。某周完成十个小任务，不能直接等同于完成一个关键项目里程碑。

因此，吞吐量最好结合工作类型、完成定义和周期时间看。若任务拆分方式发生变化，完成数可能突然提高，但真实交付能力并没有变化。复盘时要同时问“完成了多少”“完成的是什么”“是否符合验收”，而不是只看柱状图变高没有。

5. 老化任务与阻塞时间：哪些工作正在失去流动性

老化任务指仍未完成、但已在流程中停留较久的工作。它补足了只看已完成任务的盲区：周期时间统计通常只包含完成项，正在停滞的任务还没有进入完成样本。团队可以定期查看进行中任务的已停留时间，并标记超过自身常态范围的卡片。

阻塞时间用于观察任务因依赖、审批或资源等原因无法继续推进的时长。必须先约定什么才算阻塞，并区分正常等待与真正停滞。若把所有暂停都当阻塞，数据会失去辨别力；若要求成员只有在问题严重时才标记，团队又会错过早期信号。

指标定义可参考 Kanban Guide 对流动指标的说明，包括在制品、吞吐量、工作项年龄和周期时间。具体团队仍需自行规定状态范围、计时方式和例外处理；公开指南提供的是概念框架，不是适用于所有组织的绩效阈值。

五、用一组情景模拟数据演示如何诊断

1. 示例团队的观察结果

下面是一组情景模拟数据，用于演示分析步骤，不来自真实客户项目，也不代表行业基准。假设一个跨职能项目组连续观察四周，统一以“进入处理中”为周期时间起点，以验收通过为完成终点，每周固定记录WIP、完成项数和阻塞情况。

从这组示例可以提出一个诊断假设：第1周到第3周，WIP持续增加，完成量没有随之增加，周期时间中位数和长时间阻塞项也在上升。这提示团队可能有过多工作同时启动，或等待与依赖正在累积。但这仍只是线索，不能仅凭表格断言原因。

2. 继续向下钻取，不要直接开药方

下一步应按状态和工作类型拆开看。如果新增WIP主要落在“待评审”，要检查评审容量、评审责任是否明确，或任务是否集中在少数评审人手中。如果阻塞任务主要等待外部确认，则需要看依赖方响应机制，而不是要求执行成员加快处理。

还要检查任务规模是否变化。若第3周集中进入大型跨团队任务，周期时间变长可能与样本构成有关。此时应将任务按类型分组，比较同类工作的趋势。没有完成这个步骤就设置全员WIP上限，可能会限制必要工作，却没有解决真正的等待来源。

3. 试行规则后看过程和结果

假设团队确认“待评审”是主要等待来源，可以尝试为评审指定每日固定处理时段，并明确评审责任人；若发现大家同时启动太多任务，则可试行团队级WIP上限。一次只改一个主要规则，观察接下来两到四周的WIP、周期时间、阻塞构成和完成项数。

不要因为一周的数值改善就宣布优化成功。节假日、项目阶段、任务规模和人员休假都会影响数据。更稳妥的做法是观察多个周期的方向，并结合具体卡片复盘：等待是否减少？任务是否更快通过瓶颈？完成质量和返工是否变化？若只改善一个数字，却引发返工或质量下降，就不能视为整体流程改善。

4. 每个数据结论都要回到卡片核验

当指标异常时，我会抽取几张代表性卡片，查看状态更新时间、负责人交接、阻塞原因和实际完成记录。数据说明“哪里值得查”，卡片记录和成员访谈才帮助解释“为什么发生”。如果指标显示周期变长，但任务记录缺少状态更新时间，首先要解决的是数据质量，而不是流程速度。

当分析结果与成员体感冲突，也不要先假设一方错了。可能是统计范围只包含完成任务，遗漏了仍在等待的卡片；也可能是团队成员把“等待评审”视为工作完成，而指标仍将其视作进行中。把定义和样本摊开核对，通常比争论谁的感受更准确。

六、不同情况下的行动建议

1. WIP升高，完成量不变

先区分新增WIP出现在“处理中”还是“等待中”。如果主要是处理中，检查任务是否切得过细、成员是否频繁切换优先级，以及是否存在多个并行项目争抢同一批资源。可以试行团队级而非个人级的WIP限制，并规定新工作进入前先判断已有工作能否完成。

如果WIP增加主要来自等待评审、测试或外部依赖，单纯限制成员开工不一定有效。应优先改善瓶颈环节的响应机制，例如明确评审值班、约定依赖方响应时限、提前预约共享资源。不要把等待问题简单归结为“成员做得不够快”。

2. 周期时间变长，但WIP稳定

这种情况应检查工作项结构、任务类型、返工和流程步骤是否变化。若同类任务的周期时间都变长，可能存在容量或流程问题；若只有某一类工作变长，问题可能集中在审批、测试或外部协作。需要观察任务停留位置，而不是只看最终耗时。

还要核验起止点是否变更。例如团队近期把“等待验收”纳入周期时间，但过去没有纳入，那么数据变长可能只是口径更完整。口径调整具有价值，但应在图表和报告中标明变更日期，避免把统计方式改变误读为团队突然变慢。

3. 吞吐量提高，但返工或质量风险增加

当完成项数上升时，要同时检查验收通过率、返工次数、缺陷或投诉等与结果相关的信号。对不同业务而言，质量指标各不相同，但原则一致：不能用更多“完成”抵消更高的返工成本。若任务拆分方式变化，也要确认完成项数提高是否只是计数单位改变。

出现质量回退时，不要简单要求团队降低吞吐量。先确认是验收条件不清、并行工作过多、评审覆盖不足，还是交付节奏压缩导致检查被跳过。改进要针对产生返工的节点，而不是惩罚让问题暴露出来的人。

4. 只有少数任务长期停滞

为老化任务建立轻量检查机制，例如每周两次看一次超过团队近期常态的卡片。每张卡片只要求回答三件事：停在哪里、下一步是什么、需要谁协助。若任务确有合理等待，也要记录等待对象和预计响应时间，避免把正常队列误判为无人负责。

老化阈值应从团队自身数据逐步形成，而不是直接采用一个通用天数。可以先看近期同类任务的周期时间分布，再把明显偏离常态的未完成任务作为复核对象。阈值用于提醒检查，不应成为机械超期处罚线。

5. 多团队数据无法比较

先确认各团队是否使用相同的任务单位、完成定义、计时起点和统计周期。如果这些基础口径不同，建议先建立最小共同定义，再保留团队特有的状态细节。不要急着发布横向排行榜；口径不一致时，名次会鼓励团队优化报表，而不是改善流程。

中大型组织可以将项目管理平台作为统一数据入口，但平台上线并不等于指标自动可比。迁移历史数据时，应标记缺失时间戳、旧状态映射和重复任务；若采用私有化部署或从既有系统迁移，也要把权限、审计和数据保留要求纳入实施计划。真正的选型判断应基于试点验证，而非只比较功能清单。

七、指标与规则的取舍：不要把“精细管理”变成额外负担

1. 状态列要细到什么程度

状态拆分能提高可见度，也会提高维护成本。如果等待阶段需要不同的负责人、升级机制或容量管理，拆成独立状态通常有意义；如果只是为了统计某个偶发原因，标签或字段可能更轻量。团队应衡量新增状态是否能改变决策，而不是看其他组织用了多少列。

一种实用做法是先用最少状态运行两到四周，再记录每次复盘时无法回答的问题。如果“等待评审”反复成为瓶颈，就把它显性化；如果某状态几乎没人使用，或成员无法一致判断归属，就合并或重新定义。看板结构可以演进，不必一次设计到位。

2. WIP限制按团队设，还是按个人设

团队级WIP限制有助于共同关注整体流动，促使成员优先协助完成已有工作；个人级限制看起来更精细，却容易掩盖跨职能协作和任务共享情况。若任务需要多人共同推进，按个人卡片数量硬性限额可能制造形式主义，不如先把“团队可同时推进的工作量”作为试点观察对象。

限制值也不应凭空设定。团队可依据近期实际WIP、完成节奏和等待构成进行小幅试行，并观察是否减少过度启动、是否造成成员等待或关键工作延误。若限制导致必要的紧急工作无法进入，应明确例外规则和复盘机制，而不是让成员私下绕过限制。

3. 哪些指标要实时看，哪些适合周期复盘

阻塞任务、无人负责的卡片和超过提醒阈值的老化任务，适合在日常协作中及时看，因为它们可能需要马上有人处理。周期时间、吞吐量和交付周期更适合按周或按迭代观察，因为短时间波动容易受样本量和单个任务影响。

指标展示频率要匹配行动频率。若每天看一张波动很大的吞吐量图，却没有每天做流程决策，成员会对数据噪声过度反应。相反，若阻塞任务只在月底报告中出现，协作问题可能已经拖延很久。先问“看到信号后谁会做什么”，再决定图表多久更新。

4. 是否要给所有工作设置统一阈值

统一阈值便于组织管理，但在任务规模和依赖差异明显时，容易造成误报。更稳妥的方式是定义共同的处理原则，例如“明显偏离本团队同类任务常态时复核”，再允许不同工作类型形成不同观察区间。阈值首先是提醒和诊断工具，不是对成员承诺的固定交付期限。

若组织必须采用统一预警规则，应标明其适用范围和例外条件，并定期检查预警是否过多、是否漏掉真实风险。一个长期触发却从不带来行动的提醒，应重新设计或取消，否则成员会逐渐忽略真正重要的信号。

5. 要不要购买或迁移管理工具

如果团队只有少量成员、流程简单，纸面白板或轻量任务工具可能足够。若组织需要跨团队权限、审计、私有化部署、历史迁移、统一报表或复杂依赖管理，再评估项目管理平台更合理。选工具之前，应先确定要解决的具体问题和必须保留的数据。

迁移评估至少应包含状态映射、任务字段转换、附件和评论处理、用户权限、历史时间戳质量、试点团队验证及回滚方案。以 PingCode 等项目管理平台作为候选时，可针对百人以上组织的跨团队场景，实际验证私有化部署要求、Jira数据迁移路径和报告口径是否满足本组织需要。“支持迁移”不等于历史指标天然可比，“功能齐全”也不等于团队会采用。

八、从一个试点开始，形成持续改进闭环

1. 选择边界清楚的试点范围

不要第一天就要求全公司改看板。可以选一个交付目标明确、团队稳定、任务类型相对集中的项目，先覆盖一个项目组或一种工作流。试点范围太大，规则差异难以控制；范围太小且周期太短，又可能看不到稳定的流程变化。

试点开始前，记录当前状态定义、任务类型、WIP、周期时间、吞吐量和阻塞情况。数据不必一次收集得很复杂，但必须把口径写下来。若历史数据缺失，就先从当前时点开始建立基线，不要为了补齐报表而伪造或猜测时间戳。

2. 用一周把规则说清楚

启动时与项目成员一起确认进入条件、完成条件、阻塞定义和更新责任。规则要具体到卡片怎么处理，而不是只写“及时更新”“加强协作”。可以用几张真实工作卡片进行演练：分别讨论任务是否能进入处理中、等待评审时如何标记、依赖未满足时由谁跟进。

这一步的目的不是追求所有人立刻达成完美共识，而是把最常见的模糊点显性化。若成员对某个状态仍有不同理解，就先选一个临时定义，设定复核时间，并在实际工作中观察是否需要拆分或调整。

3. 每次只改少量规则

如果同时改变状态、人员配置、审批机制、任务拆分方式和WIP限制，数据即使变好，也很难判断哪项改动产生了作用。每轮先选择一个主要假设，例如“评审排队是周期时间拉长的主要原因”，再做对应的小调整，并提前约定要观察的信号。

观察周期要覆盖足够的任务流转，而不只是日历天数。低吞吐量团队可能需要更长时间积累样本；高频团队也不能因为数据多，就忽略任务类型和工作质量。复盘时要同时看指标趋势、代表性卡片和成员反馈。

4. 建立固定复盘问题

一次有效的流程复盘，不需要把所有图表逐项念完。可以围绕几个问题展开：哪些任务比团队近期常态停留更久？等待主要发生在哪里？本周期完成量变化是否由任务结构变化造成？哪些规则帮助了协作，哪些增加了无效维护？下一轮只准备改哪一件事？

复盘结论要落到责任人和时间点，但不必把责任等同于责罚。若多个任务都在相同节点等待，优先检查系统瓶颈；若只有某一张卡片异常，再讨论具体依赖和支持需求。团队需要的是明确的下一步，而不是一张每月更新、没人行动的指标报告。

5. 用试点结果决定扩大、调整或停止

试点后可以有三种选择。若等待减少、任务流动改善且维护成本可接受，就逐步推广；若部分指标变好但成员负担明显增加，先简化字段或状态；若没有改善且原假设被证伪，就停止该项规则，重新查找瓶颈。停止一个无效做法不是失败，而是避免把额外流程永久化。

对于工具迁移或平台统一，应把试点结果带入选型讨论：实际使用者能否顺畅更新？权限和审计是否满足要求？旧数据能否映射到新流程？团队是否需要额外维护字段？试点阶段就要检查这些问题，避免上线后才发现系统配置和真实协作方式不匹配。

九、下一步：用一张卡片检查表开启改进

1. 先检查当前进行中卡片

下一次项目例会前，可以抽查所有进行中卡片，逐张确认负责人是否明确、下一步动作是否具体、是否存在等待或阻塞、状态是否反映真实情况。若大量卡片无法回答这些问题，优先修正信息和规则，不要立即追求更复杂的指标看板。

• 任务是否满足团队约定的进入条件？
• 当前状态对应的是实际处理、等待，还是阻塞？
• 谁负责推动下一步，预计何时更新？
• 任务完成的验收条件是否明确？
• 若任务停留较久，具体需要什么协助？

2. 统一最小统计口径

随后选定WIP统计范围、周期时间起止点、交付周期起点、吞吐量完成定义和阻塞计时方式。把这些定义写在团队看得到的地方，并记录变更日期。对于任务类型差异明显的团队，优先按类型观察趋势，不急着和其他团队进行数值对比。

3. 每轮复盘只带走一个改进动作

团队复盘结束时，明确一个主要问题、一项拟调整规则、一个跟进责任人和一次复核日期。改进动作要能被观察，例如“减少评审等待”需要落实为责任安排或响应机制，而不是笼统要求“提升协作效率”。下一轮再根据数据和卡片现场判断是否有效。

我对项目看板优化的最终判断是：更好的看板，不是让每张卡片都看起来在动，而是让团队更早发现工作为什么没动。先把“进行中”定义清楚，再用指标找到等待发生的位置，最后小步调整规则并验证结果。现在就从抽查一张停留较久的卡片开始，问清它卡在哪里、下一步由谁推动；这比先设一个漂亮但没有依据的效率目标更有用。

参考方法：Kanban Guide（kanbanguides.org）对流动指标的定义说明。本文的案例数值与阈值均为情景模拟或建议基准，不构成行业统计结论。