預估的認知鴻溝#
在軟體開發中，「預估」往往是衝突根源，原因在於業務方與開發方對這詞的定義截然不同：
| 維度 | 業務方觀點 (Business) | 開發方觀點 (Developers) | 造成的衝突 |
|---|---|---|---|
| 詞彙定義 | 承諾 (Commitment) | 猜測 (Guess) | 雙方對「完成時間」 的性質認知不一致 |
| 本質理解 | 視為一個 確定死線與合約義務 | 視為一種基於 不確定性的機率分布 | 當實際產出偏離預估時， 產生信任危機 |
| 溝通心態 | 聽到的內容： 「三天後一定會好」 | 理想狀態下， 大概需要三天 | 訊息在傳遞過程中 喪失了風險溢價的理解 |
專業人士深知這種認知落差。因此，他們不會隨便「承諾」，
而是盡可能向業務方說明這預估背後的「機率分布」，讓對方理解風險。
計畫評審技術 (PERT)#
為了更科學地表達預估的不確定性，作者推薦用 PERT (Program Evaluation and Review Technique)。
這種方法強迫開發者從單一數值（往往過度樂觀）轉向思考三個維度的數值：
三點估算法#
| 代號 | 名稱 | 定義與發生機率 | 特徵 |
|---|---|---|---|
| O | 樂觀預估 (Optimistic) | < 1% | 一切順利、沒任何干擾的完美情況。 這通常是極度樂觀的幻想 |
| N | 常規預估 (Nominal) | 最大 | 在機率分布圖（柱狀圖）中最高的那條。 這是最可能發生的情況 |
| P | 悲觀預估 (Pessimistic) | < 1% | 當所有倒霉事都發生時 （不包含地震、戰爭等災難） |
Figure 10-1: Probability distribution
避免過度樂觀#
使用 PERT 的最大目的，是避免預估過度樂觀。
工程師天生傾向只見「常規預估 (N)」甚至「樂觀預估 (O)」，而忽略潛在風險。
透過強迫思考「悲觀預估 (P)」，我們能拉寬時間軸，給出更符合現實的風險評估。
計算公式 (參考)：
PERT 通常會搭配加權平均公式來計算期望值： $$\text{Expected} = \frac{O + 4N + P}{6}$$ 這能將單一猜測轉化為具統計意義的期望工時。