项目需求变更分析和解决之道.docxVIP

一、令人烦恼的需求变更 　　作为一个 软 件 项 目 经 理，在项目开发进行中，你是否遇到过这样的问题：客户的一个 电话，就推翻了之前你与客户、与你自己的开发 团 队，经过再三讨论而确认定下来的需求。 之后你就重新开始了和客户、和你的开发 团 队进入新一轮的需求谈论中，甚至是无休止的 谈论。甚至要重新设计现有的架构。 　　而面对这种情况，作为 项 目 经 理的你是否会说：“我们无法拒绝客户，但也无法立即满 足他的新需求，所以只好是推到以后再进行完善。”或者，更极端些的想法：客户总是在异 想天开，客户的需求在技术上根本无法实现…… 　　在与客户新的需求论证中，你是否会对需求确认的重要性产生怀疑。因为在一开始已 经多次和客户 沟 通，也在没有任何异议的情况下得到了明确的答复，但当开发项目在不断 演进，客户对系统的理解逐步加深之时，他们最终还是推翻以前自己想要的需求。而这时 你会认为对于需求，只有获取，没有确认。 　　而因为需求变更的原因，致使项目多次的延期后，客户仍然说这不是他们想要的。你 还是在抱怨客户的需求像天气一样一直变个不停，最终，无论是你的抱怨还是客户的需求 变更只会令项目组中的开发人员疲于奔命，无所适从。 　　在你的 软 件项目进行开发之前，你和你的项目成员是否有过这样的想法，在这次 软 件 项目开发中，一定要消除需求变更，不让谈论好的需求发生任何的变更？ 　　首先，这种想法和认识是错误的， 软 件项目开发中的需求变更是不能被完全消除的。 无论是 项 目 经 理还是项目开发人员，最好在项目开始之前就消除这种想法。需求变更是不 可能被消除的，而“消除需求变更”的想法却需要被消除。消除需求变更的所有的努力和想 法，在项目开发进行中通常都是费力不讨好。 　　项目开发过程中，需求的变更是不可避免的 　　虽然一般情况下， 项 目 经 理花费了大量的心力和气力去避免需求变更，可最后需求变 更总是会出现。但这并不意味着项目不应该做这方面的工作，无论是 项 目 经 理，还是开发 人员对于需求变更的正确态度应该和对待 软 件测试的态度一样，在需求变更发生之前尽量 减少需求变更发生的情况，以将需求变更带来的 风 险降到最低。 　　二、需求变更的产生原因 　　在 软 件开发项目中，需求变更可能来自方案服务商、客户或产品供应商等，当然，也 可能来源于项目组内部。 　　对于需求变更发生的原因，细细追究起来无外乎以下几种原因： 　　1、范围没有圈定就开始细化 　　细化工作是由需求分析人员完成的，一般是根据用户提出的描述性的、总结性的短短 几句话去细化的，提取其中的一个个功能，并给出描述（正常执行时的描述和意外发生时 的描述）。 　　当细化到一定程度并开始系统设计时，范围会发生变化，那细节用例的描述可能就有 很多要改动。如原来是人工手动添加的数据，要改成根据信息系统计算出来，而原来的一 个属性的描述要变成描述一个实体等。 2、没有指定需求的基线 　　需求的基线是指是否容许需求变更的分界线。 　　随着项目的进展，需求的基线也在变化。是否容许变更的依据是合同以及对 成 本的影 响，比如 软 件整体结构已经设计出来，是不容许改变需求范围的，因为整体结构会对整个 项目的进度和 成 本有初步预算。随着项目的进展，基线将越定越高（容许的变更将越少）。 　　3、没有良好的 软 件结构适应变化 　　组件式的 软 件结构就是提供了快速适应需求变化的体系结构，数据层封装了数据访间 逻辑，业务层封装了业务逻辑，表示层展现用户表示逻辑。 　　但适应变化必须遵循一些松耦合合原则，各层之间还是存在一些联系的，设计要力求 减少会对接口入口参数产生变化。如果业务逻辑封装好了，则表示层界面上的一些排列或 减少信息的要求是很容易适应的。如果接口定义得合理，那么即使业务流程有变化，也能 够快速适应变化。因此，在 成 本影响的容许范围内可以降低需求的基线，提高客户的满意 度。 　　三、需求变更控制 　　前面已经说过了，在 软 件开发项目开始之前，就要消除“绝不允许发生需求变更”的思 想。在项目进行，一旦发生需求变更，更不要不一味的抱怨，也不要去一味地迎合客户的 “新需求”，而是要管理和控制需求变更。 　　1、分级管理客户需求 　　 软 件开发项目中，“客户永远是对的”和“客户是上帝”并不完全的正确，因为在已经签定 的项目合同中，任何新需求的变更和增加除了影响项目的正常进行以外，还影响到了客户 的投入收益，所以有的时候 项 目 经 理反倒应该为客户着想。 　　对于项目中的需求，可以实行分级管理，以达到对需求变更的控制和管理。 　　一级需求（或变更）是关键性的需求，这