第4章 项目整体管理 与 第16章 项目变更管理

了解项目管理知识体系叙述的结构 子过程、ITTO、过程组、知识领域

什么是项目整体管理(P-187) 了解

项目整体管理：包括为识别、定义、组合、统一和协调各项目管理过程组的各种过程和活动而开展的过程与活动。兼具统一、合并、沟通和集成的性质，对受控项目从执行到完成、成功管理干系人期望和满足项目要求，都至关重要。它包括选择资源分配方案、平衡相互竞争的目标和方案，以及管理项目管理知识领域之间的依赖关系。

整体管理过程之一 “制定项目章程”（启动过程组）（P-189） 掌握

制定项目章程：编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程

本过程的作用：明确定义项目开始和项目边界，确立项目的正式地位，高级管理层直述他们对项目的支持。

制定项目章程—输入：项目工作说明书（SOW）（P-190） 掌握

项目工作说明书SOW：对项目需交付的产品、服务或成果的叙述性说明。

包含的内容：1、业务需求；2、产品范围描述；3、战略计划；

提供者：
内部项目：项目启动者或发起人；
外部项目：客户（作为招标文件或合同的一部分）

制定项目章程—输入：商业论证（P-191） 掌握

商业论证：从商业角度提供必要的信息，决定项目是否值得投资。在商业论证中，开展业务需要和成本效益分析，论证项目的合理性，并确定项目边界。（是对SOW进行论证）

制定项目章程—输入：协议（P-190） 掌握

协议：定义了启动项目的初衷。

协议的形式：合同（为外部客户做项目时）、谅解备忘录（MOUs）、服务品质协议（SLA）、意向书等。

制定项目章程—输入：事业环境因素（P-191） 掌握

事业环境因素：能影响项目但项目团队无法控制的任何内外部环境因素（不可控，积极或消极影响）

内部：
组织文化、结构和治理
设施和资源的地理分布
基础设施
项目管理信息系统PMIS
干系人的风险承受力
人事管理制度

外部：
市场条件
社会和文化影响与问题
法律限制
商业数据库
政府或行业标准

制定项目章程—输入：组织过程资产（P-192） 掌握

组织过程资产：执行组织特有并使用的计划、政策、（过程与程序）、（知识库），在项目的全过程中，项目团队成员可以对其进行必要的更新和增补。（遗产，可控）

过程与程序：指南和标准、模板、财务控制程序、变更控制程序、风险控制程序、组织对沟通的要求…
组织知识库：配置管理知识库、财务数据库、测量指标数据库、经验教训知识库，以往项目的档案…

制定项目章程—工具：专家判断（P-193） 掌握

专家判断：可来自具有专业知识或受过专业培训的任何小组或个人（人人都是“砖家”）

制定项目章程—工具：引导技术（P-199） 掌握

引导技术：广泛应用于各项目管理过程，用来帮助团队和个人完成项目活动的关键技术。

制定项目章程—输出：项目章程（P-189） 重点(必须背)

项目章程：由项目启动者或发起人发布的，正式批准项目成立，并授权项目经理动用组织资源开展项目活动的文件。（是项目的“宪法”，是项目经理的“尚方宝剑”）

制定项目章程过程的一些注意点（P-189） 掌握

• 项目由项目以外的实体来启动，如发起人、PMO、项目组合指导委员会等等。
• 经批准的项目章程意味着项目的正式启动。
• 项目章程在项目执行组织与需求组织之间建立起伙伴关系。
• 通过编制项目章程，来确认项目符合组织战略和日常运营的需要。
• 不要把项目章程看做合同，因为其中未承诺报酬或金钱或用于交换的对价。
• 尽早确认并任命项目经理，项目经理应该参与项目章程的制定，以便对项目需求有基本的了解。
• 最好在制定项目章程时就任命，最晚也必须在规划开始之前。

整体管理过程之二“制定项目管理计划”（规划过程组）（P203）掌握

制定项目管理计划：定义、准备和协调所有子计划，并把它们整合为一份综合项目管理计划的过程。

本过程的作用：

• 生成一份核心文件，作为所有项目工作的依据。
• 确定项目的执行、监控和收尾方式
• 可以是概括的或详细的，通过不断更新来渐进明细。一旦被确定为基准，则只能通过提出变更请求， 并 经实施整体变更控制过程批准后，才能变更
  

制定项目管理计划—输入：项目章程（P-203） 掌握

项目团队把项目章程作为初始规划的起点。

制定项目管理计划—输入：其他过程的输出（P-203） 掌握

其他规划过程所输出的任何基准和子管理计划，都是本过程的输入

制定项目管理计划—输出：项目管理计划（P-203） 掌握

项目管理计划组成部分，写下面的16个文件

项目管理计划记录的规划成果（P-202） 重点（必须背）

项目管理计划包含的内容，写下面的11条！

initiating meeting 和 kick-off meeting

Kick off meeting 主要

整合管理过程之三“指导与管理项目工作”（执行过程组）P205 掌握

指导与管理项目执行：领导和执行项目管理计划中确定的工作，并实施已批准变更的过程；

本过程的作用：

• 干计划（按项目管理计划去干活）；
• 干变更（实施已批准的变更）；
• 干接口（接口的整合）；
• 干数据（产生工作绩效数据）；

指导与管理项目工作—输入：项目管理计划（P-207） 掌握

先计划，后执行

指导与管理项目工作—输入：批准的变更请求（P-207） 掌握

批准的变更请求可能是纠正措施、预防措施、缺陷补救。

指导与管理项目工作—工具与技术：项目管理信息系统PMIS（P-208）

指导与管理项目工作—工具与技术：会议（P-208）–掌握

• 交换信息----信息交流会
• 方案评估或者方案设计----方案设计和评审会
• 制定决策----决策制定会

如何召开高效会议（案例可用）：

1. 事先制订一个例会制度、明确会议规则；
2. 放弃可开可不开的会议；
3. 明确会议的目的和期望结果、明确每个参会者的角色；
4. 发布会议通知；
5. 在会议之前将会议资料发给参会人员；
6. 面对面的会议效果最好、也可以借助视频设备；
7. 会议后要总结、提炼结论、达成共识、有行动计划；
8. 会议要有纪要；
9. 做好会议的后勤保障；
10. 不要把各种会议类型混合在一起；

指导与管理项目工作—输出：可交付成果（P-208）–掌握

可交付成果：在某一过程、阶段或项目完成时，必须产出的独特并可核实的产品、成果或服务能力，通常是有形的组件，也可包括项目管理计划。

指导与管理项目工作—输出：工作绩效数据（P-208） 掌握

指导与管理项目工作—输出：变更请求（P-209）–掌握

变更请求：是关于修改任何文档、可交付成果或基准的正式提议。可以是直接或间接的，可以由外部或内部提出，可能是自选或由法律/合同所强制的，可口头提，但必须书面记录。

包括：

整合管理过程之四“监控项目工作”（监控过程组）P-209 掌握

监控项目工作：跟踪、审查和报告项目进展，收集、测量并散发绩效信息，分析测量结果和预测趋势，以便推动过程改进。

本过程的作用：

• 让干系人了解项目的当前状态、已采取的步骤
• 对预算、进度和范围的预测，以便推动过程改进。

监控项目工作贯穿于整个项目，是唯一输出工作绩效报告的过程。

监控项目工作—输入：项目管理计划（P-210） 掌握

监控工作需要测量绩效信息，并进行分析及预测趋势，所以需要将实际绩效和计划做对比。

监控项目工作—输入：工作绩效信息（P-210） 掌握

监控项目工作—工具：分析技术（P-211） 了解

监控项目工作—输出：变更请求（P-211） 掌握

通过比较实际情况与计划要求，可能需要提出变更请求，变更请求可能导致需要收集和记录新的需求。

监控项目工作—输出：工作绩效报告（P-212） 掌握

工作绩效报告：为制定决策、采取行动或引起关注而汇编工作绩效信息所形成的实物或电子项目文件。

变更的常见原因（P-507） 掌握（论文可用）

变更的分类（P-508） 掌握

变更控制委员会（P-509） 掌握

变更控制委员会（CCB）：一个正式组成的团体，负责审议、批准、推迟或否决项目变更，以及记录和传达变更处理决定。CCB由项目所涉及的多方人员共同组成，通常包括用户和实施方的决策人员。

CCB，人可以很少，可以1个人，也可以11个人，但必须是单数。CCB的人员，可以是专职，也可以兼职。

CCB是决策机构，不是作业机构，不会提出变更方案。
CCB不是必须要有，也不是所有的变更请求都必须要由CCB来审批。

CCB只能建立在项目上。PMO是可以建立在项目上，也可以建立在组织上。

变更请求批准人的选择顺序：

1. 首选：项目管理计划或组织流程中指定的责任人。（最准确的说法，但不常见）
2. ** 次选：变更控制委员会（CCB）。（无明确前提描述情况下，默认提交CCB来审批，最常见）**
3. 再选：如题中无以上选项，则可选“PMO”、“发起人”、“项目经理”等。

整合管理过程之五“实施整体变更控制”（监控过程组）P-212 重点

实施整体变更控制：审查所有变更请求、批准变更、管理变更、并对变更处理结果进行沟通的过程。

本过程的作用：

• 从整合的角度考虑记录在案的项目变更，从而降低项目风险。
• 本过程只会审批、管理变更，不会提出变更请求（我们只处理变更，不生产变更）

实施整体变更控制—输入：项目管理计划（P-213） 掌握

会用到变更管理计划，为管理变更控制过程提供指导，记录变更控制委员会CCB的情况

实施整体变更控制—输入：工作绩效报告（P-213） 掌握

对此过程特别有用的工作绩效报告包括：资源可用情况、进度和成本数据、挣值管理（EVM）报告、燃烧图或燃尽图。

燃烧图或燃尽图：在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。

变更文件

变更流程 （与PMP有区别）8步流程 必须背

实施整体变更控制—工具：会议（P-214） 了解

通常指变更控制会议，可由变更控制委员会（CCB）开会审查变更请求，并做出批准、否决或其他决定。

实施整体变更控制—工具：变更控制工具（P-214） 了解

为便于开展配置和变更管理，可以使用一些手工或自动化的工具

实施整体变更控制—输出：批准的变更请求（P-214） 掌握

批准的变更请求应通过指导与管理项目工作过程加以实施。全部变更请求的处理结果，无论批准与否，都要在变更日志中更新。

实施整体变更控制—输出：变更日志（P-215） 掌握

变更日志：用来记录项目过程中出现的变更，被否决的变更请求也应该记录在变更日志中。

实施整体变更控制—输出：项目管理计划更新（P-215） 掌握

对基准的变更，只能针对今后的情况，不能变更以往的绩效。这有助于保护基准和历史绩效数据的严肃性

版本发布和回退计划（P-512） 掌握

对很多软件项目来说，变更就必须版本发布，并制订相应的应急回退方案。

正常项目中，很普遍更新后出现了问题，需要回退前一个版本。

回退步骤：

1. 通知相关用户；
2. 通知各关联系统；
3. 回退存储过程等数据对象；
4. 配置数据回退；
5. 应用程序、接口程序、工作流等版本回退；
6. 回退完成通知各关联系统；
7. 进行回退后测试（如SHAKEDOWN测试）；
8. 通知用户

整合管理过程之六“结束项目或阶段”（收尾过程组）P-215 掌握

结束项目或阶段：完结所有项目管理过程组的所有活动，以正式结束项目或阶段的过程。

本过程的作用：

• 总结经验教训
• 正式结束项目工作
• 为开展新工作而释放组织资源

结束项目或阶段做些什么 补充—掌握

6+2
6个必须做

项目收尾知识点 补充 掌握

行政收尾和合同收尾的异同点 补充 掌握

结束项目或阶段注意点（P-215） 掌握

在项目结束时，项目经理需要审查：
各阶段的收尾信息：确保所有项目工作都已完成，确保项目目标已经实现
范围基准：确保在项目工作全部完成后才宣布项目结束

结束项目或阶段—输入：项目管理计划（P-215） 掌握

项目管理计划规定了项目完工的标准。

要了解结项所需的活动，要看项目管理计划（行政收尾）和合同文件（合同收尾）

结束项目或阶段—输入：验收的可交付成果（P-216） 掌握

在分阶段实施或被取消的项目中，可能会包括未全部完成的可交付成果。

结束项目或阶段—工具与技术：专家判断（P-216） 掌握

用于开展行政收尾活动。由相关专家确保项目或阶段收尾符合适用标准。
主题专家会提供项目收尾的正式授权。

结束项目或阶段—输出：最终产品、服务或成果移交（P-216） 掌握

移交项目所产出的最终产品、服务或成果（在阶段收尾时，则是移交该阶段所产出的中间产品、服务或成果）。

结束项目或阶段—输出：组织过程资产更新（P-216） 掌握

• 项目档案
• 项目或阶段收尾文件：1、表明项目或阶段完工的正式文件；2、把可交付成果移交给他人的正式文件
• 若项目提前终止，需要：1、在正式的收尾文件中说明终止的原因；2、把已完成未完成的可交付成果移交他人。3、把历史信息和经验教训信息存入经验教训知识库，供未来项目或阶段使用。
• 历史信息

项目目标（P-197） 掌握

目的：想要达到的地点或境地或想得到的结果。
目标：行动对象或欲使其达到的境地或标准（具体的、可度量的、可达到的、与企业战略目标相关的、有时间限制的）

目的可能只有一个，而目标可以有多个。
目标的用途之一是衡量目的是否已经达到，结果是否符合事先说明的需要和要求。

成果目标和约束目标（P-198） 掌握

成果目标（产品目标）：通过生产，开发出满足客户要求的产品、系统、服务或成果等。
约束目标（管理目标、过程目标）：在完成成果目标的同时，又要满足时间进度、成本费用、质量要求、资源限制等约束条件要求的目标。

要分清成果目标和约束目标的轻重缓急，一般来说，约束目标应让位于成果目标。

制定目标的注意点：

1. 将成果目标和约束目标区分开来；
2. 将目的和手段区别开来；
3. 不制定无法量化或无法实现的目标；
4. 不转移项目管理人员的努力方向；

第4章 项目整体管理

第4章 项目整体管理 主要ITTO汇总

【信息系统项目管理师】第十六章 项目变更管理（考点汇总篇）

考点分析与预测

变更管理是项目整体管理的一部分，上午考题会出1分左右，已经包括在项目整体管理中。下午案例考变更管理的可能性也是很大的。如果论文题目是整体管理，必然要谈谈项目整体管理。所以本章应该是重点。而且在日常工作中，几乎没有项目是不需要变更的。本章节可以结合项目整体管理一起看。

知识点汇总

项目整体管理的知识点汇总：【信息系统项目管理师】第四章 项目整体管理（考点汇总篇）_千月星跡-CSDN博客

项目变更管理思维导图：【信息系统项目管理师】第十六章 变更管理思维导图_千月星跡-CSDN博客

章节目录

1.项目变更管理的基本概念
1.1 项目变更产生的原因
1.2 项目变更的分类
1.3 项目变更的含义
2.项目变更管理原则
3.变更管理的组织结构与工作程序
3.1 组织机构
3.2 工作程序
4.项目变更管理的工作内容
4.1 严格控制项目变更申请提交
4.2 变更控制
4.3 变更管理与其他项目管理要素之间的关系
5.版本发布和回退计划
5.1 发布前准备
5.2 应急回退方案
5.3 版本发布和回退实施过程总结

1.项目变更管理的基本概念
根据变更性质可分为：重大变更，重要变更，一般变更。通过不同审批权限控制。
根据变更的迫切性，可以分为：紧急变更，非紧急变更。通过不同变更处理流程进行。
根据变更所发生的领域和阶段，可分为进度变更、成本变更、质量变更、设计变更、实施变更和工作（产品）范围变更
根据变更来源可分为内部变更和外部变更
根据变更类型来分有四个种类：预防措施，纠正措施，缺陷补救，更新

2.项目变更管理原则
原则：项目基准化，变更管理过程规范化。
包括：基准管理；变更控制流程化；明确组织分工；评估变更的可能影响；妥善保存变更产生的相关文档。

3.变更的工作程序
工作程序：1.变更申请；2.对变更进行初审；3.变更方案论证；4.CCB审查；5.发出变更通知并实施变更；6.变更实施监控；7.变更效果评估；8.判断发生变更后的项目是否已纳入正常轨道。
超出基线的变更要走变更流程，不超出基线的变更，不必走变更流程。
项目经理在变更中的作用：响应变更提出者的需求，评估变更对项目的影响及应对方案，将需求由技术要求转化为资源需求，供授权人决策。并根据评审结果，实施即调整基准，确保项目基准反映项目的实际情况。
变更审查过程：审查通常是文档汇签的形式，重大的变更审查可以包括正式会议形式。
变更评估从以下几方面进行评估：
1.首要依据是项目基准
2.还需结合变更的初衷来看，变更所要达到的目的是否已经达成。
3.评估方案中的技术论证，经济论证内容与实施过程的差距并触发解决。

4.项目变更管理的工作内容
变更管理涉及范围，进度，成本，质量，人力资源，合同管理等多个方面。
对进度的变更控制：
1.判断项目进度的当前状态
2.对造成进度变化的因素施加影响
3.查明进度是否已经改变
4.在实际变化出现时对其进行管理
对合同变更的控制：
1.合同变更控制系统规定合同修改的过程
2.包括文书工作，跟踪系统，争议解决程序，批准变更所需的审批层次
3.合同变更控制系统应当与整体变更控制系统结合起来。

项目规模小，关联影响小的时候变更的提出和处理过程可在操作上力求简便，高效。还需要注意以下几点：
1.防止不必要变更，减少无谓的评估，提高必要变更通过效率。
2.对变更的确认应当正式化
3.变更的操作过程应该规范化

在项目整体压力较大的情况下，更需强调变更的提出，处理的规范化。可以使用分批处理，分优先级等方式提高效率。如同繁忙的交通道路，如果红绿灯变化频繁，其实效不是灵活高效，而是整体通过能力的降低。
变更管理和配置管理是相互关联的两套机制。变更管理由项目交付或基准配置调整时，由配置管理系统调用。变更管理最终应将对项目的调整结果反馈给配置管理系统，以确保项目执行与对项目的账目相一致。

5.版本发布和回退计划
在版本发布前，对每次版本发布的风险做出相应的评估
对版本发布的过程checklist做严格的评审
在评审发布内容时，对存在的风险的发布做重点评估
确定相应的回退范围，确定相应的回退策略准备以下回退方案。

大话变更管理

许多项目的失败情况是由于变化的处理不当，有些变更是积极的，有些则是消极的，做好变更管理可以使项目的质量，进度，成本管理更加有效。反之要是变更处理不当，直接会导致项目的失败。
对于变更管理的实质，随着项目建设过程中我们对项目认知的不断提高，需要不断的调整努力方向和资源配置，来满足客户的需求。
变更管理有两个原则：其一，使管理基准化（配置管理），其二，使变更管理流程化（流程管理）过程保证项目的成功。

1.变更申请
在项目中所有的干系人都可以提出变更，变更是通过书面的，所以就有了变更日志来记录变更需求。从客户那里，项目的需求会变更，即使是在团队内部，也会因为进度，质量，成本出现了与项目基准的偏差而发生了变更。这些申请的变更，都由项目经理首先进行响应。
变更分很多种类，有紧急非紧急的，内部和外部的，有质量，进度或成本相关的，还有一种叫推定变更。作为项目经理，在日常的管理中，要特别注意推定变更，通过往来的邮件或其他沟通方式的管理去找出来，同时也要教育干系人，变更依赖申请时，要用正式书面形式写到变更日志中。为什么不先分析影响在提交变更请求？因为团队该花时间在项目工作上，没有那么多时间分析影响。

2.变更评估
项目经理在确认变更日志中的变更内容后，如果干系人提出的变更信息不够全面，首选就得通过沟通去问变更需求。在对变更需求有了一个统一的认识后，确认变更的影响范围，是否是有价值的变更，是否真的需要变更，当项目经理一个人无法判断时，还可以召开变更方案论证会，记录充分讨论的结果到变更日志中，方便供CCB决策。PMBOK中说所有的变更都要经过CCB的审批后才能够实施，但是在实际的工作中，只有超出项目基线的变更需要走变更流程，基线以内的变更就不用走变更流程了。如果变更太多太大，势必会影响整体的项目进展。这个时候可以看看是否有必要终止现在的就可能需要修改项目章程，甚至可以终止现行项目，而另外启动一个新的项目。

3.变更决策
项目变更控制委员会在收到变更日志和对于变更的评估之后，就可以判断变更实施的要否了。首先自然要看看该项变更是否会改变项目的三大基准，再看看项目经理对于变更的评估结果，比如质量镀金的，或者没有价值的变更，直接拒了；对于真正需要的变更，给予审批通过。

4.变更实施
项目经理在拿到审批后变更日志后，就可以开始着手变更了。对于需要改基准的变更，先修改项目管理计划以及项目管理文件，然后根据调整后的计划，安排合适的资源去实施变更。因为变更而改动了计划改动了基准，通知给需要了解情况的干系人是十分需要的。
变更是整体项目的一部分，我们项目经理对其的监控也必不可少。

5.变更验证
批准的变更也是项目范围的一部分，对应好变更就会有变更相应的可交付成果的产生。这个可交付成果自然和其他可交付成果一样，需要通过确认范围来验收，看看本次变更是否达到我们当初的目的，本次变更跟我们之前预期和想象中差距到底大不大。变更实施后项目是否已经纳入了正常轨道。

6.沟通存档
在变更验收通过后，把包括变更产生的可交付成果，项目管理文档等都放入指定的配置库中存档。同时告诉干系人，他们要求的变更需求已经对应好了，将在下次版本发行时发布。
当积累的一定数量的变更，根据配置管理计划，我们要对变更做成基线，发布版本。发布版本前，我们该通过Checklist检查可交付成果是否满足要求，并做项目的风险评估后，向干系人发布变更。
发布的变更用户不满意的时候该怎么半？还好我们在发布版本的同时制定了回退计划，在配置管理中，根据回退计划，将发行库中的内容进行回退，因为良好的配置管理，所以回退版本也变得不那么复杂了。

一、引言

由于目前公司内部对产品的需求变动都只是口头或邮件中进行通知，并没有进行内部评审和相关需求变动后的记录，导致后续出的产品某些需求增加了，某些没有进行增加。这样就会导致测试得到的信息不完整，以及后续产品的维护困难。在这里书写一份规范说明书，希望能得到一些改善。

二、目的

控制需求变化引起的开发、测试与需求不一致的情况，约束需求分析的完整性。保证每一次的需求改动都能有相关的记录。

三、角色与职责

1、市场人员

1）负责产品需求的提交以及解答项目开发过程中遇到的需求问题。

2） 负责与客户的沟通确认，并及时反馈客户最新需求。

3）负责与项目经理的沟通

4）负责与客户协调沟通需求变更中需求部分存在的差异

5）负责将需求变更中的需求提供给客户签字确认

2、 项目组长

1）负责协调变更的需求并对变更的需求有拒绝的权利

2）负责对变更的需求部分设计的修改

3）保证项目的开发与需求的一致性

4）确定开发进度是否需要进行变更

5）分配新需求给相关开发人员

3、测试组长

1）负责相应测试需求分析书的修改

2）负责把最新需求及时传达到测试人员

3）保证测试进度与开发进度一致性

4）负责与项目组长及时确认最新需求

4、测试人员

1）负责更改测试用例，保证用例与需求同步

2）调控测试进度，保证任务的正常完成

5、项目经理

1）参与需求修改的评审工作

2）最终确认需求是否进行修改

6、配置管理员

1）负责更新需求文档，记录需求更改记录

2）负责需求变更信息的发布与跟踪

四、需求变更处理流程图

需 求变更有3种情况，一种是客户提出来要进行修改，增加需求等，一种是公司内部人员提交的建议，还有就是开发人员自己修改流程（修改后的效果比前面的更加 好），另外需求变更可能是比较小的改动，另外一种就是可能涉及到整个产品流程，这就是比较大的需求改动。下面就按照上面的3种情况进行画出流程图：

1、需求变更流程(客户提出需求变更)

1）执行条件：

客户提出需求变更

图：需求变更流程(客户提出需求变更)

2）流程说明：

需求来源：客户提交相关需求变更

审核需求变更：评估如果实现该需求，需要的时间、人力成本多少；并评估对项目工期影响有多大？判断那些需求能够目前解决，那些需要留到下一版本解决。最后输出一份审核确认表反馈给客户，和客户进行商讨。参与评审的人员要包含项目经理，项目组长，测试组长，市场人员。

配置管理员：对变更需求进行记录，需求文档进行更新，并通知相关人员

项目组长：负责调整相关开发进度表，评估任务时间，分发给相关开发人员

测试组长：根据变更需求和开发进度，对测试进度进行相对应调整，并修改测试需求分析书，分发需求更新给相关测试人员。测试人员对用例进行补充，修改。

客户提交的变更需求最后必须让客户进行签字确认。

2、需求变更流程（内部提出需求变更）

1）执行条件：

对项目进度不会影响严重

与客户原始需求无偏差

图：需求变更流程（内部提出需求变更）

2）流程说明：

内部需求变更来源：公司内部人员发现逻辑，需求上的问题，或功能上的建议以及开发、测试人员提出的需求不一致内容。

需求变更类型：需求有误、需求有遗漏、需求不明确。

需求变更审核：内部提交的需求应该经过项目经理，项目组长，测试组长，市场人员共同的确认才能确认是否修改。

项 目组长：评审需求变更部分的工作量，判断需求变更的内容是否对开发进度有影响，如果需求变更对开发进度有影响，项目组长可以拒绝变更；将变更内容放入下一 版本进行修改，若市场人员认为必须在本版中进行修改，项目组长可以将变更的内容提交给项目经理进行处理，并决定是否在本版中进行修改。

需求信息发布：经过需求人员和项目组长的沟通、协调确定在本版中进行修改的需求变更，需求人员需要将变更内容的信息，以邮件方式通知相关人员。

配置管理员：对需求变更进行备案。

开发，测试：开发、测试人员接收到需求变更内容后首先审核设计文档和测试文档，修改变更的地方。并根据变更后的文档进行开发和测试。

五、附件

版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。

本文出自hjjlearning的51Testing软件测试博客：http://www.51testing.com/?18049