從產品經理的角度，談預估工時的5個意義／Evonne Tsai
有人問，公司的開發方法是瀑布式，但由於規格常常變動，所以專案預估的時程很不準，那預估工時的意義是什麼？我認為，問「為什麼要預估工時」跟問「為什麼要做計畫」一樣，如果預估不準，應該要檢討不準的原因，而不是就不估了；如果計畫沒有照規劃執行，應該要檢討為什麼，而不是不做計畫、直接放棄治療。
Evonne Tsai
財金人，科技人，行銷人，現為電商商業轉型部副理；10年產品行銷與管理經驗，大小公司通吃，軟硬產品兼施。著作「打造360行銷產品力」即將出版，也是Medium人氣作家。歡迎預約新書！
我們公司的流程是，評估市場需求→PM提案→設計師開規格→RD實作→QA→發布，實際上是什麼開發流程我是不知道；網路上有看過離職的前輩說這是瀑布式，公司這幾年又把一些敏捷的思想帶進來……。
但矛盾的是 我們的產品上線時間很早就被敲定，所以大部分的專案，下場就是沒有得到足夠的迭代；最後不是砍規格，就是RD跟設計師一起加班趕進度，甚至還有上線兩個月前規格才完成的狀況……
我不知道是不是只有我們公司才這樣，還是這是業界常態只是我太菜了，我是真的不太懂預估工時的意義到底在哪。
（出處連結）
姑且先不談這「瀑布融合敏捷迭代」的說法是否合理，這邊先以產品經理（PM）的角度來討論「為什麼要預估工時」、以及為什麼筆者覺得即使估不準也要估。
為什麼要預估工時？
我平常最常使用的app，除了通訊、社交類型以外，最常用的是「台北等公車」；這個app功能很簡單，就是讓你知道你等的公車現在在哪一站、還有多久會到你現在在等的這一站、以及多久之後會到某個目的地的站牌。
我非常依賴這個app，因為它能讓我評估什麼時候出門、什麼時候到，並且預估後續的時程。
這跟預估工時有什麼關係呢？為什麼要預估工時？我認為最重要的目的，就是：
以「同步各方預期」作為溝通與協作的基礎。
「軟體功能開發」這件事，不是功能規格開完就能開發、開發完就可以賣了；你必須與其他部門協作，而這協作常常是有先後順序與相依性的。
在開發的一開始，PM提出需求、設計師需要提供設計圖檔、工程師需要設計技術架構然後寫程式、測試人員需要排定測試時間、行銷需要規劃上市活動、業務需要規劃推銷計畫……等等；如果沒有預估出時程，並且與各方同步，各方怎麼知道該何時投入資源、如何彼此協作？
若沒有同步各方預期，一個可能要做三個月的功能，業務人員可能覺得很簡單，所以跟客戶說一個月就能交；行銷人員猜測可能要四個月，所以先把行銷資源調到其他產品上。
或是等到功能快完成時，PM才去要後續行銷以及業務資源；但如果臨時要不到怎麼辦？
擔任RD（研發人員）的原提問者可能會說，但是規格一直變、時程也會跟著一直改變，如果估不準的話要如何協作？
一旦有了估計，在延遲時才能評估跟原本計畫的差距，進而調整計畫。
不，就是因為有變動，才要估計、才能協作；因為一旦在開始時有了估計，在萬一延遲時才能評估跟原本計畫的「差距」，進而準確調整計畫。
就像「台北等公車」app可以讓我知道到站時間，我就可以評估什麼時候出門：公車還有半小時，我可以慢慢來；公車快到了，我就得趕快出門、不要滑手機了。我也可以知道什麼時候抵達目的地；如果可能會來不及，也可以提早決定搭計程車、或是先打電話跟對方說一聲。
在專案上，如果你知道開發還有三個月才會完成，行銷資源就可以先專注在其他產品上；如果你看到某人的時間分配看起來會是專案瓶頸、或是功能開發在他身上要花最多時間，就可以提早分配其他資源協助。
當計畫有變時，就可以觀察預估和實際的差距，然後趕緊啟動應變計畫（談範疇、砍功能、協調資源、排beta版、調整開發測試順序等等）；此時也會知道，若要維持原本的協作計畫，需要縮短多少時間。
對時程的估計，也等於將「勞力」以時間的方式具體化。
同時也會知道，如果時程萬一真的無法縮短，對應的各部門要延後多久投入資源、溝通與談判要建立在什麼樣的新時程上；這就是文中提到的「甘特圖」的價值。
而且這個估計結果，等於是將「勞力」以時間的方式具體化，也更能估成本、比較功能規模、排優先順序，也能累積、傳承在其他專案上。
因為PM以後會記得，類似的功能之前估計多久，對於新專案、新功能的規模就會越來越有感覺，就更知道要如何跟客人談判﹑收錢。
如果時程估不準，是否還有價值？
我認為「估計時程」本身就有價值，因為估計的過程就是在逼你把事情想清楚。要能估計時程，總該從頭到尾想清楚要做什麼事情、各要花多少時間吧？越厲害的研發人員能想得越周到，對於可能遇到的問題也會多抓一些時間緩衝；這樣一來，估的時間就越準。
所以，這本身也是一種練習，幫助RD與PM把事情想清楚；當時程不如預期時，也能知道自己那邊沒想清楚。
就像讀書考試一樣，如果只有讀書、沒有考試，就很難知道自己是不是真懂，或者只是一眼看過去，其實沒有融會貫通。
考試答案有錯，就像時程不準一樣，能幫助我們看到盲點，也注意到哪邊是容易被忽略、高風險的地方，下次才會記得不要踩到。如果沒有「需要資源超過預期，即將要延遲了」的震撼，很難知道這邊其實是風險所在。
所以，幾次下來之後，未來在規劃時就能思考得更周全。所以：
重要的不是時程有多準，而是「它為什麼不準，我忽略了什麼，下次如何讓它更準」。
這也是一種成長思維吧？
另外，如果時程估不準的原因，是因為老闆或客戶一直改規格，反而這樣才更要估時程。
作為PM，就能在老闆訂時程的時候，將功能以及所需時間攤開，問他要捨棄哪一項；老闆要求加班時，也能知道要加多少班（無奈）。或者也可以跟客戶說明，根據預估，如果改這個功能會延遲幾天、要多收多少錢等等。
估時程還有一個心理層面的好處，就是我會請RD自己評估，而這就有種「承諾」的味道；因為自己估的時程就像一種承諾，估的時候會盡量逼自己想清楚、也會努力達到目標。即使眼看著目標無法達成，也會先舉手示警，讓PM啟動後續的應變計畫（當然，這必須是有責任感的RD才行）。
總之，估計時程有幾個好處：
- 藉由時程估計，同步各方預期，啟動協作；
- 藉由時程估計，在面對變動或不如預期時，幫助評估影響、提早啟動應變計畫；
- 藉由估時程的過程，把專案想清楚、要做的事情拆細，減少不確定性；
- 藉由檢討「實際時程」與「預估時程」的差別，幫助自己辨識盲點，在未來規劃時想得更清楚；
- 藉由估計時程，把勞力的投入具體化，就能估算成本、收錢、排優先順序，而且可以延伸到類似功能，累積專案評估經驗、並且繼續傳承。
其實我認為，問「為什麼要預估工時」，跟問「為什麼要做計畫」一樣；如果預估不準，應該要去檢討不準的原因、如何改善，而不是乾脆就不估了。如果知道計畫總是沒有照規劃執行，應該要檢討為什麼，而不是不做計畫、直接放棄治療。
如果預估不準，應該要去檢討不準的原因，而不是就不估了。
當然，「老闆硬壓時程」這件事並不在這篇文章所謂的「估時程」討論範圍之內；不過如前面提到的，面對這樣的狀況，還是要估出「合理時程」讓老闆參考。
若老闆還是堅持「不合理」的時程，就得問他要砍什麼功能；如果連功能也不給砍，到時候他訂的時間真的做不出來，至少不是RD或PM要背的黑鍋（雖然PM往往還是會被要求負責）。
然而即使如此，老闆至少也會慢慢學到，自己的要求或許真的就是不合理，就期望他未來也會做得更好吧。（笑）
為什麼會看到廣告
留言0
查看全部
你可能也想看
Google News 追蹤
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
我們可能會有一種迷思，不管開發什麼系統，開發團隊都袛會有一種方式來工作。反正不管怎麼樣，系統最終也一定是能開發出來的。那麼選擇開發生命週期又跟我何干？本篇將會介紹專案經理應該如何為不同特性的專案選擇最合適的管理策略，即生命週期。
一天見四份工之後，懷疑設計師是做什麼？
講真的，今天行程緊逼。而最大的收穫是，上下見工間距最好預留兩個小時。因為很多時候都是花在等候見工，而差點下一份工遲到。但最讓我無語的是…有些公司很好，很能分辨設計師的職責範圍。但有些公司明顯未知自己公司要請什麼人上來，就浪費了他人時間。就算我再能幹都好，從3
小王是一家大型科技公司的產品經理，每天的日程表上總是被密密麻麻的會議填滿。他的同事常常取笑他：“你不是在開會，就是在去開會的路上。”這種情況讓他感到困惑：難道經常開會真的是沒效率的表現嗎？
產品開發的成功，除了品質，更在於是否能夠在適當的時程內推出並滿足客戶需求。
身為開發、設計人員，從文中提供的三個角度來思考，以確保產品與公司的競爭力。
這篇文章探討了在專案開發中遇到的時間壓力和執行困難，以及如何無效應對這些挑戰。 沒有工時估算、客戶溝通、交付時間表設定、程式品質管理、工作量管理、合同和專業態度等方面的建議。
企劃為一種商業性的服務業，對象可以是政府單位、商業合作夥伴、一般民眾。最主要的工作軸心為時間和金錢，熟悉這兩大要素才能開始執行一個完美的企劃。企劃發想要擁有強大的創意以及精神力，在短時間內生成出所有的項目，並確保細節能夠完善執行。【時間與不確定性】【溝通與壓力排解】【明確性、敏銳度、文字掌握】
程式與頻率時間
看起來這個問題有些奇怪，程式與頻率時間有什麼關係呢？一旦程式完成，似乎就不需要再理會頻率和時間了。實際上，這可能是一些不熟悉程式設計的人所提出的疑問。了解程式設計最重要的一點是，頻率和時間的安排會直接影響程式的效能和展現速度。
時間的利用
舉例來說，假設一個表單的每筆處理時間為
EC tracker utilization
** 3C機構設計爸版權所有**
在開發設計過程中，通常會有的流程包括開案 —> 設計 —> EVT(prototyping) —> DVT(tooling T1) —> PVT(tooling Txx) —> MP(T-Final)。當然，已經有很
作為產品經理，製作簡報是日常工作的一部分，而如何製作一個有邏輯的流程圖成了一大挑戰。讓我們透過Paul的故事，探索如何製作讓老闆滿意的流程圖。
作為一位產品經理（PM），了解並優化公司的流程是提高工作效率的關鍵。以下是五個步驟，幫助你系統性地改善流程、加速產品處理時程，提高公司的效率。
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
我們可能會有一種迷思，不管開發什麼系統，開發團隊都袛會有一種方式來工作。反正不管怎麼樣，系統最終也一定是能開發出來的。那麼選擇開發生命週期又跟我何干？本篇將會介紹專案經理應該如何為不同特性的專案選擇最合適的管理策略，即生命週期。
一天見四份工之後，懷疑設計師是做什麼？
講真的，今天行程緊逼。而最大的收穫是，上下見工間距最好預留兩個小時。因為很多時候都是花在等候見工，而差點下一份工遲到。但最讓我無語的是…有些公司很好，很能分辨設計師的職責範圍。但有些公司明顯未知自己公司要請什麼人上來，就浪費了他人時間。就算我再能幹都好，從3
小王是一家大型科技公司的產品經理，每天的日程表上總是被密密麻麻的會議填滿。他的同事常常取笑他：“你不是在開會，就是在去開會的路上。”這種情況讓他感到困惑：難道經常開會真的是沒效率的表現嗎？
產品開發的成功，除了品質，更在於是否能夠在適當的時程內推出並滿足客戶需求。
身為開發、設計人員，從文中提供的三個角度來思考，以確保產品與公司的競爭力。
這篇文章探討了在專案開發中遇到的時間壓力和執行困難，以及如何無效應對這些挑戰。 沒有工時估算、客戶溝通、交付時間表設定、程式品質管理、工作量管理、合同和專業態度等方面的建議。
企劃為一種商業性的服務業，對象可以是政府單位、商業合作夥伴、一般民眾。最主要的工作軸心為時間和金錢，熟悉這兩大要素才能開始執行一個完美的企劃。企劃發想要擁有強大的創意以及精神力，在短時間內生成出所有的項目，並確保細節能夠完善執行。【時間與不確定性】【溝通與壓力排解】【明確性、敏銳度、文字掌握】
程式與頻率時間
看起來這個問題有些奇怪，程式與頻率時間有什麼關係呢？一旦程式完成，似乎就不需要再理會頻率和時間了。實際上，這可能是一些不熟悉程式設計的人所提出的疑問。了解程式設計最重要的一點是，頻率和時間的安排會直接影響程式的效能和展現速度。
時間的利用
舉例來說，假設一個表單的每筆處理時間為
EC tracker utilization
** 3C機構設計爸版權所有**
在開發設計過程中，通常會有的流程包括開案 —> 設計 —> EVT(prototyping) —> DVT(tooling T1) —> PVT(tooling Txx) —> MP(T-Final)。當然，已經有很
作為產品經理，製作簡報是日常工作的一部分，而如何製作一個有邏輯的流程圖成了一大挑戰。讓我們透過Paul的故事，探索如何製作讓老闆滿意的流程圖。
作為一位產品經理（PM），了解並優化公司的流程是提高工作效率的關鍵。以下是五個步驟，幫助你系統性地改善流程、加速產品處理時程，提高公司的效率。