软件项目的设计、开发者不顾需求的意图，一味追求所谓完美（或尽量完美）的系统。在他们认为完美的系统完全适应用户的需求。其实呢，他们在闭门造车。他们并不知道用户的真正意图，也不清楚公司做项目的真正意图。他们都是技术人员，他们关心的是技术的实现。而不是需求的实现。在系统中，极尽对先进技术的应用，而不管是否真正需要这些技术；在系统中，极尽对绚烂多彩界面的展示，而不管是否真正需要这些绚烂多彩的界面。 悲哀呀！作为系统分析员的我，无力阻止，眼看着项目越走越远；工期一再拖延，而我们在拼命实现并不需要的功能。我的意见没人采纳。在项目经理眼中我的作用竟然不如指挥实现的开发组长。悲哀呀！我多么希望出离悲哀。由他去吧。毕竟，我不是决策者、我是实践者。 可，谁知道项目失败责任的替罪羊会不会以需求不明的罪名落到我头上呢？给人打工，命运操纵在别人手中啊！ 难道，这不是技术人员的悲哀吗？
没有什么悲哀的，如果真向你说的，只有一条路！走人，这不是合适你发展的地方。 在软件中，始终是用户需求第一，技术第二的。只有在满足用户需求的情况下，才能说如何利用先进的，高级的技术来优化应用系统。至少，银行系统有这个特点。
首先，这句话在中文的角度有语法错误 “我多么希望出离悲哀。” “出离”是一个副词，不是动词 呵呵 :)- 另外，技术人员就是为了结果而生存的，不是为了技术而生存的
微软的开发方法（MSF）就比我们先进20年，但看看国内的技术同仁们？几乎都看不起微软（技术上的）！但是，恰恰是我们认为最差的，最多问题的公司却得到了几乎所有的用户的支持（80%的市场占有率）！为什么？因为他好用(这里的“好用”是指迎合用户的要，不是技术人员的要求)！ 醒醒吧同仁们！按客户的要求去做，客户不需要最先进的，只需要最合适！这种“合适”是客户的合适，不是技术的合适，因为客户永远不想知道你用什么技术去实现，也不会因为你运行是比原来要求快了1分钟！
鲁迅先生的文章《纪念刘和珍君》有“我已经出离愤怒了”的说法。：）
不错，我也看见有些人按住以前的系统功能拼命的画功能模块，还美其名曰：“做需求”。这样开发出来的系统大不了是用上了一点新技术的原有系统的翻版，不会出现任何创新（用不同的方式实现用户需求），是挺悲哀的
请问，你们有＂需求分析说明书＂，＂系统功能说明书＂吗？开发人员难道不是以这两份文档作为实现的目标吗？如果答案是肯定的，那即便开发人员画蛇添足增加了一些花里胡哨的功能，也不会影响大局的． 项目的进度是由项目经理来控制，如果你觉得开发人员为一些芝麻功能浪费了太多时间，应该把问题反映给项目经理，分析利弊，相信他会支持你的看法． 另外，一个项目的ＱＡ是十分重要的，他们的作用在于保证软件产品与分析阶段确定的系统目标相符合，如果真如你所说的＂项目越走越远＂，那就是QA的严重失职．大多数人都以为QA仅仅是软件功能的测试者，其实这样的看法是片面的，QA应该保证最终的软件与分析阶段定义的系统目标相一致，与客户的需求相一致，因此QA的工作应该贯穿项目开发整个周期，而不仅仅是测试阶段． 你是系统分析员，你的任务是理解客户需求，根据自己的行业经验引导客户需求，然后把达成的共识准确无误的写成＂需求分析说明书＂，＂系统目标说明书＂，它将作为开发人员实施的唯一依据．至于你所谈到的一些问题，应该是项目经理和QA经理来负责的
其实，按新的软件工程理念，需求开发已经不再是一个分析员或一群分析员所能做的事了，它需要一个需求分析团队来完成，团队成员就应该包括项目经理、主要开发人员在内，得到的需求文档应该是非常具体的，包括界面 而且有些用户也会在实现技术上提些要求的 如果需求是一个团队共同开发的，那么由这个团队负责实现及以后的工作，还会有大的出入吗？
选择一种你认为对的方法、实践一种你可以不断改进的过程，但请别忘记你的purpose,stakeholders,scope and vision. 方法有：MSF，XP，AM，…… 过程有：RUP，IBM－SE，NASA－SE，…… 成功则只有一种：the one who fits you。
问题是很多人不知道如何做还以为自己做得很正确。15年？你从哪儿知道的？你是说项目还是管理？
既然是这样，有几家公司又这样的能力呢？他们不抄（用别人的成功实践），该怎么办？
不要这么悲观！ 责任当然不全是你的，但你责任也不小呀， 系统分析员就是用户与程序员的桥梁，所以程序员会这样你是有一定的责任的， 项目经理也一样是活罪难逃
我不是在推荐微软的软工方法，因为它是做产品的，而我们多数是做项目的。这中间有太多的区别（我个人因为）。我也试过用它的ＭＳＦ２．０来做项目，结果当然是一塌糊涂，呵呵～～ 但是我要推荐的是微软对用户的理解和重视（这才是本论题的核心）！正是基于这种重视它才能以用户需要为核心去进行开发、控制、ＱＡ……
