下面是小编为大家整理的项目管理中需求变更分析和解决之道（完整文档）,供大家参考。
项目管理中的需求变更分析和解决之道
一、令人烦恼的需求变更
作为一个软件项目经理，在项目开发进行中，你是否遇到过这样的问题：客户的一个电话，就推翻了之前你与客户、与你自己的开发团队，经过再三讨论而确认定下来的需求。之后你就重新开始了和客户、和你的开发团队进入新一轮的需求谈论中，甚至是无休止的谈论。甚至要重新设计现有的架构。
而面对这种情况，作为项目经理的你是否会说：“ 我们无法拒绝客户，
但也无法立即满足他的新需求，所以只好是推到以后再进行完善。
” 或者，更极端些的想法：客户总 是在异想天开，客户的需求在技术上根本无法实现 ……
在与客户新的需求论证中，你是否会对需求确认的重要性产生怀疑。因为在一开始已经多次和客户沟通，也在没有任何异议的情况下得到了明确的答复，但当开发项目在不断演进，客户对系统的理解逐步加深之时，
他们最终还是推翻以前自己想要的需求。而这时你会认为对于需求，只有获取，没有确认。
而因为需求变更的原因，致使项目多次的延期后，客户仍然说这不是他们想要的。你还是在抱怨客户的需求像天气一样一直变个不停，最终，无论是你的抱怨还是客户的需求变更只会令项目组中的开发人员 疲于奔命，无所适从。
在你的软件项目进行开发之前，你和你的项目成员是否有过这样的想法，在这次软件项目开发中，一定要消除需求变更，不让谈论好的需求发生任何的变更？
首先，这种想法和认识是错误的，软件项目开发中的需求变更是不能被完全消除的。无论是项目经理还是项目开发人员，最好在项目开始之前就消除这种想法。需求变更是不可能被消除的，而 “ 消除需求变更 ” 的想法却需要被消除。消
除需求变更的所有的努力和想法，在项目开发进行中通常都是费力不讨好。
项目开发过程中，需求的变更是不可避免的
虽然一般情况下，项目 经理花费了大量的心力和气力去避免需求变更，可最后需求变更总是会出现。但这并不意味着项目不应该做这方面的工作，无论是项目经理，还是开发人员对于需求变更的正确态度应该和对待软件测试的态度一样，在需求变更发生之前尽量减少需求变更发生的情况，以将需求变更带来的风险降到最低。
二、需求变更的产生原因
在软件开发项目中，需求变更可能来自方案服务商、客户或产品供应商等，当然，也可能来源于项目组内部。
对于需求变更发生的原因，细细追究起来无外乎以下几种原因：
1 1 、范围没有圈定就开始细化
细化是由需求分析师完成的。一般是根据用户提出的几个描述性、总结性的词语进行提炼，提炼出每个功能，并给出一个描述( ( 正常执行时的描述和发生意外时的描述) ) 。
当详细到一定程度，系统设计开始的时候，范围会发生变化，详细用例的描述可能会有很多变化。如果原始数据是手工添加的，则应根据信息系统进行计算，并将属性的原始描述改为描述实体。
2 2 、没有指定需求的基线
需求基线是指是否允许需求变化的分界线。
随着项目的进展，需求的基线也在变化。是否容许变更的依据是合同以及对成本的影响，比如软件整体结构 已经设计出来，是不容许改变需求范围的，因为整体结构会对整个项目
的进度和成本有初步预算。随着项目的进展，基线将越定越高（容许的变更将越少）。
3 3 、没有良好的软件结构适应变化
基于组件的软件体系结构提供了一种能够快速适应需求变化的体系结构。数据层封装数据访问逻辑，业务层封装业务逻辑，表示层呈现用户表现逻辑。
但适应变化必须遵循一些松耦合合原则，各层之间还是存在一些联系的，设计要力求减少会对接口入口参数产生变化。如果业务逻辑封装好了，则表示层界面上的一些排列或减少信息的要求是很容易适应的。如 果接口定义得合理，那么即使业务流程有变化，也能够快速适应变化。因此，在成本影响的容许范围内可以降低需求的基线，提高客户的满意度。
三、需求变更控制
前面已经说过了，在软件开发项目开始之前，就要消除 “ 绝不允许发生需求变更 ” 的思想。在项目进行，一旦发生需求变更，更不要不一味的抱怨，也不要去一味地迎合客户的“ 新需求 ” ，而是要管理和控制需求变更。
1 1 、
分级管理客户需求
软件开发项目中， “ 客户永远是对的 ” 和 “ 客户是上帝 ” 并不完全的正确，因为在已经签定的项目合同中，任何新需求的变更和增加除了影响项 目的正常进行以外，还影响到了客户的投入收益，所以有的时候项目经理反倒应该为客户着想。
对于项目中的需求，可以实行分级管理，以达到对需求变更的控制和管理。
一级需求（或变更）是关键性的需求，这种需求如果不满足，意味着整个项目不能正常交付使用，前期工作也会被全部否定。这个级别的需求是必须满足的，否则就意味着否定自已的项目成员和成员的所有努力，所以定为 “Urgent” 。
这通常是属于补救性的 g debug 类型，要救火。
二级需求（或变更）是后续关键性需求，它不影响前面工作内容的交付，但不加以满 足，新的项目内容无法提交或继续，所以是 “Necessary” 。一般新模块关键性的基础组件，属于这个级别。
三级需求是后续重要的需求，如果不被满足会令整体项目工作的价值下降，为了体现项目价值，也是开发人员自已的技术价值的证明，所以定为 “Needed” 。一般性的重大的有价值的全新模块开发，属于这个级别。
项目管理者联盟，项目管理问题。
以上三个层次都要实施，但可以在时间上区分轻重缓急。
四级需求是改良性需求，没有满足这类需求并不影响已有功能的使用，但如果实现了则会更好，定级为 “Better” 。界面和使用方式的需求，一般在这个档次。
五级需求是可选性需求，更多的是偶是一种设想，以及一种可能，通常只是客户的的一种个人喜好而已，定级为“Maybe” 。
对于四级需求，如果时间和资源条件都允许的话，不妨做下去。对于五级需求，正如对它的描述一样，做与不做是“Maybe” 。
2 2 、全生命周期的需求变更管理
各种规模和类型的软件项目的生命周期大致可以分为三个阶段，即项目启动、项目实施、项目收尾。不要以为需求变更的管理和控制只是发生在项目实施阶段，而是要贯穿在整个项目生命周期的全过 程中。
从全局的角度来看，需求变更管理需要采用全面变更控制的方法。
（1 1 ）
项目启动阶段的变更预防
如前所述，对于任何一个软件项目来说，需求变更都是不可避免的，不可避免的，无论是项目经理还是开发人员都只能积极应对，而这种应对要从项目启动的需求分析阶段开始。
对一个需求分析做得很好的项目来说，基准文件定义的范围越详细清晰，用户跟项目经理提出需求变更的几率就越小。如果需求没做好，基准文件里的范围含糊不清，被客户发现还有很大的 “ 新需求空间 ” ，这时候项目组往往要付出许多无谓的牺牲。
如果需求分析做得好，文档清晰，客户签字，那么后期客户提出的变更就超出了合同的范围，需要额外收费。这时候项目经理一定要据理力争。这时候这不是故意赚客户的钱，而是不让客户养成勤换的习惯，否则后患无穷。
（2 2 ）
项目实施阶段的需求变更
成功的软件项目和失败的项目的区别在于项目的全过程是否可控。
项目经理应该树立一个理念，即 “ 需求变更是必然的、可控的，并且是有益的 ” 。项目实施阶段的变更控制需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。
控制需求渐变需要注意以下几点：
需求一定要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。所以，在项目的开始，无论是开发方还是出资方都要明确这一条：需求变，软件开发的投人也要变。
需求的变更要经过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。
小的需求变化都要经过正规的需求管理流程，否则积少成多。
在实践中，人们往往不愿意对小的需求变更实施正式的需求管理过程，这降低了开发效率，浪费了时间。但也正是因为这种观念，需求逐渐变得不可控，最终导致项目失败 。
需求和范围的准确定义不会阻止需求的变更。
并非对需求定义得越细，就越能避免需求的渐变，这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非需求写细了，它就不会变化了。
注意沟通的技巧。
项目开发过程中的实际情况是用户、开发者都认识到了上面的几点间题，但是由于需求的变更可能来自客户方，也可能来自开发方，因此，作为需求管理者，项目经理需要采用各种沟通技巧来使项目的各方各得其所。
（3 3 ）、项目收尾阶段的总结
能力的提高往往不是从成功的经验中来 ，而是从失败的教训中得来。许多项目经理不注重经验教训总结和积累，即使在项目运作过程中碰得头破血流，也只是抱怨运气、环境和团
队配合不好，很少系统地分析总结，或者不知道如何分析总结，以至于同样的问题反复出现。
实际上，项目总结应作为现有项目或未来项目持续改进的重要组成部分，也可作为项目合同、设计方案内容和目标的确认和验证。项目总结包括对项目中预先识别的风险和意外变化的应对措施的分析和总结，以及对项目中的变化和问题的分析和统计。
3 3 、
需求变更管理原则
虽然需求变更的内容和类型有各种各样，但 需求变更管理的原则却是万变不离其宗。实施需求变更管理需要遵循如下原则：
(1) 建立需求基线。基线是需求变化的基础。在开发过程中，在需求被确定和评审( ( 用户参与评审) ) 之后，可以建立第一个需求基线。在每次变更和评审之后，应该再次确定新的需求基线。
（2 2 ）
制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。
（3 3 ）
成立项目变更控制委员会（ CCB ）或相关职能的类似组织，负 责裁定接受哪些变更。B CCB 由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。
(4) 需求变更必须先申请，后评估，最后与变更大小同级评审确认。
(5) 需求发生变化后，受影响的软件计划、产品和活动也应相应地发生变化，以便与更新的需求保持一致。
推荐访问:项目管理中需求变更分析和解决之道 项目管理 变更 解决之道
