這系列文章的命題是：當把產品做完後，不管是已改版多次還是 MVP，只要是產品，永遠有變得更好、持續進步的空間，但要如何改善呢？該從哪裡下手呢？
以下整理了一個概略的產品優化流程，會在接下來的文章中細講每個步驟。
什麼是估時？
要打造任何一個產品或小功能時，PM 都需要幫這些案子訂出時程表，其中包含發想的時間、設計出 wireframe & mockup 的時間、工程師開發的時間、QA 測試的時間，甚至需要包含上線後修 bug 的時間、緩衝的時間等。
這些時間需要每個負責人各自估算，所謂「估時」就是「估算所需時間」，更白話就是「估計需要多久才能做完這件事」。
至於每個職能的人是以什麼作為估時依據，這就是比較專業的問題了，我並非技術或設計專業，無法多做介紹，但下面幾段會再多談「PM 如何善用估時的結果」。
註：有些採用敏捷開發的團隊，可能還會加入 scrum 的「估點」方式與流程，但這並非適用於所有軟體開發團隊，所以這篇只講比較廣泛的「估時」，不過這些「估計」的概念基本上是相通的。
為什麼需要估時？
一般來說，估時有 2 個目的，第一個算是最基礎的目的，第二個比較像是附加的好處：
1. 方便團隊掌握進度
每個案子都有死線，這個死線有時是來自外部需求 — — 比如行銷活動要在某月某日上線、產品發表會要在某天舉辦、老闆就是想在某天看到成果等，有時則是根據內部評估的合理時間線（沒有明確死線，端視內部需要多少時間才能完成）。
前者通常是較普遍的狀況，後者可能較常見於產品團隊自主發起的任務（沒有外部施壓）或研發主導（而非數據或用戶導向）的團隊。
但不管是哪種，在商場上，做每件事情都有目標、都有資源分配，老闆不太可能完全放手讓團隊用無限的時間和人力執行某個看不見盡頭的任務，而是某段時間就得交出某個成果，也就是所謂的「進度」。
而老闆想要知道產品進度，第一時間當然是去問管理產品的人，也就是產品經理。
但 PM 並非只是因為老闆壓力而需要知道估時；作為一個盡責的 PM，應該要能熟知產品的細節，誰負責哪些功能、對應的進度到哪裡、哪邊做得很順 / 哪邊有點卡關、誰的進度超前 / 誰的進度落後，PM 應該都要瞭若指掌，才能適時調配團隊資源。（關於這些細節，下一篇「step 08：開發」會細講）
2. 讓當事人自己更了解自己的能力
延續上上段說的，畢竟產品開發流程包含許多步驟，所以估時的「時」分很多種，包含發想的時間、設計出 wireframe & mockup 的時間、工程師開發的時間、QA 測試的時間，甚至需要包含上線後修 bug 的時間、緩衝的時間等。
舉個例子，小明在今年一月參加 10 公里路跑，他在這之前從沒參加過類似賽事，只能參考同為新手的成績，而他發現新手差不多需要 1 小時才能跑完，便以此為目標。一月路跑活動結束後，他發現自己其實需要 1.5 小時才能完賽。
這樣如果下次還要參加 10k 路跑，小明就會知道：自己需要 1.5 小時才能跑完；又或者下次要參加的是半馬，那也可以稍微估算：至少需要 3 小時才能跑完，而且自己的耐力沒這麼好，搞不好得再加個 30 分鐘……。
產品的估時也一樣，可以拿來當成一個基準線，當事人用來依此確認自己的工作效率與能力。
如果估時遠超出預期怎辦？
每個專案都該有個死線，有的死線是客戶、老闆或需求端壓的，有的死線是團隊自己設定的。但不論是哪種，專案不可能無止盡跑下去，一定得設定一個期望值與預計完成時間，否則這段沒有盡頭的開發路，也太讓人絕望了吧……。
也因為如此，估時完成後，可能是「驚喜大於驚嚇」（工程師做得比想像中快），也可能是「驚嚇大於驚喜（這些任務比想像中耗時）」，如果是後者， PM 可以參考以下方式跟工程師溝通，以確保雙方認知無落差：
1. 了解任務困難點
PM 看到估時特別長的任務時，可以先私下找對應的負責人，多了解這個任務的困難點，再決定採取哪個解法：
- 方案 A：維持原訂估時
- 方案 B：與其維持估時，不如討論是否能把該任務範圍縮小。
比如有個畫面分成桌面版與手機版，雖然 API 接的是同一個，對後端來說是一次工，但對前端來說是兩次工，那就可以把這一個任務分成桌面版與手機版這兩個任務。
如此一來，估時誤差能減少，負責人在做這個任務的時候，也不會覺得一直陷在同一件事裡面，做久了很可能會很膩、會很絕望。
2. 優先排序
如果任務範圍無法縮小，PM 也可以重新思考優先排序，先從那些最重要的、最不可或缺的功能下手。
PM 若想要完成一個專案，最重要的不是把全部的任務都硬塞到每個人的待辦清單，而是好好思考哪些事情最重要、哪些任務可以之後再做，進而用最有效率且 CP 值最高的方式完成專案。
3. 爭取人力
如果任務範圍無法縮小、該任務優先排序也很高，那 PM 可以試著跟主管或老闆爭取更多人力。碰到進度問題時，不要把「加班」當成第一解答，因為對老闆來說，這是最好、最容易、成本最低的解法，但對於團隊來說，其實是成本最高的方式。
再更務實一點來說，工程師在加班，PM 也不可能回家睡覺啊～開發時一定會有規則缺漏、邏輯打架的時候，PM 得繼續待命、一起討論想辦法才行，所以工程師不加班，PM 也才有個安寧的下班夜（合十）。
估時了，然後呢？
上面說的「估時」是各負責人所需的時間，PM 最後要負責的就是把這些估時綜合起來，總結為整個專案的預計時程。
一般來說，設計階段不太會有非常具體的估時，至少我遇過的設計師們不太會說「A 畫面我需要 3 天、B 需要 5 天」，而是雙方會直接討論一個「全部設計稿交付的時間」。
不過，工程師的估時就真的要切得比較細了，相關的好處下面幾段會細說，這邊先來介紹 PM 要怎麼依照工程師的估時來抓專案總時程。
通常完成估時後，PM 可以得到類似這樣的資訊：
根據上表可得知：前端（FE = Front-End）總估時 9.5 天、後端（BE = Back-End）8.5 天，所以如果前後端各有一人，且同時開工的話，在沒有其他外部因素干擾的情況下，這個案子大概兩週能做完（因為兩週基本上最多只有 10 個工作）。
但上面說的「其他外部因素」，又是什麼意思呢？
PM 該怎麼估計總時程？
在抓時程前，PM 們得先有個認知：工程師給的估時，是「做完這個任務的所需時間」，有些工程師律己甚嚴（？），會把時間抓得很緊，沒有留太多緩衝時間；有人則抓得比較保險，緩衝時間抓得比做任務的時間還長。
所以，PM 拿到估時後（甚至在估時之前），可以先跟工程師建立個共識：是否已將緩衝時間納入估時？如果沒有，那 PM 拿到工程師的估時後，就得再參酌下列幾點，才能抓出更為精準的專案總時程。
1. 同一人同時有多個產品線
想優化的功能好多、待修的 bug 也好多，所以每位工程師身上常常都不只有一個任務，有的人甚至需要負責一個以上的產品，正因如此，估時時也得考慮此項因素。
比如我最近跟一位前端工程師合作，他手上一共有 3 個產品，第一個剛做完，正在測試；第二個剛上線，可能會有 hot-fix（上線後才發現的 bug，且需要緊急修復），第三個也就是我跟他合作的產品線，估時完成後，就要準備動工了。
有鑑於此狀況，身為 PM 的我就會知道：這位工程師的一天 8 小時不可能全部都投入在第三個產品上，而我也不能把專案排成抓太緊，而是得預留一些「讓工程師去修其他產品的 bug」的時間。
2. 會議量
承上，既然同一人手上有多個產品線，那也很可能平常就要固定花時間開會，這邊說的「會議」比較廣泛，包含較正式的例行會議、不定時的專案討論，甚至連線上非即時的討論或文字訊息也算在內。
這些大大小小的討論場合加總起來，其實也會佔去一天當中很多的工作時間。
3. 休假
耳聞不少員工是會根據產品時程決定休假，不過也有公司比較有人性（？），員工可以以私人行程為主，有假就先請，產品時程是依照每個同事的假期去做對應的調整。
但反正不論是哪種情況，估時時一定要把國定假日、負責人的休假、公司活動都算進去；此外，像我負責的某幾個產品會跟其他國家的同事協作，所以在抓專案時程時，也得將對方國家的放假天數納入考量。
4. 預留緩衝時間
上面有提到：PM 拿到估時後（甚至在估時之前），可以先跟工程師建立個共識：是否已將緩衝時間納入估時？
以我個人的習慣來說，我會希望工程師自己在估時時，就先把緩衝時間也算進去，畢竟一個任務的規模大小、難度高低，做的人自己最清楚，PM 反而很難拿捏預留緩衝時間的標準。
結語
最後總結一下這篇的內容，首先是先了解什麼是估時、估時的目的、誰需要做估時，再來則是聊了一些估時與期望不符的處理方式，最後則是 PM 如何將估時總結為一份專案的總時程。
其實寫到最後，還想再談談「實際開發時間跟估時差好多」、「實際開發後，估時可以修改嗎」等面向，但這樣這篇文章就有點長了（手已痠），就留待下一篇「step 8：開發」再細講吧。
