刚刚看到有个哥们儿讲他的客户让他很郁闷，我有点想法，整理如下：

首先，我觉得开发人员遇到这样的郁闷是因为控制需求变更功夫没有做足。原因有几点：
1.涉及需求变更的东西不应该由最终使用的用户和一线开发人员来沟通，这样的沟通费时费力而且不具有权威性。
2.开发人员直接向客户汇报的工作量往往比实际工作量要低，而且低的比较多。原因很简单：客户问开发人员一个功能是否困难的时候，一般技术人员往往只考虑了单项功能的复杂度，而可能对这个需求变更对整个系统的工作量估计不足（比如美工的工作量、该功能引发的管理功能的工作量、测试工作量等等）。
这种情况会对项目产生多个负面影响：a.向客户提供一个低于实际值的工作量，导致客户期望高，而实际无法按时完成导致客户失望大，降低用户满意度。b.因为客户从开发人员口中听到的工作量总是比从项目经理口中听到的工作量低，造成客户对项目组内部不一致，沟通不足的感觉。c.因为客户从开发人员口中听到的工作量总是比从项目经理口中听到的工作量低，引诱客户喜欢直接向开发人员提出需求变更，造成恶性循环，直接导致了项目组没法按时拿到奖金，士气下降。

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

对于项目经理，尤其是从开发一线转向做项目经理的兄弟，应该主动的从项目全局来考虑一个变更的影响，而不是单纯从技术角度考虑。最好能按照公司的规范和制度以及项目实际情况为自己积累一份check list，以免在考虑需求变更时遗漏一些事项。作为开发方更要强化对于需求变更的控制。
控制需求变更最理想的办法当然是由客户方、开发方的项目经理和需求顾问共同组织CCB(变更控制委员会)
，文档化所有需求变更，双方签字然后归档需求变更。不过这样比较难以实现。但是最起码的要求是，必须由客户方项目经理（也就是甲方最终用户需要把需求变更汇总报告给甲方项目经理）向开发方项目经理提出需求变更，开发方项目经理评估工作量，并文档化需求变更，在与客户方负责人充分沟通后，使用正式方式将沟通结果（最好是打印出来给甲方签字，最起码是要求回执的电子邮件）通知客户。必要的时候需要业务人员协助，比如要求签署附加合同或者新开一个项目等等。

从我做项目几年的经验来看，蛮不讲理的客户不是没有，但是是极少数，大多数客户，尤其是客户方项目经理都是通情达理的人。所以，只要你言之有理，对方都有可能接纳。