要估出一個合理的開發時程，想必對有經驗的工程師來說，都不是一件太難的事。然而，讓討論開發時程變成一件痛苦的事的原因，無非就是如何讓估出來的時程被同意。既然對於時程的討價還價在所難免，不如就充分的準備可能會被問到的問題，讓開發時程討論的過程多一點信心，也可以先明白自己的「底價」，避免時程被壓縮到必須長期加班趕工、品質下降或無法如期交付。

洽

估算時程的方法，常見的有以下幾種:

• 經驗判斷法:
  用過去執行其他專案的經驗，來判斷新的專案須執行的時長。此種方法適用於判斷過去做過的同類型的專案，如果從未做過的專案就無法適用；且隨著開發人員對技術的熟悉度增加、套件與工具的不斷更新，開發新專案的速度可能比過去更快。
• 專家判斷法:
  找較為資深的成員或技術專家協助判斷工時。但不同執行的人可能會因為對技術的熟悉程度不一而有不同結果，建議讓專家評估任務難度，再讓實際執行的成員判斷工時。
• 由下而上法:
  將專案工作細部分解，逐一估出工時，再用工時總和作為時程。通常會先拆出WBS，再進行工時預估。但如果在專案初期對技術尚不了解，或者需求隨專案進行過程有變化時，可能因為出現了原先沒有想到的工作項目，導致估出的工時與實際有落差。
• 三點估算法:
  估出專案的樂觀、悲觀與最可能時程，並計算三者的加權平均值。

除了估算時程，也有估計工作大小的方法。例如:敏捷中使用T恤大小、計畫撲克等方式估計工作點(故事點)的方法。

各種估計方法最後都會回到一個問題:為什麼需要這麼多時間?，可以先列出專案中較難或者需要另外研究的工作，以及預計的工作內容與時間。

chart

若過去有開發類似專案的經驗，可以使用燃盡圖，查看過去工作執行的速度。不僅可以跟過去的自己比較，也可以提供其他同類型專案的數據或圖表，作為時程合理性的佐證資料。

恰

在時程預估討論時，通常會先說明:

• 關鍵時程
  例如:提供使用者測試的時間、產品部分或完全交付的時間、基礎建構完成的時間等
• 評估過程中發現較困難或有風險的項目
  例如:過去未曾做過且無人可以諮詢的項目、根據過去經驗花費較長時間的項目、內容較有可能變動的項目等

說明完以上兩項，接著就是問答車輪戰的開始。完整且有說服力的回答有助於讓時程減少被壓縮的可能，通常會被問到這些問題：

• 為什麼需要這麼多時間?
  列出所有預計進行的工作事項，以「工作項目繁多」為由，爭取需要更長的開發時間，或許是最容易想到的方式。但通常這個方法，仍免不了被「逐項砍價」的風險。若把重點放在說明較艱難或介紹「較令人期待」的項目，能讓參與討論者同理或有更高的期待，爭取到較長時程的可能性較高。例如：說明需求內容的難度與複雜度、強調專案採用的技術較為新穎，雖然需要花時間研究但可以帶來更多效益(例如：節省未來專案開發的時間、功能使用起來更友善)等。
• 是否有嘗試過任何能讓完成速度加快的方法?
  這樣的問題目的在於想知道團隊是否「竭盡全力」。比起輕易答應加班趕工，可以列出一些能夠優化的作法。例如：使用Copilot加速程式開發、將申請流程提早減少等待時間等。要注意的是，讓完成速度加快的方法，不能影響產出的品質。如果被要求以降低品質來加快速度，必須提出對應的風險並予以拒絕。
• 客戶急著要/需求很緊急/市場變化快，為什麼不能早一點完成?
  或許你曾有這樣的經驗，辛苦趕工開發的產品，上線後使用人次寥寥可數，甚至部分功能乏人問津。或許客戶的需求內容豐富多元，但真正能解決問題、經常被使用的也只佔一小部分(80/20法則，80%的使用率來自20%的關鍵功能)。此時可以先問需求急迫的原因，排序並找出能解決問題的主要功能，檢視在客戶認為急切需要的時程前能完成的部分，並分次交付給客戶。
  由於專案執行過程中，客戶所認為的功能重要性排序可能會改變。持續對準並開發當下認為最重要的功能，不僅可以減少工時浪費，也能持續收集使用回饋，讓交付的產品真正能符合需求。

經過了縝密的準備、克服重重問答，最終時程仍可能被壓縮。此時的你多少感到沮喪，但要讓專案順利完成、自己也不被壓垮，建議把重心放在可以處理的事上，並持續關注風險、臨機應變，專案總能以最好的方式完成。
參考資料

1. 準不準時都要估！預估工時的意義究竟在哪？
   https://www.bnext.com.tw/article/54364/pm-control-schedule
2. 談專案的「時程估算」：有哪幾種估算方式？與上級的期望值不符時如何因應？
   https://www.projectup.net/article/view/id/16657
3. 看電影學管理：分鏡規劃與臨場應變
   https://www.projectup.net/article/view/id/16817