你总是想确切地知道必须完成的工作内容，才会开始做它。你有一组团队成员，并需要知道他们为实现项目目标将精确完成哪些任务。范围规划过程是管理项目范围的第一步，项目范围规划是关于定义确保成功实现项目目标所需的所有工作。整个思路在于，在开始项目时，你需要清楚地了解项目中所有需要完成的工作，随着项目的进展，你需要及时将该范围更新并写入项目的范围管理计划中。

定义范围

在以可衡量的方式细化项目目标方面抢先一步，有必要进一步规划和记录整个项目中生成的所有中间和最终可交付成果。交付成果包括团队在实现项目目标方面的特定角色和职责。项目的可交付成果包括你和你的团队为客户、顾客或赞助商提供的所有产品或服务。它们包括在项目期间创建的各种文档、计划、进度表、预算、蓝图和其他项目管理材料。项目可交付成果是考虑完成整个项目或特定项目阶段所需的有形结果、可衡量结果或特定项目。与目标一样，中间可交付成果必须具体且可验证。

所有可交付成果必须被描述到足够详细的水平，以便它们可以与相关的交付成果区分开来。例如：

• 双引擎飞机与单引擎飞机
• 红色标记笔与绿色标记笔
• 日报与周报
• 部门解决方案与企业解决方案

项目经理的主要职能之一是准确记录项目的可交付成果，然后管理项目，使它们按照商定的标准制作。交付成果是每个开发阶段的输出，以可量化的方式描述。

项目需求 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