項目時間估算方法?制定技術計劃在着手開始工作前，你應該已經有了一份技術規劃或設計文件，可以為任何重要的項目提供幫助可以用這個讓别人知道你在做什麼，并獲得反饋制定技術計劃是啟動時間估算的理想階段當完成技術細節設計時，會發現未知問題，你将會神奇地修改估算時間也許你會意識到，可能需要把一個正在使用的庫升級到新版本，這可能會增加一天的時間甚至可能意識到計劃使用的庫實際上并不存在，需要自己寫，今天小編就來說說關于項目時間估算方法?下面更多詳細答案一起來看看吧!

項目時間估算方法

制定技術計劃

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

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

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

為每個步驟增加時間預算

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

添加大量的額外時間

現在你已經有一個初步的估計，但是我們之前提到的所有的點還需要考慮。随時調試：總是會有Bug。調試很大程度上取決于你對特定代碼庫的經驗和代碼庫的成熟度。會議、訪談、假期等：可能你不會在工位一直編碼。你真正會有多少個小時進行編碼？估算時應該至少看看你的日曆。

最終測試和bug清理：通常你在編碼的同時應該也在寫測試，但是很多團隊在發布前，需要進行一輪潤色工作或集成測試。在估算中要給予這些工作足夠的預算。如果分階段進行推出，最初推出的1％内容，可能會暴露需要修複的bug，需要考慮到這一點。

代碼審查：項目需要做幾輪代碼審查？通常需要多長時間？一定要确保有充足的評審人員（也可以确認一下他們的日程安排）。如果這是隻有一個評審人員的項目，應該提前征求他們同意，要求他們安排一名候補人員，以防評審人員會休假或者在關鍵節點太忙。

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

項目發布後，對時間估算做回顧總結

在項目完成之後回顧一下所做的工作，這聽起來很痛苦。但是這種審查回顧會讓你從中學到很多，下次做的更好。哪個過程結果與預期的時間不同？如果集成測試花費了比預期兩倍的時間，記下來，下次給測試留下更多的時間。或者嘗試改進集成測試系統。

你一定會看到自己的估算随着時間的推移而不斷改善。甚至可以在這個過程中提出一些很好的見解，來幫助整個團隊。最後，一切都與溝通有關

你的時間表和其他變動事宜，應該提前告知其他人。如果在發布前一個月讓經理知道你正在使用的庫中存在新的安全漏洞，不得不從頭開始，他們會有時間相應的通知公關，财務或用戶，需要推遲發布。和其他協作方溝通得來的重要反饋，有助于調整時間估算。設計師可能會說：“哦，如果這個花哨的動畫将要花一整周的時間，我們可以完全剪掉它。”PM可能會補充說：“這隻是用戶研究中的一個原型實驗。我們不需要為這個叠代做太多的bug清理。”經理可能會說，“你把一半的時間用在了開會？我來解決這個事情！”對于工程師來說，不要為了取悅上級，向不切實際的時間表妥協。坦誠地說出你的估算時間和變更方式，這樣更專業。對于其他所有人來說，尊重估算的時間是很難的，而且這需要一個過程。你隻能坐下來砍掉實際上不需要發布的功能或階段，來縮短預計的時間，而不是通過唠叨把時間縮短。

我們永遠無法完美估算項目所需的時間。唯一的辦法就是保持開放、多溝通、有同理心，并果斷地确定優先次序。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!