项目事态升级管理程序

项目事态升级管理程序项目事态升级管理程序一、令人烦恼的需求变更作为一个软件项目经理，在项目开发进行中，你是否遇到过这样的问题：客户的一个电话，就推翻了之前你与客户、与你自己的开发团队，经过再三讨论而确认定下来的需求。

之后你就重新开始了和客户、和你的开发团队进入新一轮的需求谈论中，甚至是无休止的谈论，甚至要重新设计现有的架构。

而面对这种情况，作为项目经理的你是否会说：“我们无法拒绝客户，但也无法立即满足他的新需求，所以只好是推到以后再进行完善。

”或者，更极端些的想法：客户总是在异想天开，客户的需求在技术上根本无法实现……在与客户新的需求论证中，你是否会对需求确认的重要性产生怀疑。

因为在一开始已经多次和客户沟通，也在没有任何异议的情况下得到了明确的答复，但当开发项目在不断演进，客户对系统的理解逐步加深之时，他们最终还是推翻以前自己想要的需求。

而这时你会认为对于需求，只有获取，没有确认。

而因为需求变更的原因，致使项目多次的延期后，客户仍然说这不是他们想要的。

你还是在抱怨客户的需求像天气一样一直变个不停，最终，无论是你的抱怨还是客户的需求变更只会令项目组中的开发人员疲于奔命，无所适从。

在你的软件项目进行开发之前，你和你的项目成员是否有过这样的想法，在这次软件项目开发中，一定要消除需求变更，不让谈论好的需求发生任何的变更?首先，这种想法和认识是错误的，软件项目开发中的需求变更是不能被完全消除的。

无论是项目经理还是项目开发人员，最好在项目开始之前就消除这种想法。

需求变更是不可能被消除的，而“消除需求变更”的想法却需要被消除。

消除需求变更的所有的努力和想法，在项目开发进行中通常都是费力不讨好。

项目开发过程中，需求的变更是不可避免的。

虽然一般情况下，项目经理花费了大量的心力和气力去避免需求变更，可最后需求变更总是会出现。

但这并不意味着项目不应该做这方面的工作，无论是项目经理，还是开发人员对于需求变更的正确态度应该和对待软件测试的态度一样，在需求变更发生之前尽量减少需求变更发生的情况，以将需求变更带来的风险降到最低。

二、需求变更的产生原因在软件开发项目中，需求变更可能来自方案服务商、客户或产品供应商等，当然，也可能来源于项目组内部。

对于需求变更发生的原因，细细追究起来无外乎以下几种原因：1、范围没有圈定就开始细化细化工作是由需求分析人员完成的，一般是根据用户提出的描述性的、总结性的短短几句话去细化的，提取其中的一个个功能，并给出描述(正常执行时的描述和意外发生时的描述)。

当细化到一定程度并开始系统设计时，范围会发生变化，那细节用例的描述可能就有很多要改动。

如原来是人工手动添加的数据，要改成根据信息系统计算出来，而原来的一个属性的描述要变成描述一个实体等。

2、没有指定需求的基线需求的基线是指是否容许需求变更的分界线。

随着项目的进展，需求的基线也在变化。

是否容许变更的依据是合同以及对成本的影响，比如软件整体结构已经设计出来，是不容许改变需求范围的，因为整体结构会对整个项目的进度和成本有初步预算。

随着项目的进展，基线将越定越高(容许的变更将越少)。

3、没有良好的软件结构适应变化组件式的软件结构就是提供了快速适应需求变化的体系结构，数据层封装了数据访间逻辑，业务层封装了业务逻辑，表示层展现用户表示逻辑。

但适应变化必须遵循一些松耦合原则，各层之间还是存在一些联系的，设计要力求减少会对接口入口参数产生变化。

如果业务逻辑封装好了，则表示层界面上的一些排列或减少信息的要求是很容易适应的。

如果接口定义得合理，那么即使业务流程有变化，也能够快速适应变化。

因此，在成本影响的容许范围内可以降低需求的基线，提高客户的满意度。

三、需求变更控制前面已经说过了，在软件开发项目开始之前，就要消除“绝不允许发生需求变更”的思想。

在项目进行，一旦发生需求变更，更不要不一味的抱怨，也不要去一味地迎合客户的“新需求”，而是要管理和控制需求变更。

1、分级管理客户需求软件开发项目中，“客户永远是对的”和“客户是上帝”并不完全的正确，因为在已经签定的项目合同中，任何新需求的变更和增加除了影响项目的正常进行以外，还影响到了客户的投入收益，所以有的时候项目经理反倒应该为客户着想。

对于项目中的需求，可以实行分级管理，以达到对需求变更的控制和管理。

△一级需求(或变更)是关键性的需求，这种需求如果不满足，意味着整个项目不能正常交付使用，前期工作也会被全部否定。

这个级别的需求是必须满足的，否则就意味着否定自已的项目成员和成员的所有努力，所以定为“Urgent”。

这通常是属于补救性的debug类型，要救火。

△二级需求(或变更)是后续关键性需求，它不影响前面工作内容的交付，但不加以满足，新的项目内容无法提交或继续，所以是“Necessary”。

一般新模块关键性的基础组件，属于这个级别。

△三级需求是后续重要的需求，如果不被满足会令整体项目工作的价值下降，为了体现项目价值，也是开发人员自已的技术价值的证明，所以定为“Needed”。

一般性的重大的有价值的全新模块开发，属于这个级别。

以上三个等级是应该实施的，但时间性上可以作优先级的排列。

△四级需求是改良性需求，没有满足这类需求并不影响已有功能的使用，但如果实现了则会更好，定级为“Better”。

界面和使用方式的需求，一般在这个档次。

△五级需求是可选性需求，更多的是偶是一种设想，以及一种可能，通常只是客户的的一种个人喜好而已，定级为“Maybe”。

对于四级需求，如果时间和资源条件都允许的话，不妨做下去。

对于五级需求，正如对它的描述一样，做与不做是“Maybe”。

2、全生命周期的需求变更管理各种规模和类型的软件项目的生命周期大致可以分为三个阶段，即项目启动、项目实施、项目收尾。

不要以为需求变更的管理和控制只是发生在项目实施阶段，而是要贯穿在整个项目生命周期的全过程中。

站在全局角度的需求变更管理，需要采用综合变更控制的方法。

(1)项目启动阶段的变更预防正如前面强调的，对于任何软件项目，需求变更都无可避免，也无从逃避，无论是项目经理还是开发人员只能积极应对，而这个应对应该是从项目启动的需求分析阶段就开始了。

对一个需求分析做得很好的项目来说，基准文件定义的范围越详细清晰，用户跟项目经理提出需求变更的几率就越小。

如果需求没做好，基准文件里的范围含糊不清，被客户发现还有很大的“新需求空间”，这时候项目组往往要付出许多无谓的牺牲。

如果需求分析做得好，文档清晰且又有客户签字，那么后期客户提出的变更就超出了合同范围，需要另外收费。

这个时候，项目经理一定要据理力争，此时这并非要刻意赚取客户的钱财，而是不能让客户养成经常变更的习惯，否则后患无穷。

(2)项目实施阶段的需求变更成功的软件项目和失败项目的区别就在于项目的整个过程是否是可控的。

项目经理应该树立一个理念，即“需求变更是必然的、可控的，并且是有益的”。

项目实施阶段的变更控制需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。

控制需求渐变需要注意以下几点：△需求一定要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。

所以，在项目的开始，无论是开发方还是出资方都要明确这一条：需求变，软件开发的投人也要变。

△需求的变更要经过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。

△小的需求变更也要经过正规的需求管理流程，否则会积少成多。

在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。

但正是由于这种观念才使需求逐渐变为不可控，最终导致项目的失败。

△精确的需求与范围定义并不会阻止需求的变更。

并非对需求定义得越细，就越能避免需求的渐变，这是两个层面的问题。

太细的需求定义对需求渐变没有任何效果。

因为需求的变化是永恒的，并非需求写细了，它就不会变化了。

△注意沟通的技巧。

项目开发过程中的实际情况是用户、开发者都认识到了上面的几点间题，但是由于需求的变更可能来自客户方，也可能来自开发方，因此，作为需求管理者，项目经理需要采用各种沟通技巧来使项目的各方各得其所。

(3)、项目收尾阶段的总结能力的提高往往不是从成功的经验中来，而是从失败的教训中得来。

许多项目经理不注重经验教训总结和积累，即使在项目运作过程中碰得头破血流，也只是抱怨运气、环境和团队配合不好，很少系统地分析总结，或者不知道如何分析总结，以至于同样的问题反复出现。

事实上，项目总结工作应作为现有项目或将来项目持续改进工作的一项重要内容，同时也可以作为对项目合同、设计方案内容与目标的确认和验证。

项目总结工作包括项目中事先识别的风险和没有预料到而发生的变更等风险的应对措施的分析和总结，也包括项目中发生的变更和项目中发生问题的分析统计的总结。

3、需求变更管理原则虽然需求变更的内容和类型有各种各样，但需求变更管理的原则却是万变不离其宗。

实施需求变更管理需要遵循如下原则：(1)建立需求基线。

需求基线是需求变更的依据。

在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。

此后每次变更并经过评审后，都要重新确定新的需求基线。

(2)制订简单、有效的变更控制流程，并形成文档。

在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。

同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。

(3)成立项目变更控制委员会(CCB)或相关职能的类似组织，负责裁定接受哪些变更。

CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。

(4)需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。

(5)需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。