現在有很多糟糕的軟件。不可靠，不穩定，不安全，不可用。這些軟件是如此糟糕，以致于有些人要求監管軟件開發和限制專業軟件開發人員為“軟件工程師”，以便于軟件工程師能夠保持專業水準，避免因為疏忽或玩忽職守而被指責。

認可方式可以確保每個開發軟件的人具備一定的知識和能力。但是，專業開發人員也不能保證良好的軟件。即使是訓練有素、經驗豐富并全力以赴的開發人 員，他們創建的軟件，也不能保證都是良好的軟件。這是因為大多數影響軟件質量的決定，不是由開發人員下的——而是由企業中的其他人決定的。（比如這篇文章 《軟件開發項目失敗的3個原因》提到的幾個原因）

[[147691]]

產品經理和產品負責人，項目經理和程序經理，執行發起人， CIO和CTO以及工程副總裁。這些人決定了什么是重要的事情，要做什么，不應該做什么，以及誰來做——哪些問題需要***秀的人去解決，哪些工作可以外包 以便于節約成本。決定雇傭和解雇的人，才是決定要花多少錢在培訓和工具上面的人。

管理者——不是開發人員——決定了企業對質量的選擇——哪里必須***，哪里“差不多”就行。

管理誤區

作為一個管理者，我在我的職業生涯中作過很多錯誤和糟糕的決策。不要求長期質量以降低成本。替團隊簽約卻無法在***期限前完成合同。讓市場來掌控計 劃安排和優先事項，擠出更多的功能使客戶和營銷經理滿意。不顧開發人員和測試人員告訴我的軟件還沒有準備好，以及沒有足夠的時間讓他們做好事情。不管技術 負債的增加。堅持現在或永遠不交付，但是后來莫名其妙地就搞定了。

我從這些錯誤中吸取了經驗教訓。我覺得現在我知道構建良好的軟件需要什么了。我會堅持這些理念。但是，我時常看到其他管理人員犯著與我相同的錯誤。即使是世界上***和最成功的科技公司——微軟和蘋果也不例外。

這些巨鱷能夠掌控潮流的走向。他們能夠決定他們要創建什么，以及什么時候發布。他們有世界上最棒的工程天才。他們擁有所有錢可以買得到的好工具——并且如果他們需要更好的工具，他們可以為自己寫出來。他們知道如何正確地做事情，他們有資金有規模，足以完成一個個挑戰。

他們應該寫出漂亮的軟件。使用他們的軟件時候應該是讓人愉快的。但現實中卻并非如此。而這不是工程師的錯。

微軟質量

微軟的軟件質量問題由于存在的時間長，以致于“微軟質量”已成為一個公認的術語，意味著“差強人意”的軟件，可以勉強被接受——雖然有時軟件并不那么好。

即使在微軟成為占全球主導地位的供應商后，質量仍然是一個問題。《Computer World》于2014年發表了一篇名為《At Microsoft, quality seems to be job none》的文章，抱怨Windows 10的早期版本有嚴重的質量和可靠性問題。Windows 10原本被認為代表了微軟在其新的CEO的執掌下發生的一個翻天覆地的變化，是一個彌補過去錯誤，把事情做好的機會。那么為什么還是會出現問題呢？

由于一直以來推崇的“差不多”的軟件文化和傳統，微軟似乎被困住了，無法改善這種情況，即使他們已經認識到，“差不多”的理念已經不適合這個時代了。這是一個深層次的企業和文化問題。是管理的問題。而不是工程師的問題。

蘋果的軟件質量問題

蘋果和微軟專注的技術領域不同，主要依賴設計和工程的卓越性賺錢。但是，如果說到軟件，蘋果也不比微軟好。

從蘋果地圖，到iTunes和App Store不斷涌現的問題，更新iOS安裝失敗的問題，iCloud數據丟失，嚴重的安全漏洞，沒有任何意義的錯誤消息，莫名其妙限制使用的問題，蘋果軟件在很多基礎的地方以一種尷尬的方式令人失望。

和微軟相同，蘋果的管理層似乎也陷入迷途中：

我擔心蘋果的領導層并沒有認識到軟件缺陷使得聲譽受損的嚴重性，因為如果他們意識到的話，他們必然會做出重大改變以避免這種情況的發生。然而現在并沒有，相反的，多個產品線的更新步伐似乎是正在擴大和加速。
我懷疑蘋果軟件的快速下滑，是一個表明現在的蘋果將市場的優先地位擺得過高的信號：每年都發布一個重要的新版本，顯然對于工程團隊來說既要跟上速度，同時 又保持品質是不可能的。也許你認為這是工程問題，但我懷疑不是——我懷疑沒有任何一個工程團隊能夠在保證時間的同時，維持一個明顯又更高的質量。
Marco Arment，《Apple has lost the functional high ground》，2015年1月4日

在今年的WWDC上，***的公告顯示，蘋果正在提供更多的時間，以確保他們的軟件質量。我們期待這或許是一個跡象，一個表明管理層已經開始理解質量和可靠性是多么重要的跡象。

管理人員：請不要重蹈覆轍

如果像微軟和蘋果這樣的超級公司，有著這么多的人才和資金，依然不能創建出高質量的軟件，那么我們這些小蝦米又怎么能辦到呢？很簡單。不要再犯同樣的錯誤：

1. 將產品推向市場的速度和成本擺在其他任何事情的首位。督促團隊像敢死隊一樣在期限前完成任務。喊著沖刺的口號：要求速度，不給團隊正確做事的時 間，也不給他們停下來反思和改善的機會。我們雖然得在期限和預算內開展工作，但在大多數情況下，企業還是有余地的。敏捷方法和增量交付提供了一條當你很難 談判***期限或成本時的出路。如果你不能說不，那么你可以說“還不行”。鐵面無私地安排優先工作，確保你盡可能快地發布重要的事情。并且由于這些事情的重 要性，所以一定要確保做得正確。

2. 從頭到尾拒絕測試。這意味著結束之后，依然會殘留沒有修復的bug。也意味著交付延遲，因為bug太多。訓練有素的敏捷實踐依賴于測試——和修復 ——在你的編碼過程中。 TDD甚至會強迫你在寫代碼之前測試。持續集成可以確保每次檢查的時候代碼都能工作。也就是說不讓bug有任何可趁之機。

3. 不與客戶交流，也不早點測試點子。不去了解為什么他們需要軟件，他們如何使用軟件，他們喜歡軟件哪里，哪里又是他們所討厭的地方。遞增式地發布，并獲取反饋。按照反饋行事，并改進軟件。循環往復。

4. 忽略基本又良好的工程實踐。裝得好像你的團隊不需要做這些事情，或沒有能力和時間來做這些事一樣，即使我們很早以前就知道正確地做事有助于更快地 發布更好的軟件。作為項目經理或產品所有者或企業老板，雖然你不需要成為軟件工程方面的專家，但是如果你不能深入了解軟件是如何構建的以及軟件應該如何被 構建這些基本原理，那么就作不出明智的權衡決策。關于如何才能做好軟件開發的資訊很多，你沒有理由不好好學習。

5. 忽略警告標記。傾聽開發人員的建議，當他們告訴你什么不能做，什么不應該做，或必須做什么事情的時候。開發人員一般都不太愿意和人扯淡。所以，當他們告訴你，他們不會做某件事，或者不應該做某件事的時候，一定要注意。

當你犯錯誤的時候——別否認，你一定會犯錯誤，要從中吸取經驗教訓，不要浪費這個學習的機會。當出錯的時候，讓團隊來審查以搞清楚出了什么問題，為什么，以及如何可以做得更好。從糾錯審查和測試中學習。認真對待客戶的負面反饋。這是很重要的信息。所以要重視。

作為一個管理者，你能做的最重要的事情是不要帶領你的團隊走向失敗。這要求并不過分，并且也不需要你做太多。

譯文鏈接：http://www.codeceo.com/article/donot-blame-programmer.html
英文原文：Don’t Blame Bad Software on Developers – Blame it on their Managers