对于软件开发项目来说,开发的过程中不可避免的会出现需求变更，发生变更的环节也比较多，因此变更控制显得格外重要。变更控制对项目成败有重要影响，项目开发之前要明确定义，开发过程中要严格执行。对变更控制的目的并不是控制变更的发生，而是对变更进行管理，以便更好的处理变更，确保变更有序进行，而这些变更都是靠文档来记录的，规范操作的，从而减少因为需求变更而带来的损失，加快项目的开发速度。
文档固然重要，但精细到什么程度就有待大家一起探讨了。目前大部分都是为了文档而文档就失去了意义。在项目初期（范围定义），对于文档我更倾向于写个大概，具节开发的时候不断请教，文档的工作不是不断累进明细的，是越来越明确的一个过程。在工作分解结构之前，文档工作应该明细到每个模块的功能要求，界面要求，验收标准等内容。文档写出来后，不是放在那里睡觉的，而是需要拿它和客户周旋的。一旦文档得到客户或项目干系人签字后，就按照文档严格执行。在执行过程中，有项目干系人说这说那的，少了这个或那个功能，这个时候就要用文档来说话了，若在原有功能的基础上增加的话，写个需求变更，这个时候项目经理要对变更进行分析，提出一个或多个解决方案（即使在项目目标不允许的情况下也应该这么做），然后在项目的进度，成本，质量，资源的基础对其进行评估，在评估代价并且与客户讨论的时候，要让客户了解变更的后果，变更之后面临的最大问题就是项目延期，然后让客户做判断，无非下面几种情况：
1.客户接收延期这一结果，开发人员按照客户的要求修改，但要让客户知道为此要付出的代价。如果客户认为代价太大，那么开发人员就没有必要修改，按原来的进度走，但仍要记录变更，待下一版本在修改。
2.如果客户不接受变更的代价，此时可能导致项目继续比较困难。如果客户不知道你为变更付出的代价，对你的辛苦便难以体会，以致没完没了的提出新的变更。
正如前文所说，需求变更往往是不可避免的。通常是项目负责人员花费了大量的气力避免需求变更，可最后需求变更总是会出现。但是这并不意味着项目开发人员不应该做这方面的工作，项目开发人员对于需求变更的正确态度应该和软件测试的态度一样，在需求变更发生之前尽量减少需求变更，以将需求变更带来的风险降低到最低。项目开发人员切忌在项目设计之前试图消除需求变更，这样做往往费力不讨好。
相比于需求开发人员而言，客户可能对需求变更认识不足，认为他们出钱，程序员或软件开发公司就要为它服务，因此客户对需求变更往往更加肆无忌弹，将需求变更视为儿戏，随个人喜好随意变更需求。因此，在需求人员同用户代表或用户部门主管人员接触时，就应该向他们挑明态度，和他们协商好，特别是应该让他们清楚软件的定价应该与软件的功能相关，以及需求随意变更所带来的风险的承担者应该由客户和项目开发者共同承担。通过这样做，让客户在需求分析之前就尽量对他们所需要的功能有个整体的了解和确定的思路，而不是等到程序员开始编码了，才提出以前原本在需求分析时就可以提出的需求。
可以在合同中进行约束可增加一些相关的条款：如限定用户提出需求变更的时间,按规定何种情况的变更可以接收变拒绝接收，或部分接收，还可以规定发生需求变更时必须执行变更控制流程，软件开发的变更间接地反映出一个企业的文化，企业文化是为了企业利益最大化而建立的。企业文化着眼的是企业的长远目标，如果说企业的利益则是短期目标，谁该服从谁？一个好的企业文化，会充分调动员工的积极性和热情，这远比流水线式的生产方式效率来的更高。员工不是你多给几个钱就会为你卖命的，更多的是靠企业文化，组织行为去不断的感染他的。
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
