需求变更必须经过项目经理或指定人，不能直接由客户要求程序员修改，我想这是最基础的。
用户签证确认也是可以实施的，一般用户都会配合。

@冷面阎罗
提高沟通是必需的，但是做事情也要“有章法”“讲套路”，在这样的前提下能够更有效的沟通，避免扯皮。对吧。另外，俺也是在国内呀，呵呵

@冷面阎罗
没错的，项目经理与客户沟通是门艺术。
与客户经常沟通的效果往往胜过合同条款（如果到了非得拿出合同说事的程度，项目基本上就完蛋了）。总之，客户的目标就是尽量少花钱多办事。而开发方的目标就是能不改就不改（降低成本啊），即使非得要改，也要说的让客户觉得欠了你很大一个人情似的（为下一次他们再提出需求变更做好准备）。中间具体怎么沟通达到双赢，就看个人的本事了。

@心内求法
同志啊,国内项目接触客户比较多,这也是一种锻炼.交流的艺术

@iceboundrock
是啊，还需要我等多多努力，任重道远啊：）

@心内求法
从理论上，这样是很完美的。但是很难坚持下去，因为一般来说国内的软件项目，客户和开发方根本就不平等。所以只有开发方多做一些工作了，经常与客户沟通，摆事实讲道理，呵呵。

可以采用这样的做法：在项目启动时期，把需求变更流程作为一个重要文档与客户沟通（客户需求变更整理－正式文档提交－项目经理意见及工作量评估－公司审批(当涉及比较大的工作量的时候)－变更回复－变更执行）
先制定这么一个流程，双方认可
然后在实际变更发生的时候严格按照这个流程处理。

相关内容可参考：
软件不软：需求变更与代码质量：http://www.blogjava.net/wanghaikuo/archive/2006/11/29/84355.aspx

项目时间——你会讨价还价吗？：http://www.blogjava.net/wanghaikuo/archive/2006/11/02/78698.aspx

欢迎展开这方面的讨论，让软件行业逐渐规范起来，呵呵

@冷面阎罗
如果客户提的需求你觉得有问题，你最好把你的想法整理清楚之后去和项目经理谈，让他去说服用户，或者向更高层的领导汇报。把利害关系分析清楚，我想没有那个公司想赔钱的。是吧。
但是，如果你一边觉得有问题，一边又不说话只是埋头苦干，那只有哑巴吃黄莲了。程序员除了技术，沟通也是非常重要的，尤其到了项目后期，沟通的重要性远远高于技术。

@iceboundrock
是啊,我们也想这样啊,不过客户有个大领导一下令,我们这边又不得不该,该了后下面的实用者又打电话说这不好那不好,主要是领导想着完美却没有想实用,最后的结果就是苦了我们这些程序员了.

@冷面阎罗
遇到这样的，就要给他变更造成阻力，不能让他随意变更。
如果客户给项目造成很多困扰，而项目项目经理搞不定，可以向业务人员反馈。一般来说，业务与客户的私人关系肯定好过项目经理和客户的私人关系。他们有他们的渠道来和客户沟通。
如果业务不管，可以继续向高层反馈，毕竟项目拖久了，公司也是受害者。

对啊,我也遇到这样的情况,我们是客户领导说一样,实际用的说的又是一样,上次作一个东西,还没作完就改了7.8此

所以对于客户提出的需求变更，一般技术人员最好的处理方式是：委婉的告诉客户，这个问题需要项目经理来评估。哪怕用户用挑衅、教训的语气和你讲这个功能如何简单，如何如何就可以实现，你都不能告诉他是否可以接受这个变更，更不能说实现需要多长时间。
拒绝了客户之后并不是大功告成，你最好能够早于客户通知自己的项目经理，客户想进行怎样的需求变更，你自己对工作量的评估是怎么样的。这样可以给项目经理一个准备时间，来完善的考虑需求变更的影响。


同意！

补充一点关于数组的内容，
如果在C++中声明一个对象的数组，不像C#，数组中默认的元素都是null，C++的数组中可以容纳多少元素就会在声明数组的时候执行多少次构造函数将实际函数构造出来。

谢谢您的指教，对于这三个方面，我是这么考虑的：
1，j2sdk中的Observer/Observable难道就不类型安全？
没错啊，因为接口设计的太粗，所以无法保证回调时一定传入监听器需要的类型。
2，多个事件函数的意义在于可以清晰的表明事件的含义，并且提高效率。监听器不必自己处理所有的事件。
3，TestEvents实现ITestEventHandler的确不够优雅，不过这是为了程序编写上的方便。另外因为TestEvents可以实现很多接口，所以把事件处理类型传递进去，可以减少一部分工作。您觉得这块需要如何改进呢？
这个类的目标是改进Observer，我也的确认为对Observer做出了一些改善，所以我保留标题。

1，j2sdk中的Observer/Observable难道就不类型安全？
2，所谓“可以有多个事件函数”，没有很大意义，一个和多个没有本质区别；
3，你把Observable（TestEvents）也变成一个类型Observer（ITestEventHandler），你认为这样设计在类型层次上elegant？还有，如果真是这样的设计，eventBase(Class handlerType)是不是有点可笑？（“自己不知道自己”？）


“改进j2sdk中的……”这种标题还是少用为好，免得……