我现在是在公司做内部IT项目，开发的系统是公司内部使用的系统，因此user就是内部user，这样的项目没有所谓的合同，也不会涉及到money。做过类似项目的朋友应该都知道，这样的项目，需求变更频繁就是一个非常让人头痛也很无奈的问题，至少在我们公司是这样。
有时候系统已经架构好了，PM又收到了可爱的用户提出的需求变更，这样有可能会导致系统架构师需要重新架构系统，在开发阶段、测试阶段、UAT阶段等用户都会提出各种需求变更，小到增加一些小功能，大到变更整个系统的架构(这简直是一个灾难性的变更)。因为不会涉及到money，所以他们在提需求和变更需求时也不会手下留情，能提多少就提多少，能怎么变就怎么变。这样无疑会增加项目的成本，拖延项目的进度，这是任何PM都不想看到的。但是用户是上帝，我们只能顺应上帝(oh，God!)。
我们公司做软件开发项目正常的流程是：PM收集需求--开发部门架构和开发系统--QC部门测试系统--用户测试系统(UAT)--系统上线。但是用户在任何时候都可能会提出新需求，或变更之前的需求。
若是外部项目，大家都知道，用户提出任何需求变更，几乎都会增加自己的成本，所以用户在提需求的时候也会很慎重，能不变则尽量不变。考完PMP，我知道如果客户提出需求变更，首先是要求客户开立新合同(新合同=更多的money，嘿嘿。。。)，可是对于像我们这样的内部项目，没的合同开怎么办呢?我们有时候根本无法拒绝用户的需求变更，这其中包括有企业文化的因素和政治因素(有一次，我们拒绝用户的需求，结果用户跟我们说，我们强迫他们接受他们不喜欢的东西......真是无语......)。
我总结了一下，我们公司的需求变更大概有以下几个原因：
1.用户自己对业务内容和流程不熟悉，在需求收集阶段提出的需求与实际业务需求和流程不符合，在系统开发阶级或者测试阶段发现了自己的错误，所以提出需求变更，希望开发出的系统满足业务需求和业务流程;
2.上头的领导(包括用户部门的领导和IT部门的领导)就自己的习惯和看法，提出需求变更;
3. 貌似正常的需求变更，如增强系统功能，或者减少一些不必要的功能以满足业务需求；
4.系统可以以A种方式运行，也可以以B种方式运行，在需求收集阶段用户A提出以A种方式运行，可是用户A离职后由用户B接手该系统，但是用户B却希望以B种方式运行，所以需求变更又这么诞生了。