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

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

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

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

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

-《人月神話》

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

想要搞清楚乙個事情需要多少時間完成，這最好的方法是找乙個程式設計師已經完成的、相似的專案。對一些簡單的**和應用來說非常有效，或者那些使用標準crud的專案也是適用。當專案小且簡單時這種方法最好用。這種方法可以用在軟體1.0版本時，但以後的版本就不行了，因為這時你跟相參照的專案開始慢慢的產生差異，這時寫的**是你以前沒有寫過的。

我的好朋友、並且是以前的同事john walker(不是這個john walker)喜歡用這種方法。把專案拆解成最小的任務。然後記錄完成每個任務你認為可能需要多少小時、天、周、月。遵循這種原則，如果乙個任務需要幾小時，就是算成一天，如果需要數天，就是算成一周，如果是數週，就算成一月。如果超過乙個月，那你就無法知道需要多少時間了，或你根本不知道要做什麼。

我有自己的預估方法，但事實上跟john的把任務拆分成最小的子任務的方法非常相似。我是以最壞的情況下每個最小單元需要的完成時間為標準。彙總，然後乘以4。再向上取捨到最近的素數，就算是對我的這種沒譜的方法的諷刺吧。

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

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

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

[英文原文：how long would this project take? ]

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

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

個人部落格開發完成貼

詠南應用開發框架研發完成

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

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

個人部落格開發完成貼

詠南應用開發框架研發完成

相關推薦