一个词让开发不敢早开工：把需求变更记成Bug的代价

并行交付里，分析师、开发和测试从第一天就同时起跑，速度正是从这里来的。可最近一个项目，这套模型差点被四个字拆掉：BUG · 规则行为不正确 · #0412 · QA。

项目开工几周后，客户调整了一条业务规则。这是合理的变更，好的需求发现本来就该把它挖出来。分析师记录了变更，但开发在第一天就按原始规则把功能建好了——这正是团队要求他做的。测试阶段，QA发现对不上，提了上面那张标准工单。开发几小时就修完了，没人抱怨。

一个月后，同一个开发不再提前开工。他说在“等故事稳定下来”，在“先清理环境”。追问原因，回答很短：他受够了把东西建两遍，还被记在自己账上。

团队惩罚的不是烂代码，是速度。

“Bug”这个词为什么这么重

顺序交付里，需求在写代码前就冻结了。软件和文档对不上，就是有人犯了错，“缺陷”这个词用得没错。

并行交付的假设不同：需求本来就该在代码编写过程中演化。健康的团队会为15–20%的工作量变化做计划，在排期和预算里都留出缓冲。

把这些计划内的变化标成Bug，工单系统就变成了一份永久的追责记录：

• 看板不读评论。报表和绩效评审只数工单，那条“客户周二改了方向”的说明永远上不了图表。
• 人会自保。工程师很快发现提前开工换来的是缺陷记录，于是停下来，悄悄回到等完整签字的状态。

没人决定要慢下来，是工单系统教会了这件事。

同步检查点：两个问题，三个标签

启动会后，并行流各自独立推进，直到汇入同一个质量闸门——同步检查点。可工作的代码、最终确定的业务规则和自动化测试套件在这里第一次碰面。

测试失败时，不默认填“Bug”，而是按顺序问两个问题。

问题一：规则是在代码写完之后才变的吗？功能周一提交，客户周三更新规则，这是范围偏移（需求缺口）。修得一样快，但时间从计划好的变更缓冲里出，不记在开发者的履历上。

问题二：如果规则在先，开发者真的被告知了吗？有时分析师和客户在会上谈妥了变更、记进了决策日志，却没人发到团队频道，也没人更新开发者的工单。开发者基于旧信息建了东西。这既不是需求在动，也不是开发者的错，而是沟通遗漏（流程缺口）：每日同步的习惯断了。

只有当规则在编码开始前就已锁定、且明确传达，构建结果仍然对不上，才叫真Bug（缺陷）。

看时间戳，不看谁嘴硬

管理者第一个问题通常是：开发者会不会把什么都标成范围偏移，好让自己好看？

不能，因为标签不是主观判断，而是三件事发生的先后顺序。对不上时，业务分析师（管决策日志）、QA负责人（管测试）和开发者（管提交）开个短会，守两条规矩。

• 时间戳胜过记忆。“我挺确定在Slack上提过”不算数。决策比提交新，就是范围偏移；决策更早但没有书面痕迹证明它到达了构建者，就是沟通遗漏。
• 十分钟规则。三人十分钟内理不清顺序，默认记为沟通遗漏。追不到决策是什么时候做的，说明记录本身失败了，这个默认值给了所有人保持日志干净的理由。

AI做跑腿，人做判断

AI能让检查点快很多，前提是守住一条：AI干体力活，人拍板。

AI测试代理几分钟能跑完数千项检查，而不是几天，但结果正式生效前仍由QA工程师复核签字。把AI测试通过直接放行到最终闸门，缺陷就是这么发出去的。查历史也一样：助手读决策日志和git历史，递上一份回执，三人约三十秒核验完就往下走。机器从不关工单。

客户为什么喜欢这套

传统测试阶段容易变成一场持续的争论：这是Bug（客户免费）还是变更请求（要计费）？标签清晰，大部分争论在开始前就结束了，因为每个桶都对应第一天谈好的约定。

• 真Bug和沟通遗漏算我们的，客户不为我们的错误付钱，不管是代码错还是决策没传到位。
• 范围偏移从项目计划里已含的15–20%变更缓冲中扣。

客户每周看到一根简单的油量表：这周改了多少规则，缓冲还剩多少。超过20%才谈额外预算。客户很少介意为变化付钱，前提是能盯着表；他们反感的是意外账单。

一眼看团队健康

把范围偏移和真Bug放在一起看，能得到团队真实状态的X光片。单看任何一个都会误导。

四种组合各讲一个故事，其中两种值得多看一眼。“平静的假象”最常被领导表扬：Bug很少，几乎没有变更，一片绿。这通常意味着团队回到了等待状态，代价体现在交付速度上，而不是工单里。“质量滑坡”是更新的风险：标签是诚实的，但随着AI写了更多代码，评审纪律最先松动。

如果范围偏移远超20%，别去调检查点，问题在上游：启动会的需求发现挖得不够深。

教一个团队并行工作要几个月，毁掉它只要一个下午的错误标签。被工单系统伤过的开发者很少在复盘会上提这件事，他们只是慢下来保护自己。

下一个项目进入测试之前，改掉工单系统里的选项：把真Bug、范围偏移和沟通遗漏分开，每一个都用时间戳来定，而不是互相指认。

根据新信息做调整不是失败。把它当成失败才是。