軟件開發(fā)過程管理被比作放養(yǎng)貓。換句話說，你不能真的做到這件事，但你可以盡你最大的努力去做。再換句話說，軟件項(xiàng)目就像試圖在 NBA 防守勒布朗·詹姆斯(LeBron James)一樣。你根本就阻止不了他，最多只能希望牽制到他。

軟件項(xiàng)目的開發(fā)管理是一門不精確的科學(xué)，這不是什么秘密。以下是我這些年來學(xué)到的 11 條真理，它們幫助我理解了，要管理軟件開發(fā)項(xiàng)目這個(gè)奇怪的世界，我們的能力是多么的有限。

1. 估算總是錯(cuò)誤的

無論是你花一個(gè)小時(shí)還是一年的時(shí)間來做估算，估算結(jié)果都是錯(cuò)誤的。事情本來就是這樣的。結(jié)果不一定錯(cuò)得大相徑庭，可能只錯(cuò)了那么一點(diǎn)點(diǎn)，但肯定還是錯(cuò)的。

如果你看到一份錯(cuò)誤報(bào)告，并認(rèn)為“修復(fù)它需要一個(gè)小時(shí)”，那么幾乎可以肯定的是，它不會(huì)正好需要一個(gè)小時(shí)。它可能需要 45 分鐘，也可能需要 3 個(gè)小時(shí)，但正好花上一小時(shí)的可能性很小，甚至可能僅僅相差一兩分鐘?，F(xiàn)在，你可能會(huì)說，“大約一個(gè)小時(shí)”。這實(shí)際上是一個(gè)更好的估算，因?yàn)榫唧w的、精確的估算是錯(cuò)誤的。

眼下，對(duì)于一個(gè)可能只需要一個(gè)小時(shí)的短小項(xiàng)目來說，這不是什么大問題。但是…

2. 項(xiàng)目越大，你的估算就越不準(zhǔn)確

項(xiàng)目越大，估算就越不精確，尤其是在項(xiàng)目一開始就做的估算。就像上例那個(gè)一小時(shí)的估算，如果你將一個(gè)項(xiàng)目估算為一年，那么它可能需要 9 個(gè)月或者 36 個(gè)月。在某些情況下，它甚至可能需要五年時(shí)間。沒有辦法知道這個(gè)項(xiàng)目是什么時(shí)候開始的。

項(xiàng)目越大，“未知的未知”就越多。通常項(xiàng)目越大，就會(huì)有越多的人參與。也就是說，隨著項(xiàng)目規(guī)模的增加，會(huì)有更多的變量和更多的事情發(fā)生，而這些你根本就無法預(yù)料。所有這些事情都會(huì)增加項(xiàng)目的時(shí)間，而這些時(shí)間你一開始就不會(huì)做到計(jì)劃里，原因很明顯，你并不知道它們會(huì)發(fā)生。

3.注意力和專注力是我們最寶貴也是最稀缺的東西

在構(gòu)建軟件時(shí)，完成一個(gè)項(xiàng)目所需的最有價(jià)值的一件東西，就是團(tuán)隊(duì)中的開發(fā)人員以不受干擾的方式集中精力的能力。

分心的事情越少，團(tuán)隊(duì)的效率就越高。就是這么簡(jiǎn)單。軟件開發(fā)經(jīng)理的主要職責(zé)之一就是減少團(tuán)隊(duì)分心的次數(shù)和持續(xù)時(shí)間。

當(dāng)軟件開發(fā)人員不受干擾時(shí)，他們有很高的工作效率。當(dāng)他們被打斷時(shí)（無論是由于開會(huì)還是被人問問題或者其他的什么事情），他們會(huì)快速喪失工作效率。我們都知道“心流”，都知道進(jìn)入并維持在“心流”狀態(tài)有多困難。流動(dòng)的時(shí)間就像黃金一樣寶貴，應(yīng)該予以保護(hù)。

4. 霍夫斯塔德定律是真理

霍夫施塔特定律是這么說的：

“即使你考慮到了霍夫施塔特定律,項(xiàng)目的實(shí)際完成時(shí)間也總是比預(yù)期的要長(zhǎng)?！薄S基百科（https://en.wikipedia.org/wiki/Hofstadter\’s_law）

這與估算有關(guān)，但值得注意的是這句格言的妙處。你可以虛報(bào)你的估算，因?yàn)槟阏J(rèn)為這樣可以為你贏得完成任務(wù)的時(shí)間。你可以添加額外的因素，將“未知的未知因素”做到計(jì)劃里，并增加你的估算，從而考慮到實(shí)際將比你認(rèn)為的時(shí)間更長(zhǎng)，但是最終，實(shí)際上完成一個(gè)項(xiàng)目仍然會(huì)比你認(rèn)為的實(shí)際上更長(zhǎng)的時(shí)間要更長(zhǎng)。

5. 你不能加快軟件開發(fā)，你只能限制其減慢的程度

這條真理對(duì)于一些管理者來說真的很難理解。軟件需要多久就需要多久。沒有辦法讓它更快。你可以要求團(tuán)隊(duì)投入更多的時(shí)間。你可以揮起鞭子、拿起大棒。你可以乞求、哄騙、懇求開發(fā)人員。你可以說，“但是，這應(yīng)該只需要三個(gè)月??！”但最后從長(zhǎng)遠(yuǎn)來看，你無法提高軟件開發(fā)團(tuán)隊(duì)的速度。

如果你開始意識(shí)到霍夫斯塔德定律的正確性并認(rèn)為“我能讓這些人工作得更快”那么你就錯(cuò)了。你所能做的就是減少他們的干擾，讓他們自主工作，從而防止他們降低工作速度。這個(gè)區(qū)別很微妙，但卻很重要。

6. 你只能在非常短的時(shí)間內(nèi)出現(xiàn)赤字

同樣地，你可以要求團(tuán)隊(duì)投入更多的時(shí)間，熬夜、周末加班，以及種種“鞭笞”的手段，你可能會(huì)從中獲得一些(非常)短期的收益。

但如果你試圖讓它成為一種常態(tài)，如果你試圖讓團(tuán)隊(duì)的引擎始終在 RPM 的紅線上運(yùn)行，它就會(huì)被燒壞。很快，你就會(huì)看到收益遞減。人，就像賽車上的引擎一樣，不能長(zhǎng)時(shí)間承受過多壓力，否則就會(huì)出現(xiàn)故障。

7. 大腦時(shí)間比屁股時(shí)間更重要

沒有什么比要求工作時(shí)長(zhǎng)更能降低生產(chǎn)力了（例如，你的開發(fā)人員要連續(xù)幾個(gè)小時(shí)坐在椅子上）。你可以度量工作時(shí)長(zhǎng)，感覺得到了一個(gè)能夠真正顯示出人們工作效率的指標(biāo)。但是這樣做就錯(cuò)了。要求工作時(shí)長(zhǎng)只會(huì)使團(tuán)隊(duì)士氣低落，因?yàn)樗麄儗?shí)際上是想把時(shí)間花在思考上。

大腦時(shí)間才是最重要的。你這樣想：假設(shè)你是一位經(jīng)理，對(duì)于你來說最重要的是看到團(tuán)隊(duì)坐在電腦前“工作”。你在辦公室里走來走去，看著那些開發(fā)人員坐在椅子上敲擊著鍵盤。真是一番繁榮景象。

但之后你偶然發(fā)現(xiàn)一些開發(fā)人員只是坐在那里盯著屏幕。就是這樣傻坐著，他們只是坐在那里傻看。搞什么鬼！大概半個(gè)小時(shí)，他們什么都沒做！

但是，他們確實(shí)是在工作。他們正在思考。他們?cè)谟么竽X思考解決一個(gè)非常困難的問題。也許他們甚至?xí)酒饋?，在辦公室里轉(zhuǎn)上一圈。最后，他們坐下來，寫下 11 行代碼，并將用戶故事標(biāo)記為完成。

他們符合你的“屁股時(shí)間”標(biāo)準(zhǔn)嗎？不符合。他們是否為一個(gè)非常困難的問題想出了一個(gè)巧妙的解決方案？是的。

屁股時(shí)間證明不了什么。大腦時(shí)間意味著一切。

8. 硬件比開發(fā)人員的時(shí)間更便宜，而且要便宜得多

開發(fā)人員其實(shí)很貴的。要吸引頂尖人才，你就得支付有競(jìng)爭(zhēng)力的薪水。他們每一個(gè)小時(shí)的時(shí)間都不便宜。盡管如此，許多公司并沒有意識(shí)到開發(fā)人員這一個(gè)小時(shí)的時(shí)間具有極高的價(jià)值，舍不得為團(tuán)隊(duì)提供硬件。

還是算了吧，電腦很貴的！額外的內(nèi)存會(huì)讓硬件預(yù)算超標(biāo)的！

好吧，可能是會(huì)超出預(yù)算，但那是因?yàn)槟愕念A(yù)算有問題！

現(xiàn)在我們來算一筆賬：假設(shè)你每年付給每名開發(fā)人員 10 萬美元，或者每小時(shí)大約 50 美元。假設(shè)他們每天花一個(gè)小時(shí)等待編譯器完成工作。然后，假設(shè)你可以為開發(fā)人員的機(jī)器添加一些內(nèi)存和更快的處理器，將等待編譯的時(shí)間減少到每天 45 分鐘。那么一名開發(fā)人員每天就能節(jié)省 15 分鐘。以一年 200 天計(jì)算，也就是總計(jì) 50 個(gè)小時(shí)。按每小時(shí) 50 美元計(jì)算，每名開發(fā)人員每年可節(jié)省 2500 美元。如果速度更快的機(jī)器的增量成本是 500 美元，結(jié)果如何呢？

我們來算一下。如果你有 20 個(gè)開發(fā)人員，那么用更快的機(jī)器反而會(huì)為你節(jié)省 4 萬美元的投資?？谒銘?yīng)該就能算得出來。

這只是為了減少編譯時(shí)間的等待。另外，做其他事情的速度也都會(huì)更快。

如果你的預(yù)算不允許更快的機(jī)器，那么就需要調(diào)整你的預(yù)算。

9. 你不能度量軟件開發(fā)人員的生產(chǎn)力

就這一主題我曾寫過一篇文章。

可以這么說，試圖以一種客觀的方式衡量開發(fā)人員的生產(chǎn)力是徒勞的，根本就不應(yīng)該這樣做。有一些方法可以從主觀上度量生產(chǎn)力，但這些方法需要經(jīng)驗(yàn)和良好的判斷。這些能力都很難得到，一旦擁有它們，就能為你帶來非常寶貴的價(jià)值。

10. 如果你沒有讀過《人件》，那么你就不是一個(gè)真正的軟件開發(fā)經(jīng)理

在我看來，只有一本書能教你如何管理軟件開發(fā)人員：那就是由Tom DeMarco和Timothy Lister一起編寫的《人件》(一定要選擇第三版……)。

這本書非常優(yōu)秀，見解深刻，一針見血，條理清晰，毫無保留。這本書里面充滿了管理軟件項(xiàng)目和軟件開發(fā)人員的智慧。它是永恒的經(jīng)典之作。

快快找來讀一讀吧！

11. 質(zhì)量是一種認(rèn)知，而不是缺陷數(shù)量

這一點(diǎn)真的讓人很難接受。

基本前提是：你的缺陷管理工具中的缺陷已經(jīng)趨近于零，而人們卻仍然可以認(rèn)為你的軟件有缺陷。你的缺陷管理工具中可能有大量的缺陷，而人們卻可以認(rèn)為你的軟件像磐石一樣堅(jiān)固。缺陷管理工具中的缺陷數(shù)量與軟件質(zhì)量之間沒有關(guān)系。

在此，我并不是說你不應(yīng)該嘗試減少你的缺陷數(shù)量，而是恰恰相反。但是最終，你的軟件只有在你的客戶認(rèn)為它質(zhì)量夠高的時(shí)候才可以說它是高質(zhì)量的，而你的缺陷數(shù)量不一定能說明這一點(diǎn)。很奇怪，是吧？

當(dāng)我們談到這個(gè)話題時(shí)，“高”的缺陷數(shù)量意味著什么？如果你的代碼庫有 100,000 行代碼，“高”的定義是什么？那么 500 萬行代碼呢？誰說的？

結(jié)論

即使在最好的情況下，讓一個(gè)軟件項(xiàng)目在短跑道上安全著陸也是一個(gè)具有挑戰(zhàn)性和困難的命題。在這個(gè)過程中，再加上一些模棱兩可，再加上一些隨時(shí)可能出錯(cuò)的定時(shí)炸彈，成功才是奇跡。

訣竅在于接受和理解這些模棱兩可，并與之和諧相處，而不是與之對(duì)抗。接受這 11 條真理將有助于解決這一問題。