指南
軟件項目需時多久?是什麼令它更久?
任何在未了解您項目之前就給出單一數字的人,都只是在猜測。時間視乎範疇、能同步工作的人數,以及同樣重要的,您這邊多快作出決定、提供內容及給予回饋。本指南說明影響時間表的因素,以及如何規劃。
重點摘要
- 時間 = 工作量 ÷ 能同步進行的程度,再加上等待時間。
- 等待內容、決定及審批,是最大的隱藏延誤原因。
- 增加人手並不會按比例縮短項目,甚至可能令它更慢。
- 規劃時預留緩衝,並顧及香港公眾假期及惡劣天氣日。
- 以下例子是按我們自己模型得出的示例,並非承諾。
影響長短的因素
三個示例
我們的成本估算器會把描述轉為以人週計的工作量,以及一個參考曆日時間,並對團隊規模作出明確假設。對三種典型描述,它的結果是:
這些是模型的示例,並非承諾。它們假設簡介清晰、決定迅速,並不包括等待第三方的時間。真實項目往往因本指南所述原因而更長。
項目為何超時
- 範疇悄悄擴大。每項「小」增添單獨看很便宜,合計卻很昂貴。請保留一份看得見的清單,並有意識地決定。
- 內容遲到。文字、相片、翻譯及產品資料在上線前都需要。請在第一天就開始準備。
- 回饋成堆湧到。沉默兩週然後一次四十項意見,比每週穩定的回饋花費更多。
- 整合的表現與文件所述不同。先測試風險最高的幾項。
- 一切留到最後才測試。遲發現的問題最費時修正。請要求定期看到可運作的軟件。
- 團隊不是全職投入。分身於多個項目的人,比時數顯示的更慢。
規劃切實可行的日期
常見問題
增加開發人員可以加快進度嗎?
只在一定程度內。更多人意味著更多協調,而且有些工作無法分拆。在項目後期才加人,往往反而更慢。
應用程式商店審查需時多久?
視乎情況,無人能控制,由數小時至數天不等,被拒絕則須重新提交。請在上線日期之前預留數天餘地,並查閱 Apple 及 Google 的現行指引。
趕工的項目一定較差嗎?
不一定,但速度是靠削減範疇、增加人手或接受風險換來的。趕上日期最穩妥的方法是較小的首個版本,而不是壓縮日程。