景成樂天
一個項目的整個流程，不僅僅只有程序開發部分；開發的上游有業務和需求，下游有測試，如果出現任何上線後的問題，都怪罪到程序員的頭上，那麼就有失公允了。
項目是個整體
其實大多數單位，項目推進過程中出現了各種各樣的問題，都會有人跳出來甩鍋，俗稱“甩鍋俠”；需求甩給開發，開發甩給運維。其實也可以理解，可能涉及到個人的績效、考核；其實完全沒有必要這樣。
項目是一個整體，如果項目上線後出現了問題，那就是這個項目組的問題。所以現在很多公司都採用敏捷開發，從需求到開發到測試，都是一個整體，不僅僅可以快速迭代，快速響應業務需求，也可以從一定程度上，避免這種“甩鍋”的行為。
為什麼是程序員背鍋
現實工作中，項目出錯程序員背鍋的事情還是非常多的，為什麼是程序員，而不是測試，不是需求呢？
我觀察，大部分公司的項目流程，開發佔了絕大部分時間和比重，需求和測試被弱化了很多，並沒有做到需求和測試該做到的事情；甚至有些單位的需求人員/產品經理在做需求的時候，還要問開發怎麼寫這個需求；測試人員問開發人員，這個功能應該怎麼測...
在這種背景下，項目出現問題，生產出現BUG，難免需要開發人員背鍋。
生產出現問題應該怎麼處理
我這裡說的不是指，如果快速定位問題，如何進行BUG修復，而是想說說追責方面。
如果是開發人員，代碼是你寫的，問題是因為你的代碼BUG而出現的，那麼先要做好定位問題，解決缺陷，配合運維人員上線及做好上線後的驗證的工作，然後自我反思，以後如何避免出現類似的問題。
如果是開發人員的直屬領導，比如項目經理，“對上”，要勇於站出來承擔責任，而不是說“這個是我們項目組XXX的責任”，項目經理一定要站在項目組成員的前面；“對下”，陪著開發人員一起，定位問題，解決缺陷，配合上線，和項目組成員一起反思；
如果開發人員一而再，再而三的出現錯誤，那麼反思是不是自己任務分配的有問題，比如有難度的工作，分配給一名初級程序員。
當然，如果一個反覆犯錯還不知道改進，甚至是因為工作態度的問題導致經常出錯，那麼可以考慮讓他離開項目。
希望我的回答，能夠幫助到你！我將持續分享Java開發、架構設計、職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
只要是程序就會存在漏洞，成熟的程序相對漏洞會少一點，上線之後出了問題並且造成損失，表面上看是程序員代碼直接導致的，作為實現者本身來講是負有一定責任，但如果把所有的過失都歸結到程序員身上欠妥，從整個鏈條上來看項目的負責人要承擔很大的責任，因為項目版本的發佈和負責人的最後的拍板有直接的關係，項目中除了技術人員還有測試人員，重大的隱患沒有測試出來測試人員也是負有一定的責任。
為什麼程序這麼容易出問題？
1.項目中程序框架設計不合理，導致兼容性或者抗風險能力出問題，好的框架在一定程度上會規避很多不必要的問題出現，而且在新添加功能後不會影響整體邏輯，千軍好得一將難求，一個好的架構師對於一個項目啟動顯得至關重要，但並不是每個軟件公司都能請的起高端的技術人才，所以難免開始設計的框架存在問題，架構師不是天生就有的，也是無數項目摸爬滾打出來經驗提煉出來的，很多老程序員根據自己做的多個項目積累經驗，然後架構出來的東西基本上差異也不會太大。
2.項目週期趕得太急，導致很多功能沒有完全走通就匆匆忙忙上線，這種可能導致功能模塊在還沒有完全調研清楚就直接開搞代碼，所以容易在實現功能過程中忽略掉一些細節，這種細節可能在測試過程中不太容易被發現，結果造成問題到客戶的手裡才被發現，這種會導致出現隱患在裡面，常見的項目故障大部分都是在這種場景下出現的。
穩定的產品是靠時間打磨出來的，任何一點出問題都是某一個人的因素，程序員本身而言就是一個執行者完成到什麼程度，能夠達到什麼效果外在影響還是挺大，週期短以及功能複雜都會導致異常。
曾經做過一個項目，有個同事因為在管理指針進行釋放內存的時候，沒有管理好代碼，造成局部的內存洩露，而且是小塊內存的洩露，結果連續運行72小時系統就會崩潰，造成很差的客戶影響，表面上看是程序員的疏忽造成，但如果在測試階段能夠及時發現這個問題，也不至於到客戶現場才能被發現，所以任何一個問題的出現都不是單一的，單純怪到程序員身上，不太公平。
希望能夠幫到你。
大學生編程指南
不該！
上線不是程序員說上就上的，首先是項目團隊裡的測試人員測試，內部測試通過後交給客戶測試，客戶測試通過，簽字確認同意上線，這才可以上線。
有問題，沒有被測試出來，說明測試人員不給力，首先要問責的，是測試人員。
我在做項目經理的時候，所有要上線的內容，我都會跟客戶反覆確認好：在上線前您可以隨便倒騰，做各種測試，但是您確定無誤上線，就不只是我們的責任了。
即使後面出現了問題，也不是程序員的問題，運維的人來解決，並且，還收費的！
我最討厭甩鍋行為，代碼邏輯有問題，項目經理要檢討，技術精力要檢討，測試團隊要檢討，唯獨不是程序員的錯，可是把鍋給了程序員本人，這就說不過去了。
其實，我們工作中很多的扯皮，推諉，甩鍋，都源於流程搞得不清楚。每個流程都有相應的負責人，各自承擔各自部分的責任，哪裡還有那麼多的破事呢。
傅一聲
這個問題，我想我有必要回答一下。首先，程序員一定不會承擔全部責任，這是肯定的，但你又肯定是要承擔一定的責任的。
直接責任：開發、測試
開發人員和測試人員，在本次事故中，都負有主要責任。作為程序員，代碼邏輯出現問題，源頭在於你，理論上你承擔的責任是比較大的（實際情況下面說）。
寫出與符合項目要求的代碼，是開發人員的責任，所得你的負責。同樣，找出代碼中的bug、其他問題，也是測試人員的工作職責。
既然出錯了，就不要怕擔責任……
第一責任
你的項目經理，要負領導責任。通常情況下，直接責任人都是第一責任人的“擋箭牌”。項目經理對這個過程把控不嚴，導致了事故的出現，但是項目經理通常不負主要責任，更多的是連帶責任。
如果你們家的公司比較小，測試的工作由項目經理或者其他人員充當，那麼項目經理除了要承擔第一責任外，還要承擔主要責任。
測試和開發，誰的責任大？
前面說過，程序員需要寫出符合項目要求的代碼，這就代表需要有一定的自查能力，不能寫出一大堆bug，然後讓測試人員給你提。而測試人員的工作，是找bug。兩者均是主要職責，所以你們需要負的責任是一樣的。
當然，具體情況還要具體分析，一般而言，測試擔的責任有時會多一些。
項目損失，誰的責任？
前面說的，是代碼出現問題，誰的責任比較大的問題。但是當這個項目上線之後，出現了問題，直接責任人就由程序員和測試人員，轉移到了項目經理。換句話說，項目出了問題，老闆只會找項目經理，沒聽說過找程序員或者測試的……
當然，就團隊內部而言，開發和測試依然有不可推卸的責任……
損失誰來承擔？
作為公司的僱傭人員，在工作期間，你所有創造出來的價值，均歸公司所有，同樣造成的損失，也應由公司承擔，但合同另有約定的除外。
難道項目經理、開發、測試就不需要擔責任了嗎？不是，公司可以扣你們績效或者其他處罰，這是合情合理的。
實際情況
我想，一個管理優良的團隊，也會出現這樣的狀況。但與一些差勁的團隊不同，項目經理一定不會揪著成員的頭髮不放，說一定要誰誰承擔責任之類的，而是會開個小會，總結一下教訓，檢討一下自己，該扣績效扣績效，該鼓勵還是要鼓勵。
一直糾結於過去，你要考慮適不適合在這裡發展了，好的團隊，一定是總結過去，放眼未來的。
——摘自W3Cschool學員的回答。
W3Cschool
項目上線後軟件產品出現問題，其實是不應該由程序員來承擔的，這應該是整個項目組來承擔。
程序員在軟件開發過程中，產品經理有沒有跟客戶把需求弄清楚？有沒有把詳細需求跟研發人員溝通好，有沒有定期對產品功能組織審核？
測試人員有沒有理解需求，進而發現產品存在的功能性Bug？
項目經理有沒有定期組織討論產品進度及質量？上線前有沒有組織試運行？
再就是程序員有沒有很好的理解需求，在存在疑惑的需求時有沒有及時的溝通？
這些每一個環節，只要認真負責並且切實做到，都可以讓軟件產品的成熟度更好。
所以一旦產品上線出現重大Bug，不應該由某一個人來完全承擔，應該由項目組集體承擔。希望能夠對你有所幫助。
80後技術老白
具體的責任是在於測試組，應該由測試組負責，程序猿的工作只是負責開發與生產力，但是質量的檢測在於測試
我要掙一個億
其實這東西真的挺搞笑的，作為項目負責人負小頭，開發負大頭，那收益怎麼不是開發佔大頭，項目負責人佔小頭？作為項目負責人，有reviewcode的義務，出現問題明顯應該由項目負責人擔主責的，但事實往往是開發的擔責。項目負責人的reviewcode和測試都沒測出問題，卻要開發負責真心操蛋
傳說中的大表哥
不會讓開發的程序員獨自承擔責任的。開發是團隊合作，交付後出現的問題，營業部門，項目管理部門，質量保證部門，開發部門，測試部門，設計部門，運維部門都是有責任的。一般是營業部門，按照合同約定賠償客戶損失。運維部門，處理問題，向用戶提交解決方案。其他部門則需要檢討開發流程的問題，提出質量保證方案。
日衝信息 黃
當然不能，否則誰還敢打工？即便是程序員的錯誤，難道想讓程序員賠個幾百萬？那老闆也太好當了，完全無風險啊，隨便找個理由就可以讓打工者支付所有費用了。想想原先的農奴，不就是這樣造成的嗎？乾的越多，賠的就越多～您的問題好像是在問如何追究主責，其實就是想問可不可以達到這個目的，其心可誅。
小火雞
這肯定大領導的主鍋，程序要是要提交測試，測試完畢要預發環節，之後才會正式上線。靠譜的公司應該都是這麼來的，只有連環節都不懂的垃圾公司才會這麼讓開發背鍋，大公司都是從領導到測試到開發全搞一遍………手打狗頭
