小編精選 - 技術文章翻譯 · 11月14日

「大概需要多少工時？」不能用「大概就是這個工時」來回答

前言

「如果要做這個 App，大概要多少工時？」

被這樣問到時，你是否也曾下意識地回答：「大概〇人月左右吧。」

之前我在「從『工時不夠』中脫身」這篇文章裡，談過面對計畫所需工時不足時的情況。這次要談的是更前面的階段，也就是如何提出估算、以及該如何傳達估算。

只用一句「大概就是這樣」來回答並不好。
我認為，粗估應該掌握以下 3 點：

用能和利害關係人溝通的數量 × 每單位工時來表達
每單位工時不是靠猜，而是用過去的實績求出來
估算本來就是預測，所以不要只給一個數字，而要用範圍與機率分布來傳達

「大概就是這樣」會造成的落差

首先，先談談問「大概多少？」的人背後的立場。
事業負責人或經營者，想盡快判斷要不要做。誰也不想等上好幾週，才拿到詳細估算。這種心情其實很能理解。

問題在於，若只是回覆沒有根據的數字，就會出事。

一旦說出口，數字就會自己跑出去。
之後即使提出正式估算，也會被拿來比對：「你之前不是說〇人月嗎？」
被問到「為什麼要這麼久？」時，又因為沒有根據，只能變成感覺與感覺的爭論，也就是所謂的空中戰。

問的人和答的人都不一定有錯，卻還是會錯位。
為了快速回應對方想要迅速判斷的需求，同時又能提供有根據的答案，我認為關鍵工具就是接下來要說的「公式」與「分布」。

數量 × 每單位工時

粗估可以用「數量 × 每單位規模」這個公式來算。

能和利害關係人溝通的單位

重點在於「數量」要怎麼定義。
我真正想傳達的是，要用能和利害關係人溝通的單位來估算。

估算是用來讓雙方達成共識的工具。
就算我們用再精細的單位來估算，如果對方不理解那個單位，最後還是會回到「為什麼要這麼多」的空中戰。

例如，定期批次作業或 API，和畫面的單價感完全不同。
如果對方能理解這種差異，那麼在粗估階段就可以分開處理成「畫面 ◯ 個、批次 ◯ 支、API ◯ 支」。

但實際上，更多時候並不是這樣。
相較之下，畫面是看得見的，誰都能數。
一般來說，能達成共識的單位，往往會是容易看懂的畫面數。

那麼，如果只用畫面數來估算，批次與 API 的工時跑到哪裡去了呢？
別擔心。之後會提到的「過去案件總工時」裡，會把批次和 API 的工時也一起記錄進去。所以即使不另外數，它們也會被平均吸收進每畫面的工時裡。

以畫面數建立公式

工時 = 畫面數 × 每畫面工時

假設是 20 個畫面 × 0.5 人月 = 10 人月，像這樣。
※本文中的數字全部都只是說明用的範例。

有了公式，討論就不再是「貴不貴」，而是變成「這個畫面真的有必要嗎」這類範疇問題。
即使畫面數改變，也只要代回公式重新計算就好。

每畫面工時要從實績求出

每畫面工時不能靠「這個畫面大概 0.5 人月吧」這種預測來決定。
即使形式上看起來像公式，如果內容只是憑感覺，那就和「大概就是這樣」沒什麼兩樣。

每畫面工時應該使用過去案件的實績平均。

每畫面工時 = 過去案件總工時 ÷ 過去案件畫面數

我認為這就像透天厝的坪單價一樣。

第一次向建商諮詢時，通常會得到這樣的回答：「坪單價是 ◯ 萬元，所以 35 坪大概是 ◯◯ 萬元。」這個坪單價，其實就是過去蓋過的房子的平均值。雖然廚房或外牆的等級不同，金額會改變，但那是等到規格細節都確定後才會決定的事。粗估階段，不會為了某一棟房子先預測它的特殊規格而去調整單價。

App 也是一樣。
在粗估階段先用實績平均，等到規格詳細化後，再依照各畫面逐一加總。規格差異較大的前提，會在更後面的詳細規格階段才決定。

再補充一點，房屋估價時通常會把「主體工程是坪單價，外部工程與雜費另計」分開列出。
因為屋主理解「外部工程是另外要付的」，所以才可以分開說明。
App 的批次與 API 也是同樣道理：如果對方能理解，就分開列；如果不能理解，就把它們包含在主體（畫面）的單價裡。這就是我認為應該採取的區分方式。

順帶一提，這種「根據類似過去案件的實績來預測」的想法，和 Flyvbjerg 等人所提倡的參照類別預測（Reference Class Forecasting）幾乎是同一概念。

實績請用這種格式記錄

實績還不多的團隊，從今天就開始記錄吧。至少有這些資訊就夠用了。

案件名稱｜畫面數｜總工時（人月）｜期間｜備註
案件 A（例）｜20｜9｜4 個月｜以管理畫面為主。批次 2 支、外部 API 串接 1 個
案件 B（例）｜16｜10｜5 個月｜有付款串接

重點有兩個：

畫面數的數法要在團隊內固定。例如「網址變更算 1 個畫面，彈出視窗或分頁不算」之類，規則一旦飄移，平均也會跟著飄移
總工時要把整個案件的工時全部放進來，包括設計、測試、PM、批次與 API。正因如此，只靠畫面數來估算也不會漏掉

用分布來回答估算

估算還有另一件需要掌握的事。
估算本來就是預測。
預測一定會有誤差。

就像天氣預報不會只說「明天會下雨」，而是會說「降雨機率 70%」一樣，我認為預測本來就應該以機率分布來回答。

尤其是在粗估階段，規格還沒定、未知項目很多。這時如果只回答「10 人月」，就等於假裝自己知道其實還不知道的事情。用範圍和機率來回答，才是比較誠實的作法。

這個範圍會隨著規格逐漸確定而縮小。這就是 McConnell 推廣的不確定性錐體（Cone of Uncertainty）概念。

從實績求出三點估算法

要輕鬆表達分布，可以用三點估算法。不是只給一個數字，而是提出三個數字。

樂觀值（a）：順利時
最可能值（m）：最有可能的情況
悲觀值（b）：不順利時

這 3 個數字也不要靠猜，而是從實績求出來。
例如，假設在這次案例中，畫面數是 20～24（畫面通常只會增加不太會減少），而過去實績中每畫面工時的最小值、平均值、最大值分別是 0.4、0.5、0.75 人月。

樂觀值 a = 20畫面 × 0.4人月  = 8人月
最可能值 m = 20畫面 × 0.5人月  = 10人月
悲觀值 b = 24畫面 × 0.75人月 = 18人月

另外，我認為三點估算法是在實績較少時的一種近似。如果類似案件的實績已經累積得很足夠，那麼與其壓縮成 3 個點，不如直接使用實績的波動，也就是分布本身，更加自然。

用金額、期間與機率來傳達

三個點出來後，就可以算出期望值與範圍。以剛才的數字來看，會是這樣（假設每人月 100 萬日圓，且由 3 人團隊執行）。

工時｜金額｜期間（3 人單純計算）
範圍 8～18 人月｜800～1,800 萬日圓｜約 2.7～6 個月
期望值（五五波）11 人月｜1,100 萬日圓｜約 3.7 個月
約 8 成機率可落在的線｜約 12.7 人月｜約 1,270 萬日圓｜約 4.2 個月

最可能值是 10 人月，但期望值是 11 人月。
軟體開發在提早完成的方向上有極限，但延遲的方向上卻幾乎沒有上限。由於悲觀側尾巴較長，平均值自然會往右偏。

計算內容（PERT 法與 Beta 分布）
在三點估算中，可以把工時視為服從 Beta 分布，並用以下公式求出期望值與標準差（PERT 法）。Beta 分布能表現右側拖長尾巴的形狀，因此很適合用在估算上。

期望值   = (a + 4m + b) / 6 = (8 + 4 × 10 + 18) / 6 = 11人月
標準差   = (b - a) / 6      = (18 - 8) / 6        ≒ 1.7人月
約8成的線 ≒ 期望值 + 標準差 = 11 + 1.67      ≒ 12.7人月

「期望值 + 標準差 ≒ 約 8 成」是把它近似為常態分布時的參考值（嚴格來說約為 84%）。

另外也有幾點但書：

PERT 的公式本身就是對 Beta 分布的近似。我把它當作比精密更重要的，是一個用來「用範圍說話」的工具
規模越大，每畫面工時通常也越高（規模不經濟）。請參考規模相近的案件實績
不同團隊的生產力不同。若要引用其他團隊的實績，必須做補正
期間是把人數直接相除後得到的簡單計算。增加人力不會線性縮短時程

要在哪裡承諾

這裡要注意的是，不能用期望值作為承諾。
期望值是「五五波」的線，所以如果以 11 人月承諾，幾乎有一半機率會超出。

我認為，預算或承諾應該放在約 8 成機率可落在的線上，例如 12.7 人月、約 1,270 萬日圓。

事業端可以做的事

如果只說範圍，大家很容易會想：「那我到底要決定什麼？」其實事業端能做的事很多。

預算就用上限那條線來抓。若以約 8 成的線來預留，通常都能裝得下，剩下的還可以回收
盡快決定規格。正如不確定性錐體所示，規格越確定，範圍就越小
減少畫面數。既然是公式，畫面數少了，金額和範圍都會下降

與其說「太貴了，請打折」，不如改成「要刪掉哪些畫面」「要先決定哪裡」，這樣就能實際改變金額。這也是我認為用公式與分布來談的最大優點。

實際被問到時，可以這樣回

如果被問「大概多少？」的時候，我認為可以像這樣回答：

以目前的內容來看，大概有 20 個畫面。
依照過去實績，每個畫面平均 0.5 人月，所以最可能大約是 1,000 萬日圓。
不過因為還有很多尚未確定的地方，所以範圍大約是 800～1,800 萬日圓。
平均來看是 1,100 萬日圓，而有 8 成把握落在的範圍，大約是 1,300 萬日圓以下，所以若預算能抓在那裡會比較安心。
等規格更明確後，範圍就會縮小；如果減少畫面，金額也會下降。

即使如此，對方還是可能會說：「別管那麼多，直接給我一個數字。」
這時候我會建議這樣回答：