信息系統(tǒng)項目管理師第四版9章項目范圍管理

信息系統(tǒng)項目管理師第四版第9章項目范圍管理項目范圍管理包括確保項目做且只做所需的全部工作，以成功完成項目。項目范圍管理主要在于定義和控制哪些工作應該包括在項目內，哪些不應該包含在項目內。9.1管理基礎9.1.1產品范圍和項目范圍在項目環(huán)境中，“范圍”這一術語有兩種含義：●產品范圍：指某項產品、服務或成果所具有的特征和功能。產品范圍的完成情況是根據產品需求來衡量的?！靶枨蟆笔侵父鶕囟▍f(xié)議或其他強制性規(guī)范，產品、服務或成果必須具備的條件或能力?！耥椖糠秶喊óa品范圍，是為交付具有規(guī)定特性與功能的產品、服務或成果而必須完成的工作。項目范圍的完成情況是根據項目管理計劃來衡量的。9.1.2管理新實踐需求一直是項目管理的關注重點，需求管理過程結束于需求關閉，即把產品、服務或成果移交給接收方，以便長期測量、監(jiān)控、實現并維持收益。隨著全球項目環(huán)境變得日益復雜，項目范圍管理的新趨勢和新興實踐更加注重與商業(yè)分析師一起合作，以便：確定問題并識別商業(yè)需要；識別并推薦能夠滿足需要的可行解決方案；收集、記錄并管理干系人需求滿足商業(yè)和項目目標；推動項目集或項目產品、服務或最終成果成功應用。如果項目已配備商業(yè)分析師，該角色的職責還應包括需求管理相關的活動，項目經理則負責確保這些活動列入項目管理計劃，并且在預算內按時完成，同時能夠創(chuàng)造價值。項目經理與商業(yè)分析師之間應該是伙伴式合作關系。如果項目經理和商業(yè)分析師能夠理解彼此在促進項目目標實現過程中的角色和職責，項目成功的可能性會更大。9.2項目范圍管理過程9.2.1過程概述項目范圍管理過程包括：●規(guī)劃范圍管理：為了記錄如何定義、確認和控制項目范圍及產品范圍，創(chuàng)建范圍管理計劃?！袷占枨螅簽榱藢崿F項目目標，確定、記錄并管理干系人的需要和需求?！穸x范圍：制定項目和產品詳細描述?！駝?chuàng)建WBS:將項目可交付成果和項目工作分解為較小的、更易于管理的組件?！翊_認范圍：正式驗收已完成的項目可交付成果?！窨刂品秶罕O(jiān)督項目和產品的范圍狀態(tài)，管理范圍基準的變更。在項目實際進展中，以上各過程會相互交疊和相互作用。表9-1概括了項目范圍管理的各個過程。表9-1項目范圍管理過程9.2.2裁剪考慮因素因為每個項目都是獨特的，所以項目經理可能根據需要裁剪項目范圍管理過程。裁剪時應考慮的因素包括：●知識和需求管理：項目經理應建立哪些指南?為了在未來項目中重復使用需求，組織是否擁有正式或非正式的知識和需求管理體系?●確認和控制：組織是否有正式或非正式的與確認和控制相關政策、程序和指南?●開發(fā)方法：組織是否采用敏捷方法管理項目?開發(fā)方法屬于迭代型還是增量型?是否采用預測型方法?混合型方法是否有效?●需求的穩(wěn)定性：項目中是否存在需求不穩(wěn)定的領域?是否有必要采用精益、敏捷或其他適應型技術來處理不穩(wěn)定的需求，直至需求穩(wěn)定且定義明確?●治理：組織是否擁有正式或非正式的審計和治理政策、程序和指南?9.2.3敏捷與適應方法對于需求不斷變化、風險大或不確定性高的項目，在項目開始時通常無法明確項目的范圍，而需要在項目期間逐漸明確。敏捷或適應型方法特意在項目早期縮短定義和協(xié)商范圍的時間，為后續(xù)細化范圍、明確范圍爭取更多的時間。在許多情況下，不斷涌現的需求往往導致真實的業(yè)務需求與最初所述的業(yè)務需求之間存在差異。因此，敏捷方法有目的地構建和審查原型，并通過多次發(fā)布版本來明確需求，范圍會在整個項目期間被定義和再定義。采用敏捷或適應型生命周期，旨在應對大量變更，需要干系人持續(xù)參與項目。因此，應將適應型項目的整體范圍分解為一系列擬實現的需求和擬執(zhí)行的工作(有時稱為產品未完成項),通過多次迭代來開發(fā)可交付成果，并在每次迭代開始時定義和批準詳細的范圍。在一個迭代開始時，團隊將努力確定產品未完成項中，哪些優(yōu)先級高的未完成項需要在下一次迭代中交付。在每次迭代中，都會重復開展三個過程：①收集需求；②定義范圍；③創(chuàng)建WBS。在適應型或敏捷型生命周期中，發(fā)起人和客戶代表應該持續(xù)參與項目，并對迭代交付的可交付成果提供反饋意見，確保產品未完成項真實地反映了他們的當前需求。在每次迭代中，都會重復開展兩個過程：①確認范圍；②控制范圍。在預測型項目中，經過批準的項目范圍說明書、工作分解結構(WBS)和相應的WBS詞典構成項目范圍基準。只有通過正式變更控制程序，才能進行基準變更。在開展確認范圍、控制范圍及其他控制過程時，基準被用作比較的基礎。而采用適應型生命周期的項目，則使用未完成項(包括產品需求和用戶故事)反映當前需求。確認范圍是正式驗收已完成的項目可交付成果的過程。從控制質量過程輸出的核實的可交付成果是確認范圍過程的輸入，而驗收的可交付成果是確認范圍過程的輸出之一，由獲得授權的干系人正式簽字批準。因此，干系人需要在規(guī)劃階段早期介入(有時需要在啟動階段就介入),對可交付成果的質量提出意見，以便控制質量過程能夠據此評估績效并提出必要的變更建議。9.3規(guī)劃范圍管理規(guī)劃范圍管理是為了記錄如何定義、確認和控制項目范圍及產品范圍，而創(chuàng)建范圍管理計劃的過程。本過程的主要作用是在整個項目期間對如何管理范圍提供指南和方向。本過程僅開展一次或僅在項目的預定義點開展。規(guī)劃范圍管理過程的數據流向如圖9-1所示。圖9-1規(guī)范范圍管理過程的數據流向圖范圍管理計劃是項目或項目集管理計劃的組成部分，描述將如何定義、制定、監(jiān)督、控制和確認項目范圍。制訂范圍管理計劃和細化項目范圍始于對下列信息的分析：項目章程中的信息、項目管理計劃中已批準的子計劃、組織過程資產中的歷史信息和相關事業(yè)環(huán)境因素。9.3.1輸入1.項目章程項目章程記錄項目目的、項目概述、假設條件、制約因素，以及項目想要實現的高層級的需求。2.項目管理計劃規(guī)劃范圍管理中使用的項目管理計劃組件主要包括：●質量管理計劃：在項目中實施組織的質量政策、方法和標準的方式會影響管理項目和產品范圍的方式?！耥椖可芷诿枋觯憾x了項目從開始到完成所經歷的一系列階段?！耖_發(fā)方法：開發(fā)方法定義了項目是采用預測型、適應型還是混合型開發(fā)方法。3.事業(yè)環(huán)境因素能夠影響規(guī)劃范圍管理過程的事業(yè)環(huán)境因素主要包括：組織文化、基礎設施、人事管理制度和市場條件等。4.組織過程資產能夠影響規(guī)劃范圍管理過程的組織過程資產主要包括：政策和程序、歷史信息和經驗教訓知識庫等。9.3.2工具與技術1.專家判斷規(guī)劃范圍管理過程中，應征求具備如下領域相關專業(yè)知識或接受過相關培訓的個人或小組的意見，涉及的領域包括：以往類似項目；特定行業(yè)、學科和應用領域的信息等。2.數據分析適用于本過程的數據分析技術是備選方案分析。備選方案分析技術用于評估、收集需求，詳述項目和產品范圍，創(chuàng)造產品，確認范圍和控制范圍的各種方法。3.會議項目團隊可參加項目會議來制訂范圍管理計劃。參會者包括項目經理、項目發(fā)起人、選定的項目團隊成員、選定的干系人、范圍管理各過程的負責人以及其他必要人員。9.3.3輸出1.范圍管理計劃范圍管理計劃是項目管理計劃的組成部分，描述將如何定義、制定、監(jiān)督、控制和確認項目范圍。范圍管理計劃用于指導如下過程和相關工作：①制定項目范圍說明書；②根據詳細項目范圍說明書創(chuàng)建WBS;③確定如何審批和維護范圍基準；④正式驗收已完成的項目可交付成果。根據項目需要，范圍管理計劃可以是正式或非正式的，非常詳細或高度概括的。2.需求管理計劃需求管理計劃是項目管理計劃的組成部分，描述如何分析、記錄和管理需求。需求管理計劃的主要內容包括：①如何規(guī)劃、跟蹤和報告各種需求活動；②配置管理活動，例如，如何啟動變更，如何分析其影響，如何進行追溯、跟蹤和報告，以及變更審批權限；③需求優(yōu)先級排序過程；④測量指標及使用這些指標的理由；⑤反映哪些需求屬性將被列入跟蹤矩陣等。9.4收集需求收集需求是為實現目標而確定，記錄并管理干系人的需要和需求的過程。本過程的主要作用是為定義產品范圍和項目范圍奠定基礎。本過程僅開展一次或僅在項目的預定義點開展。收集需求過程的數據流向如圖9-2所示。圖9-2收集需求過程的數據流向圖讓干系人積極參與需求的探索和分解工作(分解成項目和產品需求),并仔細確定、記錄和管理對產品、服務或成果的需求，能直接促進項目成功。需求是指根據特定協(xié)議或其他強制性規(guī)范，產品、服務或成果必須具備的條件或能力。它包括發(fā)起人、客戶和其他干系人的已量化且書面記錄的需要和期望。應該足夠詳細地挖掘、分析和記錄這些需求，并將其包含在范圍基準中，在項目執(zhí)行開始后對其進行測量。需求將作為后續(xù)工作分解結構(WBS)的基礎，也將作為成本、進度、質量和采購規(guī)劃的基礎。9.4.1輸入1.立項管理文件會影響收集需求過程的立項管理文件是商業(yè)論證產生的文件，它描述了為滿足業(yè)務需要而應該達到的必要、期望及可選標準。2.項目章程項目章程記錄了項目概述以及將用于制定詳細需求的高層級需求。3.項目管理計劃收集需求中使用的項目管理計劃組件包括：●范圍管理計劃：包含如何定義和制定項目范圍的信息?！裥枨蠊芾碛媱潱喊绾问占⒎治龊陀涗涰椖啃枨蟮男畔?。●干系人參與計劃：從該計劃中了解干系人的溝通需求和參與程度，以便評估并適應干系人對需求活動的參與程度。4.項目文件可作為收集需求過程輸入的項目文件主要包括：●假設日志：識別了有關產品、項目、環(huán)境、干系人以及會影響需求的其他因素的假設條件?！窀上等说怯泝裕河糜诹私饽男└上等四軌蛱峁┬枨蠓矫娴男畔?，及記錄干系人對項目的需求和期望?！窠涷灲逃柕怯泝裕禾峁┝擞行У男枨笫占夹g，尤其針對使用敏捷或適應型產品開發(fā)方法的項目。5.協(xié)議協(xié)議會包含項目和產品需求。6.事業(yè)環(huán)境因素會影響收集需求過程的事業(yè)環(huán)境因素主要包括：組織文化、基礎設施、人事管理制度、市場條件等。7.組織過程資產會影響收集需求過程的組織過程資產主要包括：政策和程序；包含以往項目信息的歷史信息和經驗教訓知識庫等。9.4.2工具與技術1.專家判斷收集需求過程中，應征求具備如下領域相關專業(yè)知識或接受過相關培訓的個人或小組的意見，涉及的領域包括：可行性研究與評估；需求獲取；需求分析；需求文件；以往類似項目的項目需求；圖解技術；引導；沖突管理等。2.數據收集可用于收集需求過程的數據收集技術主要包括：●頭腦風暴：是一種用來產生和收集對項目需求與產品需求的多種創(chuàng)意的技術?！裨L談：是通過與干系人直接交談，來獲取信息的正式或非正式的方法。訪談的典型做法是向被訪者提出預設和即興的問題，并記錄他們的回答。訪談經常是一個訪談者和一個被訪者之間的“一對一”談話，但也可包括多個訪談者或多個被訪者。訪談有經驗的項目參與者、發(fā)起人和其他高管及主題專家，有助于識別和定義所需產品可交付成果的特征和功能。訪談也可用于獲取機密信息?！窠裹c小組：是召集預定的干系人和主題專家，了解他們對所討論的產品、服務或成果的期望和態(tài)度。由一位受過訓練的主持人引導大家進行互動式討論。焦點小組往往比“一對一”的訪談更熱烈?！駟柧碚{查：是指設計一系列書面問題，向眾多受訪者快速收集信息。問卷調查方法非常適用于受眾多樣化，需要快速完成調查，受訪者地理位置分散并且適合開展統(tǒng)計分析的情況?！駱藯U對照：將實際或計劃的產品、過程和實踐，與其他可比組織的實踐進行比較，以便識別最佳實踐，形成改進意見，并為績效考核提供依據。標桿對照所采用的可比組織可以是內部的，也可以是外部的。3.數據分析可用于收集需求過程的數據分析技術是文件分析。文件分析指審核和評估任何相關的文件信息。在此過程中，文件分析用于通過分析現有文件，識別與需求相關的信息來獲取需求，可供分析并有助于獲取需求的文件包括：協(xié)議；商業(yè)計劃；業(yè)務流程或接口文檔；業(yè)務規(guī)則庫；現行流程；市場文獻；問題日志；政策和程序、法規(guī)文件，如法律、準則、法令等；建議邀請書；用例等。4.決策適用于收集需求過程的決策技術主要包括：●投票：是一種為達成某種期望結果，而對未來多個行動方案進行評估的決策技術和過程。本技術用于生成、歸類和排序產品需求?！癃毑眯蜎Q策制定：采用這種方法，將由一個人負責為整個集體制定決策?！穸鄻藴蕸Q策分析：該技術借助決策矩陣，用系統(tǒng)分析方法建立諸如風險水平、不確定性和價值收益等多種標準，以對眾多創(chuàng)意進行評估和排序。5.數據表現可用于收集需求過程的數據表現技術主要包括：●親和圖：用來對大量創(chuàng)意進行分組的技術，以便進一步審查和分析。●思維導圖：把從頭腦風暴中獲得的創(chuàng)意整合成一張圖，用以反映創(chuàng)意之間的共性與差異，激發(fā)新創(chuàng)意。6.人際關系與團隊技能可用于收集需求過程的人際關系與團隊技能主要包括：●名義小組技術：是用于促進頭腦風暴的一種技術，通過投票排列最有用的創(chuàng)意，以便進一步開展頭腦風暴或優(yōu)先排序。名義小組技術是一種結構化的頭腦風暴形式，由四個步驟組成：①向集體提出一個問題或難題，每個人在沉思后寫出自己的想法；②主持人在活動掛圖上記錄所有人的想法；③集體討論各個想法，直到全體成員達成一個明確的共識；④個人私下投票決出各種想法的優(yōu)先排序，通常采用5分制，1分最低，5分最高。為減少想法數量、集中關注想法，可進行數輪投票。每輪投票后，都將清點選票，得分最高者被選出?！裼^察和交談：是指直接察看個人在各自的環(huán)境中如何執(zhí)行工作(或任務)和實施流程。當產品使用者難以或不愿清晰說明他們的需求時，特別需要通過觀察來了解他們的工作細節(jié)。觀察也稱為“工作跟隨”,通常由旁站觀察者觀察業(yè)務專家如何執(zhí)行工作，但也可以由“參與觀察者”來觀察，通過實際執(zhí)行一個流程或程序，來體驗該流程或程序是如何實施的，以便挖掘隱藏的需求?！褚龑В阂龑c主題研討會結合使用，把主要干系人召集在一起定義產品需求。研討會可用于快速定義跨職能需求并協(xié)調干系人的需求差異。因為具有群體互動的特點，有效引導的研討會有助于參與者之間建立信任、改進關系、改善溝通，從而有利于干系人達成一致意見。此外，與分別召開會議相比，研討會能夠更早發(fā)現并解決問題。7.系統(tǒng)交互圖系統(tǒng)交互圖是對產品范圍的可視化描繪，可以直觀顯示業(yè)務系統(tǒng)(過程、設備、計算機系統(tǒng)等)及其與人和其他系統(tǒng)(行動者)之間的交互方式。8.原型法原型法是指在實際制造預期產品之前，先造出該產品的模型，并據此征求對需求的早期反饋。原型包括微縮產品、計算機生成的二維和三維模型、實體模型或模擬。因為原型是有形的實物，它使得干系人可以體驗最終產品的模型，而不是僅限于討論抽象的需求描述。原型法支持漸進明細的理念，需要經歷從模型創(chuàng)建、用戶體驗、反饋收集到原型修改的反復循環(huán)過程。在經過足夠的反饋循環(huán)之后，就可以通過原型獲得足夠的需求信息，從而進入設計或制造階段。故事板是一種原型技術，通過一系列的圖像或圖示來展示順序或導航路徑。故事板用于各種行業(yè)的各種項目中，如電影、廣告、教學設計以及敏捷和其他軟件開發(fā)項目。在軟件開發(fā)中，故事板使用實體模型來展示網頁、屏幕或其他用戶界面的導航路徑。9.4.3輸出1.需求文件需求文件描述各種單一需求將如何滿足項目相關的業(yè)務需求。一開始可能只有高層級的需求，然后隨著有關需求信息的增加而逐步細化。只有明確的(可測量和可測試的)、可跟蹤的、完整的、相互協(xié)調的，且主要干系人愿意認可的需求，才能作為基準。需求文件的格式多種多樣，既可以是一份按干系人和優(yōu)先級分類列出全部需求的簡單文件，也可以是一份包括內容提要、細節(jié)描述和附件等的詳細文件。許多組織把需求分為不同的種類，如業(yè)務解決方案和技術解決方案。前者是干系人的需要，后者是指如何實現這些干系人需要的方案。把需求分成不同的類別，有利于對需求進行進一步完善和細化。需求的類別一般包括：(1)業(yè)務需求：整個組織的高層級需要，例如，解決業(yè)務問題或抓住業(yè)務機會，以及實施項目的原因。(2)干系人需求：干系人的需要。(3)解決方案需求：為滿足業(yè)務需求和干系人需求，產品、服務或成果必須具備的特性、功能和特征。解決方案需求又進一步分為功能需求和非功能需求：①功能需求：描述產品應具備的功能，例如，產品應該執(zhí)行的行動、流程、數據和交互；②非功能需求：是對功能需求的補充，是產品正常運行所需的環(huán)境條件或質量要求，例如，可靠性、保密性、性能、安全性、服務水平、可支持性、保留或清除等。(4)過渡和就緒需求：如數據轉換和培訓需求。這些需求描述了從“當前狀態(tài)”過渡到“將來狀態(tài)”所需的臨時能力。(5)項目需求：項目需要滿足的行動、過程或其他條件，例如里程碑日期、合同責任、制約因素等。(6)質量需求：用于確認項目可交付成果的成功完成或其他項目需求的實現的任何條件或標準，例如，測試、認證、確認等。2.需求跟蹤矩陣需求跟蹤矩陣是把產品需求從其來源連接到能滿足需求的可交付成果的一種表格。使用需求跟蹤矩陣，把每個需求與業(yè)務目標或項目目標聯(lián)系起來，有助于確保每個需求都具有業(yè)務價值。需求跟蹤矩陣提供了在整個項目生命周期中跟蹤需求的一種方法，有助于確保需求文件中被批準的每項需求在項目結束的時候都能實現并交付。最后，需求跟蹤矩陣還為管理產品范圍變更提供了框架。跟蹤需求的內容包括：①業(yè)務需要、機會、目的和目標；②項目目標；③項目范圍和WBS可交付成果；④產品設計；⑤產品開發(fā)；⑥測試策略和測試場景；⑦高層級需求到詳細需求等。應在需求跟蹤矩陣中記錄每個需求的相關屬性，這些屬性有助于明確每個需求的關鍵信息。需求蹤矩陣中記錄的典型屬性包括唯一標識、需求的文字描述、收錄該需求的理由、所有者、來源、優(yōu)先級別、版本、當前狀態(tài)和狀態(tài)日期。為確保干系人滿意，可能需要增加一些補充屬性，如穩(wěn)定性、復雜性和驗收標準。需求跟蹤矩陣示例如圖9-3所示。圖9-3需求跟蹤矩陣示例9.5定義范圍定義范圍是制定項目和產品詳細描述的過程。本過程的主要作用是描述產品、服務或成果的邊界和驗收標準。本過程需要在整個項目期間多次反復開展。定義范圍過程的數據流向如圖9-4所示。圖9-4定義范圍過程的數據流向圖由于在收集需求過程中識別出的所有需求未必都包含在項目中，所以定義范圍過程需要從需求文件(收集需求過程的輸出)中選取最終的項目需求，然后制定出關于項目及其產品、服務或成果的詳細描述。準備好詳細項目范圍說明書，對項目成功至關重要。應根據項目啟動過程中記載的主要可交付成果、假設條件和制約因素來編制詳細的項目范圍說明書。在項目規(guī)劃過程中，隨著對項目信息了解的逐漸深入，應該更加詳細、具體地定義和描述項目范圍。此外，還需要分析現有風險、假設條件和制約因素的完整性，并做必要的增補或更新。9.5.1輸入1.項目章程項目章程中包含對項目的高層級描述、產品特征和審批要求。2.項目管理計劃定義范圍中使用的項目管理計劃組件是范圍管理計劃，其中記錄了如何定義、確認和控制項目范圍。3.項目文件可作為定義范圍過程輸入的項目文件主要包括：●假設日志：識別了有關產品、項目、環(huán)境、干系人以及會影響項目和產品范圍的假設條件和制約因素?！裥枨笪募鹤R別了應納入范圍的需求?！耧L險登記冊：包含了可能影響項目范圍的應對策略，例如縮小或改變項目和產品范圍，以規(guī)避或緩解風險。4.事業(yè)環(huán)境因素會影響定義范圍過程的事業(yè)環(huán)境因素主要包括：組織文化、基礎設施、人事管理制度、市場條件等。5.組織過程資產能夠影響定義范圍過程的組織過程資產主要包括：用于制定項目范圍說明書的政策、程序和模板；以往項目的項目檔案；以往階段或項目的經驗教訓等。9.5.2工具與技術1.專家判斷定義范圍過程中，應征求具備類似項目的知識或經驗的個人或小組的意見。2.數據分析可用于定義范圍過程的數據分析技術是備選方案分析。備選方案分析可用于評估實現項目章程中所述的需求和目標的各種方法。3.決策可用于定義范圍過程的決策技術是多標準決策分析。多標準決策分析是一種借助決策矩陣來使用系統(tǒng)分析方法的技術，目的是建立諸如需求、進度、預算和資源等多種標準來完善項目和產品范圍。4.人際關系與團隊技能人際關系與團隊技能的一個典型示例是引導。在研討會和座談會中使用引導技能來協(xié)調具有不同期望或不同專業(yè)知識的關鍵干系人，使他們就項目可交付成果以及項目和產品邊界達成跨職能的共識。5.產品分析產品分析可用于定義產品和服務，包括針對產品或服務提問并回答，以描述要交付產品的用途、特征及其他方面。每個應用領域都有一種或幾種普遍公認的方法，用以把高層級的產品或服務描述轉變?yōu)橛幸饬x的可交付成果。首先獲取高層級的需求，然后將其細化到最終產品設計所需的詳細程度。產品分析技術主要包括：產品分解、需求分析、系統(tǒng)分析、系統(tǒng)工程、價值分析、價值工程等。9.5.3輸出1.項目范圍說明書項目范圍說明書是對項目范圍、主要可交付成果、假設條件和制約因素的描述。它記錄了整個范圍，包括：項目和產品范圍；詳細描述了項目的可交付成果；代表項目干系人之間就項目范圍所達成的共識。為便于管理干系人的期望，項目范圍說明書可明確指出哪些工作不屬于本項目范圍。項目范圍說明書幫助項目團隊進行更詳細的規(guī)劃，在執(zhí)行過程中指導項目團隊工作，并為評價變更請求或額外工作是否超過項目邊界提供基準。項目范圍說明書描述要做和不要做的工作的詳細程度，決定著項目管理團隊控制整個項目范圍的有效程度。詳細的項目范圍說明書包括內容有(直接列出或參引其他文件):●產品范圍描述：逐步細化在項目章程和需求文件中所述的產品、服務或成果特征?！窨山桓冻晒簽橥瓿赡骋贿^程、階段或項目而必須產出的任何獨特并可核實的產品、成果或服務能力，可交付成果也包括各種輔助成果，如項目管理報告和文件。對可交付成果的描述可略可詳。●驗收標準：可交付成果通過驗收前必須滿足的一系列條件?！耥椖康某庳熑危鹤R別排除在項目之外的內容。明確說明哪些內容不屬于項目范圍，有助于管理干系人的期望及減少范圍蔓延。雖然項目章程和項目范圍說明書的內容存在一定程度的重疊，但它們的詳細程度完全不同。項目章程包含高層級的信息，而項目范圍說明書則是對范圍組成部分的詳細描述，這些組成部分需要在項目過程中漸進明細。2.項目文件(更新)可在定義范圍過程更新的項目文件包括：●假設日志：隨同本過程識別出更多的假設條件或制約因素，從而更新假設日志?！裥枨笪募嚎梢酝ㄟ^增加或修改需求而更新需求文件?！裥枨蟾櫨仃嚕簯撾S同需求文件的更新而更新需求跟蹤矩陣?！窀上等说怯泝裕喝绻诙x范圍過程中收集到了現有或新干系人的更多信息，則記錄到干系人登記冊中。9.6創(chuàng)建WBS創(chuàng)建工作分解結構(WBS)是把項目可交付成果和項目工作分解成較小、更易于管理的組件的過程。本過程的主要作用是為所要交付的內容提供架構。它僅開展一次或僅在項目的預定義點開展。創(chuàng)建WBS過程的數據流向如圖9-5所示。圖9-5創(chuàng)建WBS過程的數據流向圖WBS是對項目團隊為實現項目目標，創(chuàng)建所需可交付成果而需要實施的全部工作范圍的層級分解。WBS組織并定義了項目的總范圍，代表著經批準的當前項目范圍說明書中所規(guī)定的工作。WBS最低層的組成部分稱為工作包，其中包括計劃的工作。工作包對相關活動進行歸類，以便對工作安排進度，進行估算，開展監(jiān)督與控制。在“工作分解結構”這個詞語中，“工作”是指作為活動結果的工作產品或可交付成果，而不是活動本身。9.6.1輸入1.項目管理計劃創(chuàng)建WBS中使用的項目管理計劃組件是范圍管理計劃。范圍管理計劃定義了如何根據項目范圍說明書創(chuàng)建WBS。2.項目文件可作為創(chuàng)建WBS過程輸入的項目文件主要包括：●需求文件：詳細描述了各種單一需求如何滿足項目的業(yè)務需要?！耥椖糠秶f明書：描述了需要實施的工作以及不包含在項目中的工作。3.事業(yè)環(huán)境因素會影響創(chuàng)建WBS過程的事業(yè)環(huán)境因素包括項目所在行業(yè)的WBS標準，這些標準可以作為創(chuàng)建WBS的外部參考資料。4.組織過程資產能夠影響創(chuàng)建WBS過程的組織過程資產主要包括：用于創(chuàng)建WBS的政策、程序和模板；以往項目的項目檔案；以往項目的經驗教訓等。9.6.2工具與技術1.專家判斷創(chuàng)建WBS過程中，應征求具備類似項目知識或經驗的個人或小組的意見。2.分解分解是一種把項目范圍和項目可交付成果逐步劃分為更小、更便于管理的組成部分的技術。工作包是WBS最低層的工作，可對其成本和持續(xù)時間進行估算和管理。分解的程度取決于所需的控制程度，以實現對項目的高效管理。工作包的詳細程度則因項目規(guī)模和復雜程度而異。創(chuàng)建WBS的方法多種多樣，常用的方法包括自上而下的方法、使用組織特定的指南和使用WBS模板。自下而上的方法可用于歸并較低層次的組件。1)分解活動要把整個項目工作分解為工作包，通常需要開展如下活動：①識別和分析可交付成果及相關工作；②確定WBS的結構和編排方法；③自上而下逐層細化分解；④為WBS組成部分制定和分配標識編碼；⑤核實可交付成果分解的程度是否恰當。如圖9-6所示，某工作分解結構的一部分，若干分支已經向下分解到工作包層次。圖9-6分解到工作包的WBS示例2)WBS結構WBS的結構可以采用多種形式：●以項目生命周期的各階段作為分解的第二層，把產品和項目可交付成果放在第三層，如圖9-7所示。圖9-7以階段作為第二層WBS示例●以主要可交付成果作為分解的第二層，如圖9-8所示。圖9-8以主要可交付成果作為第二層的WBS示例●納入由項目團隊以外的組織開發(fā)的各種較低層次組件(如外包工作)。隨后，作為外包工作的一部分，賣方須制定相應的合同WBS。對WBS較高層組件進行分解，就是要把每個可交付成果或組件分解為最基本的組成部分，即可核實的產品、服務或成果。如果采用敏捷或適應型方法，可以將長篇故事分解成用戶故事。WBS可以采用提綱式、組織結構圖或能說明層級結構的其他形式。確認WBS較低層組件是完成上層相應可交付成果的必要且充分的工作，以此來核實分解的正確性。不同的可交付成果可以分解到不同的層次。某些可交付成果只需分解到下一層，即可到達工作包的層次，而另一些則須分解更多層。工作分解得越細致，對工作的規(guī)劃、管理和控制就越有力。但是，過細的分解會造成管理努力的無效耗費、資源使用效率低下、工作實施效率降低，同時造成WBS各層級的數據匯總困難。要在未來遠期才完成的可交付成果或組件，當前可能無法分解。項目管理團隊因而通常需要等待對該可交付成果或組成部分達成一致意見，才能夠制定出WBS中的相應細節(jié)。這種技術又稱為滾動式規(guī)劃。3)注意事項在分解的過程中，應該注意以下8個方面?！馱BS必須是面向可交付成果的：項目的目標是提供產品或服務，WBS中的各項工作是為提供可交付的成果服務的。WBS并沒有明確地要求重復循環(huán)的工作，但為了達到里程碑，有些工作可能要進行多次。最明顯的例子是軟件測試，軟件必須經過多次測試后才能作為可交付成果?！馱BS必須符合項目的范圍：WBS必須包括也僅包括為了完成項目的可交付成果的活動。100%原則(包含原則)認為，在WBS中，所有下一級的元素之和必須100%代表上一級的元素。如果WBS沒有覆蓋全部的項目可交付成果，那么最后提交的產品或服務是無法讓用戶滿意的?！馱BS的底層應該支持計劃和控制：WBS是項目管理計劃和項目范圍之間的橋梁，WBS的底層不但要支持項目管理計劃，而且要讓管理層能夠監(jiān)視和控制項目的進度和預算?！馱BS中的元素必須有人負責，而且只有一個人負責：如果存在沒有人負責的內容，那么WBS發(fā)布后，項目團隊成員將很少能夠意識到自己和其中內容上的聯(lián)系。WBS和責任人可以使用工作責任矩陣來描述。在一些參考文獻中，這個規(guī)定又稱為獨立責任原則?！馱BS應控制在4～6層：如果項目規(guī)模比較大，以至于WBS要超過6層，此時，可以使用項目分解結構將大項目分解成子項目，然后針對子項目來做WBS。每個級別的WBS將上一級的一個元素分為4～7個新元素，同一級元素的大小應該相似。一個工作單元只能從屬于某個上層單元，避免交叉從屬?！馱BS應包括項目管理工作(因為管理是項目具體工作的一部分),也要包括分包出去的工作?！馱BS的編制需要所有(主要)項目干系人的參與：各項目干系人站在自己的立場上，對同一個項目可能編制出差別較大的WBS。項目經理應該組織他們進行討論，以便編制出一份大家都能接受的WBS?！馱BS并非是一成不變的：在完成了WBS之后的工作中，仍然有可能需要對WBS進行修改。如果沒有合理的范圍控制，僅僅依靠WBS會使得后面的工作僵化。9.6.3輸出1.范圍基準范圍基準是經過批準的范圍說明書、WBS和相應的WBS詞典，只有通過正式的變更控制程序才能進行變更，它被用作比較的基礎。范圍基準是項目管理計劃的組成部分。1)項目范圍說明書項目范圍說明書包括對項目范圍、主要可交付成果、假設條件和制約因素的描述。2)WBSWBS是對項目團隊為實現項目目標、創(chuàng)建所需可交付成果而需要實施的全部工作范圍的層級分解。工作分解結構每向下分解一層，代表對項目工作更詳細的定義。3)工作包WBS的最低層是帶有獨特標識號的工作包。這些標識號為成本、進度和資源信息的逐層匯總提供了層級結構，即賬戶編碼。每個工作包都是控制賬戶的一部分，而控制賬戶則是一個管理控制點。在該控制點上，把范圍、預算和進度加以整合，并與掙值相比較來測量績效?？刂瀑~戶包含兩個或更多工作包，每個工作包只與一個控制賬戶關聯(lián)。4)規(guī)劃包規(guī)劃包是一種低于控制賬戶而高于工作包的工作分解結構組件，工作內容已知，但詳細的進度活動未知，一個控制賬戶可以包含一個或多個規(guī)劃包。5)WBS字典WBS字典是針對WBS中的每個組件，詳細描述可交付成果、活動和進度信息的文件。WBS字典對WBS提供支持，其中大部分信息由其他過程創(chuàng)建，然后在后期添加到字典中。WBS字典中的內容一般包括：賬戶編碼標識、工作描述、假設條件和制約因素、負責的組織、進度里程碑、相關的進度活動、所需資源、成本估算、質量要求、驗收標準、技術參考文獻、協(xié)議信息等。2.項目文件(更新)可在創(chuàng)建WBS過程更新的項目文件主要包括：●假設日志：隨著創(chuàng)建WBS過程識別出更多假設條件或制約因素而更新?！裥枨笪募嚎梢愿滦枨笪募?，以反映在創(chuàng)建WBS過程提出并已被批準的變更。9.7確認范圍確認范圍是正式驗收已完成的項目可交付成果的過程。本過程的主要作用：①使驗收過程具有客觀性；②通過確認每個可交付成果來提高最終產品、服務或成果獲得驗收的可能性。確認范圍過程應根據需要在整個項目期間定期開展。確認范圍過程的數據流向如圖9-9所示。圖9-9確認范圍過程的數據流向圖由主要干系人，尤其是客戶或發(fā)起人審查從控制質量過程輸出的核實的可交付成果，確認這些可交付成果已經圓滿完成并通過正式驗收。確認范圍過程依據從項目范圍管理知識領域的相應過程獲得的輸出(如需求文件或范圍基準),以及從其他知識領域的執(zhí)行過程獲得的工作績效數據，對可交付成果的確認和最終驗收。1.確認范圍的步驟確認范圍應該貫穿項目的始終。如果是在項目的各個階段對項目的范圍進行確認工作，則還要考慮如何通過項目協(xié)調來降低項目范圍改變的頻率，以保證項目范圍的改變是有效率和適時的。確認范圍的一般步驟包括：①確定需要進行范圍確認的時間；②識別范圍確認需要哪些投入；③確定范圍正式被接受的標準和要素；④確定范圍確認會議的組織步驟；⑤組織范圍確認會議。通常情況下，在確認范圍前，項目團隊需要先進行質量控制工作，例如，在確認軟件項目的范圍之前，需要進行系統(tǒng)測試等工作，以確保確認工作的順利完成。確認范圍過程與控制質量過程的不同之處在于，前者關注可交付成果的驗收，而后者關注可交付成果的正確性及是否滿足質量要求?？刂瀑|量過程通常先于確認范圍過程，但二者也可同時進行。2.需要檢查的問題項目干系人進行范圍確認時，一般需要檢查以下6個方面的問題：●可交付成果是否是確定的、可確認的?！衩總€可交付成果是否有明確的里程碑，里程碑是否有明確的、可辨別的事件，例如，客戶的書面認可等?！袷欠裼忻鞔_的質量標準：可交付成果的交付不但要有明確的標準標志，而且要有是否按照要求完成的標準，可交付成果和其標準之間是否有明確聯(lián)系。●審核和承諾是否有清晰的表達：項目發(fā)起人必須正式同意項目的邊界，項目完成的產品或者服務，以及項目相關的可交付成果。項目團隊必須清楚地了解可交付成果是什么。所有的這些表達必須清晰，并取得一致的同意。●項目范圍是否覆蓋了需要完成的產品或服務的所有活動，有沒有遺漏或錯誤?！耥椖糠秶娘L險是否太高：管理層是否能夠降低風險發(fā)生時對項目的影響。3.干系人關注點的不同確認范圍主要是項目干系人(例如，客戶、發(fā)起人等)對項目的范圍進行確認和接受的工作，每個人對項目范圍所關注的方面是不同的：●管理層主要關注項目范圍：是指范圍對項目的進度、資金和資源的影響，這些因素是否超過了組織承受范圍，是否在投入產出上具有合理性。在確認范圍工作進行之后，管理層可能會取消該項目，可能是因為項目范圍太大，造成對時間、資金和資源的占有遠遠大于管理層的預計或者組織的承受能力。更多的情況是要求項目團隊壓縮范圍以滿足進度、資金和資源的限制?！窨蛻糁饕P注產品范圍：關心項目的可交付成果是否足夠完成產品或服務。有些項目的產品經理就是客戶，這種情況下，可減少項目團隊對產品理解失誤的可能性，降低項目的風險。在項目中，客戶往往有在當前版本中加入所有功能和特征的意愿，這對于項目來說是一種潛在的風險，會給組織和客戶帶來危害和損失?！耥椖抗芾砣藛T主要關注項目制約因素：關心項目可交付成果是否足夠和必須完成，時間、資金和資源是否足夠，主要的潛在風險和預備解決的方法?！耥椖繄F隊成員主要關注項目范圍中自己參與的元素和負責的元素：通過定義范圍中的時間檢查自己的工作時間是否足夠，自己在項目范圍中是否有多項工作，而這些工作是否有沖突的地方。如果項目團隊成員估計某些可交付成果無法在確定的時間完成，需要提出自己的意見。9.7.1輸入1.項目管理計劃確認范圍中使用的項目管理計劃組件主要包括：●范圍管理計劃：定義了如何正式驗收已經完成的可交付成果。●需求管理計劃：描述了如何確認項目需求。●范圍基準：用范圍基準與實際結果比較，以決定是否有必要進行變更、采取糾正措施或預防措施。2.項目文件可作為確認范圍過程輸入的項目文件主要包括：●需求文件：將需求與實際結果比較，以決定是否有必要進行變更，采取糾正措施或預防措施?！裥枨蟾櫨仃嚕汉信c需求相關的信息，包括如何確認需求?！褓|量報告：該報告內容可包括由團隊管理或需上報的全部質量保證事項、改進建議，以及在控制質量過程中發(fā)現的情況的概述。在驗收產品之前，需要查看所有這些內容。●經驗教訓登記冊：在項目早期獲得的經驗教訓可以運用到后期階段，以提高驗收可交付成果的效率與效果。3.工作績效數據工作績效數據可能包括符合需求的程度、不一致的數量、不一致的嚴重性或在某時間段內開展確認的次數。4.核實的可交付成果核實的可交付成果是指已經完成，并被控制質量過程檢查為正確的可交付成果。9.7.2工具與技術1.檢查檢查是指開展測量、審查與確認等活動，來判斷工作和可交付成果是否符合需求和產品驗收標準。檢查有時也被稱為審查、產品審查和巡檢等。2.決策可用于確認范圍過程的決策技術是投票，當由項目團隊和其他干系人進行驗收時，使用投票來形成結論。9.7.3輸出1.驗收的可交付成果符合驗收標準的可交付成果應該由客戶或發(fā)起人正式簽字批準。應該從客戶或發(fā)起人那里獲得正式文件，證明干系人對項目可交付成果的正式驗收。這些文件將提交給結束項目或階段過程。2.變更請求對已經完成但未通過正式驗收的可交付成果及其未通過驗收的原因，應該記錄在案?？赡苄枰槍@些可交付成果提出變更請求，開展相應的缺陷補救工作。變更請求應該由實施整體變更控制過程進行審查與處理。3.工作績效信息工作績效信息包括項目進展信息，例如，哪些可交付成果已經被驗收，哪些未通過驗收以及原因。這些信息應該被記錄下來并傳遞給干系人。4.項目文件(更新)可在確認范圍過程更新的項目文件主要包括：●需求文件：記錄實際的驗收結果，更新需求文件。需要特別注意實際結果比原定需求更好的情況，或者原定需求已經被放棄的情況?！裥枨蟾櫨仃嚕焊鶕炇战Y果更新需求跟蹤矩陣，包括所采用的驗收方法及其使用結果。●經驗教訓登記冊：更新經驗教訓登記冊，以記錄所遇到的挑戰(zhàn)、本應如何避免該挑戰(zhàn)的方法，以及良好的可交付成果驗收的方法。1.項目范圍說明書項目范圍說明書是對項目范圍、主要可交付成果、假設條件和制約因素的描述。它記錄了整個范圍，包括：項目和產品范圍；詳細描述了項目的可交付成果；代表項目干系人之間就項目范圍所達成的共識。為便于管理干系人的期望，項目范圍說明書可明確指出哪些工作不屬于本項目范圍。項目范圍說明書幫助項目團隊進行更詳細的規(guī)劃，在執(zhí)行過程中指導項目團隊工作，并為評價變更請求或額外工作是否超過項目邊界提供基準。項目范圍說明書描述要做和不要做的工作的詳細程度，決定著項目管理團隊控制整個項目范圍的有效程度。詳細的項目范圍說明書包括內容有(直接列出或參引其他文件):●產品范圍描述：逐步細化在項目章程和需求文件中所述的產品、服務或成果特征。●可交付成果：為完成某一過程、階段或項目而必須產出的任何獨特并可核實的產品、成果或服務能力，可交付成果也包括各種輔助成果，如項目管理報告和文件。對可交付成果的描述可略可詳?！耱炇諛藴剩嚎山桓冻晒ㄟ^驗收前必須滿足的一系列條件?！耥椖康某庳熑危鹤R別排除在項目之外的內容。明確說明哪些內容不屬于項目范圍，有助于管理干系人的期望及減少范圍蔓延。雖然項目章程和項目范圍說明書的內容存在一定程度的重疊，但它們的詳細程度完全不同。項目章程包含高層級的信息，而項目范圍說明書則是對范圍組成部分的詳細描述，這些組成部分需要在項目過程中漸進明細。2.項目文件(更新)可在定義范圍過程更新的項目文件包括：●假設日志：隨同本過程識別出更多的假設條件或制約因素，從而更新假設日志?！裥枨笪募嚎梢酝ㄟ^增加或修改需求而更新需求文件。●需求跟蹤矩陣：應該隨同需求文件的更新而更新需求跟蹤矩陣?！窀上等说怯泝裕喝绻诙x范圍過程中收集到了現有或新干系人的更多信息，則記錄到干系人登記冊中。9.8控制范圍控制范圍是監(jiān)督項目和產品的范圍狀態(tài)，管理范圍基準變更的過程。本過程的主要作用是在整個項目期間保持對范圍基準的維護。本過程需要在整個項目期間開展?？刂品秶^程的數據流向如圖9-10所示。圖9-10控制范圍過程的數據流向圖控制項目范圍確保所有變更請求、推薦的糾正措施或預防措施都通過實施整體變更控制過程進行處理。在變更實際發(fā)生時，也需要采用控制范圍過程來管理這些變更。控制范圍過程應該與其他項目管理知識領域的控制過程協(xié)調開展。未經控制的產品或項目范圍的擴大(未對時間、成本和資源做相應調整)被稱為范圍蔓延。9.8.1輸入1.項目管理計劃控制范圍中使用的項目管理計劃組件主要包括：●范圍管理計劃：記錄了如何控制項目和產品范圍?！裥枨蠊芾碛媱潱河涗浟巳绾喂芾眄椖啃枨??！褡兏芾碛媱潱憾x了管理項目變更的過程?！衽渲霉芾碛媱潱憾x了哪些是配置項，哪些配置項需要正式變更控制，以及針對這些配置項的變更控制過程?！穹秶鶞剩河梅秶鶞逝c實際結果比較，以決定是否有必要進行變更、采取糾正措施或預防措施。●績效測量基準：使用掙值分析時，將績效測量基準與實際結果比較，以決定是否有必要進行變更、采取糾正措施或預防措施。2.項目文件可作為控制范圍過程輸入的項目文件主要包括：●需求文件：用于發(fā)現任何對商定的項目或產品范圍的偏離。●需求跟蹤矩陣：有助于探查任何變更或對范圍基準的任何偏離對項目目標的影響，它還可以提供受控需求的狀態(tài)?！窠涷灲逃柕怯泝裕喉椖吭缙诘慕涷灲逃柨梢赃\用到后期階段，以改進范圍控制。3.工作績效數據工作績效數據可能包括收到的變更請求的數量，接受的變更請求的數量或者核實、確認和完成的可交付成果的數量。4.組織過程資產能夠影響控制范圍過程的組織過程資產主要包括：現有的、正式的和非正式的與范圍控制相關的政策、程序和指南；可用