需求池四十七件事，标着 P0 的十九件。当十九件都是 P0，这个字段的信息量就是零——它不再区分"先做哪个"，只表达"提需求的人有多急"。
优先级不是排名表，是一组必须有人承担的取舍。 它失效几乎从不因为排得不对，而因为没人有权说不、没人愿承担后果、以及"急"由嗓门决定。
1. 失效的三个机制
| 机制 | 现场形态 | 后果 |
|---|---|---|
| 无人有权降级 | 每个 P0 都有"提出者级别"，没人敢动 | 只升不降，最后全是 P0 |
| 沉没成本绑架 | "投了两个月，停下就白费" | 该停的继续吃产能 |
| 紧急感来自声音 | 谁在会上多说两句谁先做 | 排序随会议气氛波动 |
三者叠加会出现一个稳定结果：团队按"谁最近提"排序，不按"什么最重要"排序。判据是同一件事两个月内排位改过三次，且每次都没有新增证据。
2. 四个真实维度
| 维度 | 问什么 | 高值含义 | 判据来源 |
|---|---|---|---|
| 影响面 | 谁受影响、多深 | 核心链路不可用 | 流量、调用方清单 |
| 时效性 | 拖一周会怎样 | 窗口关闭、风险扩大 | 截止日、合同条款 |
| 可逆性 | 做错能否收回 | 数据损坏、对外承诺 | 有无回滚路径 |
| 成本 | 占多少稀缺资源 | 只算稀缺那一项 | 人力、专家、审批位 |
不能用单一分数：四个维度不可通约，把不可逆风险折成分数等于给它的严重性设了上限。加权求和的真实作用是把排序责任从人转给公式，结果不合意就去调权重，而调权重不受记录约束。
可行做法是字典序：先按可逆性分层，层内比时效性，再比影响面，成本只判断"能不能在本周期开工"。
3. 紧急与重要的工程形态
| 类型 | 例子 | 正确处理 |
|---|---|---|
| 紧急且重要 | 支付故障、数据错乱 | 立即抢占，事后补记录 |
| 紧急不重要 | 客户催的临时导出 | 限时窗口或给替代路径 |
| 重要不紧急 | 拆慢查询、补观测、降耦合 | 占固定产能，不参与竞争 |
| 都不紧急 | 改命名、换日志格式 | 批量或不做 |
第三行是唯一需要制度保护的位置：它没有触发者、没有截止日，放任竞争必然排到最后，直到以故障形态回来。反向偏差也要防——"重要不紧急"的判据是有没有可观测的恶化趋势（慢查询占比在涨、恢复时长在拉长），没有趋势只是"更优雅"。
4. P0 名额制与副作用
规则：同一时刻只能有一个 P0，第二个想升的必须先把当前 P0 降下去。
| 设计项 | 规则 | 副作用 |
|---|---|---|
| 名额数 | 团队 1，或每工作流 1 | 真并行故障会卡住 |
| 升级路径 | 只能替换，不能追加 | 冲突从"排序"变成"人对人" |
| 降级责任 | 提议者留名并写理由 | 没人愿当坏人 |
| 期满 | 默认 5 个工作日 | 长期 P0 变成常态 |
最值得说的是第二条副作用：名额制把"哪个更重要"的争论转成"你凭什么把我这个换下去"。所以它必须配裁定角色和书面理由，否则只是把政治成本抬高了一档。
// p0-slot.yaml ── 名额制的可执行形态
slot:
capacity: 1
holder: PAY-3412 支付回调超时
expires_in: 5d // 到期自动降级，续期需新证据
escalated_by: 值班负责人 // 不是提出者
5. 优先级的有效期
不重审的优先级表，三个月后等于一份历史文档——影响面的流量变了、截止日过了、成本依据的人力换了。
| 周期 | 对象 | 动作 | 不做的后果 |
|---|---|---|---|
| 每周 | P0/P1 | 确认成立或过期 | P0 长期占名额 |
| 每两周 | P2 排队项 | 剔除已失效 | 池子越排越长 |
| 每季度 | 整个池子 | 重新问"还要不要" | 旧需求原样回来 |
| 事件触发 | 任一 | 承诺变更、故障、组织调整 | 排序与现实脱节 |
一条纪律：复核不是重排。复核只做两件事——确认仍成立、或删除。每次复核都重排一遍，排序就变成每周一次的谈判，团队会学会"每次都要重新争"。
// 需求条目的最小字段，缺一项不进入排序
id, owner, 影响面, 时效性, 可逆性, 成本, 承诺(有/无), 上次复核日期
6. 降级必须有人做，且承担后果
降级的组织难度高于升级：收益分散（团队受益），成本集中（提出者受损）。
| 方式 | 谁宣布 | 需要什么 | 后果归属 |
|---|---|---|---|
| 延期 | 需求方 + 交付方 | 新的最早可行时间 | 排期者 |
| 缩范围 | 交付方提议、需求方确认 | 不可做清单 | 需求方对外解释 |
| 不做 | 有决策权的人 | 书面理由与替代方案 | 决策者留名 |
| 转交 | 提出者 | 接收方明确接下 | 原提出者不再跟催 |
最糟的是软降级：不说延期，只是不再提，让它在池子里自然下沉。它看起来无冲突，实际让"还要不要做"无人负责，需求方会以更高优先级再提一次。配套要求只有一条：降级理由写成技术判断（"要跨三个服务同时上线，风险不可控"），不是对人的判断。
7. 技术工作的位置
技术工作在优先级表里的位置可预测：永远靠后。不是不重要，而是天然不紧急——无外部触发者、无截止日、下周看不出差别。
| 方式 | 机制 | 结果 | 风险 |
|---|---|---|---|
| 参与竞争 | 与技术需求一起排队 | 长期排末尾 | 债务以故障回来 |
| 固定配额 | 每周期预留比例，不参与竞争 | 稳定推进 | 配额可能被浪费 |
配额制的关键不是比例，而是配额内也要排序：预留 20% 不等于这 20% 随便用，否则会退化成"谁最会表达谁拿走"。代价是当期交付变慢，必须写进排期；悄悄扣的结局是加班补，几个月后以流失结算。
// 配额记账：每周期末核对，超支显式记录
capacity_total: 100%
reserved_tech: 20% // 不参与竞争
reserved_ops: 10% // 值班、故障、发布支持
committed: 70% // 对外承诺只能用这部分
overrun_policy: 从下周期扣，不从上周期借
8. 资源约束常被忽略
优先级表假设资源可按需分配，而真实瓶颈通常只有一两项。
| 资源 | 稀缺形态 | 错误假设 | 检查 |
|---|---|---|---|
| 特定专家 | 只有一人懂 | 假设可并行 | 看该人排期是否超 100% |
| 审批位 | 每周两个名额 | 假设审批不占时间 | 统计评审队列长度 |
| 环境 | 预发唯一 | 假设验证可并发 | 看环境占用日历 |
| 库变更窗口 | 每周一次 | 假设随时可改表 | 看 DDL 排期 |
快检：把条目按"何时能开工"重排一次，顺序变化超过三成，说明排的是意愿不是产能。 表里写本周开始十件事、实际只有两个环境位，这张表从第一行起就是假的。
9. 承诺会覆盖内部优先级
对外承诺一旦做出，权重就高于任何内部判断：它不是"重要"，而是"不能不算数"。
| 情形 | 实际机制 | 处理 |
|---|---|---|
| 承诺插队 | 承诺权重高于内部排序 | 只许占用已分配产能 |
| 承诺过量 | 总量超过可靠产能 | 设承诺上限 |
| 承诺未登记 | 只存在于聊天记录 | 不占产能，也不被承认 |
关键动作是把承诺变成一个占位资源：要么吃掉配额，要么被拒绝。允许承诺"额外增加产能"的组织，等于宣布产能可无限透支，直到某次事故结账。
10. 排序的执行形态
争论的根源常不是判据不清，而是没把判据写成可执行的比较。两步比较能让争论量显著下降：
// 字典序比较，替代加权求和
step1: 可逆性不同? → 不可逆者优先，或先止损
step2: 相同 → 比时效性（有截止日先）→ 比影响面
影响面相近 → 成本低者先做（更早拿到反馈）
edge: 成本占稀缺资源超过本周期可用量 → 不进入排队
"成本低者先做"容易被误读成捡软柿子：它只在影响面相近时成立，目的是缩短反馈，不是挑最省事的。
// 每周排序检查：打出违反名额与过期项
// 依赖 jq 与导出的 backlog.json，字段见 §5
jq -r '.[] | select(.prio=="P0") | .id' backlog.json | wc -l // 应为 1
jq -r --arg d "$(date +%F)" '.[] | select(.reviewed < $d)' backlog.json
11. 度量
| 指标 | 口径 | 读到什么 | 反噬 |
|---|---|---|---|
| P0 数量 | 当前处于 P0 的条目数 | 名额制是否执行 | 改标签不改行为 |
| 平均停留时长 | 同一优先级里的时长 | 复核是否发生 | 强降 → 重要项被误降 |
| 降级次数 | 每周期降级数 | 是否有人做取舍 | 只降无关紧要的 |
| 承诺达成率 | 按时交付比例 | 承诺是否超产能 | 靠缩范围刷高 |
要一起读：P0 在名额内 + 降级次数不为零 + 达成率不下降才算排序在起作用。P0 为零通常不是好信号，而是没人敢标。
12. 排错
| 现象 | 可能原因 | 验证 |
|---|---|---|
| 每件事都是 P0 | 无名额约束 | 数当前 P0 数 |
| 排序每周都变 | 复核被当成重排 | 看有无新增证据 |
| 计划外工作占半天以上 | 承诺未占配额 | 统计插入项来源 |
| 技术工作两季未动 | 参与竞争而非配额 | 看配额是否存在 |
13. 边界
| 场景 | 为什么不划算 | 替代 |
|---|---|---|
| 只有一条工作流 | 无并行度可竞争 | 口头约定 + 每日同步 |
| 需求来自单一来源 | 外部已替你排好 | 与该来源约定队列上限 |
| 周期极短（周级） | 排序周期比工作周期长 | 按到达顺序，附一句理由 |
| 危机期 | 资源被动响应 | 只保留止损与恢复两档 |
| 条目少于一屏 | 排序成本高于收益 | 一张人人可见的清单 |
出现以下任一信号即开始回本：并行工作流 ≥ 2、在追踪的对外承诺 ≥ 3、条目超过一屏、出现过跨部门排序争议。
14. 自测
- P0 名额制为什么必须配裁定角色？不配会退化成什么？
- 加权求和在什么意义上是"把责任从人转给公式"？
- 用什么判据把"重要不紧急"与"只是更优雅"区分开？
- 软降级与显式降级的差别在哪？为什么需求会原样回来？
- 配额制下为什么配额内还要排序？
- 出现哪几个信号时，口头协调已经不够用？