高项5. 项目管理之范围管理

908486905

已于 2023-11-04 00:04:05 修改

阅读量2.5k

点赞数

分类专栏：项目管理文章标签：软件工程

于 2022-09-18 13:08:52 首次发布

本文链接：https://blog.csdn.net/u010025781/article/details/126916485

版权

项目管理专栏收录该内容

40 篇文章 21 订阅

订阅专栏

项且范围是项且目标的更具体的表达。范围管理必须清断地定义项目目标，此定义必须在项目干系人之间达成一致，并且将项且工作范围详细地划分为工作包，以便更好地执行。

简单地理解，项目范围管理(Scope Management)就是要做范围内的事，而且只做范围内的事，既不少做也不多做。如果少做，会影响功能的实现;如果多做,又会造成资源浪费。

项目管理四个核心：成本、进度、质量和范围。范围是基础性和全局性的工作。

具体来说，项目范围管理需要做以下三个方面的工作:
(1)明确项目边界。
(2)监控项目执行，确保所有该做的工作都做了，而且没有多做。
(3)防止项目范围发生蔓延。范围蔓延是指未经控制的产品或项目范围的扩大。

范围管理的重要性
（1）项目范围来自于项目目标，项目目标是范围定义的依据。
（2）项目范围管理及控制的有效性，是衡量项目是否达到成功的一个必要标准。
（3）不断重申项目工作范围，有利于控制项目不偏离正确归到，是实施控制管理的个主要手段。
（4）项目范围管理可以详细、清楚地界定分工界面和责任。
（5）范围管理能确定边界，明确项目目标和主要可交付成果，用了WBS工作分解结构，有助于提高对成本、进度和资源估算的准确性。
（6）项目范围管理影响到项目的成功，在实践中，范围蔓延是项目失败最常见的原因之一。

第一章概述

1. 范围三个概念

范围蔓延：客户提出新需求，未走变更程序，超出了范围基准
范围潜变：客户不断提岀小的、不易察觉的范围改变，未加控制，导致项目严重偏离范围基准，导致项目失控和失败。
范围镀金：客户没有提新需求，乙方自己做了额外客户不需要的工作【项目实施人员往往愿意尝试新的技术或者为信息系统项目加上更牛X的功能】

2、产品范围（强调结果）与项目范围（强调过程）

①产品范围是指产品或者服务所应该包含的功能，项目范围是指项目所必须做的工作。
②产品范围是项目范围的基础，产品范围的定义是产品要求的描述，而项目范围的定义是产生项目管理计划的基础，两种范围在应用上有区别。
③项目的范围基准是经过批准的项目范围说明书、WBS和WBS词典。判断项目范围是否完成，要以范围基准来衡量。产品范围是否完成，则根据产品是否满足了需求说明书来判断。
④产品范围描述是项目范围说明书的重要组成部分。

但是，产品范围变化了，项目范围不一定会变化；项目范围变化了，产品范围也不一定发生变化。

●清晰:交付什么?理解一致
●完整:关注什么?没有盲区
●受控:怎么关注?避免范围蔓延与镀金

第二章范围管理过程

2.1 规划范围管理--范围管理计划+需求管理计划

规划范围管理就是规划项目如何定义、确认和监控项目范围，具体来讲，是为项目的范围管理过程制定统一的原则、规范、技术、工具、操作指南等。


范围管理计划	需求管理计划
范围管理计划描述将如何定义、制订、监督、控制和确认项目范围。定义怎样变化怎样变化、变化频率如何、变化了多少等项目范围预期的稳定性进行评估。对变化范围怎样确定，变化应归为哪一类等问题的清楚描述；---范围潜变；蔓延；镀金；	需求是软件项目成功的核心所在，它为其他许多技术和管理活动奠定了基础。需求管理贯穿于整个过程。基本任务就是明确需求，达成共识，建立需求基线。建立需求跟踪能力联系链,确保所有用户需求都被正确地实现、核实和确认。变更时，控制其影响范围，始终保持产品与需求的一致性。
①如何制订项目范围说眀书 ②如何根据范围说明书创建WBS ③如何维护和批准WBS ④如何确认和正式验收已完成的可交付成果。 ⑤如何处理项目范围说明书的变更，走实施整体变更控制过程。	①如何规划、跟踪和汇报各种需求活动 ②需求管理需要使用的资源 ③培训计划 ④规划项目干系人参与需求管理的策略 ⑤判断项目范围与需求不一致的准则和纠正规程 ⑥需求跟踪结构 ⑦配置管理活动

2.2 收集需求，分析初步需求，调研，确认，排优先级，输出需求文件和跟踪矩阵

1、需求分类

包括业务需求、干系人需求、解决方案需求、过渡需求、项目需求和质量需求等。


收集需求的工具与技术	1.文件分析，标杆对照---分析初步需求 2. 访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、 3. 问卷调查、观察 4. 原型法、系统交互图--进一步开发和确认需求
收集需求的工具与技术	访谈正式或非正式，一对一会谈或一对多访谈；焦点小组一对一访谈的扩展形式，加入了专家，专门的主持人；引导式研讨会集中主要干系人，集中讨论定义产品需求，强调跨职能和协调客户、设计技术和开发等干系人组织一系列结构性的专题研讨会，集中确定需求，效率高，客户参与度高。群体创新技术组织一些群体活动来识别项目和产品需求群体决策技术为达成某种期望结果，对多个未来行动方案进行评估原型法制造模型，征求反馈，支持渐进明细标杆对照用实际和计划与其他组织的进行比较系统交互图法：软件需求分析中的DFD数据流图、用例图都可以看作是系统交互图。
群体创新技术	群体创新技术包括头脑风暴法、名义小组技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析等。 ①头脑风暴：各抒己见，庭外判决，追求数量，取长补短； ②名义小组技术：通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序。名义小组技术是头脑风暴法的深化应用，是更加结构化的头脑风暴法。将参加头脑风暴的人员按名义分组，分组讨论，促进创意。 ③德尔菲技术：可以防止个人的观点被不正确的放大。 ④概念/思维导图：是将从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。 ⑤亲和图又称为KJ法，是针对某一问题，充分收集各种经验、知识、想法和意见等语言、文字资料，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决的一种方法。亲和图的核心是头脑风暴法，是根据结果去找原因。 ⑥多标准决策分析是借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。
群体决策技术	群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序。。一致同意(Unanimity)。。大多数原则(Majority) 。获得群体中50%以上的人的支持，就能做出决策。。相对多数原则(Plurality)。。独裁(Dictatorship)。

2、整理需求，输出需求文件+需求跟踪矩阵

需求文件	需求跟踪矩阵
用户需求说明书；软件需求规格说明书；	1. 跟踪 2. 跟踪矩阵
可能只有概括性的需求，然后随着信息的增加而逐步细化。只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。	可跟踪性是项目需求的一个重要特征，需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规则、系统组件，以及帮助文件等。五类需求可跟踪： 1. 用户需求--需求文件双向跟踪； 2. 需求文件---设计、产品，测试文档双向跟踪 3. 需求文件格需求之间的逻辑关系可跟踪。
需求文件的内容包括： ①业务需求 ②干系人需求 ③解决方案需求 ④项目需求 ⑤过渡需求 ⑥与需求有关的假设条件、依赖关系和制约因素。	需要跟踪的内容包括以下几个方面。业务需求、机会、目的和目标。项目目标。项目范围(WBS可交付成果)。. 产品设计。产品开发。测试策略和测试场景。高层级需求到详细需求。

需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（例如，进行中、已取消、已推迟、新增加、已批准、已分配、己完成等）和状态日期。

2.3 定义范围，复核需求，确认边界，输出范围说明书，初定范围基准.

定义范围是制定项目和产品详细描述的过程，是明确所收集的需求哪些包含在项目范围内，哪些在项目范围外，从而明确产品、服务或成果的边界。

定义范围工具与技术：	专家判断、产品分析、备选方案生成和引导式研讨会。
定义范围工具与技术：	产品分析技术包括产品分解、系统分析、需求分析、系统工程、价值工程和价值分析等。关键的还是产品分析后的范围界定，例如是否包含基础开发平台，只提供前台还是前后台都提供。价值工程( Value Engineering)与价值分析( Value Analysis)两种活动都是对商品的价值、功能与成本进-步做思考与探索，以小组活动方式集思广益，朝各方向寻求最佳方案，再运用体系分工的方式达成价值提升或降低成本的目标。两者都是指对项目的范围和成本进行分析，以便在保持项目范围不变的前提下，降低项目成本，追求功能与成本之间的更高的性价比。价值工程是在产品开发设计阶段进行的价值与成本革新活动，因为仍在工程设计阶段，故称为价值工程。而一旦开始量产后，往往为了成本或利润压力，如果不进行详尽的价值分析，就难以发掘可以降低成本或提高价值的改善点。此阶段以后持续的分析是降低成本的主要方法，就称为价值分析。因此，要注意价值工程与价值分析的细微差别，
项目范围说明书的内容	①产品范围描述 ②验收标准 ③可交付成果 ④项目的除外责任 ⑤制约因素 ⑥假设条件
项目范围说明书的主要作用：	①确定范围 ②沟通基础 ③规划和控制依据 ④变更基础 ⑤规划基础

2.4 创建WBS, 工作分解，编码建控制账号，确定范围基准

创建WBS是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程，其主要作用是对所要交付的内容提供一个结构化的视图。

WBS是以可交付成果为导向的工作层级分解，其分解的对象是项目团队为实现项目目标、提交所需可交付成果而实施的工作。WBS定义项目的总范围，代表着现行项目范围说明书所规定的工作。

WBS分解

1. 里程碑

2. 工作包，WBS最底层交付成功或者项目工作。

1）工作要具体，有明确的目标和责任，方便指派。

2）工作包的颗粒度要合适，不能太大，也不能太小，太大会导致估算控制偏差过大；太小浪费管理效率资源； 8/80原则，即工作包不小于8人时，不大于80人时。1-10人天。

3. 控制账号，项目范围，进度，成本等绩效控制的基础单元。项目管理团队在控制账户上考核项目的执行情况，将项目执行情况与计划情况进行比较，发现问题与纠正偏差。

控制账尸是WBS某个层次上的要系，既可以是工作包，也可时县比工作包更高层次上的一个要素。一个工作包仅属于一个控制账户。

4. 规划包( Planning Package)是指在控制账户之下，工作内容已知但尚缺详细进度活动的WBS组成部分。也就是说，规划包是在控制账户之下、工作包之上的WBS要素。

项目管理团队虽然已经知道它是一-个什么样的成果，但是尚不清楚究竟要做哪些具体的活动才能将该成果开发出来。

由于当前无法分解到编制项目管理计划所需要的详细程度，规划包是暂时用来做计划的。随着情况的逐渐清晰，规划包最终将被分解成T作包以及相应的具体活动。

WBS词典：

WBS词典也称为WBS词汇表，它是描述WBS各组成部分的文件。对于WBS的每一组成部分，WBS词典可能包括账户编码标识、工作描述、假设条件和制约因素负责人或组织单元、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等。

WBS分解工作

7、分解是一种将项目可交付成果和项目工作分解成较小的、更易于管理的组件的技术。
8、要将整个项目工作分解为工作包，需要开展以下活动：
①识别和分析可交付成果及相关工作
②确定WBS的结构和编排方法
③自上而下逐层细化分解。
④为WBS组件制定和分配标识编码。
⑤核实可交付成果分解的程度是恰当的

9、创建WBS时对工作的划分原则包括：
①功能或者技术原则。在创建WBS时，需要考虑工作分派。
②组织结构
③系统或者子系统。

创建WBS分解原则

□ 包含原则：又称100%规则，WBS整体包含了项目，所需要完成的全部工作

□ 不可再分原则：WBS的最底层必须有相对独立的属性，即不可再分

□ 信息透明原则：分解到可以充分估算，完成该工作包所需的时间、费用、资源的层次为止

□ 80小时原则：最底层工作包可以在80个小时内完成，使得工作绩效至少可以2周更新一次，以便监控

□ 独立责任原则：分解到可以安排给一个责任者（个人或团队）负责

□ 滚动分解原则：信息暂时不足的，可暂时不分解，等信息充分后继续分解

10、WBS分解的方法：
①项目生命周期的各阶段作为分解的第二层，产品和项目可交付成果放在第三层。（如按项目周期的需求、设计、开发、测试、实施等阶段做为第二层；把每个阶段产出的可交付成果作为第三层，如：需求分析结果、调研结果等）
②主要可交付成果作为分解的第二层
③整合可能由项目团队以外的组织来实施的各种组件（例如，外包工作），然后作为外包工作的一部分，卖方需编制相应的合同WBS。
例子看这里：https://m.sohu.com/a/150900112_208218

14、WBS分解注意8个方面：
①WBS必须是面向可交付成果的。
②WBS必须符合项目的范围。
③WBS的底层应该支持计划和控制。
④WBS中的元素必须有且只由一个人负责，尽管实际上可能需要多个人参与。
⑤WBS的指导（不是原则），WBS应控制在4∽6层。
⑥WBS应包括项目管理工作，也要包括分包出去的工作。
⑦WBS的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与。
⑧WBS并非是一成不变的。需要不断维护和更新。
补充：
（1）在层次上保持项目的完整性，避免遗漏必要的组成部分。
（2）一个工作单元只能从属于某个上层单元，避免交叉从属。
（3）相同层次的工作单元应用相同性质。
（4）工作单元应能分开不同的责任者和不同的工作内容。
（5）便于项目管理计划和项目控制的需要。
（6）最底层工作应该具有可比性，是可管理的，可定量检查的。
（7）应包括项目管理工作，包括分包出去的工作。

WBS的作用

当一个项目的WBS分解完成后，项目干系人应该给予确认，并对此达成共识，然后才能据此进行时间估算和成本估算。

WBS的目的和用途主要体现在以下8个方面
(1)明确项目范围，团队成员能够清楚地理解任务的性质和需要努力的方向。
(2)清楚地定义项目的边界，有了一致认可的项目要做的和不要做的标准。
(3)为各独立单元分派人员，定义职责。
(4)针对独立单元，进行时间、成本和资源需求量的估算，提高估算的准确性。
(5)为计划、预算、进度安排和费用控制奠定共同基础，确定项目进度和控制的基准。
(6)将项目工作和项目的财务账目联系起来。
(7)确定工作内容和工作顺序，将项目分解成具体的工作任务，就可以按照工作任务的逻辑顺序来实施项目。
(8)有助于防止需求蔓延。

当项目用户或者其他项目干系人试图为项目增加功能时，在WBS增加相应的工作的同时，也就能够很容易地让他们理解，相关成本和进度也必须做相应的改变。

2.5 确认范围，正式验收已经通过质量控制核实确认的可交付成果，贯穿项目始终

确认范围包括与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的正式验收。注意：确认范围前，需要先就项目成果做完备的测试审核，即只有核实确认的成果，才能进行范围确认。

确认范围的要点：

①与客户或发起人一起审查可交付成果

②确保可交付成果已经圆满完成并通过正式验收。

③确认范围过程主要关注“量”，控制质量过程主要关注“质”

④控制质量过程通常先于确认范围过程，但二者也可同时进行。

确认范围的主要工具与技术是检查和群体决策技术。检查也称为审查、评审、审计、走查、巡检、测试等，是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。

例如，验收测试就是一种典型的确认范围的技术。

确认范围要考虑的问题

(1)可交付成果是否是确定的、可确认的。

(2)每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，
例如，客户的书面认可等。

(3)是否有明确的质量标准，也就是说，可交付成果的交付不但要有明确的标准标志，而且要有是否按照要求完成的标准，可交付成果和其标准之间是否有明确的联系。

---------怎么证明质量监测结果

(4)审核和承诺是否有清晰的表达。项目发起人必须正式同意项目的边界，项目完成的产品或者服务，以及项目相关的可交付成果。项目团队必须清楚地了解可交付成果是什么。所有的这些表达必须清晰，并取得一致的同意。

(5)项目范围是否覆盖了需要完成的产品或服务进行的所有活动，有没有遗漏或者错误。
(6)项目范围的风险是否太高，管理层是否能够降低可预见的风险发生时对项目的冲击。

范围确认干系人的关注点
管理层关注	进度，成本，质量是否超标，投入产出比是否合理。
客户关注	可交付成果是否满足产品和服务的要求。
项目管理人员	主要关注可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法。
项目团队成员	项目团队成员主要关心项目范围中自己参与的元素和负责的元素，通过定义范围中的时间检查自己的工作时间是否足够，自己在项目范围中是否有多项工作，而这些工作文有冲突的地方。
1.确认范围与核实产品核实产品是针对产品是否完成，在项目(或阶段)结束时由发起人或客户来验证，强调产品是否完整; 确认范围是针对项目可交付成果，由客户或发起人在阶段末确认验收的过程。 2. 确认范围与质量控制确认范围主要强调可交付成果获得客户或发起人的接受;质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求(质量标准)。质量控制一般在确认范围前进行，也可同时进行;确认范围一般在阶段末尾进行，而质量控制并不一定在阶段未进行。由执行组织的相应质量部门]实施;确认范围则是由外部干系人(客户或发起人)对项目可交付成果进行检查验收。从检查的详细程度来说，核实产品、确认范围和质量控制是递进的、越来越细的检查过程。 3.确认范围与项目收尾。虽然确认范围与项目收尾工作都在阶段未进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目(或阶段)所要做的流程性工作。。确认范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品。