序言
在專案開始落實之前，需要先對其所需工作時長進行預估。目的在於：
- 給上一級或者你知道你專案所需要的工時，從而判斷該專案值不值得執行。
- 上級也可以通過工時預估，合理的呼叫資源。
- 在進行專案外包上，預估所需的時間，可以根據每人工時單價進行整體報價。
- 在專案落實時候，也可以根據預估表，進行階段性監督，促使專案穩步進行中。 本文主要講述有無歷史資料如何預估、執行時根據現實情況修改預估、預估失敗總結。
1. 預估猜測
無歷史資料
- 舉一反三
根據別的專案進行派生，推算。這個專案跟另一個相似，再根據現實情況進行修改。
- 站在巨人的角度上
請教前輩朋友。陌生專案在自己沒把握的情況下，不要盲目預估。
- 稻田取樣法
多次預估平均法。比較複雜的專案，需要多次預估取平均值。
- 夏農定律
提高容錯率。人的預估往往過於理想樂觀。根據自己以往的情況，適當增加時長。我個人是，如果個人預估100天，對上級一般報120天。而往往是在110到120之間完成。
* 有歷史資料
有做過的專案在專案難度上相對把握的比較好，需要注意的是，環境、個人能力的變化，所需要的工時有所變化。建議如下： 通過推測重演、完整覆盤，來考慮當初碰到了什麼意外，有哪些不確定因數，任務完成度如何，是否值得繼承。假如當初任務發生在今日會是怎樣的，多了還是少了。
2. 執行
- 第一次預估：常規預估：
見 1. 預估猜測
- 第二次預估：修正預估：
工作開始後可能發現意外情況，根據實際情況重新評估，修改計劃表。
- 第三次預估：最後預估：
失敗的話：要回過頭重新考慮。情況嚴重的話需要向上級反饋情況需求幫助。
3. 失敗原因
-
自我：
預估能力欠缺不夠嚴謹，見 1. 預估猜測
-
工作必備條件不夠:
例如： 基礎知識不夠 - 沒看完vue的文件，導致api瞭解不夠； 想做個登入頁面結果，結果一直停留在bug查錯上； 這個時候：需要建立並執行另外一個任務 - 去了解工作文件
- 工作強度 || 複雜度過高：
例如： 就是說沒有把把工作進行拆分到到自己能正確預估的範圍內； 業務邏輯沒有理順導致開發卡住
後記
很多新手礙於面子，沒有定時反饋需求幫助，到最後領導來詢問進度的時候，支支吾吾，已經嚴重阻礙到專案的進行。在專案實施時，要建立合理的監督反饋機制，如：需要一個月的專案，每隔稽核一下進度，反饋給上級。如果專案難度比想象中大，向上級尋求幫助，或者請求延長時間。切記到最後時間截止時，專案沒做成，也丟了自己的信譽。