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