bug是大家的,最后写说明的只有我一个

昨天下午，同事突然发信息给我。

“大老板说，最近P2有点多，需要你这边提供一下情况说明和改进意见，下班前给他。”

我问了一句：

“所有P2单子你有吗？发我看看。”

很快把单子甩了过来。

我打开，一条一条往下看。

看着看着，心里慢慢有数了。

这一批所谓“最近的P2”，其实跟我直接相关的——

就一个。

而且这个还挺典型：

用户异常操作 + 研发改库 = 数据异常。

说白了，这种锅，谁都能沾点，但很难说是谁一个人的问题。

剩下的那些？

不是我负责的需求，就是我压根没测这几个。

我私下问了几个研发，还有另一个测试同事。

问得很随意：

“你们那边有没有收到要写说明的通知？”

他们一脸懵：

“没有啊。”

那一刻，其实答案已经很清楚了。

这次，需要“说明情况”的人，只有我。

你也经历过这种时刻吧？

明明是一堆问题的集合，最后却变成了一个人的“总结陈词”。

就像一场群体事故，最后需要一个人站出来，写一份“我们哪里做得不够好”。

而这个“我们”，往往就落在你头上。

我坐在工位上，盯着那一堆P2单子发了会儿呆。

脑子里其实有两个声音在打架。

一个说：

“这不合理吧？凭什么就你写？”

另一个说：

“让你写，你就写，废话那么多？”

你猜最后我听了谁的？

当然是后者。

不是因为你最该写，
更像是——这事最后总会落到你这。

那怎么办？

不写？不可能。

敷衍写？也没意义。

既然要写，那就好好写。

但写什么，其实很关键。

我没有去纠结“这个锅是谁的”，也没有去逐条解释“这不是我的问题”。

这种东西，写出来既没用，还容易把自己写进更尴尬的局面。

我也懒得纠结是谁的问题了。

第一部分，我还是认了一个“该认的点”。

比如那个唯一跟我相关的P2：

确实，在测试的时候，没有充分覆盖到用户的异常操作场景（虽然测试的时候提出过，但是大家一致认为不可能。）

这点你可以不情愿，但不能不承认。

因为这不是甩锅，这是补洞。

我写了一句很简单的话：

“在异常使用路径上的测试覆盖不足，后续会补充相关场景。”

不夸张，不自黑，也不推卸。

点到为止。

第二部分，我开始写“改进建议”。

这才是重点。

我刻意避开“个人问题”，直接从流程下手。

写了三点，很直白：

1. 提测时间过晚

很多需求是压着时间提测，留给测试的空间非常有限。

说白了，不是你不想测，是你没时间测。

1. 提测质量偏低

有些需求一看就知道，连基本自测都没做好。

这种情况下，测试再补，也只是兜底，不是解决问题。

1. 影响范围评估不足

改动一个地方，影响到哪里，其实很多时候是模糊的。

没人说清楚，测试就只能“猜着测”。

而P2，往往就藏在这些“没被说清楚”的地方。

写完这三点，我自己都松了口气。

其实也就那回事。
不纠结是谁的，反而好写多了。

写完我发给同事.

顺便问了一句：

“这样可以吗？”

他说：

“可以可以”

回家的路上，我想了下这件事：

为什么这种事，会落到我头上？

咋混的？哈哈哈哈

但换个角度看，其实也是一种信号：

我已经从“做事的人”，要慢慢变成了“兜事的人”（自嘲）。

前者靠能力，

后者，靠的是信任+稳定+一点点抗压能力。

当然，这种“被选中”，也有代价。

你会多做一些本不属于你的事，

你会偶尔觉得“为什么又是我”，

你甚至会怀疑自己是不是哪里做错了。

但如果你能把每一次这种时刻，都变成一次“表达清楚、推动一点点改变”的机会，

那它就不只是负担了。

现在我也不纠结了。

写说明这件事，本质上不是“认错”，

说白了，就是你怎么写这件事。

你可以把自己写小，

也可以把事情写明白。

反正这次我是这么处理的。
至于对不对……
也就先这样吧。