学会拒绝

最近工作比较忙，很多项目交付节点临近，积压不少问题单(DTS)需要解决。

其中，有个问题经分析，属于某个功能模块导致的。需要转交给相应模块深入分析整改。但在沟通时，该模块的负责人说可能跟某个特性的被打开有关，建议我关闭后复测看是否解决。复测后，发现关闭前述特性开关，问题不再重现。经沟通，原来该特性在本机型上不支持，但被错误打开了。前不久有另外一个问题单，已经确定属于该原因导致。解决该问题的代码已经提交上库，下周新出的软件版本将解决该问题。

问题原因既然已经确定，那按照通常做法，问题单应该分发给该模块继续后续处理流程：开发人员实施修改（填写分析原因，修改方法，自测试报告等信息），然后提交审核人员审核，归档，测试回归等。但该模块负责人嫌麻烦，觉得按照同样原因问题处理中，直接找测试回归即可，避免上述麻烦的处理步骤，也许在他看来，同样原因的问题处理两遍浪费时间与精力。于是，他提出让测试直接回归即可，同时让我转测试处理，而测试也同意了。

其实，我完全可以拒绝他的要求，因为这不符合问题处理的惯例：那个模块的责任，由那个模块负责处理。但是，不太善于拒绝的我，想着其他两方都同意了，我只是做个顺水人情罢了，费口舌又浪费大家争论的时间，有点不够灵活。于是，就决定按照他们的建议处理下去。

但当我尝试这么做的时候，发现问题出现了。如果按照他们的建议，把问题单直接分给测试处理，就会违反一般问题单的处理流程，万一被质量管理者 QA 检查出来会追究责任。如果按照非问题单处理，则测试不同意，因为这影响到测试团队的绩效。

问题很明了，如果按照合规处理流程，问题单应该走给对应模块，按照规范流程处理即可。如果我顺从该模块的想法处理，那该模块省事了，但违反规则担责任的人是我，还要影响团队绩效。如果不违规，影响的是测试的绩效，测试又不答应。利益与合规与否的关系，很清楚了。

权衡之下，我决定把自己的想法及诉求说出来，合理拒绝其他两方的甩锅。要么走非问题关闭，测试同意即可；要么走一般问题处理，走合规流程，由责任方处理。否则，我将承担责任被追责。

最后，大家达成一致意见，按照合规流程，走一般问题关闭。

在工作中，还是要符合规范，合理拒绝，避免做一个不会拒绝的人。

附录：规范流程

公司对于问题单处理，有专门的规章制度。根据不同类型（标准流程，简易流程，一般问题，非问题，重复问题，同根因问题等）的问题单，分门别类制定了相应的处理流程，处理方法，不同环节填写模板（原因分析，修改策略，上库链接，测试报告等）。同时为保证质量，还有质量管理团队，周期性检查问题单规范是否达标，对不合规处理的问题单责令整改。对造成质量事故的，进行回溯，追究相关责任人的责任。

按理说，大家按照规章制度办事即可。但在实际操作过程中，总有人会基于种种考量想便宜行事。