团队一周里三天在救火，项目表上八件事有七件挂着"进行中"。周会上都同意"要减少救火"，散会后继续救。不是意愿问题，是时间账户没人管：救火随时支取，项目靠"剩下的"，维护永远排最后。
这篇谈：三类工作为何不能互换、比例怎么判、预算该显式还是靠剩余、什么规模下这套机制本身就是过度管理。
1. 三类工作与时间不可互换性
| 类型 | 时间形态 | 能否并行 | 被打断的后果 |
|---|---|---|---|
| 日常维护 | 碎片、可中断 | 能 | 延迟，可补 |
| 项目交付 | 需 2h 以上连续块 | 不能 | 当天报废 |
| 救火 | 不可预测 | 不能 | 抢占一切 |
关键不在时长，在形态。救火打断的是连续思考：一个设计判断被打断十分钟，恢复要二十分钟；打断三次，这天就不再设计，只做响应。
所以"这周救火只花了 8 小时，还有 32 小时做项目"是错的算法。那 32 小时已被切成十六段，只能做维护，做不了项目。
// 同一份 40 小时，两种排法（典型量级）
A：项目 2×3h 连续块 + 维护 4×1h + 救火 6h 分散
→ 项目能推进，维护能还，救火被吸收
B：救火 6h 却切成 12 段（每段 30min）
→ 项目 0 推进：没有任何一段够长
// 结论：预算要按"块"记，不按"小时"记
2. 健康比例不是一个数字
"救火占 20% 算健康"这类说法流传很广，但它把结论当成了标准。真实约束只有一条：救火不能侵蚀项目的最小连续块。
| 救火占比 | 项目吞吐 | 判断 |
|---|---|---|
| 低于一成 | 正常 | 可能藏着未被发现的风险 |
| 一到两成 | 正常 | 稳态区间 |
| 两到四成 | 开始延期 | 连续块不再成型 |
| 四成以上 | 基本停滞 | 已进入响应模式，项目名义存在 |
| 波动极大 | 不可预测 | 比稳定高位更难管 |
最后一行的形态最容易被忽略：平均值好看，实际每周都在赌博。管理动作应看波动，不只看均值。
3. 救火占比怎么观测
不能靠回忆，要看工单来源与打断记录，三口径互校：
| 口径 | 怎么取 | 回答什么 | 盲区 |
|---|---|---|---|
| 非计划工作比例 | 工单是否计划外 | 总量 | 口头救火会丢失 |
| 打断频率 | 被切次数 | 连续块损失 | 需埋点 |
| 工单重复率 | 同类月度重复数 | 可消除份额 | 粒度影响结果 |
// 最小可用的工单打标（三个字段就够做趋势）
source : plan / alert / user / self ← 谁发起
recurrence : first / repeat(同类 30 天内第 n 次)
interrupt : yes / no ← 是否打断了正在进行的块
// 只要 recurrence=repeat 的占比在涨，就说明救火里有可消除的部分
没有第三列时，团队会低估损失：一个 20 分钟的工单插进 3 小时的设计块，账面 20 分钟，实际损失接近 3 小时。
4. 日常维护的黑洞
维护项的共同特征：没有截止日，而没截止日的工作永远排最后，直到以故障形态回来。
| 维护项 | 有无截止日 | 被挤压后的表现 |
|---|---|---|
| 证书续期 | 有 | 到期前集中处理，或直接过期 |
| 磁盘清理 | 无 | 直到打满，转为救火 |
| 依赖升级 | 无 | 落后到无法升级，转为项目 |
| 备份校验 | 无 | 恢复时才发现不可用 |
| 告警规则清理 | 无 | 噪声上升，响应质量下降 |
判据：凡是"不做也不会立刻出事"的工作，必须给它一个显式的时间槽，否则它一定会以更贵的形式回来。 这不是管理技巧，是热力学。
5. 计划被挤占的信号
不需要复杂看板，看四个迹象：
- 连续两周没有任何计划项完成——不是慢，是没在跑；
- 计划项开始时间被反复改期，理由都是"临时有事"；
- 项目会讨论的是"何时开始"而不是"做到哪了"；
- 团队用"下周就空了"作承诺，且连续三周没兑现。
第三条最值得警惕：讨论焦点从"进展"变成"启动"，说明项目时间账户已归零，只在等一个不会来的空窗。
6. 预算机制：显式预留，不靠剩余
两种分配逻辑，差别不在比例，在谁先拿。
| 机制 | 顺序 | 结果 |
|---|---|---|
| 剩余法 | 救火 → 维护 → 项目 | 项目拿残值，永远延期 |
| 预留法 | 项目块 → 维护槽 → 救火吸收余量 | 项目有下限，救火有上限 |
| 硬隔离 | 每周固定两天不排救火 | 项目成型，但救火会积压到隔离日 |
预留法不是让救火等死，是给救火设上限：超出部分必须升级成"加人、降级、或接受延期"的决策，而不是自动从项目里扣。
─── 一周预算模板（示例结构，不是标准值）
项目连续块 2 × 3h ← 不可被救火占用，占用需升级决策
维护槽 3 × 1.5h ← 固定时间，按清单消耗，不用完也不回收
值班/响应 余量 ← 明确写"余量"，而不是默认填满
复盘与改进 1 × 1h ← 最容易被删的一项，删了就回到原点
模板的价值在于把"余量"写成显式字段；没有这一行，救火会默默吃掉所有空档。
7. 值班与项目工作的冲突
| 安排 | 项目产出 | 响应质量 | 适用 |
|---|---|---|---|
| 全员轮值，值班日照做项目 | 名义在做，随时被切 | 中 | 告警量低 |
| 值班日不排项目 | 一周损失一天/人 | 高 | 告警量中等以上 |
| 专职 on-call 分离 | 高 | 高 | 团队够大时 |
| 无人值班 | 不稳定 | 低 | 早期项目 |
最差的是第一行：同时损害两件事且不可见——既没做完项目，也没第一时间响应。
判据：值班日能否做项目，取决于告警的中位响应时间，不取决于团队的意愿。 中位响应超过 15 分钟的系统，值班日就不该排需要连续块的工作。
8. "救火英雄"的组织代价
| 激励信号 | 实际奖励的行为 | 长期后果 |
|---|---|---|
| 表扬深夜修复 | 不预防，等出事 | 故障变成表现机会 |
| 复盘只问谁快 | 快速止血 | 同类故障重复 |
| 延期不追责 | 时间可被任意征用 | 项目永远排最后 |
| 维护无人评价 | 只做可见的事 | 黑洞扩大 |
最后一行是闭环：奖励救火会抑制预防，预防减少则救火增加，于是奖励更多救火。 打破它不需要文化运动，只需要在复盘里加一问："这次故障，哪个没做的维护项会导致它？"
9. 削减救火的顺序
顺序错了会白干。正确顺序是先让问题可见，再消重复，最后才谈自动化。
| 顺序 | 手段 | 见效时间 | 失效条件 |
|---|---|---|---|
| 1 | 加可观测性 | 几天到两周 | 告警无分级则收益被噪声吞掉 |
| 2 | 消重复工单 | 两到四周 | 无打标则识别不出 |
| 3 | 自动化 | 数周到数月 | 流程未稳定则加速错误 |
| 4 | 加人 | 即时 | 三个月后回到原点 |
第 1 步先做的理由：没有可观测性，连"哪部分是重复的"都不知道，后续手段都在盲选。第 3 步放最后：把尚未理解的流程自动化，等于把偶发故障变成批量故障。
10. 项目工作的最小连续块
项目推进需要的不是总时长，是一段不被切开的窗口。两个数字要一起定：
// 最小连续块的经验区间（按任务类型校准，不是标准值）
设计/架构判断 ≥ 90min，一次最多 2 段/天
编码实现 ≥ 60min，一次最多 3 段/天
评审与讨论 ≥ 45min，可碎片化，但不宜插入上述块
// 排布规则：连续块放上午，维护槽放下午，救火吸收余量
// 反模式：把连续块排进"有空再说"的日历，它一定不会发生
日历上写"项目"不算预留，写具体时间是。差别在于前者可被任意覆盖，后者需要一次显式决策才能覆盖——而需要决策才能覆盖，正是预算的作用。
11. 度量：四个数
| 指标 | 定义 | 读法 | 误读风险 |
|---|---|---|---|
| 打断频率 | 每日被打断次数 | 连续块是否可能 | 漏掉自招的打断 |
| 计划完成率 | 完成/计划 | 预算是否被尊重 | 计划虚高时无意义 |
| 救火占比趋势 | 月度非计划工时占比 | 结构是否恶化 | 看 6–8 周 |
| 工单重复率 | repeat/总数 | 可消除份额 | 粒度不一致会失真 |
// 判读顺序（先看趋势，再看绝对量）
1) 救火占比连续 6 周上升 → 结构性恶化，进第 9 节顺序
2) 计划完成率长期低于五成且计划项数不变 → 计划虚高或预算不实
3) 打断频率高而工单量低 → 大量口头救火未进系统，先补打标
第三条最常见：工单量看起来健康，实际工作全在聊天窗口完成，账面干净，人已耗尽。
12. 排错：四种"预算做了但没用"
| 现象 | 真实原因 | 处理 |
|---|---|---|
| 项目块仍被会议占满 | 预算只管救火，不管会议 | 把会议纳入块规则 |
| 维护槽是空的 | 没有维护项登记 | 先建清单再排槽 |
| 占比降了仍延期 | 连续块依旧碎 | 看打断频率 |
| 两周后放弃 | 超预算时没有升级路径 | 定义超限三选项 |
最后一条是成败关键：预算能守不是因为共识，是因为超限时必须有人决策——加人、降级、接受延期。没有这个出口，预算会在第一次大故障时被放弃且不再回来。
13. 边界：什么时候这套机制是过度管理
| 场景 | 值得做吗 | 理由 |
|---|---|---|
| 三人以下团队 | 不值得 | 口头协调更快 |
| 工单量趋近于零 | 不值得 | 没有救火要吸收 |
| 项目收尾期 | 不值得 | 短期集中本就合理 |
| 纯维护型团队 | 收益低 | 只需清单与响应 SLA |
| 有多项目并行、交付有承诺日期 | 值得 | 时间账户冲突显形 |
| 救火占比连续上升 | 值得 | 结构恶化需要显式约束 |
判断只有一条：是否存在多方对同一份时间的竞争，且结果没有记录。 竞争不存在时，预算表只是每周多填一张表。
14. 自测
- 救火 8 小时、项目 32 小时，为什么项目仍然没有进展？
- 为什么"救火占 20% 算健康"不能当标准用？
- 日常维护为什么会自己变成救火？
- 值班日排项目工作的前提条件是什么？
- 削减救火时，为什么可观测性必须排在自动化之前？
- 预算执行两周后崩掉，最可能缺的是哪一环？