目录
1. 产品范围和项目范围
产品范围：指某项产品、服务或成果所具有的特征和功能。产品范围的完成情况是根据产品需求来衡量的。
项目范围：包括产品范围，是为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围的完成情况是根据项目管理计划来衡量的。
2.项目范围管理过程
| 过程 | 定义 | 作用 | 开展节点 |
| 规划范围管理 | 是为了记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。 | 在整个项目期间对如何管理范围提供指南和方向. | 仅开展一次或仅在项目的预定义点开展。 |
| 收集需求 | 是为实现目标而确定，记录并管理干系人的需要和需求的过程。 | 是为定义产品范围和项目范围奠定基础。 | 仅开展一次或仅在项目的预定义点开展。 |
| 定义范围 | 是制定项目和产品详细描述的过程。 | 作用是描述产品、服务或成果的边界和验收标准。 | 整个项目期间定期反复开展。 |
| 创建WBS | 是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。 | 作用是为所要交付的内容提供架构。 | 仅开展一次或仅在项目的预定义点开展。 |
| 确认范围 | 是正式验收已完成的项目可交付成果的过程。 | ①使验收过程具有客观性； ②通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性。 | 整个项目期间定期开展。 |
| 控制范围 | 是监督项目和产品的范围状态，管理范围基准变更的过程。 | 在整个项目期间保持对范围基准的维护 。 | 整个项目期间开展。 |
3.规划范围管理的输入输出
| 输入 | 工具与技术 | 输出 |
|
|
|
4.范围管理计划
范围管理计划可以是正式或非正式的，非常详细或高度概括的。
- 制定项目范围说明书
- 根据详细项目范围说明书创建WBS
- 确定如何审批和维护范围基准
- 正式验收已完成的项目可交付成果
- 根据项目需要，项目范围管理计划可以是正式或非正式的，非常详细或高度概括的
5.需求管理计划
- 如何规划、跟踪和报告各种需求活动
- 配置管理活动
- 需求优先级排序过程
- 测量指标及使用这些指标的理由
- 反映哪些需求属性将被列入跟踪矩阵等
6.收集需求的输入输出
| 输入 | 工具与技术 | 输出 |
|
|
|
7.收集需求相关概念
- 数据收集
- 访谈：是通过与干系人直接交谈来获取信息的正式或非正式的方法。访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。访谈经常是一个访谈者和一个被访谈者之间的“一对一"谈话，但也可包括多个访谈者或多个被访者。访谈有经验的参与者、发起人和其他高管及主题专家，有助于识别和定义所需产品可交付成果的特征和功能。访谈也可用于获取机密信息。
- 焦点小组:是召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比一对一的访谈更热烈。
- 问卷调查：是指涉及一系列书面问题，向众多受访者快速收集信息。问卷调查方法非常适用于受众多样化，需求快速完成调查，受访者地理位置分散并且适合开展统计分析的情况。
- 标杆对照：将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的，也可以是外部的。
- 文件分析指审核和评估任何相关的文件信息。
- 决策
- 投票：是一种未达成某种期望结果，而对未来多个行动方案进行评估的决策技术和过程。本技术用于生成、归类和排序产品需求。
- 独裁型决策制定：采用这种方法，将一个人负责为整个集体制定决策。
- 多标准决策分析：该技术借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，以对众多创意进行评估和排序。
- 数据表现
- 亲和图：用来对大量创意进行分组的技术，以便进一步审查和分析。
- 思维导图：把从头脑风暴中获得的创意整合成一张图，用以反映创意之间的共性与差异，激发新创意。
- 人际关系与团队技能
- 名义小组技术：是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。名义小组技术是一种结构化的头脑风暴形式。由四个步骤组成
- 向集体提出一个问题或难题，每个人在沉思后写出自己的想法；
- 主持人在活动挂图上记录所有人的想法；
- 集体讨论各个想法，直到全体成员达成一个明确的共识；
- 个人私下投票决出各种想法的优先排序，通常采用5分制，1分最低，5分最高。为减少想法数量，集中关注想法，可进行数轮投票，每轮投票后，都将清点选票，得分最高者被选出。
- 观察和交谈：是指直接察看个人在各自的环境中如何执行工作（或任务）和实施流程。当产品使用者难以或不愿清晰说明他们的需求时，特别需要通过观察来了解他们的工作细节。观察也称为“工作跟随”，通常由旁站观察者观察业务专家如何执行工作，但也可以由“参与观察者”来观察，通过实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。
- 引导：引导与主题研讨会结合使用，把主要干系人召集在一起定义产品需求。研讨会可用于快速定义跨职能需求并协调关系人的需求差异。因为具有群体互动的特点，有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通，从而有利于干系人达成一致意见。此外，与分别召开会议相比，研讨会能够更早发现并解决问题。
- 系统交互图是对产品范围的可视化描述，可以直接显示业务系统（过程、设备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式。
- 原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。在软件开发中，故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。
8.需求分类（需求文件的内容）
- 业务需求：整个组织的高层级需要。
- 干系人需求：干系人的需要。
- 解决方案需求：分为功能需求和非功能需求，是为满足业务需求和关系人需求，产品、服务或成果必须具备的特性、功能和特征。
- 过渡需求：如数据转换和培训需求。这些需求描述了从“当前状态”过渡到“未来状态”所需的临时能力。
- 项目需求：项目需要满足的行动、过程或其他条件。
- 质量需求：用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件和标准，例如，测试、认证、确认等。
9.收集需求过程的输出
需求文件
- 需求文件既可以是一份干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。
- 需求文件：例如，软件需求规格说明书就是一种典型的需求文件。因为项目具有证据明细的特点，一开始，可能只有概括性的需求，所以然后随着信息的增加而逐步细化。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，其主要干系人愿意认可的需求才能作为基准。
需求跟踪矩阵
- 需求跟踪矩阵的内容包括（口诀：“爷想搞铲车，业项高产测”）：业务需求、机会、目的和目标；项目目标；项目范围（WBS可交付成果）；产品设计；产品开发；测试策略和测试场景；高层及需求的详细需求。
- 需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。需求跟踪矩阵中记录每个需求的相关属性，包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（如进行中、已取消、已推迟、新增加、已批准、被分配和已完成）和状态日期。
10.定义范围的输入输出
| 输入 | 工具与技术 | 输出 |
|
|
|
11.定义范围的相关概念
- 由于在收集需求过程中识别出的所有需求未必都包含在项目中，所以定义范围过程需要从需求文件中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。
- 产品分析技术主要包括：产品分解、需求分析、系统分析、系统工程、价值分析、价值工程等，
- 项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。详细的项目范围说明书包括内容有（直接列出或参引其他文件）：
- 产品范围描述：逐步细化在项目章程和需求文件中所述的产品、服务或成果特征。
- 可交付成果：未完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力。
- 验收标准：可交付成果通过验收前必须满足的一系列条件。
- 项目的除外责任：识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，有助于管理干系人的期望及减少范围蔓延。
12.创建WBS的输入输出
| 输入 | 工具与技术 | 输出 |
|
|
|
13.创建WBS的相关概念
- WBS：WBS是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。WBS 组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。工作分解结构每向下分解一层，代表对项目工作更详细的定义。
- 工作包：WBS的最低层级是带有独特标识号的工作包。这些标识号未进行成本、进度和资源信息的逐层汇总提供了层级结构，即账户编码。每个工作包都是控制账户的一部分，而控制账户则是一个管理控制点。工作包对相关活动进行分类，以便对工作安排进度，进行估算，开展监督与控制。在该控制点上，把范围、预算和进度加以整合，并与挣值相比较，以测量绩效。控制账户包含两个或更多工作包，但每个工作包只与一个控制账户关联。
- 范围基准是经过批准的范围说明书、WBS和相应的WBS字典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。范围基准是项目管理计划的组成部分，包括项目范围说明书、WBS、工作包、规划包和WBS字典等。
- 规划包：规划包是一个低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知，一个控制账户可以包含一个或多个规划包。
- 项目范围说明书；项目范围说明书包括对项目范围、主要可交付成果、假设条件和制约因素的描述。
- WBS字典：WBS字典是针对WBS中的每个组件，详细描述可交付成果、活动和进度信息的文件。WBS字典对WBS提供支持，其中大部分信息由其他过程创建，然后在后期添加到字典中。WBS字典中的内容一般包括账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献和协议信息等。
14.分解活动（口诀：“别排接配合”）
- 识别和分析可交付成果及相关工作；
- 确定WBS结构和编排方法;
- 自上而下逐层细化分解;
- 为WBS组成部分制定和分配标识编码;
- 核实可交付成果分解的程度是否恰当；
15.WBS的结构可以采用多种形式。
- 以项目生命周期的各个阶段作为分解的第二层
- 以主要可交付成果作为分解的第二层
- 纳入由项目团队以外的组织开发的各种较低层次组件如（外包工作）。随后作为外包工作的一部分，卖方需制定相应的合同WBS
16.分解时应该注意以下8个方面
- WBS必须是面向可交付成果的：项目的目标是提供产品或服务，WBS中的各项工作是为提供可交付的成果服务的。
- WBS必须符合项目的范围：WBS必须包括也仅包括为了完成项目的可交付成果的活动。100%原则（包含原则）认为，在WBS所有下一级的元素之和必须100%代表上一级的元素。
- WBS的底层应该支持计划和控制：WBS的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算。
- WBS中的元素必须有人负责，而且只有一个人负责。WBS和责任人可以使用工作责任矩阵来描述。
- WBS应控制在4~6层，一个工作单元只能从属于某个上层单位，避免交叉从属。
- WBS应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作。
- WBS的编制需要所有（主要）项目干系人的参与。
- WBS并非是一成不变的：在完成了WBS之后的工作中，仍然有可能需要对WBS进行修改。
17. 确认范围的输入输出
| 输入 | 工具与技术 | 输出 |
|
|
|
18.确认范围的一般步骤（口诀：“石头准不会”）
- 确定需要进行范围确认的时间；
- 识别范围确认需要哪些投入；
- 确定范围正式被接受的标准和要素；
- 确定范围确认会议的组织步骤；
- 组织范围确认会议。
19.项目干系人进行范围确认时，需要检查6个方面的问题
- 可交付成果是否具是确定的、可确认的。
- 每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，例如，客户的书面认可等。
- 是否有明确的质量标准：可交付成果的交付不但要有明确的标准标志，而且要有是否按照要求完成的标准，可交付成果和其标准之间是否有明确联系。
- 审核和承诺是否有清晰的表达：项目发起人必须正式同意项目的边界，项目完成的产品和服务，以及项目相关的可交付成果。
- 项目范围是否覆盖了需要完成的产品或服务的所有活动，有没有遗漏或错误。
- 项目范围的风险是否太大：管理层是否能够降低风险发生时对项目的影响。
20.干系人关注的要点
| 干系人 | 关注点 |
| 企业管理层 | 关注项目范围投入产出的合理性。 |
| 客户 | 关心产品的范围，关心项目的可交付成果是否足够完成产品或服务。 |
| 项目管理人员 | 注可交付成果是否足够和必须完成，时间、资金和资源是否足够。 |
| 项目团队成员 | 关注项目范围中自己参与的元素和负责的元素。 |
21.确认范围和控制质量的不同之处
| 确认范围 | 控制质量 | |
| 关注点 | 可交付成果的验收 | 可交付成果的正确性及是否满足质量要求 |
| 进行阶段 | 一般在阶段末尾进行 | 一般在确认范围前进行，也可同时进行 |
| 检查形式 | 外部干系人（客户或发起人）对项目可交付成果进行检查验收 | 内部检查 |
22.控制范围的输入输出
| 输入 | 工具与技术 | 输出 |
|
|
|
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
