案例背景

WRQ 是企業應用整合軟體公司，產品銷售超過50國。案例聚焦 R-Web 第7版（Release 7），一項約需一年完成的軟體開發專案。公司以每年固定主要版本作為產品策略的一部分，發布日期由管理階層事先設定。

Release 7 預定增加檔案傳輸、安全代理伺服器、使用量計量、管理用網頁應用程式，並首次爭取美國 NIST 的 FIPS 140-2 密碼模組認證。

問題／衝突

專案進行六個月後，團隊發現上一版 Release 6 存在重大安全弱點。修復舊版本預估需要約1.5個全職當量的人力月份，直接干擾 Release 7 的既定資源與時程。

此外，Release 7 的使用量計量功能必須跨越其他產品線並處理授權合規與法務問題；FIPS 140-2 認證又依賴外部實驗室與 NIST，外部排程遠超團隊可控制範圍。

決策點／實施

R-Web 團隊採用功能驅動開發（Feature-Driven Development, FDD），以短週期、功能集合與逐步設計／建置方式管理開發。主要流程包括：建立整體模型、建立功能集合、依功能規畫、依功能設計、依功能建置。

團隊設置需求變更截止點，使用 WBS、專案時程、功能完成率、功能狀態報告與儀表板等工具追蹤進度，並利用 Wiki 式分散資訊系統讓成員更新狀態。

面對資源干擾，產品經理與工程經理重新檢視功能優先順序；對 FIPS 認證則改以在出貨前進入「預核准」狀態作為較務實目標。團隊也把專案學習由事後檢討改為多日回顧與持續回顧，並在下一版本加入更多可測試的中間里程碑。

原書狀態／結果

案例結束時 Release 7 仍在進行。團隊認為 FDD 已比過去臨時性或多重瀑布式方法更有結構，但仍處於試驗與調整階段。主要經驗包括：跨團隊需求需更正式、外部依賴需增加時程餘裕、需求優先順序必須清楚，而且不能假設外部認證機構會依內部專案節奏運作。

原書討論問題

1. 列出案例中 R-Web 軟體開發專案涉及的所有問題。討論解決方法，並提出可預防這些問題的行動。
2. 若你是多版本軟體開發專案的專案經理，如何降低前一版本的突發問題對新版本成功造成的影響？
3. 討論 FDD 流程的優缺點。
4. 提出持續擷取團隊學習的方法。

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

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

本案最重要的整合問題是：單一版本並不是孤立專案。前一版本的缺陷、其他產品線、法務單位、外部實驗室與政府機構都可能改變當期專案的資源、範疇與時程。整合管理因此必須涵蓋跨專案與外部依賴，而不只是專案內部工作。