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