怎样控制需求变更
实际上就算美工和程序员的这样分工可以减少不少工作，但没有解决根本问题，只要客户不断更改就怎么样都要做些重复工作。可是要怎样才能控制需求变更呢？
我向老总提写议确认书，并让客户签确认书，可老板说这是不可能的，你功能都没做出来，怎么让他们签啊？你做完功能让他们去体验，他们才知道有哪些地方是需要修改的，而页面的变更，实际上很多时候都是我们在开发或者开发完了，老总提出来要更改的。就像上周我们花了一周时间完成了一个功能模块，并经过了第1步测试，结果老板说要改页面，页面的布局和字段全都变化，相当于我们完全没做，而老板还以为页面的更改对功能开发影响不大，当然我也是今天才看到更改后的页面才知道的，而现在老板又在客户那边开会调研，我们无法沟通（而且更改后的页面除了老板同意外，其他美工和我们都觉得那样页面很难看而且变形了）:cry:
更有意思的是，我们做的功能也一直不去确认，还在那边梳理流程，这样的话，我们开发的越多，以后也就改的越多，甚至又是完全重做！我感觉很可怕，可是解决的办法呢？我想只能做记录，记录下更改了多少，花费了我们多少时间，让老总感觉到其实这些是很耽误时间的，看他是否会重新考虑他现在的做法，不然的话，我们会死的很翘很翘！
我相信很多人都遇到过这样的情况，不知道大家都是怎么控制需求变更的？怎么解决这些问题的？ 更有意思的是，我们做的功能也一直不去确认，还在那边梳理流程，这样的话，我们开发的越多，以后也就改的越多，甚至又是完全重做！我感觉很可怕，可是解决的办法呢？我想只能做记录，记录下更改了多少，花费了我们多少时间，让老总感觉到其实这些是很耽误时间的，看他是否会重新考虑他现在的做法，不然的话，我们会死的很翘很翘！
我相信很多人都遇到过这样的情况，不知道大家都是怎么控制需求变更的？怎么解决这些问题的？
说得太好了。


正因为大多数维护都是免费的...所以...
PS:灵活性这东西最好越少越好.够用就得. 62 楼 rabbitbug 2009-04-20 需求变更是无可避免的，再牛的系统分析员也不敢说他按他写的系统分析说明书写的软件肯定完全符合照客户的业务要求，可以一次性通过客户的眼睛。
但一个好的分析员写的说明书，至少整体框架是对的，用户需求变更不会影响到你的程序的整体架构，否则说明他就根本没有仔细进行需求分析，没有深入地了解业务流程。我们可以容忍细节性的需求变更，这也是合情合理的，当然你的需求说明书要通过具体操作人员，操作人员所在部门领导的认可，如果让他们大的领导认可那就完美了。为什么让他们认可，那是因为知道我们做了哪些工作，如果事后又要变理需求，如果是同一处的反复变更那是他们的不责任，如果影响到你们大的进度，那这就是你们的依据了。非常重大的变更那是要把双方的领导叫到一起的，可能需要修改合同等手段，否则一些枝节性的变更，开发人员你就忍着吧，迭代对于开发人员来说太正常了。如果你已经可以代替他们的操作人员，替他们上班，那说明你已经非常了解这个业务了，否则作为开发人员，对你写的代码非常有怀疑是不是符合客户的要求。
大的需求甲方领导可能会过问，有些整体界面他会有些要求的，这个最后是开始时就征求，其他细节性的应该找操作人员，需要符合他们的需要，这是王道，还有还要研究一下旧的系统，很有必要的，旧的系统有哪些优点，客户认为失败在哪，对新系统很有帮助。
开发人员一定要和操作人员搞好关系（电脑帮着修修，和他们拉拉家常），还有相关的部门领导，他们通过了，你才有资格找大头说我的软件好了，下面操作人员认为不错，请你验收。 63 楼 benswallow 2009-04-24 其实你这个问题是在大多数项目中都存在得问题，其实处理这个问题也不难，看你怎么沟通，要让客户的思维跟着你走，而不是你跟着客户的思维走，这样你很被动，这个就体现了一个沟通的问题。
一句话，我们每天都在忽悠和被忽悠中徘徊 64 楼 brilliant2008 2009-05-03 还是页面驱动开发的好，这样成本会相对低点