需求变更四的对策.docVIP

需求变更四的对策 　　需求变更频繁发生，如果处理不好更会影响项目团队和客户之间的关系，同时也影响产品的交付。 　　 　　从理论上讲，需求包括业务需求、用户需求和功能需求。业务需求（Business Requirement ）反映了组织机构或客户对系统、产品高层次的目标要求，用户需求（User Requirement ）描述了用户使用产品必须完成的任务，功能需求（Functional Requirement ）定义了开发人员必须实现的软件功能。这些需求在项目执行过程中都可能发生改变，即发生需求变更。 　　需求变更的表现形式也是多方面的，如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。在IT项目中，变更可能来自方案服务商、客户或产品供应商等，也可能来源于项目组内部，比如对项目人员的临时离职会发生突然的需求等。 　　 　　原因 　　 　　1、需求信息错位 　　在需求分析员确定客户需求之前，毫无疑问要和客户做好深度沟通。但是由于沟通渠道的限制，以及双方能力、教育、习惯背景的限制，往往会出现信息沟通偏差，就是我们说的需求信息错位。 　　当客户向需求分析人员提出需求的时候往往是通过自己的想法用一般语言来表达的，而且是基于客户对自己需求的理解角度上表达的，这就引起表达的结果对于真实的需求来说是一种仅仅从某个角度的一般描述，远远不能保证这样的描述可以得到百分之百的正确理解。以前有个盲人摸象的故事，这个例子可以解释一下为什么存在信息的偏差:顾客想要画一头大象，可是却不清楚大象的身子、耳朵、四条腿以及尾巴是什么具体样子，只能描述出这几个部分大致像什么。于是顾客告诉分析员，“我要的是大象，身子象一堵墙，耳朵象扇子，四条腿象四根柱子，尾巴象绳子”。分析员听到这些，就按照自己对墙、扇子、柱子、绳子的理解画出了“大象”。 　　结果可想而知。然而这种现象在软件项目需求变更中并不少见的。 　　这里面还有一个细化工作的问题。细化工作是一般由需求分析人员完成，一般是根据客户提出的描述性的、总结性的文档去细化客户需求，将这种需求细化到一定程度后，就可以提取其中的一个个细小的功能，并给出描述。 　　但是不能光靠分析员做细化工作，还应该把这些细化过的功能描述与客户继续深入地沟通，否则以后将会发生因为细化而引起的不能适应范围的问题，比如原来是手工填入的数据，要改成根据信息系统计算出来，而原来的一个属性的描述要变成描述一个实体等。 　　2、建设期的沟通局限性 　　现实中，一个大中型系统的建设可能要持续较长的一段时间。在整个建设内，当客户提出要求时，因为不能看到系统的运行情况，客户和开发商双方就会认为需求沟通方面不存在什么分歧，然而事实上还常常会有需求最终期限的问题，此时开发商就已经开始工作了。 　　最后当客户从开发商那里拿到差不多可以试用的产品时候，因为现在可以实际操作，他就会对现实的系统提出很多问题，就是我们说的需求变更，比如系统的界面、操作、功能、性能等方面。 　　3、客户所在环境的改变 　　当前客户的运营情况不确定，有可能客户行业的竞争度高，需要随时做出调整和反应，那么他们自然会经常提出需求变更的要求;也有可能客户所在的行业操作不规范，本身存在很多人为因素，这时候开发变更是需要随时准备应变。 　　一般说来客户会要求改变界面，改变操作方式，甚至改变业务，客户甚至会说:“当时我是那样要求的，不过现在我们的业务调整了。”这一切都是由行业大环境成的，所以对于这方面的需求变更必须要有一定的预测措施。 　　4、开发商的系统升级 　　为适应市场需求，或是由于竞争等因素，开发商自身会有可能存在进行开发系统版本的升级或性能改进、设计修正的要求，因此会出现需求变更。这时谁也无法绕开这个问题。 　　从上面的分析可以看出，就算分析人员和客户之间不存在理解分歧，客户对于实际的系统还是会提出一些个人意见，就算没有个人意见，他们自己的业务会变化或环境发生变化，这些都是无法避免的，所以项目团队，或者说是开发商不要梦想会存在多么理想的需求分析，应该从一开始就要有客户需求变更一定会存在的准备。 　　 　　代价 　　 　　任何项目只要存在某个方面变更，那么就要付出对应的代价。需求的变更通常意味着需求的增加，同时也意味着相应的代价。当客户提出新需求的时候，项目开发人员应该分析这些新需求对项目现阶段带来的风险，得出双方实现变更需求所需要的成本，包括时间、人力、资源等方面。 　　同时，在评估代价、与客户讨论的过程中，要让客户了解变更的后果，变更之后面临最大的问题就是项目延期，让客户一起做是否继续修改还是要接受修改后果的决策。这样就会出现三种可能: 　　1、客户接受延期的后果，开发人员按客户要求做出修改，让客户知道为此需要付出延期的代价;