這個專案要多久開發完成？

這個問題是我最常碰到的一個，也是我最難回答的一個。對這種問題最好的回答方式是用全職員工來推算天數。這非常容易，你只需要找出有多少個不重疊的功能特徵，然後每個人負責一個。一旦各個功能塊被分成了不能再分的任務，你計算需要多少人天，這就是你的答案。你無論如何都不可能用比這更少的時間開發完這個專案。

“一個女人生一個孩子要10個月，不論你再增加多少個女人來做這事，都不會縮短這個時間”

“只有當一個任務的完成可以分配多人，並且不需要他們之間相互交流合作的情況下能完成時，人和月才能互相替換。”

“往一個已經延遲的專案裡新增程式設計師只會使專案進一步延遲”(因為專案中現有的人需要培訓新來的人)

-《人月神話》

不幸的是，大部分人只想知道一個專案需要多少時間完成。這實際是個偽命題，因為90%軟體成本的產生是發生在軟體釋出之後。這些費用會產生於修復bug、增加欠缺的功能、效能的改進、對新平臺進行支援(安卓就是一個大債主)或重寫質量差的老程式碼來減少技術債務。即使是專案釋出前，對於如何合適的處理每一種報錯情況，這也是無法預先估計全的。從某種程度上，你就是被別人問了這樣一個問題：“我有一個問題，我想解決它，但我無法說清問題是什麼。請問解決這個問題需要多少時間？”

儘管預估很難，但程式設計師最終要找到一種預估的方法。雖然無法知道一個確切的答案，但我有3種方法能大致估計出一個軟體專案要花多少時間：

1. 想要搞清楚一個事情需要多少時間完成，這最好的方法是找一個程式設計師已經完成的、相似的專案。對一些簡單的網站和應用來說非常有效，或者那些使用標準CRUD的專案也是適用。當專案小且簡單時這種方法最好用。這種方法可以用在軟體1.0版本時，但以後的版本就不行了，因為這時你跟相參照的專案開始慢慢的產生差異，這時寫的程式碼是你以前沒有寫過的。
2. 我的好朋友、並且是以前的同事John Walker(不是這個John Walker)喜歡用這種方法。把專案拆解成最小的任務。然後記錄完成每個任務你認為可能需要多少小時、天、周、月。遵循這種原則，如果一個任務需要幾小時，就是算成一天，如果需要數天，就是算成一週，如果是數週，就算成一月。如果超過一個月，那你就無法知道需要多少時間了，或你根本不知道要做什麼。
3. 我有自己的預估方法，但事實上跟John的把任務拆分成最小的子任務的方法非常相似。我是以最壞的情況下每個最小單元需要的完成時間為標準。彙總，然後乘以4。再向上取捨到最近的素數，就算是對我的這種沒譜的方法的諷刺吧。

對於大型的、獨特的專案，程式設計師幾乎無法知道它需要多少時間開發。它就是像在問“需要花多少時間能找到治療癌症的方法？”然而，大部分的管理部門都拒絕接受這種答案，於是，程式設計師只好玩一些花招，先弄清楚老闆們希望聽到的時間，然後加入一些餘地。還能有什麼辦法？通常都是超近路，這都是因為要去追趕那個本不應該設定的最後期限。你需要明白，預估是困難的，需要執行計劃上的變更。除非你的程式設計師能將任務拆分小於一個月的子任務，千萬不要在軟體釋出時間上做任何市場活動計劃。

這最後一件需要注意的事是，當你在一個現有的軟體(比如2.0版，3.0版….)上增加新功能時，你需要追加20%用來對現有程式碼進行重寫的時間(程式設計師稱之為重構)。這是為了償還技術債務，或為未來的行動鋪路。人們以為Google是拿出20%的時間用來創新，但我敢打賭，其實這大部分是來償還技術債務的。

估計一件事情要花多少事情是非常難的，通常也是不可能的。雖然你曾在一些小專案上有成功的預測，但隨著專案的發展你會感覺到越來越難。一個好的方法是給程式設計師留足額外的時間。很多年輕的程式設計師通常沒有這方面的經驗，所以，專案經理必須把他們估計出的時間乘以4。