与我们的不同。第二，是开发者对需求的理解偏差。有可能是由于缺乏知识，开发者对需求理解错了；还可能是开发团队内部造成的偏差，比如需求调研人员往往同时做好几个项目，在调研完成后便不在开发团队中，这样偏差便在所难免。还有就是内部沟通、人员更替造成的偏差。因此，在这样一个三极世界，需求变更是必然的。
（2）合同签订马虎，没有真正明白客户需求
当我以合同上没有规定的需求不予开发时，客户搬出销售人员的承诺这一招，更让我几乎吐血。销售人员在签订合同时缺乏对客户需求的认真对待，导致需求描述不清，为开发带来了许多困惑和后患。例如，销售人员有时为使客户能够快速地签订合同，往往草率决定和片面同意客户提出的需求。当客户提出新的需求时，往往是销售人员一看“应该”只是一个小小的修改，没有太大的影响，所以直接答应能变更。
该问题的关键是合同签署得太烂，没有把需求明确再签合同，而且也没有把需求变更的流程写入合同。如果在签合同前就把客户需求弄清楚，后期就根本不需要频繁地变更需求。签订合同时明确定义开发需求的范围，可以为以后各项开发工作的开展奠定好的基础。
需求变更为何没完没了？
在软件开发中，最常抱怨的是这样一个问题：客户为什么总是反反复复？造成需求变更没完没了的原因，可以是这样几个方面存在问题。
（1）没有明确的需求变更流程
没有明确的需求变更管理流程，就会使需求变更变得泛滥，在这一点上我尝尽了苦头。并不是所有的变更都要修改，也不是所有变更都要立刻修改，明确需求变更管理流程的目的是为了决定什么类型的变更需要修改和什么时候修改。比如单纯的界面风格问题，就可以先不修改，或者规划一下修改的时间待到以后进行优化。另外，对于核心功能的修改没有严格把关流程，有些小需求看起来工作量不大，但是哪些销售人员或者客户没有考虑到的细节问题实际上需要花费开发人员相当长的时间去完成，从而是捡了芝麻掉了西瓜，得不偿失，使开发进度失控和资源浪费。
（2）没有让客户知道需求变更的代价
对变更的影响没有进行成本评估是需求变更泛滥的根本原因，这是我从单纯的技术人员转变到统筹兼顾成本管理的转变点之一，当然为了这一点我也付出了血与泪，为此饱受公司领导和客户的重重抱怨和责备。变更都是有代价的，应该要评估变更的代价和对项目的影响，要让客户了解需求变更的后果。如果客户不知道需求变更付出的代价，对开发人员的辛苦就会难以体会。在评估代价（包括成本、时间等多方面）过程中，可以请客户一起做判断：“我可以修改，但您能接受后果吗？”
如何有效控制需求变更？
需求变更对软件开发项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以实施需求变更之前必须做好控制。需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。
（1）明确合同约束，建立需求基线
需求变更给软件开发带来的影响有目共睹，所以在与客户签订合同时，可以增加一些相关条款，如限定客户提出需求变更的时间，规定何种情况的变更可以接受、拒绝或部分接受，还可以规定发生需求变更时必须执行变更管理流程。虽然软件开发合同很难在签订之初就能够精确定义每项需求，单靠合同是帮不上忙的，但也不能忽视合同的约束力。
明确和树立需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后（客户参与评审），建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线，做到小需求可以变更，但大方向要力保不频繁变更。例如，对于项目中的需求，可以实行分级管理，以达到对需求变更的控制和管理。
（2）建立变更
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
