軟體工程師如何估算項目時間？最終，一切都是跟溝通有關

作者丨Kat Busch

翻譯丨雁驚寒

本文介紹了軟體工程師在開發過程中進行時間估算的原因和方法，從而可以更加合理地安排項目進度。

我的一個產品經理朋友最近跟我提起她遇到的問題：「軟體工程師永遠不會估算他們的項目需要多長時間。我能做什麼呢？「 兩位CEO最近也告訴了我同樣的事情。

我們的工程師也都證實了這一點。我曾經看到過原本預估只要兩天就能完成的項目最終卻花了4個月的時間。在這種情況下，即使是採用「只需把時間翻倍」的經驗也比實際情況差了一個數量級。這可能會對業務產生真正的影響。我曾經見到過一家公司為了一場發布會而竭盡全力，但是最終還是推遲了幾個月。

站在較高的層次來看，問題出在工程師估算的時間與PM、經理、公關人員以及其他所有人估算的時間不一致上。大多數地工程師從本能上想的是，如果一切按照計劃進行，寫出一個可以運行的原型所需的最短時間。但是，那些受阻的下游部門想要知道的是項目什麼時候能夠為發布準備就緒，這完全就是另外一回事了。

對於工程師來說，掌握估算技能是一段終身的旅程。如果忽視它，這會讓你以及與你直接或間接接觸的每個人造成麻煩。掌握估算技能能讓你在同事中脫穎而出，你的同事會把你跟專業、穩定和高質量的工作聯繫在一起。

為什麼需要估算

讓我先回答一下從工程師那裡聽到最多的問題：「為什麼要這麼麻煩估算時間？」許多工程師抱怨這是一個額外的開銷。 「如果我加把勁全力去做的話，很快就能完成了！」

進行估算主要有兩個原因：存在外部依賴，以及需要確定優先順序順序。

外部依賴

任何有效的事情都不會在真空中發生。項目通常都具有外部依賴性，例如跟非工程團隊（通訊、金融、公關、客戶支持）、其他工程團隊甚至最終用戶之間的協調。與外部依賴協調通常是經理、PM或CEO的工作。這意味著最有資格做出時間估算的人（工程師）並不是最需要估算結果的人。這種不對稱性導致了最主要的緊張關係。

優先順序順序

時間估算也是確定工作優先順序順序的關鍵。 「物有所值」是工程中的一項重要指標，沒有經過真正的估算就不值「錢」。即使你正在開發的功能是世界上最棒的東西，如果你花時間做一個全面估算的話，你可能也會意識到需要花太多時間來完成。

假設你正在開發一個項目，它能使網站的速度提升50％，但在相同的時間內，你可以完成兩個項目，這些項目能使網站快40％。如果你不花點時間做一個初步估算的話，你永遠都不會知道自己本來可以做出一個更快的網站！

時間估算基礎

現在大家都同意時間估算在絕大多數情況下都是必須的，下面我們就討論一下估算技巧吧。

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

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

我們低估的另一個原因是我們在編碼的過程中總是會遇到「未知的未知數」。而這些是不可能完全預料到的。也許你的IDE要進行更新而中斷了你的項目，然後你不得不花一整天的時間去弄好環境。你的估算是無法將這個也考慮進去的。

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

第一步：制定技術計劃

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

顆粒度在這裡很重要。如果任何一個步驟給人感覺不清楚的話，要麼忽略細節（應該了解更多），要麼得把它分解為更細一點的步驟。同時，如果某個步驟的顆粒度太細的話，那麼在實踐中可能會使整個計劃無效。

想要知道技術計劃里應該要考慮哪些東西，可以看看Alicia Chen的這篇文章。關鍵點之一是消除跟PM或者其他利益相關者之間的分歧，這樣最後才不會把東西做錯而不得不重新開始。

第二步：為每個步驟添加時間估算

估算技術計劃里每一個步驟完成所需的時間。這通常涉及到對細節的研究（「是不是已經有現成的庫來實現這個了？」）。根據項目的性質，拋出一個簡單的原型可能有助於暴露很多潛在的痛點。

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

現在你已經有一個初步的時間估算了，不過我們還要考慮上文提到過的很多東西。

隨時調試：Bug總是存在的。調試很大程度上取決於你對特定代碼庫的熟悉程度以及該代碼庫的成熟度。

會議、訪談、假期等：在這期間你是不會在辦公桌前編程的。你真正用於寫代碼的時間究竟有多少呢？在估算的時候，你至少應該看看自己的日程表。

最終測試與bug大掃除：你通常應該一邊寫代碼一邊寫測試用例，但很多團隊還需要進行額外的優化工作或者在發布前進行集成測試。要在估算中充分考慮到這些。如果你是分階段推出的話，前面最初的1%可能會暴露出那些需要修正的bug。你要把這個也考慮進去。

代碼評審：在這個代碼庫中你一般要評審幾輪？通常要花多長的時間？確保要給評審人足夠的時間（可能要留意一下他們的日程表）。如果只有一位評審人，你應該事先問一下他的備崗，以防關鍵時刻那個人出去度假或者因為太忙而耽擱了。

一旦你把所有這些交付所需的時間開銷都考慮進去了，你就會看到自己的時間估算跟項目的實際發布時間會更加匹配。是的，實際情況會比估算的更長。是的，你可能會在縮短工期上受到壓力。但是，當大家都知道可以依賴你時，他們會欣賞你的估算。

第四步：在發布之後對估算進行回顧

是的，在項目完成之後再回過頭來看看你的時間估算感覺是一種痛苦。但是這種回顧就是你可以學到東西的時候，並且下次能做得更好。

如果實際花費的時間跟預期不一樣會怎麼樣？如果集成測試花費的時間是你原先估算的兩倍，那麼請記下來，下一次留出更多的時間。或者嘗試著改進你的集成測試系統。

你肯定會看到你估算的能力隨著時間的推移而得到提升。你甚至可以在這個時候找到一些有助於整個團隊的偉大見解。

最終，一切都是跟溝通有關

儘早地、經常地跟別人溝通你的時間表和變化。如果你在發布前一個月讓你的經理知道你正在使用的一個庫被發現了一個新的安全漏洞，你將不得不重頭開始的話，他們將有時間通知公關、財務或者用戶說版本需要推遲。

跟相關參與者進行溝通也會讓他們為你提供可影響你估算的重要信息。某位設計師可能會說：「哦，如果那個花絮動畫需要整整一周才能做出來的話，我們乾脆砍掉好了。」PM可能會補充說：「這只是一個在用戶研究中進行實驗的原型。這次迭代我們不需要做太多的bug大掃除。」經理可能會說：「你有一半的時間都用在開會上了？讓我來幫你解決這件事！」

對於工程師來說，不要屈服於壓力，為了取悅上級而報告比實際情況要短的時間。誠實地說明你的估算和變化的方法，這顯得你更加的專業。

對於涉及到的其他任何人來說，尊重估算出來的時間是很難的，這需要一個過程。你只有坐下來砍掉發布時不需要的功能才能減少時間。嘮叨是不可能把時間減下來的。

我們永遠都無法完美地估算出項目的時間。唯一的辦法就是開放溝通、有惻隱之心以及堅定地確定優先次序。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！