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

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

[[147691]]

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

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

管理誤區(qū)

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

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

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

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

微軟質(zhì)量

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

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

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

蘋果的軟件質(zhì)量問題

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

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

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

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

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

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

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

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

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

3. 不與客戶交流，也不早點測試點子。不去了解為什么他們需要軟件，他們?nèi)绾问褂密浖麄兿矚g軟件哪里，哪里又是他們所討厭的地方。遞增式地發(fā)布，并獲取反饋。按照反饋行事，并改進(jìn)軟件。循環(huán)往復(fù)。

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

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

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

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

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