做项目的时候，我们都有很好的计划，也在不断的强化风险承受力等等~~~ 但事实上，Devolpment完了，到了test和UAT的时候了，通常时间处于这个阶段的时间都比计划安排或者领导认为需要的时间要长的多。程序员一次又一次的收到bug report 和new changes。这里面new changes 当然是新添加的修改了，可以要客户再算钱的，bug就不是了。优秀的程序员团队的code中一般的range异常阿，null异常阿，分支阿，算法阿等等真正的技术bug是很少的。最常见的，也最难修改的是logic error和实现情况与真正需求不一致。
最让整个团队懊恼的就是实现和真正需求不一致的情况，程序员抱怨：需求文档明明就是这么写的，我这么做是对的。需求分析人员则抱怨更多，我明明是这么写的，怎么他们做成了那个样子啊？客户当初就是这么说的啊，怎么现在到测试了，他们说不是这个意思啊，都快变的面目全非了？.......
总结一下个人对于实现与需求不一致现象出现的原因：
1、需求文档表述不明确，这个包含2个意思，一是需求条款含义模糊；二是需求信息不全面。这导致分析人员与设计人员理解出现较大偏差。而且，一般公司如果有专业的分析人员和职位，他们做完一个项目的分析后可能马上就接收下一个项目的需求了，这导致在开发中间需要需求再讨论和澄清的时候，分析员可能自己都不能完全确定需求或者表示错误了。
2、需求挖掘不深，记录的未能表达客户真正需要的。这通常表现为将产品拿到客户那里测试时，客户没看完几眼，就说：这个***怎么是这样的？ 这个报表要加*** ........
3、分析人员未能引导客户那边决策人员与实际操作人员的需求统一。这表现为时常的，我们按照客户项目负责人的表述完成了需求分析。最后UAT的时候几乎都是由实际的操作人员参入的，于是很多操作人员开始7嘴8舌的表述自己的要求 。客户的项目负责人在这时候表现出极高的尊重下属意见的素质：这个是他们用的，当然他们都说是那样，当然要改成那个样子了，不然我买来干嘛~~~~ 云云
4、不断的发现问题和小修小改，导致最后如果要查询一个部分的最终详细需求，可能需要参考n个相关文档.人之常情，即使假设所有人都知道这些文档并能获得，那也不如去找一个人问，所以问下 程序经理/分析人员/项目经理，而对被改动过的需求，他们（被问者）是否都对修改了然于胸呢？就算他/她很明确，他/她的表述力如何？
出现test和UAT不断延期的状况后影响是极大的，几乎你见到的每个人都在抱怨.领导开始不满，怎么拖了这么久阿，原计划将人马投入下一个项目的计划不得不变更了.项目成本不断增加，而项目的总订单额倒不一定增加了多少.程序员开始在bug-fix的过程中情绪低落，因为项目拖的久了，修改的东西有没有新意，而且对所有人都一样的会催化情绪的是，要做的（实现的）变来变去.分析人员面对着压力，但很多人会把责任推到程序员和客户.项目经理最为倍受煎熬.一个现象也可能出现了： 加班，加班，再加班.....
那么我们应该怎样来减少这种事件的概率呢？这里列举1，2所想：
1、需求表述一定要保留文字描述，不要以为使用了OOA和UML后就不写描述性需求了。
2、需求表述每项尽量简短明确，意思单一，进出唯一。
3、分析人员要保管好未整理前的需求调研材料。
4、分析人员对需求的理解尽量要达到与分析人员每一项都一样，可以采用讲解，复述，确认等手段。
5、分析人员最好能在详细设计文档初步完成后和设计人员一起讨论确认详细设计。
6、保持纪录和维护需求文档.这一点非常重要。