程式設計師必備：專案時間估算技能

導讀	有位PM 最近告訴我她面臨的一個難題：「軟體工程師永遠不能估算出他們的專案需要多長時間。我該怎麼辦？」還有兩位CEO 最近也告訴我同樣的事情。從高階層面上講，這個問題在於時間估算的時候，工程師、PM、經理、公關以及其他所有人的看法有不同。大多數工程師本能考慮的是，如果一切都按照計劃進行，寫出一個可用的原型所需的最短時間。但下游的人想知道的是專案何時準備發布——這完全是另外一回事了。

有位 PM 最近告訴我她面臨的一個難題：「軟體工程師永遠不能估算出他們的專案需要多長時間。我該怎麼辦？」還有兩位 CEO 最近也告訴我同樣的事情。

《為什麼程式設計師總是無法準確估測專案時間？ 》（http://blog.jobbole.com/24924/），我們都深有體會。我曾經遇到一個項目，預計需要兩天完成，結果做了四個月。在這種情況下，也就是使用「時間翻倍」的經驗估算，也依然差出了一個數量級之多。這樣真的非常影響業務。我曾經看過整個公司為了舉辦一個發布活動費盡心力，結果卻不得不延後數月。

從高階層面上講，這個問題在於時間估算的時候，工程師、PM、經理、公關以及其他所有人的看法有不同。大多數工程師本能考慮的是，如果一切都按照計劃進行，寫出一個可用的原型所需的最短時間。但下游的人想知道的是專案何時準備發布——這完全是另外一回事了。

#對工程師而言，把握估算專案所需時間是一段終身的旅程。忽視這個問題，會給你以及與你直接或間接接觸的每個人帶來困擾。精準把握估算專案所需時間會讓你脫穎而出，同事們將會把這些和你的專業精神，穩定性和工作品質相關聯。

為什麼我們要時間估算

首先我來回答工程師常問到的問題：「為什麼要估算時間？」許多工程師抱怨（有一定道理）這是一份間接成本。 「如果我開足馬力去做，會更快完成專案！」

主要有兩個原因：外部依賴和優先順序。

外部依賴

沒有任何有效活動會在真空中運作。專案通常有外部依賴，例如與非工程團隊（通訊，金融，公關，客服）、其他工程團隊甚至最終使用者本身的協作。協調這些外部依賴關係通常是經理、PM或CEO的職責。這意味著最有資格做時間估算的人（工程師）不是最需要估算時間資訊的人。這種不對稱導致了根本的矛盾。

優先順序

#時間估算也是決定工作優先順序的關鍵。 「錢花的值不值」是專案中的重要指標，沒有真正的估算，也就無法確定錢花的值不值。即使你正在做的功能是世界上最棒的，如果花時間做一個全面的估計，你可能會意識到這將需要花費很長時間才能完成。

假設你正在做一個項目，這將使網站的速度提升50％，但在相同的時間內，可以完成兩個項目，每個項目將使網站快40％。如果沒有花時間做初步的估計，你永遠不會知道你可以做出一個訪問速度更快的網站！

時間估算入門

現在大家都同意絕大多數時候都需要時間估算，我們來談談技巧。

我們低估時間是因為我們考慮的是「我需要多長時間才能寫出這個基本版本？」

但交付的東西不僅僅是基礎版。還需要考慮到編寫，測試，調試和潤色所需的時間。不要忘了開會、訪談、做程式碼審查以及發送電子郵件等事情也需要時間。

低估時間的另一個原因是我們幾乎總是在編碼過程中遇到“未知數”，這些未知數是不可能完全預測和考慮周全的。也許IDE會更新，中斷了項目，你花一天的時間去修復它。在時間估算中無法考慮到這一點。

但是，我們仍然可以比最初的直覺做的更好。以下是我的做法：

第一步：制定技術計畫

#在著手開始工作之前，你應該已經有了一份技術規劃或設計文件，可以為任何重要的專案提供協助。可以用這個讓別人知道你在做什麼，並獲得回饋。制定技術計劃是啟動時間估算的理想階段。當完成技術細節設計時，會發現未知問題，你將會神奇地修改估算時間。也許你會意識到，可能需要把一個正在使用的庫升級到新版本，這可能會增加一天的時間。甚至可能意識到計劃使用的庫實際上並不存在，需要自己寫。

顆粒度在這裡很重要。如果任何一步感到模糊或不清楚，或許你會跳過這個步驟（應該學習更多），或者需要將其分解成更小的步驟。同時如果某個步驟粒度太細，那麼在實務上可能會不堪一擊使整個計畫無效。

有關技術計劃裡應該考慮哪些方面，請參閱 Alicia Chen 的這篇文章《What do you mean ‘we need more time’?》。其中一個關鍵點是消除與 PM 或其他利害關係人之間的任何潛在歧義，這樣最終你就不會因為做錯了某些事而不得不重新開始。

第二步：為每個步驟增加時間預算

估算一下技術方案中的每一步將執行多久。這通常會涉及對細節的研究（「有沒有已經有人實現了這個庫的功能？」）。根據專案的性質，羅列一個簡單原型，可能有助於暴露出許多未來潛在的痛點。

第三個步驟：增加大量的額外時間

現在你已經有初步的估計，但是我們之前提到的所有的點還需要考慮。

• 隨時調試：總是會有Bug。調試很大程度取決於你對特定程式碼庫的經驗和程式碼庫的成熟度。
• 會議、訪談、假期等：可能你不會在工位一直編碼。你真正會有多少小時進行程式設計？估算時應該至少看看你的行事曆。
• 最終測試和bug清理：通常你在編碼的同時應該也在寫測試，但是很多團隊在發布前，需要進行一輪潤色工作或整合測試。在估算中要給予這些工作足夠的預算。如果分階段進行推出，最初推出的1％內容，可能會暴露需要修復的bug，需要考慮到這一點。
• 程式碼審查：專案需要做幾輪程式碼審查？通常需要多長時間？一定要確保有充足的評審人員（也可以確認他們的行程）。如果這是只有一個評審人員的項目，應該提前徵求他們同意，要求他們安排一名候補人員，以防評審人員會休假或在關鍵節點太忙。

一旦開始將所有這些時間開銷添加到專案中，就會開始看到自己的時間估算值與專案實際啟動時匹配地多了。是的，實際情況可能會比估計的更長，你可能會倍感壓力去縮短工期。但是當大家知道他們可以依靠你時，他們會欣賞你的估價。

第四步：專案發布後，對時間估算做回顧總結

#在專案完成之後回顧一下所做的工作，這聽起來很痛苦。但這種審查回顧會讓你從中學到很多，下次做的更好。

哪個過程結果與預期的時間不同？如果整合測試花了比預期兩倍的時間，記下來，下次給測試留下更多的時間。或嘗試改進整合測試系統。

你一​​定會看到自己的估算隨著時間的推移而不斷改善。甚至可以在這個過程中提出一些很好的見解，來幫助整個團隊。

最後，一切都與溝通有關

你的時間表和其他變動事宜，應該提前告知其他人。如果在發布前一個月讓經理知道你正在使用的庫中存在新的安全漏洞，不得不從頭開始，他們會有時間相應的通知公關，財務或用戶，需要推遲發布。

和其他協作方溝通得來的重要回饋，有助於調整時間估算。設計師可能會說：「哦，如果這個花哨的動畫將要花一整週的時間，我們可以完全剪掉它。」PM可能會補充說：「這只是用戶研究中的一個原型實驗。我們不需要為這個迭代做太多的bug清理。」經理可能會說，「你把一半的時間用在了開會？我來解決這個事情！」

對於工程師來說，不要為了取悅上級，向不切實際的時間表妥協。坦誠地說出你的估價時間和變更方式，這樣更專業。

對於其他所有人來說，尊重估算的時間是很難的，而且這需要一個過程。你只能坐下來砍掉實際上不需要發布的功能或階段，來縮短預期的時間，而不是透過嘮叨把時間縮短。

我們永遠無法完美估算專案所需的時間。唯一的辦法就是保持開放、多溝通、同理心，並果斷地決定優先順序。

以上是程式設計師必備：專案時間估算技能的詳細內容。更多資訊請關注PHP中文網其他相關文章！