下面说说程序员都觉得头痛的需求更改的问题，有时客户明明上午说好了这样做的需求，到了下午又要改成那样做了，这样编好的程序又要修改或是重写了。这种情况在项目的开发阶段程序员还可以忍受，很多情况下项目到了测试阶段甚至是上线阶段的时候，用户还会提出功能变更的要求。面对用户需求的不断变更，程序员倍感头痛但也无可奈何，抱怨归抱怨，还是只能按照用户的要求去做。可以说，项目越大，用户需求变化的概率就越大。

既然用户需求不断变化是一种客观规律，那么程序员在心态上就要进行调整，将用户需求不能变化调整为用户需求一定会变化，树立起“变正常，不变不正常”的观点。做国内的外包要保持一个好的心态，遇到改要坚强，改十遍八遍我觉得很正常，接受不了的接单时就慎重。有了这样的心态，我们就不会去抱怨用户需求了，就会对用户需求的变更有更多的理解。其实，有时候越往后变更的代价要比现在变更的代价大得多。举例来说，如果一个用户在系统开发期内提出一个需求变更，程序员就可以在开发期内解决；如果用户在系统上线后提出同样的需求变更，那这个变更可能对其他程序产生重大影响，甚至对现有系统架构产生影响。

程序员一般性格比较急，用户一提出修改往往马上会按用户的要求去改程序。虽然一般情况下用户要求的时间比较紧，但程序员还是不要急于修改为好。因为用户提出的修改意见不一定全是想得比较周全的。在现实中，程序员刚刚按用户需求改好了，这个时候用户又提出新的要求了，这种现象并不少见。

需求产生变更无非是以下几个原因，一是需求分析不够深入，没有挖堀出潜在的需求，那么就应该多花些时间在需求的分析上。二是客户不了解需求过程，任意妄为，随意修改已经达成的需求。遇到这种情况，那么在需求分析开始前，可以与客户一起进行一次需求分析的培训，以求达成一致。三是没有最基本的配置管理。配置管理将首先确定需求，一旦确定，需求变更须谨慎进行。

这时，你也要问问自己，你们的需求当时是不是做得很细。做需求的时候，客户提出的这些修改意见是不是你们当时已经提出过了，而且他们已经否定了，如果没有，那么就是你的问题。作为一个项目领头人，你的经验一定要比客户多，如果你做行业软件，那么你一定要对该行业的业务知识非常熟悉，而且要看很多模型，然后告诉客户他们的业务属于哪个范畴的，并且他们提出的需求那些是合理的哪些是不合理的。当你显示比他专业的时候，有些更改他们也自然就放弃了。最怕的是你对于行业知识一无所知就去与客户谈需求，这样定下来的需求就不是需求了，只能说是客户的要求。

因此，我的建议是，用户提出需求变更以后，要先和其沟通，看看是否真的需要变更，如果真的需要变更，则要和用户交流一下变更后可能出现的各种情况，让用户认可。此时可以建议用户再影响的小的需求修改，可以积极配合，但对于影响项目进度的大的需求修改，则要对这部分的修改另外增加项目费用，相应地项目的工期也要进行延长，并且一定要把这条写进合同里。这样可以从一定的程度上抑制客户随意修改需求的冲动。想一想，再看一看，还有什么要改动的地方。等到用户实在提不出新要求了，再考虑进行实际地编程工作。另外，作为团队的领头人，在与客户的谈判时，事先就应该约定，对于一般的对进度没有影响的小的需求修改，可以积极配合，但对于影响项目进度的大的需求修改，则要对这部分的修改另外增加项目费用，相应地项目的工期也要进行延长，并且一定要把这条写进合同里。这样可以从一定的程度上抑制客户随意修改需求的冲动。

需求的变更是不可必免的，只能去尽量减少，不管你前期需求做得多么详细，因为大部的用户都不清楚他们的系统真正是怎么样的，一般都是等你开发完，试用行时就什么问题都来的。我个人觉得在做需求时应尽量少用模糊的字眼如“等”什么之类的，到时客户就会针对这些字眼跟你没玩没了的，钱在他们手上你没有不做的理由。至于一些在需求合同上没定的功能，我想还是可以通过沟通，分析成本与期限等来解决的。

一般来说，需求的更改分三种情况，一是立即可以改的，不用花什么时间和精力的小的更改，可以立即答应客户。二是能够更改的，但是需要投入一些时间和精力的，在请示过甲方和乙方的领导后，一般也是可以改。三是需要投入大量时间和精力的更改，这些就要跟客户说，改这个要需要牵动其它方面，需要花费多少时间和精力，需要重新测试等等，说服对方不要修改。如果他们还是坚持的话，可以适当地提出增加费用。

还有，客户的情况也分为三种。第一种客户是有一定的项目经验的，对计算机比较了解，能给出比较明确的需求，可以采用瀑布模型的方式来开发。第二种客户客户是对计算机不是太了解，但有过类似项目的经验，并且能积极的给出正确的需求，这时就可以采用演化式原型开发方法。第三种客户是对计算机一窍不通的，这时就比较适合用废弃式原形开发方法。如果客户的主要需求基本稳定，但需求的增长速度和变动频率都比较高，这时就应该用螺旋模型做开发过程模型。

如果一开始需求定的很明确，如果客户一定要改的话，可以让他们提交需求变更报告，在一定条件下，你们批准后再更改。一般客户提出这种要求时，我都会先衡量工作量大不大，如果工作量不大，就同意给他们修改一下，然后告诉客户我们用了很多的人手并通过加班加点才帮他们处理好这次更改。如果工作量大了，就告诉客户，如果做修改，需要很大的改动，把事情说得严重一些，然后要求客户追加款项。另外也可以适当地给客户验收负责人点好处，或者给他的上级领导点好处来化解对方的修改要求。

总之，在需求明确后需要让对方确认。当对方提出更改的想法时，一般是基于他觉得软件的修改不需要花费多少人力物力，你可以在赞同对方的同时，告诉对方实现起来的难度，主要体现在工期与资金方面。还有一些客户提出想法无非是想展示自己的专家身份，可避重就轻，接受一些小工作量的修改。如其一再坚持，可以通过市场人员与对方进行沟通和了解，你们可以做一些投入，比如吃饭、唱歌、送点小礼品之类的。搞好一下关系。

关系融洽了后，然后再说：“我们先这样试用着，这个东西改起来比较麻烦，需要些时间，您看是不是能够给我们些时间？”如果双方的关系真的比较融洽了，你的要求他肯定会答应的。至于什么时间改完，那就看你们公司自己的要求了，愿意改动就改，不愿意改动，过一段时间后，再说我们的确非常忙，您看也用了这么长时间了，如果真的有妨碍功能的地方我们一定尽量改，这些小需求您看是不是先暂缓一下。当然，说这些话的时候千万不要在正式场合。

另外，面对需求的变更，我们还要做到以下几点，一是要适当照顾客户的心情，当然了，是那些重要客户，还是尽量给予修改。还要看是客户中哪一个人提出来的，如果是对方的领导提出的可以做，其他人的就要看变更是否影响到项目的完成。二是要规范提出需求变更的过程，比如需求的更改必须要有对方部门经理的签字，这样，很多能忍受的小更改对方就不会提出来了。因为他也怕麻烦。三是事先把需求做透，一个软件，一定要有它的核心价值，如果实现了这个核心价值，那么总体就已经成功了。所以原型确认以后，短时间内要再与客户交流几次原型，这样往往会让客户彻底地认可。