缺陷管理流程图

凌晨两点，缺陷测试组的管理小王在群里发了一张截图——一个支付按钮在iOS 14.2上点击无响应。他标注了“严重”，流程转给了开发老李。缺陷老李第二天早上十点才回复：“复现不了啊，管理你用的流程什么网络？”这条消息在群里躺了三个小时，产品经理介入，缺陷拉了个临时会议。管理你看，流程缺陷管理流程图的缺陷第一格，从来不是管理“提交缺陷”，而是流程“谁说了算”。

大多数公司画的缺陷流程图都是从“发现缺陷”开始，箭头指向“提交”，管理再指向“分配”。流程但现实里，第一步往往是“扯皮”。开发说环境问题，测试说代码问题，产品说需求就没写清楚。流程图解决不了这个，但流程图能强制一个动作——记录现场。截图、日志、操作步骤、设备型号，缺一不可。小王后来补了五张截图和一段录屏，老李十分钟就定位了问题：一个第三方SDK在弱网下的回调时序bug。

缺陷从提交到修复，中间最容易被忽略的节点是“优先级判定”。不是所有缺陷都值得立刻修。我见过一个团队，把“登录页logo颜色偏了”和“用户提现后余额不更新”都标成P1，结果开发修了三天logo，提现问题拖到周五晚上才紧急发版，用户已经在应用商店刷一星了。优先级不该由测试一个人拍脑袋，得有个简单的矩阵：影响范围乘以用户感知强度。颜色问题影响所有用户但感知弱，提现问题影响少数用户但感知炸裂。后者永远优先。

流程图的中间段，是“修复与验证的循环”。这里有个反直觉的细节：开发说“修好了”，测试别急着点“关闭”。先看代码改动范围，如果动了核心模块，哪怕只改一行，也要跑一遍相关回归。我有次就是太信任那句“就改了个判断条件”，结果那个判断条件牵扯到整个订单状态机，线上出了两小时故障。验证不是点两下按钮就完事，得看改动影响面，必要时要拉开发一起过代码。

最后一段，是“关闭与复盘”。很多团队把缺陷关闭当成终点，流程图画到这就停了。但缺陷真正的价值在于它暴露了流程里的洞。比如前面那个支付bug，根源是测试环境没覆盖弱网场景。复盘时不是骂谁，而是改流程：测试环境加一个网络限制工具，开发提测前必须自测弱网。流程图最后应该有个虚线框，写着“改进措施”，指向流程的起点——不然同样的坑，换个版本还会踩。

说句实在话，画一张完美的流程图不难，难的是让每个节点都有个“负责的人”和“时限”。没时限的流程图就是张装饰画。我们团队现在每个缺陷标签上必须带两个日期：期望修复日和实际关闭日。超期的自动抄送技术总监。压力是有了，但缺陷的平均存活时间从五天降到了两天半。流程这东西，本质上不是用来好看的，是用来逼着人做决定的。

回到开头那个凌晨的截图。现在小王会直接@老李，附上完整日志，并在群里说：“这个我标了P1，影响所有iOS用户，建议今天上午修，下午我验证。”老李回个“收到”，十点前代码就提交了。你看，流程图没变，但每个节点上的人知道自己该干什么，图就活了。