姬麻咩七淘

※確保專案包含了所有的工作，確保僅有完成專案所需要的工作。

※專案範疇管理的關鍵概念：範疇-產品範疇與專案範疇

※生命週期

※需求：產品、服務或成果需達到的狀態或能力，以滿足協議或其他正式的規格。

※8.3管制品質所產出的「已驗證的可交付成果」(Verified Deliverables)經5.5 確認範疇正式接收後才成為「已接受的可交付成果」(Accepted Deliverables)。

※利害關係人在規畫或更早的啟始階段參與並提供需求相關的投入，才可在管制品質時評量可交付成果的性能及建議必要的變更。

※趨勢、新興的實務作法：與商業分析專業人員協作(Collaborative Partnership)。

※裁適的考量因素：知識與需求管理、組織的確認與管制機制、開發手法、需求穩定度、組織治理。

※在敏捷式/調適性環境的考慮因素：開始階段的需求不斷演化、高風險、相當不確定；花較多的時間建歷過程持續探索與細緻化。

※Note：專案章程+需求文件 --(定義範疇)--> 專案範疇說明書 --> WBS --> 範疇基準

5.1 規劃範疇管理(Plan Scope Management) [規劃過程組]

說明「專案與產品範疇」如何被定義、確認與管制，為專案提供如何管理範疇的指導原則與方向。執行一次或在事先訂好的時機點進行。

OUTPUT

1. 範疇管理計畫書(Scope management plan)：制定詳細專案範疇說明書的過程；從詳細的專案範疇說明書促成建立工作分解結構的過程、建立如何維護予核准範疇基準的過程；具體說明如何正式接受已完成之專案產物的過程。

2. 需求管理計畫書(Requirements management plan)：需求如何規劃、追蹤與報告；構型管理活動；優先度排序過程；使用的量測指標與理由；反映出哪些需求屬性將被列入追訴矩陣的追溯結構。

5.2 蒐集需求(Collect Requirements) [規劃過程組]

決定、紀錄及管理利害關係人之需要與需求，以符合專案目標；提供定義與管理專案範疇、產品範疇之基礎。執行一次或在事先訂好的時機點進行。

§利害關係人的積極參與、並細心地決定、紀錄、管理這些需求對專案的成功影響很大。

§需求被涵蓋於「範疇基準」，專案開始執行時就可被衡量。

T/T

2. 資料蒐集

※焦點團體(Focus groups)：預審合格的利害關係人及主題專家，有訓練過的主持人，反映會比一對一訪談熱烈。[Faciliated group - 跨領域的專家]

※問卷調查：有系統的問題設計，可快速累積大量的回饋意見。

※標竿比對：與值得學習的組織，比對其過程與操作方式。

5. 資料呈現

※親和圖法(Affinity diagram)：將想法歸類群組。

※心智圖法(Mind mapping)：無限衍伸，反應共同與差異性。

6. 人際關係與團隊技巧

※觀察/交談：直接觀察個人在環境中，如何完成其工作及其過程。工作影子(Job shadowing)，亦可由觀察者實際執行，發掘隱藏需求。

※促進：邀集關建利害關係人，快速定義「跨功能需求」。不同產業有不同的技巧：聯合應用設計/發展會議(Joint Application Design/Development, JAD)、品質機能展開(Quality Function Deployment, QFD)、使用者故事(User Story)。

7. 系統關聯圖(Context diagram)：範疇模型的範例，將產品範疇以視覺化的圖型呈現，展現專案成果予其他系統、人的互動。

8. 雛型(Prototypes)：有形的模型，可避免抽象的方式討論需求。可接受回饋反覆修正模型達到逐步精進的效果。其他模型技術：分鏡表(Storyboarding)。

OUTPUT

1. 需求相關文件(Requirements documentation)：格式可以是一個清單，從一開始高層次的描述到後來越趨詳盡。需求分類：

※商業需求(高層次需求)

※利害關係人需求

※解決方案需求(分功能性及非功能性，後者如產品的安全性、保密性)

※過渡性(移轉)與就緒需求(從現有狀態轉移至未來狀態，如資料轉換與訓練需求)

※專案需求(滿足專案行動、過程，如里程碑日期、協議責任)

※品質需求(確認產出及其他需求的條件或限制，如測試、驗證、確認)

2. 需求追溯矩陣(Requirements traceability matrix)：格式為一個表格，將產品需求從開始連結到結束，內容包括：營運需要、機會與目標；專案目標；專案範疇/WBS可交付成果、產品設計、產品開發、測試策略與測試情境；高層次的需求到更詳細的需求。需含有獨特的識別碼，版本、現況等資訊。

5.3 定義範疇(Define Scope) [規劃過程組]

發展專案與產品詳盡說明的過程，說明產品、服務或成果的界限與允收準則。高度反覆執行。

§利害關係人的積極參與、並細心地決定、紀錄、管理這些需求對專案的成功影響很大。

§需求被涵蓋於「範疇基準」，專案開始執行時就可被衡量。

§迭代式生命週期方案：先發展整體高層次需求，詳細的範疇在每個迭代中定義。

T/T

5. 產品分析：定義產品和服務。獲得高階需求後，將需求分解到設計最終產品所需具備的詳細程度。ex. 產品分解、需求分析、系統分析、系統工程、價值分析、價值工程(以最低成本滿足產品、服務需求的方法)。

OUTPUT

1. 專案範疇說明書：包含專案範疇描述(詳細的、逐步精進)、可交付成果(完成過程、階段、專案所必需產生的)、允收準則(Acceptance Criteria，可交付成果被接收前，必須滿足的條件)、專案排除事項(不含的項目，防止範疇潛變)。

5.4 建立工作分解結構(Create WBS) [規劃過程組]

將專案可交付成果與專案工作細分為較小、較容易管理的組件(Components)；為專案所應交付的內容提供架構(Framework)。執行一次或在事先訂好的時機點進行。

§WBS：組織、定義專案的全部範疇，為科層式分解(Hierachical Decomposition)，顯示已獲准之專案範疇說明書中具體的工作。

§工作包(Work Package)：WBS最底層所含蓋的預定工作，歸類數個相關活動(Activity，這才是規劃時程、成本的基礎)，以便排程、估算、監視及管制工作。

§工作：在WBS裡指的是活動成果的工作產品或可交付成果，非活動本身。

T/T

2. 分解：將專案可交付成果與專案工作細分為較小、較容易管理的組件之技術。需包含下列活動：辨識與分析可交付成果與相關工作；結構化與組織化工作分解結構(編排方法)；分解上層的工作分解結構為低層的細部組件；發展與分派工作分解結構組件的識別碼(Identification Code) - 確定每個工作分解結構所在的層次；驗證可交付成果之分解程度的適當性。

※分解的方法：自上而下法、運用組織之指導方針、使用WBS範本、自下而上法。

※出騎實還無法預估未來明細的可交付成果，故通常等到可交付成果或子專案認可後才發展WBS細節，稱為湧浪規劃法(Rolling Wave Planning)。

※正確性：下層之WBS組件恰可以整合成其對應之上層WBS組件。沒有遺漏、也沒有額外工作，100%法則。

OUTPUT

1. 範疇基準：為三個文件的核準版：專案範疇說明書、工作分解結構、工作分解結構說明表。做為管理實際狀況之比較基準，核准後只能經由正式變更程序修改。組件包含：

※專案範疇說明書

※工作分解結構

※工作包(Work Package)：WBS最下一層的工作，有獨一的識別碼；數個工作包組成一個管制帳戶(管理管制點)，整合後的資料用以與實獲值相比。

※規劃包(Planning Package)：低於管制帳戶，高於工作包的WBS組件；有已知的工作內容，但沒有詳細的時程活動。(工作包的前身)

※工作分解結構說明表：針對每個WBS組件，提供更詳細的可交付成果活動與時程之文件。

5.5 確認範疇(Validate Scope) [監視與管制過程組]

正式允收已完成的專案可交付成果的過程。使允收過程更為客觀(Objectivity)，並透過確認每個可交付成果，以提高最終產品、服務或成果被允收的機率。視需求、定期執行之。

§確認範疇與管制品質的差別：

T/T

1. 檢驗：決定工作及可交付成果，是否符合需求與產品允收準則。亦稱：審查(Review)、產品審查、稽核(Audit)、逐步解說、現地勘查(Walkthroughs)。

OUTPUT

1. 變更申請：已完成、未獲正式接受的可交付成果，配合書面紀錄並註明未接受理由；可能需要提出變更申請，以進行缺陷修復(Defect Repair)。

5.6 管制範疇(Control Scope) [監視與管制過程組]

監視專案與產品範疇狀態，並管理範疇基準變更的過程。確保所有的變更申請、建議的矯正措施或預防措施都經由「進行整合變更管制」過程執行。整個專案期間都要執行本過程。

§避免未經管制的產品或專案範疇擴充，稱為「範疇潛變」(Project Scope Creep)。

OUTPUT

1. 工作績效資訊：包含已辨識的範疇變異及其原因，變異如何影響時程或成本，及對未來範疇績效的預測。

2. 變更申請：可能產生：分析專案績效，可能產生範疇基準、時程基準、專案管理計畫書其他成分的變更申請，將經由「進行整合變更管制」，進行審查與處置。