【我們為什麼挑選這篇文章】我很喜歡這篇文章，因為他不止在談工程師為什麼要做好測算。
老闆跟工程師為什麼很常發生衝突，這其實是因為考量的立場不同，各自不懂各自的難處。很多老闆都是不懂程式的，當然不懂寫程式的難處。所以做好測算，給出一個準確的時程表，解釋為什麼要這麼做，然後跟老闆、PM 做好溝通，相信一切都會好很多（責任編輯：林子鈞）
「霍夫斯塔特定律：實際時間總是比預期要長，即便你考慮到了霍夫斯塔特定律」——道格拉斯·霍夫斯塔特
我的一位元產品經理朋友最近告訴我她碰到的一個問題：「軟體工程師永遠都沒辦法估計自己的項目要花多長時間。我該怎麼辦？」有兩位 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 可能會補充說：「這只是一個原型，就是用來對用戶研究進行實驗的。這次反覆運算我們不需要做太多錯誤大掃除。」經理可能會說：「你有一半時間都用在了開會上？讓我來搞定這件事！」
對於工程師來說， 不要為了取悅上司而向不切實際的更短時間表妥協 。對你的測算及其該變更方式開誠佈公會顯得更加專業。
對於牽涉到的任何其他人來說，尊重這一估算時間是很難的，這需要一個過程。你只有坐下來減少發佈時不需要的功能或者階段才能削減時間。光靠嘮叨是不可能把時間減下來的。
我們永遠也沒有辦法完美地估算出項目所需的時間。解決之道唯有開放溝通、有同理心以及毫不留情地確定優先次序。
- 延伸閱讀
資料科學家、資料工程師和軟體工程師差在哪？這張圖讓你秒懂
Stack Overflow 害了工程師？扭曲的「聲望值」文化，讓這個工程師庇護所不再美好
【AWS 當機一分鐘虧 6 萬美元】當工程師為小事跟你計較時，要知道他們肩上的壓力有多大啊 - 本文經合作夥伴 36 氪授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈 軟件工程師必備時間估算指南 〉。）
【TechOrange 徵才：社群編輯、程式設計】 如果你對數位行銷、Startup 趨勢、產業轉型、程式設計，以及新科技議題有興趣，不怕用與眾不同的面向，去衝撞一般思維，歡迎你加入 TO >> 詳細職缺訊息 意者請提供履歷自傳以及文字作品，寄至 jobs@fusionmedium.com 來信主旨請註明：【應徵】TechOrange 職缺名稱：您的大名