案例背景

SSA 是一個21人單位，專門為一家約700人的軟體公司 SBA 開發內部軟體管理工具，用於測試母公司各事業單位製造的微處理器。

過去 SSA 常花最多 6個月蒐集需求，甚至在開發中途繼續接受新需求，希望滿足所有人，結果功能清單愈來愈長，專案拖很久，仍經常刪除承諾功能並發生嚴重範疇蔓延。

問題／衝突

SBA 各部門對 SSA 的範疇與時程管理有大量抱怨。公司因此組成跨部門團隊研究問題，最後建議改用 Quick Release 模式，作為大型複雜專案的反制方法。

決策點／實施

Quick Release 把大計畫拆成一連串頻繁的小型專案。每次 release 通常只包含 2～3項功能，並在 program life cycle 的 discovery phase 後、development phase 開始前凍結範疇，由 program manager 核准。

例如大型 Program X 被拆成 X1、X2 等小型 release。Hillsboro 團隊可在 X1 進入程式開發並交給 Russia 團隊時，同步蒐集 X2 的需求。每次 quick release 約 3個月，而新增功能若不屬於已核准的2～3項功能，就很難在中途加入。

原書狀態／結果

原書描述 SSA 採用此模式以降低大型專案常見的範疇蔓延與重大延誤，但沒有提供長期量化績效資料。

原書討論問題

1. 整體而言，你如何比較 Quick Release 與傳統方法？請列出兩者的優缺點。
2. Quick Release 比較適合大型還是小型軟體開發組織？請說明理由。
3. 說明 Quick Release 如何避免大型專案常見的重大延誤。

原書本 A 檔未提供正式解答。

參考分析（教學延伸／依本章內容推論）

Quick Release 的核心不是單純「做快一點」，而是把範疇與時間盒縮小，降低每次決策需要處理的複雜度。代價則是需要更強的跨 release 優先排序與整合能力。