看到PTT Soft_Job板上有人問了一個問題，作者公司的開發方法是瀑布式，但是由於規格常常變動（據說原因是「加入了敏捷的迭代想法」），所以專案預估的時程也很不準，所以作者心中浮起了一個疑惑：預估工時的意義是什麼？
姑且先不戰這瀑布融合敏捷迭代的說法，來以PM的角度來討論為什麼要預估工時，還有為什麼我覺得即使估不準也要估。
為什麼要預估工時？
我平常最常使用的App，除了通訊、社交App以外，最常用的是「台北等公車」，這個App功能很簡單，能讓你知道你在等的公車現在在哪一站、還有多久會到你現在在等的這一站，以及多久之後會到某個目的站牌。
我非常依賴這個App，因為它讓我能評估什麼時候出門、什麼時候到，並預估後續的時程。
這跟預估工時有什麼關係呢？為什麼要預估工時？
我認為最重要的目的，就是藉由「同步各方預期」，成為「溝通與協作的基礎」。
「軟體功能開發」這件事，不是功能開完就能開發，開發完了就可以賣了，你必須與其他部門協作，而這協作常常是有先後順序與相依性的。在開發的一開始，PM提出需求，設計師需要提供設計圖檔，工程師需要設計技術架構，接著寫程式，測試人員需要排定測試時間，行銷需要規劃上市活動，業務需要規劃推銷計畫等等，如果沒有一個對時程的預估，並與各方同步，各方資源怎麼知道該什麼時候投入，彼此如何協作？
若沒有同步各方預期，可能一個要做三個月的功能，業務覺得這很簡單，跟客人說一個月就能交，行銷可能猜測要四個月，先把行銷資源調到其他產品上，或是等到功能快完成時，PM才去要後續行銷以及業務資源，如果臨時要不到怎麼辦？
文中的RD可能會說，但是規格一直變，時程也會一直改變，估不準如何協作？不，就是因為有變動，才要估計，才能協作。
因為只有開始時有了估計，在delay時才能評估跟原本計畫的「差距」，進而準確調整計畫。
就好像公車到站時間App，可以讓我知道到站時間，我就可以評估我什麼時候要出門──公車還有半小時，我可以慢慢來；公車快到了，我趕快出門不要滑手機了，我也可以知道什麼時候可以抵達目的地，如果看起來會來不及，也可以提早決定搭計程車，或是先打個電話跟對方說一聲。
在專案上，如果你知道開發還有三個月才會完成，行銷資源就可以先專注在其他產品上；如果你看到某一個人的時間分配看起來會是專案瓶頸，或功能在他身上要花最多時間，我會提早分配其他資源協助；當計畫有變，我看到預估和實際的差距，就會趕緊啟動應變計畫（談範疇、砍功能、橋資源、排beta版、調整開發測試順序等等），我會知道若我要維持原本的協作計畫，需要縮短多少時間，也會知道如果萬一真的無法縮短，對應的各部門要延後多久投入資源，我的溝通與談判要建立在什麼樣的新schedule上。這就是文中提到的 「甘特圖」 的價值。
而且這估計結果等於是將「勞力」以時間的方式具體化了，也更能估成本、比較功能規模、排優先順序，也能累積、傳承在其他專案上──PM記得類似的功能之前估計多久，對於新專案、新功能的scope就會越來越有理解，更知道要如何跟客人談判﹑收錢。
如果時程估不準，是否還有價值？
我認為 「估計schedule」本身就有價值。 因為估計schedule的過程，就是在逼你把事情想清楚。要能估計時程，總該從頭到尾想清楚要做什麼事情、各要花多少時間吧？越厲害的RD，能想得越周到，對於可能遇到的問題也會多抓一些時間做緩衝，他們估的時間就越準。
所以這本身也是一種練習，幫助RD／PM把事情想清楚，當時程不如預期時，也能知道自己哪邊沒想清楚，就像讀書考試一樣，如果只有讀書，沒有考試，很難知道自己是不是真的懂了，還是只是看過去，沒有融會貫通。
考試答案有錯，就像schedule不準一樣，能幫助我們看到盲點， 可以注意到那邊是容易被忽略、高風險的地方，下次會記得不踩到，如果沒有「超過預期要delay了」的震撼，很難知道這邊其實是風險所在，幾次下來，之後在做規劃時就能思考得更周全。所以說——
重要的不是schedule有多準，而是「它為什麼不準」，我忽略了什麼，「下次如何讓它更準」。
這也是一種成長思維吧？
另外，如果時程估不準的原因，是因為老闆或客戶一直改規格，反而這樣才更要估時程。做為PM，老闆壓時間時，就能把功能以及所需時間攤開，問他要捨哪一項，或老闆真的要硬壓加班時，知道要加多少班，也可以跟客戶說明，根據預估，若改這個功能，會delay幾天，要多收多少錢。
估時程還有一個好處，我覺得是心理層面的，就是我預估schedule時，都是請RD自己評估，這有種「承諾」的味道，自己估出去的schedule，像是自己的承諾，會盡量逼自己想清楚，也會努力去達到目標，或是眼看著目標無法達成，也會先舉手示警，可以讓PM啟動後續的應變計畫。
總之，估計時程有幾個好處：
- 藉由時程估計，同步各方預期，啟動協作
- 藉由時程估計，在面對變動或不如預期時，幫助評估影響，並提早啟動應變計畫
- 藉由估時程的過程，把專案想清楚，要做的事情拆細，減少不確定性
- 藉由檢討實際時程以及預估時程的差別，幫助自己辨識盲點，在未來規劃時想得更清楚
- 藉由估時程，把勞力投入具體化，就能估成本、收錢、排優先順序，而且可以延伸到類似功能，累積專案評估經驗並傳承
其實我認為問「為什麼要預估工時」，跟「為什麼要做計畫」一樣，如果預估會不準，應該要去檢討不準的原因、如何改善，而不是乾脆就不估了；如果知道計畫總是沒有照規劃的執行，應該是要去檢討為什麼，而不是不做計畫，直接放棄治療。
但是當然「老闆硬壓時程」這件事不在這篇文章「估時程」的討論範圍內。不過如前面提到的，我面對老闆硬壓時程的應對，也是會估「合理時程」給老闆參考，若老闆還是堅持，就問他要砍什麼功能，如果連功能也不給砍，到時候他壓的時間真的做不出來，至少不是RD／PM的鍋，他就會慢慢學到他的要求真的不合理。
本文由Evonne Tsai授權轉載自其Medium。
責任編輯：陳建鈞
《數位時代》長期徵稿，針對時事科技議題，需要您的獨特觀點，歡迎各類專業人士來稿一起交流。投稿請寄edit@bnext.com.tw，文長至少800字，請附上個人100字內簡介，文章若採用將經編輯潤飾，如需改標會與您討論。
（觀點文章呈現多元意見，不代表《數位時代》的立場。）