无论是企业用户还是政府客户，由于诸多商业和政治因素，其需求势必会在整个开发过程中不断的变动，加上开发方的需求工程师的业务熟悉度不足以及对需求管理方法的掌握程度不够，综合起来就会导致大部分国内项目到上线的前一天需求还在变动的现象。
要解决这个问题不是一朝一夕的事情，毕竟客户的成熟度是需要时间和市场来培养的，我们不可能等到那天再去做国内软件，势必要找到解决之道。
首先，我们可以从开发模式上进行变革。
绝大部分的软件公司做软件都是采用的一次性瀑布方法，需求-设计-实现-测试-上线，基本上都是按照教科书上的方法在做。这种方法的确很简单，但是实施起来越到后期风险越大，特别是在需求基本不清晰的场景。
根据我自己和公司现有的成功经验，我们找到一个可以初步解决此问题的方法，那就是采用敏捷开发的部分思路，将现有的开发模式进行修改，以达到质量、成本、进度、范围的要求。
1.
对于绝大部分国人的客户，写需求文档给他们评审和确认是没有太大效果的，往往都是事倍功半，因为他们不是专业人士，开发方将工程师的交流物给客户去确认，
本身就是一件非常不可思议的事情，但是教科书上这么写，很多人也就这么做了，所以基本上这种方式都没啥效果。
对于需求不清楚的客户，做需求调研和确认期间，不需要编写任何格式的需求文档。需求调研时需带上界面工程师，每天调研后，内部确认达成一致的理解，然后界
面工程师根据需求调研记录开始制作带javascript脚本的静态界面，完成后配上界面功能和约束的PPT，一并给客户进行讲解和初步确认。根据客户的
反馈立即进行修改和确认直至与客户在界面上初步达成一致。
这里要说明一下的是，第一个界面或者首界面是非常重要的，基本上会确定整个软件的界面风格。所以在整个环节上一定要跟客户进行确认，同时，需要跟客户说明
清楚，一旦界面风格确定下来，后期投入开发了再修改所带来的成本和品质风险是非常大的，这点务必要客户的领导知道。毕竟客户也是为了能使用软件，我们提前
将这种关键问题阐述清楚，客户还是会配合的，毕竟，界面风格只要几个领导达成一致就可以了，不是很难做到的事情。
很多公司就是在界面风格上不停的变，导致功能也不停修改，质量、成本和进度都没法控制。因此在一开始就应该尽量避免这种情况的出现。清晰的说明和耐心的讲
解是很关键的，特别是要用客户能理解的语言让客户知道这种关键性的修改所带来的危害是会让双方都受害的。客户理解后都会积极配合的。
其它方法待续。。。。。。