Pavel Simsa, PMP — Bellevue, Washington, USA

軟體專案的獨特性#

如果說有什麼東西能區分軟體開發專案與其他類型的專案，那就是範疇變更（scope change）的必然性。沒有任何其他行業，有著如此持續波動的範疇。

專案受三重限制（triple constraint）所支配：成本、時間、範疇。

三重限制的現實#

成本#

追加資金或資源很少能解決問題。若同時加倍軟體開發人員的數量，不但不會加倍速度，反而會造成代碼所有權混亂與溝通成本暴增。成本必須維持穩定。

時間#

每個專案都有一個「那個日期」（The Date）。它不是計畫書上的交付日，而是那個心照不宣、真正不能越過的截止點。例如：某安全產品若預計 11 月發布，滑到 1 月還能接受，但若錯過 2 月的國際安全大會（Black Hat），才是真正的危機。時間有一定彈性，但幅度有限。

範疇#

最具彈性的限制反而是範疇。原因很簡單：每個新軟體產品都有「必備功能」（must have）和「加分功能」（nice to have），而後者的數量往往遠多於前者。

補充： 軟體不像建築工程，不能說「原本要蓋 60 層，現在只蓋 40 層，其餘以後再說」。但在軟體中，「Release One 只支援兩個作業系統，其餘版本再加」是完全可行的。

主動規劃範疇縮減#

說老實話：範疇變更幾乎無法避免，這是軟體開發的本質。但你可以做的是提前規劃，讓裁切決策在真正需要時更容易執行：

• 從專案一開始，就明確識別**「加分功能」清單**
• 分析這些功能之間的相依關係（dependencies）——這一點至關重要

注意： 裁切「加分功能」時，若忽略相依關係，可能連帶影響「必備功能」的開發架構，導致額外的重工成本。

關鍵： 預先規劃可能的範疇縮減方案，當決策時刻到來，你就知道要砍什麼、怎麼砍，而不是在壓力下倉促決定。接受範疇會變，才能從容應對變化。