大师兄的信息化项目管理学习笔记（十七）：项目范围管理（二）

大师兄的信息化项目管理学习笔记（十六）：项目范围管理（一）

四、收集需求

1. 关于需求

• 需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件和能力。
• 需求包括发起人、客户和其他相关方的已量化且书面记录的需要和期望。
• 需求是整个项目，特别是后面的创建工作分解结构WBS过程以及规划成本、进度、质量和采购等过程的基础。只有明确需求了，后续工作才能有序进行，项目最终实现的产出才有价值。

2. 需求类型

• 业务需求：整个组织的高层级需要。
• 相关方需求：相关方或相关方群体的需要。
• 解决方案需求：为满足业务需求和相关方需求，产品、服务或成果必须具备的特性、功能和特征。进一步分为功能需求和非功能需求。
• 过度和就绪需求：描述了从“当前状态”过度到“将来状态”所需的临时能力，入数据转换和培训需求。
• 项目需求：项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素等。
• 质量需求：用于确认项目可交付成果成功完成的条件和标准。

3. 关于收集需求

• 为实现目标而确定、记录并管理相关方的需要和需求。
• 为定义产品范围和项目范围奠定基础。
• 仅开展一次或仅在项目的预定义点开展。

4. ITTO

输入	工具与技术	输出
1. 项目章程 2. 项目管理计划 - 范围管理计划 - 需求管理计划 - 相关方参与计划 3. 项目文件 - 假设日志 - 经验教训登记册 - 相关方登记册 4. 商业文件 - 商业论证 5. 协议 6. 事业环境因素 7. 组织过程资产	1. 专家判断 2. 数据收集 - 头脑风暴 - 访谈 - 焦点小组 - 问卷调查 - 标杆对照 3. 数据分析 - 文件分析 4. 决策 - 投票 - 多标准决策分析 - 数据表现 - 亲和图 - 思维导图 6. 人际关系与团队技能 - 名义小组技术 - 观察/交谈 - 引导 7. 系统交互图 8. 原型法	1. 需求文件 2. 需求跟踪矩阵

5. 输入

5.1 项目章程

• 项目章程记录了项目概述以及将用于制定详细需求的高层级需求。

5.2 项目管理计划

• 范围管理计划：包含如何定义和制定项目范围的信息。
• 需求管理计划：包含如何收集、分析和记录项目需求的信息。
• 相关方参与计划：从相关方参与计划中了解相关方的沟通需求和参与程度，以便评估并适应相关方对需求活动的参与程度。

5.3 项目文件

• 假设日志： 识别了有关产品、项目、环境、相关方以及会影响需求的其他因素的假设条件。
• 经验教训登记册：提供了有效的需求收集技术，尤其针对使用迭代型或适应型产品开发方法的项目。
• 相关方登记册：用于了解哪些相关方能够提供需求方面的信息，及记录相关方对项目的需求和期望。

5.4 商业文件

• 商业论证：描述了为满足业务需要而应该达到的必要、期望及可选标准。

5.5 协议

• 协议包含项目和产品的需求。

5.6 事业环境因素

• 组织文化
• 基础设施
• 人事管理制度
• 市场条件

5.7 组织过程资产

• 政策和程序
• 包含以往项目信息的历史信息和经验教训知识库。

6. 工具与技术

6.1 专家判断

• 基于某应用领域、知识领域、学科和行业等的专业知识而做出的，关于当前活动的合理判断：

• 商业分析
• 需求获取
• 需求分析
• 需求文件
• 以往类似项目的项目需求
• 图解技术
• 引导
• 冲突管理

6.2 数据收集

• 访谈是一种通过与相关方直接交谈，来获得信息的正式或非正式方法，通常只面向关键相关方。
• 焦点小组是召集预订的相关方和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度，其中主持人的角色至关重要：

• 确认话题的内容、顺序
• 活跃气氛、鼓励发言
• 保持中立

• 问卷调查是指设计一系列书面问题，向众多受访者快速收集信息，适用以下情况：

• 受众多样化
• 需要快速完成调查
• 受访者地理位置分散
• 适合开展统计分析

• 头脑风暴：用来产生和收集对项目需求和产品需求的多种创意和技术。
• 标杆对照：将实际或计划的产品、过程和实践，与其它可比组织的时间进行比较，一遍识别最佳实践，形成改进意见，并未绩效考核提供依据。标杆对照所采用的的可比组织可以是内部的，也可以是外部的。

6.3 数据分析

• 文件分析包括审核和评估任何相关的文件信息。在此过程中，文件分析用于通过分析现有文件，识别与需求相关的信息来获取需求。
• 可供分析的文件包括：

• 协议
• 商业计划
• 业务流程或接口文件
• 业务规则库
• 现行流程
• 市场文献
• 问题日志
• 政策和程序
• 法规文件，如法律、准侧、法令等
• 建议邀请书
• 用例

6.4 决策

• 投票是一种未达成某种期望结果，而对多个未来行动方案进行评估的集体决策技术和过程。本技术用于生成、归类和排序产品需求。

• 一致同意
• 大多数同意：参与决策人数为奇数
• 相对多数同意：候选项超过两个时使用

• 独裁型决策制定是由一个人负责为整个集体制定决策。
• 多标准决策分析借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，以对众多创意或方案进行评估和排序。
  
• 亲和图用来对大量创意进行分组的技术，以便进一步审查和分析。亲和图针对某一问题广泛收集资料，按照资料近似程度、内在联系进行分类整理，归类合并，从而从复杂的现象中整理出思路，抓住本质，并找出解决方法。
• 思维导图把从头脑风暴中获得的创意整合成一张图，用以反应创意之间的共性与差异，激发新创意，它将中心概念与关联概念连接起来，通过训练运用全脑思考，来刺激想象力和创造力。

6.5 人际关系与团队技能

• 名义小组技术是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。

• 提出问题
• 记录想法
• 公开讨论
• 私下投票

• 观察和交谈是指直接查看个人在各自的环境中如何执行工作和实施流程。当产品使用者难以或不愿清晰说明他们的需求时，就特别需要通过观察来了解他们的工作细节。

• 外部观察：旁站观察者观察业务专家如何执行工作
• 内部观察：参与观察者实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。

• 引导与主题研讨会结合使用，把主要相关方召集在一起定义产品需求。

• 能快速定义跨职能需求并协调相关方的需求差异。
• 有助于参与者之间建立信任、改进关系、改善沟通，从而有利于相关方达成一致意见。
• 与单项会议相比，研讨会能够更早发现并解决问题。
• 联合应用开发JAD：用于软件开发行业，注重把用户和开发团队集中在一起，以收集需求和改进软件开发过程。
• 质量功能展开QFD：用于制造行业，帮助确定新产品的关键特征。从收集客户需要开始，然后客观地对这些需要进行分类和排序，并未实现这些需要而设定目标。
• 用户故事：在敏捷方法中广泛应用，对所需功能的简短文字描述，经常产生于需求研讨会。用户故事描述哪个相关方将从功能中收益（角色），他需要实现什么（目标），以及他期望获得什么利益（动机）。

6.6. 系统交互图

• 系统交互图是范围模型的一个例子，它是对产品范围的可视化描绘，显示业务系统（过程、设备、计算机系统等）及其与人和其他系统之间的交互方式。
• 一般来讲，系统交互图需要显示业务系统的输入、输入提供者、业务系统的输出和输出接收者。

6.7 原型法

• 原型是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需的额早起反馈。
• 原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。
• 原型法支持渐进明细的理念，需要反复循环。
• 故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。

7. 输出

7.1 需求文件

• 需求文件描述各种单一需求将如何满足与项目相关的业务需求。
• 一开始可能只有高层级需求，然后随着有关需求信息的增加而逐步细化。
• 需求基准需要时明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的、且主要相关方愿意认可的需求，才能作为基准。

7.2 需求跟踪矩阵

• 需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。
• 优势：

• 把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。
• 提供了在整个项目生命周期中跟踪需求的一种方法，确保被批准的每项需求都能交付。
• 为管理产品范围变更提供了框架。

• 应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。