5.項目范圍管理5.1規(guī)劃范圍管理5.2收集需求★5.3定義范圍5.4創(chuàng)建WBS（工作分解結(jié)構(gòu)）5.5確認范圍5.6控制范圍
5.項目范圍管理
做范圍管理的目的：做且只做所需的全部工作
產(chǎn)品范圍 VS 項目范圍 產(chǎn)品范圍：成果所具有的特性和功能（APP的功能） 項目范圍：為了交付成果而必須完成的所有工作（為了完成這個APP所做的工作）。產(chǎn)品范圍側(cè)重結(jié)果，項目范圍側(cè)重過程；
原則：確認范圍、控制范圍、監(jiān)測范圍、范圍圍繞需求展開
新興實踐：敏捷方法
5.1規(guī)劃范圍管理
定義：創(chuàng)建范圍管理計劃,書面描述將如何定義、確認和控制項目范圍
內(nèi)容：在整個項目中對如何管理范圍提供規(guī)范和指導(dǎo)性文件
輸出：需求管理計劃、范圍管理計劃
輸入：項目章程；項目管理計劃：質(zhì)量管理計劃
工具與技術(shù)：數(shù)據(jù)分析：備選方案分析
輸出：范圍管理計劃、需求管理計劃
范圍管理計劃：定義如何開展范圍的工作
需求管理計劃：如何開展需求的工作
5.2收集需求★
定義：為實現(xiàn)項目目標而確定、記錄并管理相關(guān)方的需要和需求“需求的文檔化”
內(nèi)容：為定義和管理項目范圍(包括產(chǎn)品范圍)奠定基礎(chǔ)
輸出：需求文件、需求跟蹤矩陣★
輸入：項目章程；商業(yè)文件：商業(yè)論證；協(xié)議；相關(guān)方登記冊（記錄人以及他們的需求、期望）；
工具與技術(shù)：數(shù)據(jù)收集：頭腦風(fēng)暴、訪談、焦點小組、問卷調(diào)查、標桿對照；數(shù)據(jù)分析：文件分析；決策：投票、德爾菲、獨裁型決策、多標準決策分析；數(shù)據(jù)表現(xiàn)：親和圖、思維導(dǎo)圖；人際關(guān)系與團隊技能：名義小組技術(shù)、觀察/交談、引導(dǎo) ；系統(tǒng)交互圖；原型法
頭腦風(fēng)暴：發(fā)散思維，提創(chuàng)意。
訪談：一對一 或 一對多面談，打電話也是；
問卷調(diào)查：給一個表，讓用戶填；使用場景★★：相關(guān)方眾多，地理位置分散；適合開展數(shù)據(jù)統(tǒng)計，快速完成數(shù)據(jù)收集；
標桿對照：抄 比如做一個通訊軟件，對照微信，看看哪些功能好，抄過來。
文件分析：從文件中分析用戶需求
投票：三個原則：一致同意；大多數(shù)同意：50%以上；相對多數(shù)同意；
德爾菲：匿名(背靠背)的一種技術(shù)；避免專家與專家之產(chǎn)生影響，避免因別人的身份，影響到自己的判斷；
多標準決策分析：多個維度來考慮；
親和圖：就是做分組、分類
思維導(dǎo)圖：從一個點發(fā)散思維，對提出的創(chuàng)意做圖形化的整理，細化，以便于做進一步分析；
名義小組技術(shù)：將收集到需求做排序，將最有用的創(chuàng)意拿出來，進一步開展頭腦風(fēng)暴或優(yōu)先排序；
觀察/交談：(不愿說、不能說、說不清)用戶無法表達清楚自己的需求，我們可以自己看，看用戶怎么工作（也叫工作跟蹤），記錄下來，再與用戶交談
引導(dǎo)★★：跨職能用戶在自己的立場上提需求，引導(dǎo)所有用戶針對某一功能形成一致認可的結(jié)論；會議：引導(dǎo)式研討會 ；
聯(lián)合應(yīng)用開發(fā)JAD★：由用戶與項目開發(fā)團隊一起，定義、分析、管理、排序需求，決定要做什么東西；
質(zhì)量功能展開QFD:將用戶需求轉(zhuǎn)化為數(shù)字，根據(jù)數(shù)字進行排序；
用戶故事（敏捷）：簡單理解為需求；角色，目標，價值；
系統(tǒng)交互圖：各個系統(tǒng)之間是怎么交互的，系統(tǒng)與人又是怎么交互的。
原型法：趨近于敏捷，用戶對自己的需求不是很清楚，可以做一個Demo,畫一個原型，讓用戶體驗，幫助用戶提煉自己的需求。（比如找別人裝修房子，都是先做一個設(shè)計圖，讓你看看是不是這樣的做。）使用場景：適合迭代項目；
輸出：需求文件、需求跟蹤矩陣★
對需求做分類，有哪些類型（包括但不限于）：
業(yè)務(wù)需求
相關(guān)方需求
解決方案需求： 功能需求、非功能需求
需求跟蹤矩陣RTM：★
需求溯源：1、往前追溯：從哪兒來，最早的需求評估（商業(yè)論證前的那個需求評估），是不是和業(yè)務(wù)目標相符合；往后追溯：這個需求有沒有開發(fā)、有沒測試、有沒有驗收、有沒有移交；2、確保每個需求都具有商業(yè)價值；3、對需求的優(yōu)先級進行排序；4、需求的可行性；
考點：驗收時有個功能不符合業(yè)務(wù)需求、漏了、沒有實現(xiàn)，PM應(yīng)該拿出需求跟蹤矩陣看看。
5.3定義范圍
重點： 輸出：項目范圍說明書的內(nèi)容★（哪些需求是項目內(nèi)的，哪些需求是項目外的）
輸入：工具與技術(shù)：產(chǎn)品分析
- 產(chǎn)品分析：就是分析當(dāng)前做的這個產(chǎn)品到底有沒有價值，它的價值最終體現(xiàn)在哪里?
輸出：項目范圍說明書★
項目范圍說明書 內(nèi)容：（核心考點：背）
項目范圍描述（漸近明細）：是要開展的工作
項目可交付成果
驗收標準
項目排除項（除外責(zé)任）：把不做的那些，都寫到這里
項目產(chǎn)品范圍：是產(chǎn)品具體的特性
假設(shè)條件
制約因素
5.4創(chuàng)建WBS（工作分解結(jié)構(gòu)）
定義：就是對可交付成果和項目工作做分解
輸出：WBS+WBS字典+范圍說明書（定義范圍的輸出）=范圍基準
輸入：
工具與技術(shù)：分解
分解：1、相關(guān)方盡可能參與，誰來分解：團隊成員（誰熟悉，誰來做分解，這樣可行性才高）；2、工作包是最底層的工作組件（沒必要再細分、工作包的詳細程度根據(jù)具體項目來定）；3、至上而下的分解；4、WBS包含了全部的產(chǎn)品和項目工作
分解實例：1、可以以項目生命周期的各階段作為第二層；2、也可以以主要可交付成果作為分解的第二層
CA控制帳戶：績效審查點；
輸出：范圍基準★
WBS: 控制帳戶（可能包括一個或多個工作包）、工作包（但是一個工作包只能屬于一個控制帳戶）、規(guī)劃包（未來很長一段時間后要做的工作）；
WBS也是一個漸近明細的工作，近期的工作詳細分解，遠期的工作先放著。
WBS是基于范圍說明書來的
WBS詞典：就是對WBS做解釋和說明（讓別人可以看懂WBS）；（解釋工作包的內(nèi)容：誰負責(zé)、什么時間完成、怎么驗收、發(fā)多少成本、要達到什么質(zhì)量要求、驗收標準）
項目范圍說明書
范圍哪里來的？-->商業(yè)文件、項目章程、需求文檔、WBS、WBS詞典、項目范圍說明書
CA--->績效（成本+進度）
5.5確認范圍
定義：就是在做驗收，驗收項目可交付成果
輸出：驗收的可交付成果★
確認范圍的說明：
時間：QC內(nèi)部檢驗后，項目收尾前
人物：★ 客戶 或 發(fā)起人
事件：★ 獲得客戶或發(fā)起人的正式驗收（書面簽字批準）
輸入：核實的可交付成果★
工具與技術(shù)：檢查、決策（投票）
- 檢查：檢查可交付成果（范圍基準）（工作有沒有開展完、可交付成果是不是滿足需求）
輸出：驗收的可交付成果★、工作績效信息、變更請求
驗收的可交付成果：給你一個清單，逐一確認簽字
工作績效信息：工作績效數(shù)據(jù)和計劃進行比較 形成 工作績效信息
變更請求：有問題發(fā)起變更（驗收過程中出現(xiàn)問題，要改，這個時候用的是缺陷補救）
5.6控制范圍
主要做的事：維護/管理范圍基準的變更；防止項目范圍潛變(蔓延)
1、不能做的：
范圍鍍金：項目成員自行添加，想提升客戶滿意度。
范圍蔓延：客戶提出變更需求，但我們沒有遵守變更控制系統(tǒng)，直接進行修改。
2、如果做了怎么辦？
范圍鍍金 立即停止 走流程 寫申請 是否涉及基準
范圍蔓延 不能立即停止 先寫審批 如果否決再停止
范圍控制在整個項目過程隨時開展
控制過程有一些常規(guī)的輸入、輸出：就是輸入工作績效數(shù)據(jù)，輸出工作績效信息。
輸入：工作績效數(shù)據(jù)
工具與技術(shù)：數(shù)據(jù)分析（偏差分析、趨勢分析）
輸出：工作績效信息、變更請求
