看到這樣標題，我的***反應(yīng)就是反對老板這樣做。作為開發(fā)人員，我最討厭有人指著我的鼻子說：這是你的責任，你寫的代碼出了問題。我通常會爭辯，有時會惱羞成怒。但如何能用充分的論據(jù)來證明這樣做法是不合適的呢？我還真沒有系統(tǒng)的考慮過。所以，當看到有這樣的一個討論時，我馬上就被吸引住了，群眾的力量是巨大的，群眾的思想放光芒，我從討論中學到了不少知識，有了這些論據(jù)，當日后不可避免的遇到指責時，至少心里能找到不少安慰。下面先看看這個偉大討論的發(fā)起人對自己遇到的問題的描述吧：

在最近的制度改革中，老板要在我們的bug跟蹤單模板中加入“誰的責任”項，他認為這樣能提高程序員的責任感（跟蹤單上已經(jīng)有地方指明bug是屬于哪個功能/用例的）。我認為這樣會打擊程序員的士氣，導致人們相互指責，而且對于一些由于需求問題而被當成bug的情況無法填寫。

有沒有其它的能反駁這種做法的有效方法？有誰知道哪里有關(guān)于這方面問題的文章可參考的？我希望能拿這些給團隊的同事和老板看。我認為這種文化是不可接受的，希望能在實施前阻止它。任何建議我都十分感激。

有網(wǎng)友一針見血的指出這樣做的弊端，就是：

如果有人認為“誰的責任”項要填的是自己的名字，他就不會報告這個bug。這個會導致團隊的bug數(shù)減少。

對這樣一個問題，我最欣賞的回答是下面一條：

對于這樣的做法，我首先要做的是問你的老板他這樣做究竟想解決什么問題。有很多顯然更好的方法能解決他想解決的問題。

對于一個事情，真的需要有一個人站出來承擔責任嗎？如果是這樣，那你的老板可能在其它什么地方出了問題。一個好的工作流程是需要多人共同參與的，在軟件正式發(fā)布前，它需要經(jīng)過分析人員，開發(fā)人員，代碼審查人員，測試人員。如果你們沒有經(jīng)過所有的這些步驟，那么嚴格按照這些步驟開發(fā)將是解決你的老板的問題的***方案。如果你們已經(jīng)是按照這個流程去做了，那么，哪個個人應(yīng)該為此承擔責任呢？也許誰都不應(yīng)該，也許應(yīng)該譴責的是這些歷史遺留的代碼。

讓人們背后議論、相互指責會引起很不好的后果，千萬不要隨意給人涂黑點，一旦做了就很難挽回。這樣做解決不了任何問題。很少有人會故意的大意犯錯誤。你的老板應(yīng)該自我反思，看看問題究竟是出在什么方面，看看如何能讓這種錯誤不再發(fā)生。

這樣做了后，你就能清楚的看出，如果有人在不斷的犯錯，這很可能是完全不同另外一個問題。

但是指stackexchange網(wǎng)站上***的回答卻是下面一個：

告訴他，這外行人對內(nèi)行人所說的問題根源的外行叫法(如果沒有專門的項來描述這個，一般會使用注釋來替代)。

你可以在網(wǎng)上搜一下軟件bug根源分析等內(nèi)容，你能搜到豐富的資料來證明你的觀點1, 2, 3, 4, …。

… 一個軟件bug的根源通常不是在某個單個的開發(fā)人員身上(填寫此項時特別要注意這點)…

這清楚的說明了為什么“問題根源”是專業(yè)的，而“誰的責任”是外行的。能說明個人責任當然很好，但有時候問題的根源會產(chǎn)生在開發(fā)團隊“外部”。

告訴你的老板，如果需要指明一個承擔責任的人，“問題根源”項應(yīng)該寫成這樣：“編碼錯誤由鮑勃提交，版本號是1234，吉姆在代碼審查中疏漏了此錯誤，審查號是567”。“問題根源”項的目的就是要記錄這樣的內(nèi)容，包括一些在開發(fā)團隊之外的原因。

例如，如果一個bug是由于硬件引起的(受到譴責的應(yīng)該是開發(fā)團隊外的購買/測試硬件的那個人)，用“問題根源”就能很好的描述這個問題，而“誰的責任”就會導致問題跟蹤線索中斷。

對于其它的開發(fā)團隊之外的人導致的錯誤也能這樣記錄 —— 測試錯誤，需求變更，管理決策問題等。比如，如果管理部門決定不投入資金制備災(zāi)難應(yīng)急硬件設(shè)備，在數(shù)據(jù)中心停電宕機事件上填寫“哪個程序員的責任”將毫無意義。

你遇到過這樣的事情嗎？你對此有何見解？