從產品經理的角度,談預估工時的5個意義/Evonne Tsai

有人問,公司的開發方法是瀑布式,但由於規格常常變動,所以專案預估的時程很不準,那預估工時的意義是什麼?我認為,問「為什麼要預估工時」跟問「為什麼要做計畫」一樣,如果預估不準,應該要檢討不準的原因,而不是就不估了;如果計畫沒有照規劃執行,應該要檢討為什麼,而不是不做計畫、直接放棄治療。

我們公司的流程是,評估市場需求→PM提案→設計師開規格→RD實作→QA→發布,實際上是什麼開發流程我是不知道;網路上有看過離職的前輩說這是瀑布式,公司這幾年又把一些敏捷的思想帶進來……。

但矛盾的是 我們的產品上線時間很早就被敲定,所以大部分的專案,下場就是沒有得到足夠的迭代;最後不是砍規格,就是RD跟設計師一起加班趕進度,甚至還有上線兩個月前規格才完成的狀況……

我不知道是不是只有我們公司才這樣,還是這是業界常態只是我太菜了,我是真的不太懂預估工時的意義到底在哪。

出處連結

姑且先不談這「瀑布融合敏捷迭代」的說法是否合理,這邊先以產品經理(PM)的角度來討論「為什麼要預估工時」、以及為什麼筆者覺得即使估不準也要估。

為什麼要預估工時?

我平常最常使用的app,除了通訊、社交類型以外,最常用的是「台北等公車」;這個app功能很簡單,就是讓你知道你等的公車現在在哪一站、還有多久會到你現在在等的這一站、以及多久之後會到某個目的地的站牌。

我非常依賴這個app,因為它能讓我評估什麼時候出門、什麼時候到,並且預估後續的時程。

這跟預估工時有什麼關係呢?為什麼要預估工時?我認為最重要的目的,就是:

以「同步各方預期」作為溝通與協作的基礎。

「軟體功能開發」這件事,不是功能規格開完就能開發、開發完就可以賣了;你必須與其他部門協作,而這協作常常是有先後順序與相依性的。

在開發的一開始,PM提出需求、設計師需要提供設計圖檔、工程師需要設計技術架構然後寫程式、測試人員需要排定測試時間、行銷需要規劃上市活動、業務需要規劃推銷計畫……等等;如果沒有預估出時程,並且與各方同步,各方怎麼知道該何時投入資源、如何彼此協作?

若沒有同步各方預期,一個可能要做三個月的功能,業務人員可能覺得很簡單,所以跟客戶說一個月就能交;行銷人員猜測可能要四個月,所以先把行銷資源調到其他產品上。

或是等到功能快完成時,PM才去要後續行銷以及業務資源;但如果臨時要不到怎麼辦?

擔任RD(研發人員)的原提問者可能會說,但是規格一直變、時程也會跟著一直改變,如果估不準的話要如何協作?

一旦有了估計,在延遲時才能評估跟原本計畫的差距,進而調整計畫。

不,就是因為有變動,才要估計、才能協作;因為一旦在開始時有了估計,在萬一延遲時才能評估跟原本計畫的「差距」,進而準確調整計畫。

就像「台北等公車」app可以讓我知道到站時間,我就可以評估什麼時候出門:公車還有半小時,我可以慢慢來;公車快到了,我就得趕快出門、不要滑手機了。我也可以知道什麼時候抵達目的地;如果可能會來不及,也可以提早決定搭計程車、或是先打電話跟對方說一聲。

在專案上,如果你知道開發還有三個月才會完成,行銷資源就可以先專注在其他產品上;如果你看到某人的時間分配看起來會是專案瓶頸、或是功能開發在他身上要花最多時間,就可以提早分配其他資源協助。

當計畫有變時,就可以觀察預估和實際的差距,然後趕緊啟動應變計畫(談範疇、砍功能、協調資源、排beta版、調整開發測試順序等等);此時也會知道,若要維持原本的協作計畫,需要縮短多少時間。

對時程的估計,也等於將「勞力」以時間的方式具體化。

同時也會知道,如果時程萬一真的無法縮短,對應的各部門要延後多久投入資源、溝通與談判要建立在什麼樣的新時程上;這就是文中提到的「甘特圖」的價值。

而且這個估計結果,等於是將「勞力」以時間的方式具體化,也更能估成本、比較功能規模、排優先順序,也能累積、傳承在其他專案上。

因為PM以後會記得,類似的功能之前估計多久,對於新專案、新功能的規模就會越來越有感覺,就更知道要如何跟客人談判﹑收錢。

如果時程估不準,是否還有價值?

我認為「估計時程」本身就有價值,因為估計的過程就是在逼你把事情想清楚。要能估計時程,總該從頭到尾想清楚要做什麼事情、各要花多少時間吧?越厲害的研發人員能想得越周到,對於可能遇到的問題也會多抓一些時間緩衝;這樣一來,估的時間就越準。

所以,這本身也是一種練習,幫助RD與PM把事情想清楚;當時程不如預期時,也能知道自己那邊沒想清楚。

就像讀書考試一樣,如果只有讀書、沒有考試,就很難知道自己是不是真懂,或者只是一眼看過去,其實沒有融會貫通。

考試答案有錯,就像時程不準一樣,能幫助我們看到盲點,也注意到哪邊是容易被忽略、高風險的地方,下次才會記得不要踩到。如果沒有「需要資源超過預期,即將要延遲了」的震撼,很難知道這邊其實是風險所在。

所以,幾次下來之後,未來在規劃時就能思考得更周全。所以:

重要的不是時程有多準,而是「它為什麼不準,我忽略了什麼,下次如何讓它更準」。

這也是一種成長思維吧?

另外,如果時程估不準的原因,是因為老闆或客戶一直改規格,反而這樣才更要估時程。

作為PM,就能在老闆訂時程的時候,將功能以及所需時間攤開,問他要捨棄哪一項;老闆要求加班時,也能知道要加多少班(無奈)。或者也可以跟客戶說明,根據預估,如果改這個功能會延遲幾天、要多收多少錢等等。

估時程還有一個心理層面的好處,就是我會請RD自己評估,而這就有種「承諾」的味道;因為自己估的時程就像一種承諾,估的時候會盡量逼自己想清楚、也會努力達到目標。即使眼看著目標無法達成,也會先舉手示警,讓PM啟動後續的應變計畫(當然,這必須是有責任感的RD才行)。

總之,估計時程有幾個好處:

  1. 藉由時程估計,同步各方預期,啟動協作;

  2. 藉由時程估計,在面對變動或不如預期時,幫助評估影響、提早啟動應變計畫;

  3. 藉由估時程的過程,把專案想清楚、要做的事情拆細,減少不確定性;

  4. 藉由檢討「實際時程」與「預估時程」的差別,幫助自己辨識盲點,在未來規劃時想得更清楚;

  5. 藉由估計時程,把勞力的投入具體化,就能估算成本、收錢、排優先順序,而且可以延伸到類似功能,累積專案評估經驗、並且繼續傳承。

其實我認為,問「為什麼要預估工時」,跟問「為什麼要做計畫」一樣;如果預估不準,應該要去檢討不準的原因、如何改善,而不是乾脆就不估了。如果知道計畫總是沒有照規劃執行,應該要檢討為什麼,而不是不做計畫、直接放棄治療。

如果預估不準,應該要去檢討不準的原因,而不是就不估了。

當然,「老闆硬壓時程」這件事並不在這篇文章所謂的「估時程」討論範圍之內;不過如前面提到的,面對這樣的狀況,還是要估出「合理時程」讓老闆參考。

若老闆還是堅持「不合理」的時程,就得問他要砍什麼功能;如果連功能也不給砍,到時候他訂的時間真的做不出來,至少不是RD或PM要背的黑鍋(雖然PM往往還是會被要求負責)。

然而即使如此,老闆至少也會慢慢學到,自己的要求或許真的就是不合理,就期望他未來也會做得更好吧。(笑)