R3.04.2unbudgeted performance goals are not executed设计
无预算的性能目标不会被执行
别名: 没有上限的性能目标 · 口号不会进迭代 · slogan is not a budget
概念解释
「注意性能」「别太慢」进不了迭代，因为它们不能在某次改动上判定失败。真正会被执行的是带上限的预算：超了就要砍范围、拒合入、或记下一次明确的超支。没有上限的目标在排期里永远排在有日期、有范围的功能后面，等于没有目标。
这里说的是目标在队列里有没有约束力，不是上限该绑哪台设备，也不是检查跑在哪条流水线上。一句没有数字的性能愿望，在和其他工作抢人手时会先输掉。
机制
迭代分配的是能失败的约束。功能有范围和日期，缺陷有复现，预算有「超 / 未超」。口号没有失败态：无论这周做没做，明天仍可以再说一次「要注意」。于是性能工作变成自愿的打磨，只在有人闲下来时发生，而闲下来几乎不发生。
有了可判定的上限，讨论从「要不要管」变成「这次超了哪一条、砍什么才能回去」。砍功能、换实现、拆包，都是执行。没有上限，这些动作没有合法理由，负责人也无法在复盘里指出哪一次本该拦住。目标不是写在原则里就会被做掉的；它必须能在某张票、某次发布上给出否决。
边界
还量不出数的早期探索，当前目标可以是「先立出上限」，而不是假装已经很快——这仍是一个可判定的目标（有没有立出预算）。领导层已经接受现状很慢、并明文暂停治理时，执行被政治停掉，不是因为口号写得不够好；即便如此，把现状写成上限仍然有用，因为它让以后的回归可见。纯研究原型、不发用户的实验可以没有性能目标。预算数字若完全不可及（按当前架构无解），它也不会被执行，只会变成被忽略的墙报，需要先改成可及的一步，而不是继续加口号。
怎么落地
- 把每一条性能愿望改写成可判定的上限；改写不了的，从目标列表里拿掉，不要留在原则文档里充数。
- 迭代计划里给超预算一个处理动作（砍、拆、或明文超支），没有动作的上限仍不会被执行。
- 复盘时只承认那些曾经能判失败的目标；从未有过失败态的「要注意」，不算本季的性能工作。
- 验证：翻上一季度带「性能」字样的票和原则条目，问每一条「哪一次改动本可以因为它失败」。指不出失败点的，就是未被执行的目标。再看实际合入：有没有一次因为超上限被挡或被砍——一次都没有，执行仍未发生。