估工時有哪些好方法?有興趣了解一下本系列改寫出版的《Agile一本通！敏捷新手入門導引》嗎?
現在最優惠不用喊價 >> https://www.books.com.tw/products/0010968755

「這個項目估兩周!太長了吧?」

「這個技術我是第一次碰，給我點時間研究吧。」

「你可以問問灰貓，他有做過。你再評估一下，這項我認為頂多五天。」

「...」

「使用者說他一個月後就要!你估這時程我不同意。」

「不可能，這讓我假日來加班都做不完...」

「應該沒有這麼難，你再想一下，別的團隊都可以配合，你應該也可以。」

誰決定工時

當團隊規模較小，或沒有明確分工時，工時通常是開發人員得知需求，或將需求帶回評估後的一句話

若團隊中有技術主管或領導人，工時會由開發人員與技術主管共同討論，或者由開發人員初步評估，再由技術主管檢視

而更多時候，時程往往已經由使用者決定，開發人員評估工時的意義，在於提供PM/PO/主管決定是否調配人力，或是否有無法如期交付的風險

估工時的目的

或許有人認為，工時是估不準的。畢竟無法預測當天是否有臨時的會議、人員請假或插隊進來的事。而估工時主要的意義在於: 設定計畫完成的時間與了解工作的內容。

萬事起頭難，尤其是有拖延症的人更能夠明白。藉由與使用者、PM/PO/主管對準工作的內容，自己也經過評估給出承諾的時程，專案開始這件事就不再是遙遙無期；而PM/PO/主管也能充分了解每一個階段開發團隊成員在做的事情，若有其他事務出現，也應妥善排序待辦順序

估工時的難處與解法

• 需求不明確就押時程:常常遇到PM在需求尚未明確時，就急著要開發團隊給出時程。而團隊迫於壓力，只好接受暫訂的時程，到開發中途才發現有相當費時、待克服的技術困難點，導致最後無法如期交付或成員被迫加班

  解法:
  PM應積極向使用者釐清需求，協助雙方溝通；而主管必須與開發團隊站在同一陣線，當需求與開發技術評估明確後，再進行時程預估

• 使用者/技術人員對需求/技術的認知落差:在評估時程時，使用者往往覺得需求「很簡單」，無法理解工時較長的原因；或技術人員間能力差異，導致低估或高估開發難度，進而導致時程評估失準

  解法:
  PM應向使用者解釋工時較長的原因，或協助排序需求的重要性，在一定的時程當中訂出合理的交付項目；工時的預估應由開發團隊成員間相互討論後訂出，釐清評估較長工時的理由，開發過程中團隊成員間應相互支援，並樂於分享、學習以提升能力。

容易歪掉的部分

• 主管不尊重討論結果，直接硬性決定時程
• 工時討論淪為討價還價，主管砍工時、開發成員先高估工時，使時程預估失準
• 使用者/PO在工時/時程訂定後，增加額外的需求與待辦項目
• PM/PO/主管在開發時程開始之前，要求先完成部分的待辦項目

明天，我們來看看如何使用計畫撲克估工時/工作量