前言
近期專案由於時程規劃偏差的問題因此對於「時程規劃」這個主題挺感興趣的，也想看看不同的工程師對於這個問題的看法，主要參考：The work is never just “the work” - Dave Stewart 文章。
發現身為初階打工人其實通常只是看見問題並拼命解決它，但換個角度思考：「如果現在手上專案燒起來，主管定個超乎預期的時程但你也沒有自己一套說法，要如何交代？」所以這是為什麼我想研究這個主題的原因，最貼近實作的人其實是最能開出真實預估的人。
大家都希望專案能夠又快又準時的完成，且當出事了我會希望能夠分析出因果以及改善的方向。
為什麼專案時間預估這麼難？
你從來沒有真實體驗過相同的經歷，你認為自己體驗過，但沒有。任何事物都會改變，同事、公司、客戶、工具……你自己，不是已經改變就是在改變的路上……
這篇 Hacker News 來源 引起了我的興趣，其中提到一些有趣的討論：
我以前有個老闆，總是選那些自信過頭、不可靠、出價低的人。他完全不會用天或週來估算時間。對他來說，所有事情都是「一小時」到「一個下午」就能搞定。
所以當我說「完成整個流程需要兩週時間」時，
那個人會說「我下午就能搞定」。但他交出來的代碼根本跑不通，然後需要我、QA 和他一起花三週的時間來修修補補，才能真正正常運行。
結果是，原本需要兩個人週的工作量，最終變成了大約 5 到 6 個人週的工作量。
問題還是在於無法預測需要做什麼以及需要多長時間去完成，或許單純多一點相似的經歷有幫助？或許一些建議像是「預留 30% 給專案管理」、「添加預估時間的 n 倍時間」有幫助？但這些方式都只是仰賴大致的經驗，而唯一準確的預估只會存在於製作完成的當下。
預估失敗了，然後呢？
預估是失敗的，但可以透過失敗經驗來分析學習，大多失敗的預估不外乎有兩個要點：
- 許多工作是「為了完成工作而做的工作」，而不是「實際的工作」
- 大部分工作因為不是「實際的工作」，所以被低估或未估計
我們喜歡預估事情如果在專業的執行下會有多順利，而不是關心捉摸不定的變數，這也牽扯到自尊與壓力等問題，所以與其盲目相信直覺上事情會多順利，或許能夠建立一套框架流程，用於將工作與其連帶的附加工作也納入評估當中。
評估框架
所有專案都有不變的特點，就是進行前、進行中、進行後這三種類別的工作，具體可以依照一個更詳細的框架做細分：
- ⚫ 圍繞在專案的工作（行政）：開會、評論、專案管理
- 🔴 為了得到專案而做的工作（獲取）：研究、實驗、定義邊界、報價、說服
- 🟠 專案之前的工作（準備）：設定、基礎建設
- 🟡 專案本身（執行）：實際產品設計、開發、測試
- 🟢 專案之間的工作（迭代）：迭代除錯、重構
- 🔵 專案延伸的工作（改變）：遺漏、新變動、可額外添加事項
- 🟣 案之外的工作（問題）：意外事件、延伸任務
- 🟤 專案之後的工作（支援）：部屬、安全問題、更新
事先將專案各方面的工作切分出來有助於用更客觀的角度評估時程。悲傷的是每個專案的性質都不同，並沒有一套適應任何問題的框架可以套用，但這樣的框架可以幫助我們更好的留意專案的潛在複雜性。
總結
- 替結束的專案進行評估，將期望拉回現實
- 留意絕大多數專案都存在隱性工作
- 出事時與其持續埋頭苦幹，思考改進估計偏差和弱點
- 留意固定代價的專案
由於執行因素持續變動是不可改變的因素，因此關於這個議題我的想法是不需要太過於執著於預估的準確性，而是要學會如何在預估失敗時快速調整，對工作的全貌有所認識。