代码快上线，临时变需求，匆忙出事故…
The following article is from 常柱 Author 常柱
（给程序员的那些事加星标）
作者：常柱
按照已确认的需求，代码都快要上线了，产品提出需求变更，匆匆改完代码上线后导致重大 bug，锅（责任）应该是研发还是产品来背呢？
工作中背锅是常态。柱哥想说：背锅不可怕，背了无数口锅还没有一点长进才是最可怕的。
下面我们聊聊背锅的艺术：
分锅原则
首先，我们需要明确责任原则：谁执行谁负责。这种场景下，代码开发和最终上线的的是研发同学（RD 和 QA）的执行的，事故的主要责任是在研发同学了，产品同学变更需求只是一个诱因，所以这个锅没得甩了，只能默默的背着吧。
背锅甩锅的艺术
当然，背锅大家都是不愿意的，特别是这种好心办坏事的锅背的那就更是有点冤了，那我们怎么更好的处理才能更好呢。个人建议主要如下：
不留机会
需求变更慎重评估，坚持流程和原则。需求的变更，特别是快上线前的变更，一定要慎重评估对系统稳定性的影响范围，我们要坚持三条原则：
就是尽可能的不做变更，非核心的需求一律留到下一个版本迭代 如果确实需要变更，就要全团队一起做整体的评估，根据实际情况调整计划 RD 不要做私活，变更至少团队内三方讨论达成共识（PM，RD，QA）
特别是第三点，实际工作比较常见的情况， PM 和 RD 同学私下协商后变更了需求，没通知 QA 同学，结果导致线上出现严重 bug。是典型的好心干了一件坏事。
正确背锅
这种情况下，如果你接受的需求变更，锅来了，最好的方式就是用最积极态度去背锅，快速的解决问题。因为我们已经接受了需求的变更，也就是我们做出了承诺，就需要对自己的承诺负责。
无论后面是出任何问题，责任都是我们的，这个时候去抱怨需求变更等等都不是一个负责任的表现，都会损害我们的靠谱指数的。
反而承担责任，快速解决问题，会进一步增加靠谱指数。
背得漂亮
背了锅，承担了责任，如果我们更进一步去做一个根本原因分析，做个深度复盘，那这个锅其实背的还是比较值得的。因为通过复盘，可以有两个方面的收获：
个人提升：可以进一步认清问题的深层次的原因，看在做事的方法方式和做事原则上是不是可以进一步改进提高，让个人变的做事更加靠谱 团队贡献： 可以去分析是不是团队内其他人也会出现类似的问题，是不是流程机制上需要改进，进一步推动团队的工作流程的升级，这样就有了更高的团队视野
总结
正确地认识和面对背锅和甩锅，我们都会有很多不错的收获。
事前，尽量不留被甩锅的机会。承诺了，出问题锅就是我的，主动承担责任，不去想着甩锅。事后，积极从个人和团队视角做深度的分析和复盘，提升能力和视野。
总之，以终为始，解决问题是最为优先的。
- EOF -
关注「程序员的那些事」加星标，不错过圈内事
点赞和在看就是最大的支持❤️