项目需求变更较多如何控制?

阿杰

【案例正文】

我2007年9月接手了一个已经开发接近尾声的项目，项目也不大，前期需求、开发、测试做的也比较好、比较规范，接手的时候感觉问题不大。项目前期的整个过程也和客户进行了详细的讨论和分析确认，但在我们安排实施人员现场实施的过程中，客户在业务流程环节却有着许多细微的变化。
刚开始第一次实施时，客户针对演示讲解后的系统进行了讨论和分析，同时提出了许多变更的细节，问题到不大，系统修改后很快进行了第二次实施，第二次客户又对系统提出的改进的需求，也是一些细节的内容，导致第二次实施后又回去修改系统，接着第三次，整个过程导致我们实施人员很恼火，说是需求变更吧，也不完全是，有些细节的东西是无法一次性满足客户的……，直到2008年5月，这个小项目才算达到试运行，从第一次拿到客户现场的系统和最后一次试运行的系统的功能的对比来看，系统功能需求的确发生了很大的变化，但是从第一次和第二次的功能比较来看，只是一些细节性的变化。
对于这些细节性的变更，应该如何处理和控制？


一、变更控制要有技巧
其实像案例中描述的系统，需求方面已经不存在很大的问题，所以才会导致"细微的变动"。
这些细节上的变化，也许仅仅是一些用户习惯等等，而提出变更请求的用户，也未必能代表其他用户的意见，需要让他们内部先充分讨论，让用户领导确认，明确成本，避免往复修改。
再者，用户和客户的概念也是不一样的，只要不是客户，用户提到，可以再做做工作嘛。

二、制定变更流程

可能的原因：
1、需求调研分析不到位。客户不会无缘无故变动，要么是之前没有做到位，要么就是政策发生了变化，目前来看应该是前者；
2、没有变更流程。任何的变更都应该有流程，没有规矩不成方圆，我相信客户也应该能理解；
3、实施时，同客户交流的不到位。特别是一些细节的问题，交流时尽量全面；

处理方法：
1、建立需求变更流程，变更单表明修改内容，工作量大小，双方签字确认（对于当前这个项目，多次变更后就可以把这个单子拿出来同客户交流，情况好的话可以拿到一些补偿，情况差的也能体现实施方的辛苦工作）；
2、需求交流，尽量能讨论的仔细一些，避免以后现在的情况；
3、在项目开始时就确定关于变更的处理方法，如是项目内做，还是项目外做，允许项目内变更多少工作量等等。

三、做好需求管理和变更
客户对于需求的变更往往是比较随意的，必须要控制好项目范围，有需求变更一定要记录和确认，得到客户的认可，同时项目实施进度要合理，项目拖延往往是客户需求变更较大的原因之一。如果是建筑这一块，一旦有变更要尽早拿到甲方的签证以便结算用。
四、做好前期工作
1、在项目实施之前，尽可能的了解客户的业务和实际的需求，要对客户的业务尽量的熟悉，很多时候客户想要的和实际需要的东西是不一致的，搞不清楚，客户就容易变更，毕竟客户是上帝，乙方不可能很强硬的对抗甲方的。
2、在客户描述不清楚实际需求的时候，做好陪着着做一个原型，让客户结合原型再修改，这样可以在修改后一次到位
3、在项目启动的时候，要给客户讲解一下项目管理方面的知识，比如讲一下项目管理三角形，让客户了解范围、进度、费用之间的关系，客户理解之后也会知道项目的变更会对项目造成影响。
4、项目的变更要走流程，哪怕是一个小的变更，要不容易养成客户随意变更的坏毛病