目录(?)[+]
相信做软件开发的我们，大家都有这样的体会，当我们辛辛苦苦的熬了几个月的通宵、加班后，终于完成了客户提出的V1.0功能需求，当我们大家准备按部就班的进行系统上线时，客户、企业用户突然改变了需求，不想这么做了，提出了新的需求，新的变动，这样对于我们整个团队来说，正如晴天霹雷，很恐怖的事情啊，因为有时候，用户只是简单的一句话，但是对于系统的调整来说工作量是非常大的。
需求变更，本应是客户的权力，但也是实施顾问的为难之处。如果确需变更，当然要满足客户需要。问题是不能让变更权力滥用，把一些无关痛痒的变更宠惯养成堂而皇之的变更。记得在做各个事业单位系统的时候，对于客户提出的变更，无论大小都给予解决，客户对此是非常满意，然而，项目进度却拖的很长，项目一再延期，这样导致开发小组中的部分成员有些不耐烦了，来一点需求，修改一点，这样确实很烦人的啊.
但是如何我们对客户的要求一概不理，自顾自地按照最初的需求和计划实施，最终很可能由于没有用户的参与，使得系统与用户的需求相差甚远，导致验收通不过，公司的利益受损，对于客户来说，达不到需求的满足也浪费了投资事实上，客户不满意，则项目就不算成功，实施顾问辛勤劳动最后就只能落得个"没有功劳，只有苦劳"的份。
但按前一种"谦虚型"做法，完全顺着客户的意见走，客户满意度就一定会高吗?其实也不一定。由于需求变更会带来工作量的大量增加，甚至可能会出现大量的无效劳动。而且，频繁变动的需求也会导致实施质量下降，留下许多隐患。因此，一味的迁就用户将会使进度一拖再拖，实施方案一改再改，变更越来越多，士气越来越疲，公司越来越不满意，用户越来越急。到最后，实施顾问会发现这个项目已经成为了一个"不可能完成的任务"。
需求变更为什么总是做不完呢？
现实中的软件开发就是这样，新开发的软件不可能一次性全部都提出来，可能客户自己都不知道自己想要开发软件是什么样子，只是简单的实现他自己的功能，咱们做出来的V1.0使他们逐步的有意识的帮助他们理清这个软件的样子。
需求变更的表现形式是多方面的，如客户临时改变想法、客户的习惯、项目预算增加或减少、国家政策的改变、客户对功能需求改变等。
我们要正确的认识客户的这种需求变更，应以对等的心态来面对！
需求变更引发的一系列问题：
1：需求模糊了
在我们开发软件的过程中，对客户的工作环境、流程的不熟悉，对业务了解的不深刻以及政府部门的项目经常受国家的政策的变动而影响等等，我们拿不准客户真正想做什么了？来回的变动使我们有些迷茫。
2：系统的灵活性差
满足客户的工作习惯、新功能的拓展、算法的灵活性、细节的增删改查，极大的反应了系统的灵活性太差啦，后期的维护基本上都是超过开发时间的两三倍时间。
3：开发周期延长
需求的变更，使得开发周期延长给开发小组人员一种意识类似进入了开发周期"无期徒刑"，大家毕竟每个人的事情任务也很多，需求的变更，导致了开发周期的加长，修改这个、又改那个，修改这个对其他部分的影响变动很大，系统各个部分的耦合性太大了。
没有阶段性成功的标志，每天在加班加班中进展的度过，应该项目经理给一周应有一个总结性的会议，展示一下大家自己的成果，也算是给自己的奖励吧。
4：开发人员心态变化
大家不淡定了，着急了，慌了，不想干了、个人心情会影响到整个团队、团队的士气低下，大家开不足马力来工作了，这样势必会影响整体开发的进度。
5：自身定位不足
我们不是一个人在干一件事，是整个团队再做，不是自己那一部分完成了，就完事大吉了，组员之间要互相交流，沟通好相互交互的部分，为了我们的项目顺利达标完成！
问题---总括
面对用户需求的频繁变化，我们hold不住了，不能正确的面对，老是觉得客户的变更是不对的……
当然我们要静下心来证实一点：客户的需求变更是对的，满足其工作需求、现实中的系统需求不可能一次性的全部提出，因此我们要以对等的心态来面对客户的需求。
应对方案
1：架构方面
重思设计理念、架构的使用、系统设计要灵活。
2：文档跟进
(1)合同签订马虎，没有真正明白客户需求
(2)调研时没有深入理解客户需求
(3)没有明确的需求变更管理流程确认客户是否接受变更的代价
3：对需求变更的主动管理
(1) ：成立变更控制委员会CCB
(2) ：严格执行
(3) ：互换角度，为公司利益着想
4：零星变更，集中处理
(1) ：对于零星变更，集中研究、批量处理
(2) ：严格执行
(3) ：互换角度，为公司利益着想
5：敏捷开发
使用敏捷开发的思想作为指导来应对客户的变更，这个需要大家实施体会……
措施实施的过程当中应当注意的问题
(1)合同签订马虎，没有真正明白客户需求
签订合同时缺乏对客户需求认真对待，导致需求描述不清，为后期的实施工作带来困惑。为使客户能够快速的签订合同，往往草率决定和片面同意客户提出的需求。当客户提出新的需求时，往往是销售顾问一看"应该"只是一个小小的修改，没有太大的影响，所以直接答应能变更。
该问题的关键是合同签署的太烂，没有把需求明确再签合同，而且也没有把需求变更的流程写入合同。如果在合同时把客户需求弄清楚，后期就根本不需要频繁的变更需求。签订合同时明确定义项目需求的范围，可以为以后各项实施工作的开展奠定深厚的基础。
(2)调研时没有深入理解客户需求
不熟悉可以的真正的工作环境、工作流程，在需求调研分析阶段，项目组成员和客户的深入交流是减少频繁需求变更的关键阶段之一。但是由于双方的误解通常使需求交流难以进行。更严重的是，实施顾问只根据用户提出的描述性、总结性的短短几句话去制定实施方案，没有真正挖掘和按客户的需求去制定实施计划。当客户头脑一热或领导一拍脑袋提出新的需求时，实施顾问往往也就不能区分客户真正需求和镀金需求。如果项目组对客户需求的细节了解不充分，双方对需求的理解就会产生差异，就会导致移交进销存系统时才使问题暴露出来，客户只能频繁的提出需求变更。
(3)没有明确的需求变更管理流程
没有明确的需求变更管理流程，就会使需求变更变得泛滥。并不是所有的变更都要修改，也不是所有变更都要立刻修改，需求变更管理的目的是为了决定什么类型的变更需要修改和什么时候修改。
界面风格问题，就可以先不修改，或者规划一下修改的时间待到以后进行优化。另外，对于核心模块的修改没有严格把关流程，有些小需求看起来工作量不大，但是实际上实施顾问和开发顾问要耗费比较长的时间去完成这些销售顾问或者客户没有考虑到的细节问题。
更好的约束客户
（1）合同制（虽说没有法律效益，但是在一定程度上可以约束客户），咱们以后要让客户知道需求变更的代价；在和客户接触时应该挑明态度，特别是要让他们清楚需求随意变更所带来的代价和风险。如果客户认为代价太大，那么开发人 员就没有必要及时修改，按原来的进度走，但仍要记录变更，待下一版本在修改。
（2）确认客户是否接受变更的代价
(3)每月变更记录上报双方领导
最后，实施顾问要将有关变更措施和记录随时抄报双方最高层留档备案，可采取简报、文件、抄报、抄送、会议等多种形式。掌握主动权，逐步让不合理的随意频繁变更，成为客户不好意思开口的尴尬事件，尽快形成正常的项目执行氛围和良好的工作习惯，也为可能受到变更所带来的责任问题留下伏笔。
拓展思想反思
（1）与客户交流要耐心，学会如何来维持客户。
（2）心态的成长、客户交流的能力、技术的娴熟，最主要的心态、客户沟通的能力才是我们最需要锻炼的，珍惜这样的机会吧、项目开发、项目的维护、客户交流的机会处处我们再得到锻炼。
项目管理是作为项目经理必备的素质，通过这样的机会，好好学习，为以后的工作中搭好桥梁的作用、快速成长！，接下来会逐步的学习一些项目管理的知识和大家分享！
转http://blog.csdn.net/lishehe/article/details/22036893