指南

軟件項目需時多久?是什麼令它更久?

任何在未了解您項目之前就給出單一數字的人,都只是在猜測。時間視乎範疇、能同步工作的人數,以及同樣重要的,您這邊多快作出決定、提供內容及給予回饋。本指南說明影響時間表的因素,以及如何規劃。

重點摘要

  • 時間 = 工作量 ÷ 能同步進行的程度,再加上等待時間。
  • 等待內容、決定及審批,是最大的隱藏延誤原因。
  • 增加人手並不會按比例縮短項目,甚至可能令它更慢。
  • 規劃時預留緩衝,並顧及香港公眾假期及惡劣天氣日。
  • 以下例子是按我們自己模型得出的示例,並非承諾。

影響長短的因素

  • 範疇。更多畫面、使用者類型、規則及整合,意味著更多工作。這是最大的因素,也是您最能掌控的。
  • 不確定性。不清晰的需求及未經嘗試的整合,會增加摸索時間,並在假設被證實錯誤時導致返工。
  • 您的速度。每一個遲來的審批、內容及答覆,都會令團隊停工。
  • 需要同意的人數。一位決策者很快;一個委員會則不然。
  • 外部人士。支付供應商開戶、應用程式商店審查、供應商提供的資料及法律檢查,都有各自的時間表。
  • 品質工作。測試、修正、無障礙設計及雙語內容屬於完成工作的一部分,而非額外項目。

三個示例

我們的成本估算器會把描述轉為以人週計的工作量,以及一個參考曆日時間,並對團隊規模作出明確假設。對三種典型描述,它的結果是:

  • 雙語宣傳網站。約 6 人週,兩人團隊在日曆上大約需要 4 至 7 週。
  • 網頁式預約系統,包含網上付款、管理區、通知及兩種語言。約 19 人週,三人團隊大約需要 7 至 11 週。
  • 跨平台應用程式,包含帳戶、付款、管理區、通知及一至兩項整合。約 29 人週,四人團隊大約需要 7 至 12 週。

這些是模型的示例,並非承諾。它們假設簡介清晰、決定迅速,並不包括等待第三方的時間。真實項目往往因本指南所述原因而更長。

項目為何超時

  • 範疇悄悄擴大。每項「小」增添單獨看很便宜,合計卻很昂貴。請保留一份看得見的清單,並有意識地決定。
  • 內容遲到。文字、相片、翻譯及產品資料在上線前都需要。請在第一天就開始準備。
  • 回饋成堆湧到。沉默兩週然後一次四十項意見,比每週穩定的回饋花費更多。
  • 整合的表現與文件所述不同。先測試風險最高的幾項。
  • 一切留到最後才測試。遲發現的問題最費時修正。請要求定期看到可運作的軟件。
  • 團隊不是全職投入。分身於多個項目的人,比時數顯示的更慢。

規劃切實可行的日期

  • 分開索取工作量及曆日時間,並要求說明各自的假設。
  • 預留緩衝。百分之十五至三十很常見,範疇或整合不確定時應更多。
  • 計算真正的工作日。香港公眾假期、農曆新年及惡劣天氣日都會佔去時間。我們的項目時間表規劃器可把工作日轉為日曆日期,亦可由限期倒推。
  • 議定您自己的限期,用於提供內容及作出決定,並寫入計劃。
  • 分階段發布。較小的首個版本更早到達,也讓您學到更多。請參閱規劃首個版本。

常見問題

增加開發人員可以加快進度嗎?

只在一定程度內。更多人意味著更多協調,而且有些工作無法分拆。在項目後期才加人,往往反而更慢。

應用程式商店審查需時多久?

視乎情況,無人能控制,由數小時至數天不等,被拒絕則須重新提交。請在上線日期之前預留數天餘地,並查閱 Apple 及 Google 的現行指引。

趕工的項目一定較差嗎?

不一定,但速度是靠削減範疇、增加人手或接受風險換來的。趕上日期最穩妥的方法是較小的首個版本,而不是壓縮日程。

要趕在指定日期完成?

告訴我們限期,以及屆時必須準備好的內容。我們會說明什麼切實可行、什麼應該削減。

索取項目報價