2023 年 4 月，我被拉进一个 11 人的 SaaS 团队，老板给的 KPI 很直白：把需求从提出到上线的周期，从 40 天压到 20 天以内。
我干的第一件事是打开他们的 Jira。47 个自定义字段。真的，47 个。里面有个字段叫「预估风险等级（内部）」，我翻了两年数据，一共被填过 8 次。
那天下午开周会，12 个人，90 分钟，过三个需求，最后两个卡在「等架构师确认」。架构师那天在客户现场，根本不在会议室。
会开完我就明白了一件事：这个团队缺的不是敏捷，不是 OKR，也不是几个更拼的人。他们缺的是把「等待」这两个字显性化。
一、项目延期的账，大部分不算在「干活」头上
先摆一个公式，利特尔法则：
前置时间 = 在制品数量 ÷ 吞吐率
他们当时的情况：同时在推进的需求 24 个，每周真正能完成的 5 个。24 ÷ 5 = 4.8 周，也就是 33.6 天。老板要 20 天。
老板的思路是「让大家快一点」，把每周完成从 5 提到 8。那 24 ÷ 8 = 3 周 = 21 天，勉强够，但团队得连轴转，而且质量一定掉，缺陷逃逸率会先给你颜色看。
我的思路是动分子。把在制品从 24 降到 10。吞吐率哪怕掉到 4（大概率不会掉这么多），10 ÷ 4 = 2.5 周 = 17.5 天。
这就是我想说的核心：绝大部分项目管理工具、方法论、培训，都在教你「怎么干得更快」。但只要你老老实实量一次就会发现，一个需求从提出到上线，70% 以上的时间根本没人碰它。它在等人评审、等测试环境、等排期、等一个答案、等一个会议。
我给他们算过一次具体的：某个需求 43 天走完流程，其中被人真正动手处理的时间加起来 6.5 天。流效率 = 6.5 ÷ 43 = 15.1%。
流效率（Flow Efficiency）这个指标不新鲜，一般知识工作团队在 10%–25% 之间，DevOps 做得好的团队能到 40% 左右。低于 15% 的时候，你去优化任何「干活速度」，基本是白费力气，因为瓶颈根本不在那里。
二、四种做法，别问哪个最好，问你在哪个象限
我做过一个粗略的整理，把常见做法放在四个维度上看：需求稳定性、共享资源冲突程度、合规要求、变更频率。
瀑布 / 阶段门：需求稳定 + 合规强，这是最优解。银行核心账务系统、医疗设备、飞机航电，你让它们跑两周一个迭代试试？阶段门在这里不是「落后」，是风险控制。FDA 的软件审评、航空的 DO-178C，都有强制的过程要求，这不是项目经理能拍脑袋绕过去的。
Scrum：需求不确定、团队能自己排优先级、有稳定的产品负责人。它解决的是「做错的东西」的问题，不是「做慢」的问题。很多团队上 Scrum 之后反而更慢了，因为他们把站会、评审会、回顾会全加上了，却没减掉任何一个旧流程。会变多了，活没变快。
看板 / 持续流：运维、支持、持续交付类工作。它的核心不是那块板子，是 WIP 上限。没有 WIP 上限的看板，就是一面贴满便签的墙。
关键链（CCPM）：多项目并行、共享资源冲突严重的场景。Goldratt 在《关键链》里的做法是把每个人任务里藏的安全时间抽出来，集中成一个项目缓冲。书里宣称能缩短 25%–50% 的工期，实际落地打个对折比较现实，我第一次照搬就翻过车。
反直觉的一点：11 个人的团队，如果你同时跑 3 个以上项目，用哪种方法论都会退化。原因在切换成本。Gerald Weinberg 在《Quality Software Management》里给过一组经验值：一个人同时参与 2 个项目损失 20% 的时间，3 个损失 40%，5 个损失 75%。这组数字是经验估算不是实验数据，但方向没错。
三、如果你现在就想动手，按这个顺序来
-
先量两周，什么都别改。 导出所有任务的三个时间戳：创建时间、第一次进入「进行中」的时间、完成时间。Jira 用 JQL 配合 changelog，Linear 直接有 cycle time 报表，TAPD 也能导。
-
算 P50 和 P85，不要算平均值。 平均值会被几个超长任务带偏。P85 才是你该给老板承诺的数字——85% 的任务能在这个时间内完成。
-
画价值流图，标等待。 不用工具，白板就行。横轴是时间，纵轴是流程阶段，把每个阶段的「活跃时间」涂黑，「等待时间」留白。涂完你会看到一条黑点很少的长条。
-
设 WIP 上限。 起手公式：团队人数 × 1.5，向上取整。11 人 → 16。跑两周再往下调。超过上限时不允许开新任务，这条必须有人真的执行，通常是团队负责人自己。
-
砍字段。 判断标准很干脆：这个字段在过去 6 个月里，有没有至少 5% 的情况下改变了你的决策？没有就删。47 个砍到 6 个，我们花了一个下午。
这套东西在那个团队跑了大概 10 周。周期时间从 14.2 天降到 8.7 天，流效率从 15% 到 28%。我没法保证你也能拿到同样的数字，样本量是 1，而且我记得当时正好赶上他们把测试环境从 1 套扩到 3 套，这个变量我没法剥离。
四、我盯的 5 个指标，和它们的参考区间
| 指标 | 怎么算 | 参考区间 | 怎么看 |
|---|---|---|---|
| 前置时间 P85 | 从创建到完成，取 85 分位 | 视团队而定 | 只看趋势，连续 4 周向下才算数 |
| 流效率 | 活跃时间 ÷ 前置时间 | 25% 以上 | 低于 15% 时别优化执行 |
| WIP 超限次数 | 每周超过上限的次数 | ≤ 3 次/周 | 超得多说明上限是虚设的 |
| 缺陷逃逸率 | 上线后发现的缺陷 ÷ 总缺陷 | ≤ 15% | 突然升高说明在赶工 |
| 变更失败率 | 导致回滚或热修的部署 ÷ 总部署 | 5% 左右 | DORA 2023 精英团队基准 |
DORA 那套年报我从 2019 年看到 2024 年，2023 年的样本里能同时满足「变更失败率低 + 部署频率高」的团队占比不到两成。这些数字别拿来当 KPI 压人，它们是用来看趋势的，一旦变成考核项，第二个月就失真。
还有一句：按期交付率这个指标，我不太信。因为它太容易被修饰了——把日期往后挪一挪，数字就漂亮了。前置时间的 P85 和流效率不好造假，因为它们是从系统日志里算出来的，你改不了历史。
五、什么时候我说的这套不适用
强合规场景。药品、航空、核电、银行核心账务，这些地方的阶段门和文档不是官僚主义，是进入市场的前提。别因为敏捷流行就把它们拆了，我在一个医疗器械项目上见过有人这么干，后来补文档补了四个月。
硬件和长周期项目。一台设备的开模周期是 8 周，你 WIP 设成 2 也快不了。这类项目的瓶颈在物理时间，不在排队。这时候该做的是并行化和提前锁定供应商，不是画看板。
还有外包交付。你和供应商之间没有共同的看板，信息流是断的，这时候你能做的是把验收标准写死，而不是要求对方跑 Scrum。对方嘴上答应，实际交付物一个都不会变。
我见过最糟的一种情况，是有人把「敏捷」当成免于写文档的借口，结果项目交接的时候，新来的人花了三周才搞明白系统里到底有什么。这不是敏捷的问题，是偷懒。
我现在判断一个团队健不健康，不看燃尽图，看周会上有没有人敢说「这个我做不完」。如果连续三个月没人说过这句话，那他们的数据大概率是修过的，不是真的好。
项目管理这个事，说到底不是让项目不延期。是让延期这件事早点暴露出来，早到你还有时间做别的事。