研发团队不可预测，我们用了流动度量

一、先说清楚一件事：流动度量不是“更准的预测工具”，而是“放弃预测后的替代方案”

大多数研发管理者第一次听说“流动度量”时，问我的第一句话是：“这东西能让我预测得更准吗？”

我的回答让他们很失望：不能。流动度量的核心价值不是让预测更精准，而是让你认识到，在知识工作领域，精确预测本身就是一种幻觉，然后给你一套在“不可预测”的前提下仍然可以管理交付节奏的方法。

这个区别很微妙，但决定了你是会用这套工具，还是用完之后觉得“不过如此”。

我是从2021年开始在一个120人的研发团队里推流动度量的。在此之前，我们已经跑了两年Scrum，用的是PingCode来管理需求、迭代和任务。站会、评审、回顾，该有的仪式一个不少。但每个月底报进度的时候，PMO仍然会问我同一个问题：“下个月能交付多少？”

我每次都是拍脑袋给一个数字。偶尔蒙对了，大多数时候偏得离谱。

不是因为团队不努力。是因为研发工作本身就具备高度的变异性和依赖性，一个技术方案选型错误可能多花三周，一个第三方接口文档对不上可能把整个迭代堵死。这些东西用甘特图画不出来，用燃尽图也看不出来。

流动度量就是在这个背景下被我“逼”出来的。它不是我的原创，Domain-Driven Design社区和Kanban社区已经讲了十几年。但真正在国产中大型团队里落地并跑出结论的，我身边确实不多。下面我会把自己踩过的坑、做过的决策、以及最终沉淀下来的判断，完整写出来。

二、120人团队的真实场景：为什么Scrum跑得好，交付依然不可预测

1. 我们当时的团队结构和工作流程

先交代一下背景，这对理解后面的决策至关重要。

我负责的是一个SaaS产品研发中心，2021年高峰期约120人，分布在成都和深圳两个site。

技术栈：后端以Java微服务为主，前端React+TypeScript，移动端Flutter。产品线三条：核心SaaS平台、开放平台/API网关、以及面向大客户的私有化部署版本。

我们用的是PingCode来做需求管理、迭代规划和缺陷跟踪。当时整个团队的Scrum流程已经跑得比较顺了：

• Product Backlog用Epic-Feature-User Story三层管理
• 双周迭代，每个迭代开始时有planning meeting
• 每天15分钟站会，SM开PingCode的任务板过进度
• 迭代结束有review和retrospective
• 测试用例在PingCode Testhub里管理，和User Story关联

从Scrum Guide的标准来看，我们做到了80分。但问题出在哪里？

2. 三个让我开始怀疑“可预测性”的场景

场景一：一个User Story从“Ready”到“Done”走了14天，但实际编码只用了2天。

我让SM把那个迭代的所有用户故事拉出来，逐个标注“从开始开发到部署上线”的实际耗时。结果让我震惊：平均交付周期是11.3天，而中位数只有4.7天。这意味着有一批卡片的交付周期被严重拉长了。

原因是什么？不是开发慢。是这些卡片在“等待代码评审”、“等待测试环境”、“等待UAT反馈”这三个状态上分别堵了3-5天。

Scrum的燃尽图只看“剩余故事点”，完全不反映等待时间。所以我们看到燃尽图正常下降，就以为一切正常，实际上是“排队问题”正在把交付周期拖垮。

场景二：一个迭代承诺了42个故事点，实际交付了38个，偏差只有9.5%。表面上看起来不错，但交付的38个里，有6个不是月初承诺的，是在迭代中临时插入的紧急需求。

月初承诺的需求，实际只完成了32个，偏差率是23.8%。但因为燃尽图只统计“完成了多少点”，不关心“完成了什么”，所以这个信息被掩盖了。

场景三：连续三个迭代，团队都反馈“太忙了”，但吞吐量（每个迭代完成的故事点数）几乎没有变化。

我和三个Tech Lead分别聊了一次。结论一致：不是没干活，是同时进行的事情太多。一个开发手上同时挂着3-4个任务，每天在不同的上下文之间切换，每个任务都在往前推一点点，但没有一个能快速收尾。

这就是经典的“在制品（WIP）过高”问题。团队很忙，但交付很慢。

三、拆解三个最常见的误区：为什么管理者越努力预测，交付越不可控

1. 误区一：把“需求的规模估算”当成了“交付时间的预测”

Story Point（故事点）估的是复杂度，不是时间。

但几乎每个管理者都会忍不住在心里换算，“这个迭代有40个点，上个迭代做了38个点，差不多，应该能做完。”

这个换算忽略了一个关键变量：同样的故事点，会因为等待时间的不同，导致交付周期相差数倍。

一个3点的用户故事，如果所有依赖都就绪、评审一次过、测试环境畅通，3天可以交付。但如果需要等第三方确认接口规范、等安全评审排期、等UAT窗口，同一张卡可能拖到15天。

故事点没有变，交付周期变了。你用“复杂度”去推算“时间”，本质上是假设“系统没有排队”，而研发系统永远有排队。

2. 误区二：把“人均产出”当成核心指标来追

这是最危险的误区之一。

很多管理者喜欢追问：“每个人这个迭代完成了多少个故事点？谁的产出低？”这种管理方式会直接催生两种行为：

• 开发人员倾向于挑“容易的卡”来做，因为可以快速积攒完成量
• 大家拒绝协作，帮别人看代码、写文档、做知识分享，这些不算“产出”

结果就是局部效率看起来提高了（每个人的完成点数都还不错），但整体交付周期反而拉长了（因为复杂卡片没人碰，协作成本被外部化到等待时间里）。

流动度量的核心假设正好相反：不看个人产出，看系统产出。看价值在多长时间内流过了整个系统。

3. 误区三：试图通过“加人”来解决延期问题

当一个迭代看起来要延期，管理者的第一反应往往是“要不要再加两个人进去？”

这个决策在制造业也许有效（多一个人拧螺丝就能多产出一个），在软件开发里几乎总是适得其反。

加人意味着：

• 新人的上手时间（至少1-2周才能独立贡献）
• 原有成员需要花时间带新人（隐性成本）
• 通信链路增加（n个人有n*(n-1)/2条沟通链路）
• 代码库的认知负载上升

结果是短期内的吞吐量可能不升反降。流动度量告诉我们：增加人手解决的是“容量问题”，但大多数延期是“流量问题”，被堵住了，不是人不够。

四、流动度量的专业判断逻辑：三个核心指标如何连在一起看

1. 交付周期（Lead Time / Cycle Time），衡量“快慢”

交付周期是流动度量里最直观、也最容易被误解的一个指标。

我们定义“交付周期”的起点是“开发开始处理这张卡”，终点是“卡片部署到生产环境并验证通过”。注意，我们没有把“需求提出到进入开发”这段时间算进去，那是更广义的Lead Time，我们先从一个可控的范围内开始。

用PingCode的话来说，我们的起点状态是“开发中”，终点是“已上线”。每张卡从进入“开发中”到变更为“已上线”的时间差，就是Cycle Time。

只看平均值是危险的。我的做法是看85分位交付周期，把所有卡片按交付周期从短到长排列，取第85%位置的那张卡的耗时。

为什么是85分位而不是平均？因为研发交付周期通常是右偏分布，大多数卡在合理时间内完成，少量卡被严重拉长。平均值会被那些极端值拉高，让你误判整体情况。

举个例子：我们2021年Q3的数据，平均交付周期是天，但中位数是5.2天，85分位是14.6天。这意味着85%的卡在15天内交付完毕，但少数卡拖到了30天以上把均值拉高了。

我对团队说：不要盯着“平均交付周期”，盯着“85分位交付周期”。这个数字如果能从15天降到10天，意味着那些被堵住的卡正在减少。

2. 吞吐量（Throughput），衡量“多少”

吞吐量的定义很简单：单位时间内交付的卡片数量。

但我们踩过一个坑：什么是“一张卡”？如果一个团队习惯把需求拆得很细（一个User Story拆成5个子任务），另一个团队习惯大卡片，两个团队的吞吐量完全无法对比。

所以我们统一规定：以User Story为统计粒度，不以子任务为粒度。一张User Story不管拆分了多少个开发任务，交付后只计为“1张卡”。这个规则在PingCode里可以通过关联类型来区分。

吞吐量的价值不是用于“考核团队”，而是用于概率预测。

比如我们一个迭代（两周）的吞吐量历史数据如下（最近6个迭代）：

基于这组数据，我们可以算出来：下个迭代交付26-31张卡的概率大约是85%（取历史区间）。如果PMO问“下个月能交付多少”，我的回答不再是“大概30张”，而是“有85%的概率交付26到31张之间”。

这不是更模糊了。这是更诚实了。而且对业务方来说，知道一个靠谱的区间比拿到一个虚假的精确数字有用得多。

3. 在制品数量（WIP），衡量“堵不堵”

WIP是三个指标里最容易被忽视、但影响力最大的一个。

交付周期和WIP之间存在近似线性关系：WIP翻倍，交付周期也差不多翻倍。这不是我发明的，是利特尔法则（Little‘s

Law）推导出来的，在稳定系统中，平均交付周期 = 平均WIP / 平均吞吐量。

我们在PingCode的任务板上设置过WIP限制：每个开发人员同时进行的任务不超过2个；“代码评审中”这一列同时存在的卡片不超过5张。

刚开始推的时候，开发团队是不适应的，“我就差一个评审就可以收尾了，为什么不能同时开一个新卡？”

我的回答是：你可以开新卡，但你需要意识到每一张新开始的卡都会拖慢你手上现有卡的交付。这是物理规律，不是规章制度。

最终我们没有强制WIP限制，但把WIP数据透明化了。每个人的PingCode任务面板上都能看到自己正在进行中的卡片数量。当团队意识到“同时开5张卡导致每张卡都慢”时，行为自然会调整。

4. 三个指标不能孤立看，必须连在一起

这是流动度量最容易用错的地方：管理者只看一个指标，然后做出错误决策。

举例：

• 只看吞吐量：吞吐量上升了，管理者很开心。但可能WIP也上去了，交付周期被拉长了，这是一种“虚胖”的吞吐量增长，不可持续。
• 只看交付周期：交付周期缩短了，但可能是团队在挑简单卡做，把复杂需求推后了，这是一种“假瘦身”。
• 只看WIP：WIP降下来了，但吞吐量也降了，可能是限制太严导致开发等任务，产能闲置。

正确的看法是三个指标一起看：在WIP稳定的前提下，交付周期缩短且吞吐量保持或上升，这才是真正的系统能力提升了。

我把这个叫做“流动三角”，任何一个角动了，另外两个角一定会有反馈。管理者的职责不是追单一指标，而是维持三角平衡。

五、我们在PingCode里跑流动度量的具体实践和踩过的坑

1. 第一步：定义“工作项类型”和“流转状态”，别在这上面偷懒

流动度量的数据质量，80%取决于这一步。

如果你的团队在PingCode里一会儿把Bug当任务管，一会儿当需求管，或者“已上线”状态明明是“部署到预发布”就标记了，那后面所有的度量数据全是噪声。

我们花了两周时间，只做一件事：和三个Tech Lead、两个QA Lead一起，把团队所有可能的工作项类型和流转路径梳理清楚。

最终在PingCode里形成的规则：

• 史诗（Epic）：跨迭代的大型功能，不作为流动度量统计单位
• 特性（Feature）：单个迭代内可交付的功能集合，不做严格统计，但用于向上汇报
• 用户故事（User Story）：流动度量的基础统计单位，从进入“开发中”到“已上线”计算Cycle Time
• 缺陷（Bug）：单独统计，不与User

  Story混合。缺陷的交付周期通常比需求短，混在一起会拉低整体数据

• 技术任务（Tech Task）：如重构、性能优化、依赖升级，也单独统计，因为它们的周期特性不同

流转状态严格定义了5个关键节点：待开发 → 开发中 → 待测试 → 测试中 → 已上线。任何一个跳过状态的操作（比如从“待开发”直接拖到“待测试”）都会被PingCode记录下来，我们在周会上review这些异常流转。

这一步没什么技术难度，纯粹是纪律问题。但如果你在这里放松了，后面所有“数据驱动决策”都是在自我欺骗。

2. 第二步：至少积累6个迭代的数据再开始做任何判断

我的一个教训是：在第2个迭代结束时，我就兴冲冲地拉了一组数据，然后得出“我们交付周期在缩短”的结论。第3个迭代数据猛涨，直接打脸。

后来我理解了：研发交付周期是高度变异的，单点数据几乎没有参考价值。至少需要6-8个迭代（3-4个月）的数据，才能看到稳定的趋势线。

我们实际是在6个迭代后，才开始看到一些有统计意义的模式：

• 哪些类型的User Story交付周期稳定（如常规CRUD需求，6-8天）
• 哪些类型的周期波动大（如涉及第三方集成的，3-25天不等）
• 哪些开发者的交付周期最短，不是因为代码写得快，而是因为他们习惯把需求拆得更细，每张卡体量可控

最后一个发现直接催生了一条团队规范：单个User Story的预估周期如果超过5天，必须在Planning Meeting上拆成更小的卡。

3. 第三步：把流动数据嵌入站会和回顾会，而不是另起一套会议

我刚推流动度量时犯过一个错误：每周拉一个“流动度量周会”，把所有TL召集来看数据。结果两周后就流产了，大家觉得这是额外负担。

后来我调整了策略：不新增任何会议，把流动数据嵌入到已有的Scrum仪式里。

具体做法：

• 站会：Scrum Master打开PingCode迭代面板时，除了看任务状态，多加一句：“有哪张卡在当前状态停留超过3天了？”这比“昨天干了什么”更聚焦阻塞点。
• 迭代评审（Review）：展示交付成果前，先花5分钟看一组流动数据，本迭代吞吐量、85分位交付周期、当前WIP峰值。不是为了“追究责任”，而是让大家对系统的运行状态有共同认知。
• 迭代回顾（Retrospective）：这是我们用得最深的环节。团队看板上会贴一张“流动健康清单”：

  （1）本迭代WIP峰值是否超过了上次回顾时约定的上限？

  （2）85分位交付周期是升了还是降了？

  （3）有没有哪类卡（比如“依赖外部接口”的卡）占了延期的大头？

  复盘内容从“谁做得好/不好”变成了“系统在哪个环节堵了”，讨论质量明显提升了。

4. 第四步：用流动数据做“概率承诺”，替代“精确承诺”

这是流动度量给我们带来的最大实际改变。

以前业务团队问“下个迭代能交付什么”，PO会打开PingCode的Backlog，挑一堆高优先级需求，然后说“我们争取做完这些”。结果到下个迭代末，有些做完了有些没做完，业务方觉得研发“不靠谱”。

改为流动度量后，我们的承诺方式变了：

PO在Planning Meeting上先排好优先级，然后团队根据历史吞吐量数据，取85%概率下能交付的卡片数量，作为“承诺范围”。

举个例子：团队近8个迭代的吞吐量下限是26张卡（按85%概率取）。那这次Planning就只排26张卡进迭代。剩下的放到“如果有余力再做”的缓冲区。

如果业务方问：“那第27张卡什么时候交付？”

回答是：“有85%的概率在下一个迭代的前两天完成。因为我们优先保证前26张的价值交付，同时不堵塞系统。”

这个答案业务方最初是不满意的，“你就不能给我一个确切日期吗？”

但三个月后，他们发现：虽然每次给的都是“概率答案”，但整体交付的靠谱程度反而上升了。因为研发不会再因为承诺了做不到的事情而士气低落，也不会在迭代中途插入紧急需求打乱整个节奏。

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

1. 团队规模较小（15人以下）且业务相对稳定

建议：从最简版本开始，不要一上来就搭全套度量体系。

小团队的优势是沟通成本低，很多阻塞问题在站会上口头就解决了。这时候引入复杂的度量体系反而会让团队觉得“被监控”。

我建议只追两个指标：

• 每两周的吞吐量（就数交付了多少个User Story，别管故事点）
• 每周随机抽查3张卡，看它们从“开发中”到“上线”分别花了多少天

不需要工具改造，在PingCode里手动拉一下就行。目的不是做精准分析，而是让团队形成“关注流动”的肌肉记忆。当你发现某张卡在“待测试”上躺了5天，就去问一句：“有什么可以帮到你的吗？”，这就已经比90%的团队做得好了。

2. 团队规模在50-100人，多条产品线并行

建议：按产品线/价值流独立度量，不要混在一起。

我们120人团队就踩过这个坑。开始我把三条产品线的数据混在一起算平均交付周期，结果数字毫无意义，私有化部署那条线的交付周期天然就比SaaS长（因为多了客户环境适配环节），两个一平均，什么结论也得不出来。

后来我们在PingCode里按项目分离了统计口径：

• SaaS核心平台：独立统计，迭代节奏两周
• 开放平台/API：独立统计，迭代节奏两周
• 私有化部署：独立统计，迭代节奏一个月（因为交付链路更长）

分开之后，每个团队有自己的流动基准线，横向对比不再有意义（也不应该做横向对比），纵向对比（和自己比）开始有指导价值。

3. 团队在敏捷转型初期，流程还不稳定

建议：先不要追流动度量，先把工作可视化做好。

流动度量的前提是，工作项的状态流转是真实且及时的。如果团队还没有养成及时更新任务状态的习惯（比如卡片做完了但还挂在“开发中”），那所有度量数据都是垃圾。

这种情况下我的建议是：

• 花2-3个迭代把看板纪律建立起来，每天站会前，确保自己的任务卡状态是最新的
• SM在站会时打开PingCode面板，用事实说话：“这张卡我看到代码已经合入了，但状态还在‘开发中’，我们更新一下？”
• 流程稳定后再开始记录流动数据，否则第一组数据的质量会让你怀疑人生

4. 业务方对交付时间极度敏感（如大客户承诺了上线日期）

建议：用吞吐量做“上线日期倒推”，而不是用故事点估算倒推。

传统的做法是：拆需求 → 估故事点 → 除以团队速率 → 算出日期。这个链路每一步都有误差累积。

基于吞吐量的倒推做法是：

1. 把这个大客户需求拆成User Story，按优先级排列
2. 查看团队近8周吞吐量（每周交付的User Story数量），取一个偏保守的数字（如85分位）
3. 用总卡片数除以周吞吐量，得出大致需要的周数
4. 在这个周数上加20%的缓冲（因为大客户需求通常有更多未知依赖）

这个倒推出来的日期，比“估算-速率”链路出来的日期，实际上更接近真实情况。因为它基于的是系统真实产出能力，而不是“复杂度的主观判断乘以理想速率”。

七、流动度量的取舍：它不是万能药，有些东西你必须要接受

1. 要接受“永远有异常值”

不管你优化到什么程度，团队总会有一些卡片的交付周期远超正常范围。我们的数据显示，任何迭代中都有大约8%-12%的卡片属于“异常长尾”。

原因通常是：

• 第三方依赖突然变更（接口改了没人通知）
• 关键人员休假导致某张卡无人接手
• 需求本身在开发过程中被重新定义

不要试图消灭所有异常值。你越优化系统去处理这些极端情况，系统的常规效率就越低。正确的做法是：接受异常值的存在，但确保异常卡能被快速识别并升级处理，而不是默默烂在“测试中”那一列。

我们的做法是：任何卡片在当前状态停留超过5个工作日，PingCode自动打标，Scrum Master在站会上主动过问一次。

2. 要接受“流动数据不能用来考核个人”

这是流动度量最容易滑向深渊的地方。

如果你的老板发现某个开发的“个人交付周期”比别人长，然后要求HR把这个作为绩效考核指标，那流动度量在你公司已经死了。

因为一旦考核个人，开发人员会：

• 把大需求拆成无数个微小卡片，每张只做一丁点改动，吞吐量看起来很高，但本质是数据造假
• 拒绝接手复杂的、有依赖的卡片，因为那些卡片的周期天然就长
• 在“开发完成”后立刻把卡甩给测试，不管质量，因为他的个人周期只算到“开发完成”那一刻

流动度量是天生的系统优化工具，不是个人考核工具。如果你需要考核个人，去找别的维度（代码质量、技术方案评审通过率、协作贡献度），别碰流动数据。

我在团队里定了一个铁律：流动度量数据只用于团队级回顾和改进讨论，永远不进入个人绩效评估。这个铁律说了三次，开发团队才开始真正信任这套体系。

3. 要接受“前期投入大，见效慢”

流动度量不是那种“这个月上线下个月就看到效果”的东西。

我们团队从开始梳理工作项状态、统一统计口径，到积累足够数据做出第一个有效判断，花了大约4个月。到团队真正适应“基于概率承诺”的节奏，又花了3个月。

前前后后大半年，中间有过好几次“这玩意到底有没有用”的怀疑。

但回头看，这半年带来的变化是根本性的：

• 团队从“月初承诺月底打脸”变成“提前告知风险、管理预期”
• 站会从“过一遍进度”变成“识别阻塞、提供帮助”
• 业务方从“研发不靠谱”变成“我知道你们说的区间是什么意思，我可以根据这个做计划”

这些变化没有一个是可以速成的。如果你只是想解决“老板问我下个月能交付多少”这个问题的答案，流动度量帮不了你。如果你想改变团队和业务方之间关于“可预测性”的基本对话方式，它可能是目前最诚实的路径。

八、一些可能与你直觉相悖的经验总结

写到这里，我想把几个跟传统管理直觉相悖、但被我们团队数据反复验证过的结论单独列出来：

第一，让团队“慢下来”反而能更快交付。

我们限制WIP后的第一个迭代，吞吐量确实微降了一点。但第二个迭代开始反弹，第三个迭代超过了之前水平。原因很简单：专注完成一件事比同时推进三件事的切换成本低得多。但这个“慢下来”需要管理者的耐心，如果你在第一个迭代看到数据下降就慌了，马上恢复旧模式，那就永远验证不到后面的反弹。

第二，“不承诺精确日期”反而能提高信任。

业务方的信任不是建立在你每次都说“下周二上线”然后准时上架的基础上，因为你不可能每次都准时。信任建立在你每次给出的判断都有依据，并且你坦率地说出不确定性范围。一个诚实的概率区间，比一个虚假的精确承诺，更经得起时间检验。

第三，度量应该让团队“少做决策”而不是“多做决策”。

很多人以为流动度量是给管理者提供更多决策依据。事实上，好的流动度量系统应该减少你需要做的决策数量。当WIP灯亮红的时候，你就知道该停下来；当吞吐量区间稳定的时候，你不需要每次Planning都重新纠结排多少卡。数据把一部分决策自动化了，管理者的精力反而省下来了。

第四，最好的流动度量工具不是报表，是团队的“共同语言”。

我们现在站会上经常听到开发说：“这个卡WIP有点高，我先把另一张收掉再接新的。” 这不是我要求的，是团队自己内化了的判断逻辑。当“交付周期”、“WIP”、“吞吐量”这些词不再只有SM在讲，而是每个人都在日常交流中使用时，流动度量才算真正落地了。

九、如果你现在就想试试，我建议你这样开始

别急着买工具、搞大平台、推制度。

从下个迭代开始，做三件最小的事：

第一件：在你的PingCode（或者Jira、TAPD，什么工具都行）里，找10张上个月完成的User Story，手动算一下每张从“开始开发”到“上线完成”分别花了多少天。排序，找出第85%位置的那张卡花了多少天。把这个数字贴在团队墙上，这是你们团队的“交付周期基线”。

第二件：下个迭代开始时，和团队一起数一下上一个迭代交付了多少张User Story。别管故事点，就数卡片数量。连续记录3个迭代，取最小值。下次Planning时，只排最小值数量的卡片进迭代。

第三件：在站会上多问一个问题。不是“昨天干了什么”，而是“有没有哪张卡在某一个状态上卡住超过3天了？”一旦发现，当场找原因，当场决定怎么解除阻塞。

这三件事不需要任何额外工具，不需要任何管理授权，任何一个Scrum Master或者Tech Lead都能独立完成。

坚持3个迭代。然后你告诉我，团队对“交付节奏”的感知有没有变化。

流动度量说到底不是一套指标体系，是一种看待研发工作的方式，你不再试图控制每一张卡的走向，而是去理解整个系统的行为模式，然后顺应它、优化它。

研发团队的不可预测性不会消失。但你可以在不确定中找到概率，在混沌中找到节奏，在变化中建立信任。这不是魔法，是数据、耐心和诚实的副产品。