你總是想確切地知道必須完成的工作內容，才會開始做它。你有一組團隊成員，並需要知道他們為實現項目目標將精確完成哪些任務。範圍規劃過程是管理項目範圍的第一步，項目範圍規劃是關於定義確保成功實現項目目標所需的所有工作。整個思路在於，在開始項目時，你需要清楚地了解項目中所有需要完成的工作，隨著項目的進展，你需要及時將該範圍更新並寫入項目的範圍管理計劃中。

定義範圍

在以可衡量的方式細化項目目標方面搶先一步，有必要進一步規劃和記錄整個項目中生成的所有中間和最終可交付成果。交付成果包括團隊在實現項目目標方面的特定角色和職責。項目的可交付成果包括你和你的團隊為客戶、顧客或贊助商提供的所有產品或服務。它們包括在項目期間創建的各種文檔、計劃、進度表、預算、藍圖和其他項目管理材料。項目可交付成果是考慮完成整個項目或特定項目階段所需的有形結果、可衡量結果或特定項目。與目標一樣，中間可交付成果必須具體且可驗證。

所有可交付成果必須被描述到足夠詳細的水平，以便它們可以與相關的交付成果區分開來。例如：

• 雙引擎飛機與單引擎飛機
• 紅色標記筆與綠色標記筆
• 日報與週報
• 部門解決方案與企業解決方案

項目經理的主要職能之一是準確記錄項目的可交付成果，然後管理項目，使它們按照商定的標準製作。交付成果是每個開發階段的輸出，以可量化的方式描述。

項目需求 Project Requirements

確定所有可交付成果後，項目經理需要記錄項目的所有需求。需求描述最終交付成果（無論是產品還是服務）的特徵。它們描述最終交付成果必須具有的所需功能或特定條件，以滿足項目的目標。需求是必須滿足的目標。在範圍計劃中定義的項目需求描述了項目應該完成什麼以及如何創建和實施項目。需求回答了關於企業現狀和期望狀況的以下問題：誰（who）、什麼（what）、在哪裡（where）、何時（when）、多少以及業務流程如何運作（how）？

需求可能包括尺寸、易用性、顏色、特定成分等屬性。如果我們回到公司生產節日蛋酒的例子，其中一個主要的可交付成果是盛放蛋酒的紙盒。該交付成果的需求可能包括紙盒設計、印在紙盒上的照片、顏色選擇等。

需求規定了最終項目交付成果的外觀和功能。需求必須是可測量的、可測試的，與已確定的業務需求或機會相關，並定義到足以支持系統設計的詳細程度。它們可以分為六個基本類別：功能、非功能、技術、業務、用戶和法規需求。

功能需求 Functional Requirements

功能需求用普通非技術語言描述最終可交付成果的特徵。它們應該能夠被客戶理解，客戶應該在其開發中扮演直接的角色。功能需求是你想要交付成果實現的功能。

車輛示例

功能需求用普通非技術語言描述最終可交付成果的特徵。它們應該能夠被客戶理解，客戶應該在其開發中扮演直接的角色。功能需求是你想要交付成果實現的功能。

電腦系統示例

對於電腦系統，你可以定義系統的功能：“該系統應該存儲客戶訂單的所有細節。”

請注意，重點在於指定需要哪些功能，而不是如何實現這些功能。

非功能需求 Non-Functional Requirements

項目的非功能需求描述的是可用於評估項目交付的最終產品或服務的標準。它們是對交付物及其構建方式施加的限製或約束。它們的目的是限制能夠滿足一組需求的解決方案的數量。使用車輛的例子，功能性需求是需要一輛車將貨物從倉庫運到商店。如果沒有任何限制，所提供的解決方案可能會有各種各樣從小型到大型的卡車。非功能性需求可以分為兩種類型：性能和開發。

為了限制解決方案的類型，你可以包括以下性能限制：

• 由於政府激勵措施，購買的卡車應該是美國製造的卡車。
• 貨物區域必須有蓋子。
• 貨物區域的高度必須至少為10英尺。

同樣，在計算機系統的例子中，你可以為通用類型的性能限制指定值：

• 信息在屏幕上顯示給用戶的響應時間。
• 系統應該可用的小時數。
• 系統應該能夠保存的記錄數。
• 應該構建系統的增長能力。
• 記錄應該保留多長時間以進行審計。

對於客戶記錄的例子，限制條件可能包括：

• 系統應該在周一至週五上午9點至下午5點之間可用。
• 系統最初應能夠容納100,000個客戶記錄。
• 系統應能夠每年新增10,000個記錄，持續10年。
• 一條記錄應該在系統上完全可用至少七年。

這些示例的一個重要點是它們限制了開發人員所提供的解決方案選項的數量。除了性能約束之外，你可能會包括一些開發約束。

非功能性開發約束有三種一般類型：

• 時間：可交付物應在何時交付。
• 資源：可用於開發可交付物的資金量。
• 質量：用於開發可交付物的任何標準、開發方法等。

技術需求 Technical Requirements

技術需求是從功能需求中產生的，以回答以下問題：這次問題將如何解決，它將在技術上和/或程序上得到解決？它們規定了系統需要如何設計並實現，以提供所需的功能和滿足所需的操作特性。

例如，在一個軟件項目中，功能需求可能規定將開發一個數據庫系統，允許通過遠程終端訪問財務數據。相應的技術要求將闡明所需的數據元素、數據庫管理系統的編寫語言（由於內部現有的知識）、系統運行的硬件（由於現有的基礎設施）、應使用的電信協議等等。

業務需求 Business Requirements

業務需求是讚助組織的需求，總是從管理角度出發。業務需求是對項目的業務理由的陳述。它們通常用廣泛的結果來表達來滿足業務需求，而不是系統必須執行的具體功能。這些需求是從產品的願景中產生的，而產品的願景又是由任務（或業務）目標和目的驅動的。

用戶需求 User Requirements

用戶需求描述了用戶需要用系統或產品來做什麼。重點是在所有情況下用戶對系統的體驗。這些需求是接下來開發階段的輸入：用戶界面設計和系統測試案例設計。

監管需求 Regulatory requirements

監管需求可以是內部或外部的，通常是不可談判的。它們是由政府規定的適用於產品或業務的限制、許可和法律。

一個需求的例子

自動取款機（ATM）可以用來說明各種需求（圖9.1）。這些機器的一些物理特徵是什麼，它們為銀行的客戶提供什麼樣的功能？銀行為什麼要建立這些系統？高層次的業務需求是什麼？

以下是每一類需求的一個可能的例子，它們將被應用於銀行的外部ATM:

• ATM的功能要求。系統將使用戶能夠選擇是否在完成交易前產生硬拷貝的交易收據。
• ATM的非功能要求。所有顯示將採用黑色背景上的白色14點Arial文字。
• 自動取款機技術要求。 ATM系統將與現有的客戶數據庫無縫連接。
• 自動取款機用戶要求。該系統將在兩分鐘內完成從個人賬戶的標準提款，從登錄到取款。
• ATM業務要求。通過為我們的零售客戶提供優質的服務，夢之城娛樂銀行的ATM網絡將使我們的相關服務費收入每年持續增加10%。
• 自動取款機監管要求。所有自動取款機將連接到其公民管轄範圍內的標準公用電源，並由公司批准的不間斷電源供應。
• 需求的有效規範是項目經理面臨的最具挑戰性的工作之一。不充分的規定要求將保證項目的不良結果。

需求的有效規範是項目經理面臨的最具挑戰性的工作之一。不充分的規定需求將保證導致項目出現不良的結果。

記錄需求不僅僅是把用戶看到的需求寫下來的過程；它不僅應該包括已經做出的決定，還應該包括為什麼做出這些決定。了解做出決定的理由對於避免重複至關重要。例如，一個特定的功能被排除在外，因為它根本不可行，這一事實需要被記錄下來。如果不這樣做，那麼當利益相關者在開發或測試過程中要求恢復該功能時，項目就有浪費工作和重複的風險。

在記錄需求後，重要的是讓利益相關者正式批准他們的需求，以確認它們符合他們期望的結果。

雖然項目經理負責確保需求被記錄下來，但這並不意味著由項目經理來完成這項任務。項目經理要爭取所有利益相關者（業務分析員、需求分析員、業務流程所有者、客戶和其他團隊成員等）的幫助，進行討論、頭腦風暴和訪談，並記錄和簽署需求。項目經理只負責啟用這個過程並促進需求開發。如果項目經理覺得文件的質量有問題，他或她的責任是停止開發過程。

項目經理審查需求，將其納入項目文件庫，並將其作為項目計劃的輸入。

軟件需求基本原理

本節提到了 “軟件 “的需求，因為它涉及到軟件要解決的問題。軟件需求是為解決一個特定問題而開發或改編的軟件必須表現出的屬性。這個問題可能是將使用該軟件的人的部分任務自動化，支持委託該軟件的組織的業務流程，糾正現有軟件的缺點，控制一個設備等等。用戶、業務流程和設備的運作通常是複雜的，因此，對特定軟件的要求通常是一個組織中不同層次的人和軟件運行環境的要求的複雜組合。

所有軟件需求的一個基本屬性是它們是可驗證的。要驗證某些軟件需求可能很困難，或者成本很高。例如，驗證一個呼叫中心的吞吐量要求可能需要開發模擬軟件。軟件需求人員和軟件質量人員都必須確保在利用現有的資源限制下，驗證軟件的需求。

需求除了表達行為屬性外，還有包括其他屬性。常見的例子包括優先級，用於在有限的資源面前進行權衡，以及狀態值，用於監控項目的進展。通常情況下，軟件需求是唯一的，這樣就可以在整個軟件生命週期內對其進行監控。

測量需求

作為一個實際問題，對一個特定軟件產品的需求量有一些概念是很有用的。這個數字對於評估需求變化的大小，估計開發或維護任務的成本，或者簡單地把它作為其他測量的分母是很有用的（見表9.1）。

表9.1: 測量需求

範圍輸入

項目經理從項目章程中收集最初的項目事實。此外，關於利益相關者的工作場所、現有的商業模式和規則等背景信息，有助於創建最終產品/服務的願景，並由此產生項目範圍（見圖9.2）。

技術

當然，項目經理的經驗對於規劃項目範圍時可以使用的技術範圍的擴大起到了重要的作用。一個有經驗的項目經理可以藉鑑過去類似項目的經驗，來確定在有時間和成本的限制下，當前項目的工作是現實可行的。溝通和談判技巧也是一個 “必備 “的條件。項目經理需要讓利益相關者了解一些要求對項目的影響。增加項目的複雜性可能需要更多的人員、時間“和”或者“或”資金。它也可能對項目質量產生影響。項目的某些方面可能是不可行的— 利益相關者需要知道這一點，以便他們可以調整其設想或為未來的挑戰做準備。

收集需求是范圍定義的一部分，它可以使用以下一種或多種技術:

• 訪談
• 焦點小組
• 促進的小組，如JAD（聯合應用開發）。
• 小組創造技術：頭腦風暴、名義小組、德爾菲、思維導圖、親和力診斷
• 原型設計
• 觀察
• 問題和調查
• 小組決策技術：一致、多數、多元、獨裁

需求追踪矩陣 Requirements Traceability Matrix

需求追踪矩陣是一個表格，它將需求與它們的來源聯繫起來，並在整個項目生命週期中追踪它們。需求追踪矩陣的實施有助於確保每個需求通過與業務和項目目標的聯繫來增加業務價值。它提供了一種在整個項目生命週期中跟踪需求的方法，幫助確保在項目結束時，需求文件中批准的需求被交付。最後，它為管理產品範圍的變化提供了一個結構。這個過程包括，但不限於跟踪:

• 對業務需求、機會、目標和目的的要求
• 對項目目標的要求
• 對項目範圍/工作分解結構交付物的要求
• 對產品設計的要求
• 產品開發的要求
• 對測試策略和測試方案的要求
• 高層次的需求到更詳細的需求

與每個需求相關的屬性可以被記錄在需求追踪矩陣中。這些屬性有助於定義需求的關鍵信息。在需求追踪矩陣中使用的典型屬性可能包括一個唯一的標識符，需求的文字描述，包含的理由，所有者﹑來源﹑優先級﹑版本﹑當前狀態（如活動﹑取消﹑推遲﹑添加﹑批准） ，和完成日期。確保需求滿足利益相關者的額外屬性可能包括穩定性、複雜性和接受標準。

矩陣內容 Matrix Fields

這些只是建議，根據組織和項目的要求會有所不同。

• 一個獨特的識別號碼，包含需求的一般類別（例如，SYSADM）和按升序分配的號碼（例如﹑1.0﹑1.1﹑1.2）
• 需求說明
• 需求來源（會議﹑配置控制板﹑任務分配等）
• 包含需求的軟件需求規格/功能需求文件段落號
• 包含需求的設計規範段落號
• 包含需求的程序模塊
• 包含需求測試的測試規範
• 需要測試的測試案例編號（可選）
• 對需求成功測試的驗證
• 修改字段（如果一個需求被改變，取消，或替換，指出處理方式和修改的權限）
• 備註

工作分解結構 Work Breakdown Structure— WBS

現在我們已經很好地定義了交付物和需求，通過工作分解結構（WBS）來分解項目工作的過程開始了。 WBS定義了項目的範圍，並將工作分解成可以被安排、估計和容易監測和控制的組成部分。 WBS背後的想法很簡單：你把一個複雜的任務細分為更小的任務，直到達到一個不能再細分的水平。任何熟悉計算機內存中的文件夾和文件的安排或研究過自己祖先家譜的人都應該熟悉這個想法。當你達到一個足夠低的水平，可以對所需的精確度進行估計時，你就停止分解工作。在這一點上，通常要比在較高層次上估計這些因素更容易估計出這項小任務要花多長時間和要花多少錢。 WBS的每一個遞減層次都代表著項目工作的詳細定義水平的提高。

WBS描述了項目要交付的產品或服務，以及它們如何被分解和關聯。它是一個面向交付的項目分解為較小的組成部分。它以一種有助於組織和定義項目總工作範圍的方式來定義和分組一個項目的離散工作要素。

WBS還為詳細的成本估算和控制提供了必要的框架，同時也為時間表的製定和控制提供了指導。

概述

WBS是將項目分層次地分解為階段、交付物和工作包。它是一個樹狀結構，顯示了為實現一個目標（如某個計劃、項目和合同等）所需努力的細分。在一個項目或合同中，WBS的製定是從最終目標開始，並依次在規模、持續時間和責任方面將其細分為可管理的組件（如係統、子系統、組件、任務、子任務和工作包等），其中包括實現目標的所有必要步驟。

WBS的創建涉及:

• 列出所有的項目產出（可交付成果和其他直接成果）
• 確定交付產出所需的所有活動
• 將這些活動細分為子活動和任務
• 確定每個任務的可交付成果和里程碑
• 確定完成每項任務所需的所有資源（人員和材料）的使用時間。
• 制定WBS的目的是為了
• 允許更容易地管理每個組成部分
• 允許對時間、成本和資源要求進行準確估計
• 允許更容易地分配人力資源
• 允許更容易地分配活動的責任

開發 WBS 的目的是：

• 允許更輕鬆地管理每個組件
• 允許準確估計時間、成本和資源需求
• 允許更輕鬆地分配人力資源
• 允許更輕鬆地分配活動責任

WBS的例子

如果我想打掃一個房間，我可能會從撿起衣服、玩具和其他掉在地上的東西開始；我可以用吸塵器來清除地毯上的污垢；我可能會把窗簾拿下來，送到清潔工那裡，然後給家具除塵。所有這些任務都是為清潔房間而執行的子任務。至於用吸塵器打掃房間，我可能要把吸塵器從壁櫥裡拿出來，連接軟管，清空袋子，然後把機器放回壁櫥裡。這些都是在完成稱為吸塵的子任務時要完成的較小任務。圖9.3顯示瞭如何用WBS格式來描述這個問題。

非常重要的是要注意，在執行 WBS 時，我們不必擔心執行工作的順序或任務之間的任何依賴關係。這將在我們制定時間表時解決。比如在3.0 Vacuum下，很明顯3.3 Vacuum carpet會在3.4 Connect hose and plug之後進行！但是，你可能會發現自己按順序思考，因為這樣做似乎是人的天性。創建 WBS 的主要思想是捕獲所有任務，而不考慮它們的順序。因此，如果你發現自己和團隊的其他成員按順序思考，請不要太擔心，但也不要執著於繪製順序圖，否則你會減慢任務識別的過程。 WBS 可以按照對你和你的項目有意義的任何方式構建。在實踐中，圖表結構經常使用，但它也可以以大綱形式構成（圖 9.4）。

你會注意到，在這兩幅圖中，WBS每一級的每個元素都被分配了一個唯一的標識符。這個唯一的標識符通常是一個數字，它被用來匯總和跟踪與WBS元素相關的成本、時間表和資源。這些數字通常與公司的會計科目表相關聯，用於按類別追踪成本。總的來說，這些數字標識符被稱為賬目代碼。

你會注意到，在這兩幅圖中，WBS每一級的每個元素都被分配了一個唯一的標識符。這個唯一的標識符通常是一個數字，它被用來匯總和跟踪與WBS元素相關的成本、時間表和資源。這些數字通常與公司的會計科目表相關聯，用於按類別追踪成本。總的來說，這些數字標識符被稱為賬目代碼。

許多項目是按項目階段進行結構化或組織的（圖9.6）。每個階段將代表WBS的第一層，他們的交付物將是下一層，以此類推。

項目經理可以根據項目的複雜性自由決定WBS的層數。你需要包括足夠多的層次來準確估計項目時間和成本，但又不能有太多的層次，以至於難以區分各組成部分。無論WBS中有多少個層次，最低的層次被稱為工作包。

工作包是可以很容易地分配給一個人或一個團隊的組成部分，有明確的責任和完成任務的責任。工作包層面是確定時間估計、成本估計和資源估計的地方。

百分之百規則 100 Percent Rule

100%規則是開發和評估WBS的最重要標準。該規則指出，每一個分解的層次（子）必須代表適用於下一個更高（父）元素的100%的工作。換句話說，如果WBS的每一層都遵循100%的規則，直到活動，那麼我們就有信心在製定項目時間表時，100%的活動都被確定下來。當我們為項目創建預算時，100%的成本或所需資源將被確定。

範圍聲明

根據正在實施的項目類型和組織的性質，範圍聲明可能有多種形式。範圍聲明詳細說明了項目的可交付成果，並描述了主要目標。這些目標應該包括項目的可衡量的成功標準。

範圍說明用非常寬泛的語言描述了項目的產品：例如，”開發一個基於軟件的系統來獲取和跟踪軟件的訂單”。範圍說明還應該包括使用該產品的用戶名單，以及最終產品的功能。

作為一個基線，範圍聲明應該包含:

• 項目名稱
• 項目章程
• 項目負責人、贊助商和利益相關者
• 問題陳述
• 項目目標和目的
• 項目要求
• 項目的可交付成果
• 項目的非目標（超出範圍的內容）
• 里程碑
• 成本估算

在更多以項目為導向的組織中，範圍說明也可能包含這些和其他部分:

• 項目範圍管理計劃
• 經批准的變更請求
• 項目假設和風險
• 項目驗收標準

Image Descriptions

Figure 9.2 image description: A project manager develops a Scope Management Plan by taking the project charter, organizational memory, and the project plan and applying the following techniques and tools:

• Calls on past project experience
• Uses scope management templates (SOS, WBS, Scope Management Plan)
• Uses Communication skills (for negotiating with and educating clients)

[Return to Figure 9.2]

Figure 9.3 image description:

0.0 Clean Room

• 1.0 Mop floor.
  • 1.1 Get mop and bucket out.
  • 1.2 Mix cleaner with water in bucket.
  • 1.3 Rinse out bucket and mop.
• 2.0 Dust
  • 2.1 Coffee table
  • 2.2 Blinds
• 3.0 Vacuum
  • 3.1 Get vacuum out of closet
  • 3.2 Vacuum carpet
  • 3.3 Empty bag
  • 3.4 Connect hose and plug
• 4.0 Pick up floor
  • 4.1 Toys
    • 4.1.1 Put toys in box
  • 4.2 Clothes
    • 4.2.1 Hang up in closet
• 5.0 Clean curtains
  • 5.1 Remove curtains
  • 5.2 Take to cleaners
  • 5.3 Hang curtains

[Return to Figure 9.3]

貢獻者和歸因 Text Attributions

This chapter of 企業策略: 高管項目領導指南 Strategy Consulting: A guide for executives leading projects is a derivative of the following text:

• This chapter adapted and remixed by Adrienne Watt from the following sources:
  • Text under “Scope Planning”  adapted from “Project Planning” in Project Management by Merrie Barron and Andrew Barron. Licensed under a CC BY 4.0 licence.
  • Development Cooperation Handbook/Designing and Executing Projects/Detailed Planning or design stage by Wikibooks. Licensed under a CC BY-SA (Attribution-ShareAlike) licence.
  • Text under “Scope Inputs” adapted from Project Management/PMBOK/Scope Management by Wikibooks. Licensed under a CC BY-SA (Attribution-ShareAlike) licence.
  • Text under “Requirements Traceability Matrix” adapted from Requirements Traceability Matrix by DHWiki. Licensed under a CC BY-NC-ND (Attribution-NonCommercial-NoDerivatives) licence .
  • Text under “Work Breakdown Structure” in Work Breakdown Structure by Wikipedia. Licensed under a CC BY-SA (Attribution-ShareAlike) licence.
  • Text under “100 Percent Rule” adapted from 100 Percent Rule by Pabipedia. Licensed under a CC BY-SA (Attribution-ShareAlike) licence.

  Media Attributions

  • ATM © megawatts86 is licensed under a CC BY-SA (Attribution ShareAlike) license
  • Scope Management IO © Flaming Sevens adapted by Josie Gray is licensed under a Public Domain license
  • WBS Cleaning Room © Barron & Barron Project Management for Scientists and Engineers is licensed under a CC BY (Attribution) license
  • WBS Outline – Clean Room © Barron & Barron Project Management for Scientists and Engineers is licensed under a CC BY (Attribution) license
  • Multimedia Project WBS © Barron & Barron Project Management for Scientists and Engineers is licensed under a CC BY (Attribution) license
  • WBS Project Phases © Barron & Barron Project Management for Scientists and Engineers is licensed under a CC BY (Attribution) license