軟件工程師必備時間估算指南

英文原文：The Software Engineer’s Essential Time Estimation Guide

編者按：《人月神話》里面提到，在眾多軟件項目中，缺乏合理的進度安排是造成項目滯后的最主要原因。而進度安排的不合理大部分又出在時間測算不合理上面。事實上與實際進展一致的完美時間測算是不存在的，盡管如此，曾經在 Dropbox 負責過 Web 性能的軟件工程師 Kat Busch 還是提出了他的時間測算方法指南，按照他提供的步驟不斷實踐，你的測算準確度一定會日臻改善。

霍夫斯塔特定律：實際時間總是比預期要長，即便你考慮到了霍夫斯塔特定律。

——道格拉斯·霍夫斯塔特

我的一位產品經理朋友最近告訴我她碰到的一個問題：“軟件工程師永遠都沒辦法估計自己的項目要花多長時間。我該怎么辦？”有兩位 CEO 最近也跟我說了同樣的事情。

我們這些工程師對此早已司空見慣。我曾經見過一個預計 2 天完成的項目最后花了 4 個月。那種情況下哪怕“只需把時間翻倍”的經驗法也還差了一個量級之多。我曾經見過整家公司傾盡全力想要推出一場發布活動結果卻不得不推遲幾個月的時間。

從高級層面來看，問題出在測算時間時工程師的說法跟 PM、經理以及所有其他人的說法不一樣。大多數工程師在直覺上考慮的是，如果一切都按照計劃進行的話，寫出一個原型所需的最少時間。而那些受阻的下游想要知道的是項目什么時候可以為發布準備就緒——這個完全就是另一個故事了。

對于工程師來說，掌握測算技能是一段終身的歷程。對此疏忽大意會讓你以及直接或間接跟你打交道的人備受折磨。掌握測算能讓你在同事當中鶴立雞群，被后者視為專業、穩定和高質量的象征。

為什么要進行測算？

我先從回答聽到工程師問得最多的問題開始：“為什么要估計時間？”許多工程師抱怨（也是有道理的）這屬于額外開銷。“如果我開足馬力全心全意去寫的話項目就可以早點結束了！”

原因主要有兩點：一是存在外部依賴，二是要確定優先次序。

外部依賴

任何有效的事情都不會在真空中發生。項目通常都存在外部依賴，比如跟非工程團隊（財務、PR、客戶支持）、其他工程團隊或者甚至跟最終用戶自己的協調。跟這些外部依賴協調往往是經理、PM 或者 CEO 的工作。這意味著最有資格做出時間估算的人（工程師）并不是最需要這些測算的人。這種不對稱導致了根本性的緊張。

優先次序

時間測算對確定跟蹤優先級也很關鍵。“錢花得值”在工程領域是一項重要指標，沒有一分錢不經過真正的估算。哪怕你在做的功能是全世界最出色的東西，如果你花時間進行充分測算的話，你也許也會意識到要完成需要花費你很長很長的時間。

比方說你正在做一個項目，做成之后可以讓網站快 50%，但用同樣的時間你本來可以完成 2 個項目，而且每個項目都可以讓網站快 40%。如果你不花點時間進行初步測算的話，你永遠都不會知道自己本來可以做出一個快得多的網站！

時間測算入門

現在我們都同意時間測算在絕大部分情況下都是必要的了，下面就應該討論一下測算技巧了。

我們低估時間是因為我們想的是“寫出一個基本版本需要花我多長時間？”

但是交付出去的東西要比基本版本大得多。你需要考慮編寫、測試、調試以及優化程序花費的時間。還有，別忘了開會、訪談、代碼評審、發送郵件等事情也要花費時間的。

我們低估的另一個原因，是我們在編碼過程本身幾乎總會遇到“未知的未知”問題。而這些是不可能充分考慮得到的。也許你的 IDE 要進行更新而中斷了你的項目，然后你不得不花了一天的時間去弄好環境。你的估算是沒有辦法把這件事情也考慮到的。

但是我們依然能夠做得比最初的直覺要好得多。以下是我的做法：

步驟1：制定技術計劃

在開始任何一個重要項目之前，你應該已經有了一份技術計劃或者設計文檔了。你用這個來讓其他人知道你在做什么并且獲得反饋。技術計劃是開始進行時間測算的理想場所。當你關注到那些技術細節時，你就已經在發現那些未知的未知時魔術般地改進你的測算了。也許你會意識到你可能要把某個要用到庫更新到新版本，而這個可能要多花你 1 天的時間。你甚至可能會意識到自己打算要用的一個庫根本就不存在，得自己寫。

顆粒度在這里是很重要的。如果任何一部給人感覺不清楚或者含糊的話，要么你是在蒙蔽（且應該了解更多），要么得把它分解為更小一點的步驟。與此同時，如果某個步驟的顆粒度太細的話，可能會太脆弱導致整個計劃都無效了。

想要知道你的技術計劃里面應該要考慮哪些東西，可以看看 Alicia Chen 的這篇文章的指南。關鍵點之一是跟 PM 或者其他利益攸關者溝通清楚，消除任何有歧義的地方，這樣最后才不會把東西做錯而必須重新開始。

步驟2：給每一步增加時間估算

測算技術計劃里面的每一步實現起來需要多長時間。這往往牽涉到對細節的研究（“這個是不是已經有庫了？”）。視項目性質而言，先扔出一個簡單的原型可以幫助揭示大量可能的未來痛點。

步驟3：追加大量額外時間

現在你已經進行了初步的時間測算，不過我們前面提到過還要考慮很多的其他東西。

• 隨時調試：Bug 永遠殺不完。調試很大程度上取決與你對特定代碼庫的經驗以及該代碼庫的成熟度。

• 會議、訪談、假期等：在做這些事情的時候你基本上是不會在桌面敲代碼的。你真正用于寫代碼的時間究竟有多少呢？在進行估算的時候你至少應該看看自己的日程表。

• 最終測試與錯誤大掃除：你通常應該一邊編碼一邊寫測試，但很多團隊還需要額外進行潤色的工作或者在發布前集成測試。要在測算中給這些留足預算。如果你是分階段推出的話，前面那1% 可能會揭示出需要修正的那些 bug。你也得考慮這個。

• 代碼評審。在這個代碼庫中你一般要進行幾輪？通常要花多長的時間？確保要經過足夠的評審人（可能還要留意一下他們的日程安排）的充分驗證。如果項目是那種只有一位可能的評審人的項目，你應該事先征詢一個備份的人，以防關鍵時刻此人出去度假或者太忙而誤事。

一旦你把所有這些交付的時間開銷也考慮進去，你就會看到自己的時間測算跟項目的實際發布的匹配情況要好很多。是，實際情況仍然會比測算更長。是的，你可能會受到壓力要縮短工期。但當大家弄清楚自己可以依賴你時，他們會賞識你的測算的。

步驟4：在發布之后對測算進行回顧

是的，在項目完成之后再回過頭來審視你的時間測算似乎是一種痛苦。但是你的學習就是通過這種回顧學到的，而下一次你會做得更好。

如果實際花費的時間跟預期不一樣會發生什么事情？如果集成測試花費的時間 2 倍于你的估算，那你就記下來，下一次留出更多的時間。或者試圖改進你的集成測試系統。

這樣下去的話你絕對可以看到自己的事件測算會不斷改善。你甚至可能還會得到另一些很好的洞察來幫助整個團隊。

到頭來一切都與溝通有關

盡早地、經常地與人溝通你的時間表和變更。如果你在發布前一個月讓你的經理知道你正在使用的一個庫出現了一個新的安全漏洞，你不得不重頭開始的話，他們相應地也會通知 PR、財務或者用戶說時間需要推延。

跟相關參與者進行溝通也會讓他們為你提供可影響你測算的重要信息。一位設計師可能會說：“哦，如果那個夢幻動畫需要整整一周才能做出來的話我們干脆砍掉不要算了。”PM 可能會補充說：“這只是一個原型，就是用來對用戶研究進行實驗的。這次迭代我們不需要做太多錯誤大掃除。”經理可能會說：“你有一半時間都用在了開會上？讓我來搞定這件事！”

對于工程師來說，不要為了取悅上司而向不切實際的更短時間表妥協。對你的測算及其該變更方式開誠布公會顯得更加專業。

對于牽涉到的任何其他人來說，尊重這一估算時間是很難的，這需要一個過程。你只有坐下來減少發布時不需要的功能或者階段才能削減時間。光靠嘮叨是不可能把時間減下來的。

我們永遠也沒有辦法完美地估算出項目所需的時間。解決之道唯有開放溝通、有同理心以及毫不留情地確定優先次序。

來自: 36kr.com