別怪程式設計師——都是專案經理的錯

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

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

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

產品經理和產品負責人，專案經理和程式經理，執行發起人， 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. 忽略警告標記。傾聽開發人員的建議，當他們告訴你什麼不能做，什麼不應該做，或必須做什麼事情的時候。開發人員一般都不太願意和人扯淡。所以，當他們告訴你，他們不會做某件事，或者不應該做某件事的時候，一定要注意。

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

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