按照已確認的需求，代碼都快要上線了，產品提出需求變更，匆匆改完代碼上線後導致重大 bug，鍋（責任）應該是研發還是產品來背呢？
工作中背鍋是常態。柱哥想說：背鍋不可怕，背了無數口鍋還沒有一點長進纔是最可怕的。
下面我們聊聊如何更有效的背鍋：
分鍋原則
首先，我們需要明確責任原則：誰執行誰負責。
這種場景下，代碼開發和最終上線的的是研發同學（RD 和 QA）的執行的，事故的主要責任是在研發同學了，產品同學變更需求只是一個誘因，所以這個鍋沒得甩了，只能默默的揹着吧。
背鍋甩鍋的藝術
當然，背鍋大家都是不願意的，特別是這種好心辦壞事的鍋背的那就更是有點冤了，那我們怎麼更好的處理才能更好呢。個人建議主要如下：
不留機會
需求變更慎重評估，堅持流程和原則。需求的變更，特別是快上線前的變更，一定要慎重評估對系統穩定性的影響範圍，我們要堅持三條原則：
- 就是盡不做變更，非核心需求留到下一個版本迭代
- 如果要變更就要整體做評估，並調整上線計劃
- RD 不要做私活，變更至少團隊內三方討論達成共識（PM，RD，QA）
特別是第三點，實際工作比較常見的情況是 PM 和 RD 同學私下協商後變更了需求，沒通知 QA 同學，結果導致線上出現嚴重 bug。典型的好心幹了一件壞事。
正確的背鍋
這種情況下，如果你接受的需求變更，鍋來了，最好的方式就是用最積極態度去背鍋，快速的解決問題。因爲我們已經接受了需求的變更，也就是我們做出了承諾，就需要對自己的承諾負責。
無論後面是出任何問題，責任都是我們的，這個時候去抱怨需求變更等等都不是一個負責任的表現，都會損害我們的靠譜指數的。
反而承擔責任，快速解決問題，會進一步增加靠譜指數。
漂亮的背鍋
背了鍋，承擔了責任，如果我們更進一步去做一個根本原因分析，做個深度覆盤，那這個鍋其實背的還是比較值得的。因爲通過覆盤，可以有兩個方面的收穫：
- 個人提升：可以進一步認清問題的深層次的原因，看在做事的方法方式和做事原則上是不是可以進一步改進提高，讓個人變的做事更加靠譜
- 團隊貢獻： 可以去分析是不是團隊內其他人也會出現類似的問題，是不是流程機制上需要改進，進一步推動團隊的工作流程的升級，這樣就有了更高的團隊視野
總結
正確的認識和麪對背鍋和甩鍋，我們都會有不一樣的收穫。事前，儘量不留被甩鍋的機會。承諾了，出問題鍋就是我的，主動承擔責任，不去想着甩鍋。事後，積極從個人和團隊視角做深度的分析和覆盤，提升能力和視野。
總之，以終爲始，解決問題是最爲優先的。
