理想的状况是：
需求必须明确详细，不要乱改需求。
有效沟通，选用安全健壮易维护的方案。
做需求的人，一定要专业人士。
故事一：某个客户找我们开发。(核心主旨就是：我还没想好，你先做着我看着改)
第一版，没啥想法，提了几个大概要求，告诉我们，先做着吧，等我们做好后，他拍脑瓜子想第二版。
第二版做完，发现不满意，他继续拍脑瓜子发明创造，我们跟在后面团团转，七改八改之下，所有数据库的表逻辑基本推翻，程序之间的逻辑支离破碎。然后一个烂项目出现了，延期不说，客户和开发者同时陷入痛苦境地。
故事二：早年的某石油公司的内部管理项目。
有个非常优秀的做需求的人员，她一方面熟悉那个领域，和客户做了很认真的沟通，一方面自身又是有点开发背景。各种需求一经拍板后，就绝对不做任何改动。因项目比较急，经过和客户沟通后，一些很难实现的次要功能，已被她砍掉了。
这个项目从我们拿到需求后，高工分解模块，到开发完成第一版，仅用一周时间，再3天测试后，客户已经比较满意了。
故事三：某个客户以前有一套vb作的系统，要改版成网站式的系统。
但是他顽固的坚持老vb系统的一些操作习惯。把眼光只放在这些细枝末节，无休止的烦扰程序员实现vb的样式。但是客户不懂行啊，我们公司投入的人员和工时是有限的，你非得纠缠那些细节不放，有限的时间做了那些无意义的工作。真正涉及到功能、数据可靠性的命根子的一些深层的地方，客户就完全不懂了，导致系统稳定性不够。维护成本高。
———— 有些功能，客户不要顽固的自以为是，最好多和开发方沟通后，选用经济可靠的方案。才能保证后期使用和维护，稳健可靠。
再补充下：方案的不同，会导致程序员工作量的巨大差异。
比如你让我这样干，要5天还得加班完成没时间测试还错误频出。（说实话，为客户服务、客户至上，我们就是加班也认了。只是系统可靠性低可维护性差，我替你们以后担心啊）
我告诉你那样干，可能只是砍掉了5%的需求，1天做完1天测试，还不会影响到现有系统的稳定。
2017-4-1 续
以上只是平时在工作中见过的一些事情有感而发，限于个人的局限性，看看也就罢了。下面还是看看大牛们有什么想法：
http://www.cnblogs.com/qcloud1001/p/6606060.html
摘抄一句：需求提出前会和开发反复讨论可行性，有专门的质量跟踪，有专门的用户反馈，每天知道要做什么，也知道明天要做什么。有产品需求，也有开发需求！这个非常重要。很多团队，都是只有产品需求，开发好像牛一样，耕完地就不管了？
需求提出前，会和开发讨论可行性？
——貌似在我经历过的公司中，大多数都是：
1、销售为了接单无底线答应客户完成不了的要求。
2、产品人员迫于上方压力无尽的山寨竞争对手网站（山寨就山寨了，您倒是理清逻辑啊，实际情况是各页面跳转关系是让程序员自己去捋逻辑，我了个去啊，这两个站完全不一样的数据结构啊，这是在邯郸学步想让自己学到无法走路吗？）。
3、或者领导一拍脑瓜子一声令下
——领导说了两天必须完成，客户急着要。有什么bug以后再改，先给架出来再说！！你一个小兵敢多言？
——系统分析也省了。程序员拿着需求方案一通埋头苦干，甚至有些时候简化到了连高程做系统的设计，划分模块分工都省掉。完全任由底层程序员各干各的。做完后，互相一看，哇！！ 你的这个模块当初怎么没分配给我？ ？ 我这里有个和你功能基本一样的模块呢！！浪费工时不提，还用了两个不同的库，后期维护也麻烦。
——不堪负荷导致人员流动。众所周知程序员流动频繁，干到1年半的就是老兵了。赶上待遇不够、项目烂摊子、只罚不赏、技术无提升。难保不走几个，假如走的越多，烂摊子无人接得起，跑的越来越多，剩下几个独木难支，项目的结果是可以预见的。
以上场景，你们敢说没碰见过？
..