按照已確認的需求，**都快要上線了，產品提出需求變更，匆匆改完**上線後導致重大 bug，鍋（責任）應該是研發還是產品來背呢？
工作中背鍋是常態。柱哥想說：背鍋不可怕，背了無數口鍋還沒有一點長進才是最可怕的。
下面我們聊聊如何更有效的背鍋：
首先，我們需要明確責任原則：誰執行誰負責。
這種場景下，**開發和最終上線的的是研發同學（rd 和 qa）的執行的，事故的主要責任是在研發同學了，產品同學變更需求只是乙個誘因，所以這個鍋沒得甩了，只能默默的揹著吧。
不留機會
需求變更慎重評估，堅持流程和原則。需求的變更，特別是快上線前的變更，一定要慎重評估對系統穩定性的影響範圍，我們要堅持三條原則：
特別是第三點，實際工作比較常見的情況是 pm 和 rd 同學私下協商後變更了需求，沒通知 qa 同學，結果導致線上出現嚴重 bug。典型的好心幹了一件壞事。正確的背鍋
這種情況下，如果你接受的需求變更，鍋來了，最好的方式就是用最積極態度去背鍋，快速的解決問題。因為我們已經接受了需求的變更，也就是我們做出了承諾，就需要對自己的承諾負責。
無論後面是出任何問題，責任都是我們的，這個時候去抱怨需求變更等等都不是乙個負責任的表現，都會損害我們的靠譜指數的。
反而承擔責任，快速解決問題，會進一步增加靠譜指數。
漂亮的背鍋
背了鍋，承擔了責任，如果我們更進一步去做乙個根本原因分析，做個深度覆盤，那這個鍋其實背的還是比較值得的。因為通過覆盤，可以有兩個方面的收穫：
正確的認識和面對背鍋和甩鍋，我們都會有不一樣的收穫。事前，盡量不留被甩鍋的機會。承諾了，出問題鍋就是我的，主動承擔責任，不去想著甩鍋。事後，積極從個人和團隊視角做深度的分析和覆盤，提公升能力和視野。
總之，以終為始，解決問題是最為優先的。
需求的變更
需求的變更 2005 07 01 在專案開發的過程中，經常會出現需求發生變更的情況。從變更的結果上看，主要有以下幾種需求變更的情況 1 需求增加 2 需求刪除 3 需求發生改變 我們在實施專案的時候，往往做著做著，突然發現專案的進度已經落下了這麼多。查詢其原因，我們往往會發現，專案的某些需求在悄然的...
談談需求的變更
本來只想寫一篇的，沒想到寫著寫著就成了系列了。關於這個系列的前兩篇文章 談談專案的開發 談談專案的執行 在寫這篇文章之前，先答覆一些朋友的疑問，專案的開發，有沒有必要到那以細呀？究竟有沒有必要，見仁見智吧，畢竟每個管理者在管理時所面臨的問題都是不同的。首先說說一名team leader往往會面臨到的...
需求變更的代價和如何減少需求變更
需求變更的代價 一般來講，需求的變更通常意味著需求的增加，需求的減少相對很少，而且處理需求減少方面的問題也比較容易。當客戶提出新需求的時候，專案開發人員應該分析這些新需求對專案現階段帶來的風險，得出雙方實現變更需求的需要的成本，包括時間 人力 資源等等方面。變更都是有代價的，應該評估一下變更的代價和...