不要悲观，不管做什么工作，都需要兴趣，特别是搞程序，要不断向自己挑战，要向最难的挑战，搞程序最难的是什么？是使用最新的技术来最大程度地解决客户问题。
所谓从business考虑，我觉得就是无条件地从客户角度出发，满足客户的需求，当然并不是说，客户说一就做一，客户说二就说二，而是应该从客户说一和说二中，总结出可重用的东西来，做出一个可伸缩的系统模型出来，这样，客户说三时，已经在你的系统可扩展范围之内，最后你明白，最有预见性、最成功的还是你。你从中享受最大的满足感。
如果你做不到这点，也不要怀疑做到这点的可能性，至少我自己经历过这样过程和成功的感觉。当然要完全做到是一种理想。
当你沉浸在这样的一个自我折磨的过程中时，外界外物皆成身外之事，也许在你获得成功感觉时，物质等外界成功也会伴随而来。
难怪版主叫“J道”，果然有“道”的意境！
受教ing：）呵呵
>当你沉浸在这样的一个自我折磨的过程中时，外界外物皆成身外之事，也许在你获得成功感觉时，物质等外界成功也会伴随而来。
---------------------------------------------------
不错，当我得意于以自作主张的方式成功服务客户时，忘记了了我已经脱离工作的正规流程，忘记了我的工作都没有表现出来。
另外非常同意banq的方法，就是对我们来说客户就是傻瓜似的上帝，一方面我们要尽量满足客户的需求，一方面又不能把客户提的所有要求都当作圣旨。因为客户对自己的工作也不是十分清楚，他们每个人都只知道一部分，很少有客户能个完全说清楚整个业务，他们总是考虑不够全面，提的需求也有偏颇，因此必须能够站在比客户还要高的一个层面，从整体上分析理解客户的整个业务，然后提出一个有建设性的一整套解决方案，当然还需要引导客户按照合理的业务流程工作。这其实是一门很深的学问，类似大学里的数学建模竞赛中用到的能力。引导客户的业务到最合理的流程是解决客户因为自己混乱的业务而在需求上左突右撞的根本方法。特别是在中国这个很多客户的业务都在摸索中的情况。
其实我最看不起我们公司有些人对客户的需求都不仔细考虑，总是想要随便作完以交差了事。否则我们的项目不会返工三次。
在RUP中，需求分析之前是业务建模，即帮助客户建立他们业务的流程模型。其实不管需不需要开发软件，清晰的业务模型都是需要的，只不过很可能客户从来都没有过业务建模，所以在我们替他们开发软件的需求分析阶段之前先要帮助他们把他们自己都没有做好的业务建模做好。
原来如此，我说呢，这下从理论上找到了我的观点的依据。呵呵，谢谢。
我们的客户自己就无法作到业务建模，我们给客户上了新业务，他们就不知道业务流程该怎么跑了，特别是他们内部调整后，他们的几个部门坐到一起只有讨论，讨论到最好也没有结果，很难定下一个业务下来，有的环节也谁也不知道有什么用，但是谁也不敢说把这个环节去掉。其实他们内部没有定好业务规则时我觉得不方便就开发，最好自己有现成的解决方案去说服客户。
刚毕业时我只关心技术，但是现在我认为：一个项目的成功与否，最重要的是和业务建、需求分析和业务实现相关的那个位置好像是叫“产品经理”吧，其次是使用的技术和开发小组内部的沟通和管理。
产品的设计觉得了一个项目的成败，技术决定了这个产品的质量，但是只要能满足实现一般都不会影响项目成败，而项目组内部的沟通和管理决定了软件的成本和开发期限。
因此如果可以让我选择，我一定把产品的设计抓到自己手里，其他的都可以让给别人管，这样我才对项目的成功有信心。
架构设计和业务分析一样重要，甚至更重要，因为架构设计师实际是以技术架构的高度去帮助业务系统的实现，很多情况下，业务分析师和客户没有统一结果的真正原因是：业务分析师无法使用一个技术架构来一步到位地实现客户短中期发展需求，很多时候都是井底观蛙地完成客户需求，系统稳健性、可拓展性和可伸缩性都是非常的差，在客户新的需求下接近瘫痪，因此业务分析师最后和客户讨论是下列对话：
客户： xxxx，提新要求。
分析师：真是对不起，我们这个系统改动起来太麻烦，会瘫痪，我想你也不想看到，因为你和我坐在这里已经快两年了，这个系统好容易才建起来，你这个要求不是毁灭我们两年的劳动成果吗？
客户：?????!!!!!....
分析师：找个折中办法，你的需求让一点，我的系统再改一点。
客户：让好吧...
再过一段时间，两个人又坐在一起，
客户：对不起，领导又有新要求...
分析师：????!!!!!.....
客户：这个要求是这样......
分析师：啊，你怎么不在上一个要求里提出来，再加这个功能是不可能的了，是因为这样的原因....
下面是永远无法结束的讨论，永远得不到解决方案。
这种情况发生很频繁，你所要做的不是象分析师那样去和客户讨价还价，而是迅速理解需求，并能知道迅速实现的途径。等客户再找你实现新的需求时，应该是从度假胜地将你叫回。
靠，现在有多少人做到这么潇洒？
我也遇到这个问题，一般遇到这个问题我是分两种情况。
如果客户的需求是为了省事想脱离合理的流程或者一些很无聊的需求，我会以咨询身份和客户讲明这个事情的后果，我们目前的客户是比较明理。
如果客户的需求的确是合理的，是我们以前的业务分析时没有想到，那么再麻烦我也会修改程序，而且一定要可以容纳再有类似的需求更改。
在构架设计上，我正在做一些工具，目前已经有一个报表工具（支持简单翻页），复杂的报表基本上都可以在10条语句内完成。主要是配制业务逻辑，其他的工作都调用现成的代码。因此做报表对我来说就象在后台用sql语句出报表一样简单。关于帐务逻辑的更改，因为我们的帐务逻辑基本是封装在存储过程里，因此改动起来也非常方便，而且都不用重起服务器的。这两方面可以很快解决就为其他程序更改节省了很多时间，因此我一个人就负责了这些东西的design和coding。我的程序没有用VO，一般用map，我有一个数据库代理，以map的collection作为返回查询数据的格式，因此有数据库改动的话我只要修改sql语句和jsp的输出这两个地方就可以了，我的输出和输入都有统一的方法，这样如果字符集不同或类似问题，我只要改一个方法就可以了。就是图个简单而已，我的构架不算很面向对象，主要是为了最大的代码重用而设计的。我当前应该是属于xp的风格吧。
我们目前的构架纯粹是为了开发方便，我对j2ee也没有经验，只是自己摸索后觉得这样比较方便，如果有不妥敬请指出。
受教了，谢谢各位，尤其是Mr.robbin。
工作三年，曾经在三家公司工作过，第二家公司只工作了一个月。前两家公司规模比较大，现在这家则比较小。的确，大一点的公司发展的机会相反会少点，而且也未见得管理得很好。我想，象我这样没什么背景，能力也不是很强的人，还是在小公司寻找位置比较好。
正如顶楼楼主所言，能够以自己的方式成功的解决客户的问题的确是一件赏心悦事。我和你的工作经历似乎有点相似，我在第一家公司的时间是最长的，期间经历了整个项目的发展，也曾一人在远离公司的城市负责技术相关的所有工作，包括产品销售。
也正是接触的层面很多，发现的问题也很多。我并不乏个人的见解，也解决过不少问题，所有这些都是非常开心的经历。但由于有太多的原因，始终都没法从根本上改变，以至最后有点失望。结果我辞了工作，想到另一家公司学习解决的方法。只是很惭愧，到现在都没有学到。（诚然，这些也是我个人能力不足，接触面太广，以至深度不够之故。）
回顾一下，也许我们以前的上司不是能力不好，也不是方法不对，可能只是他们的方式不适合于自己。要想实行自己的想法，看来只有多表现，上到一个更高的位置才行。我以前也都积极表现，只可惜受距离所限，而且也只是让直接上司看到，是做得不够。
我期望在现公司能取得良好成绩，只因时间不等人，工作了近三年还没有一个见得人的成绩，的确是惭愧。
我也是一直在寻求解决之道，中国软件项目的成功解决之道。
我毕业设计是给一个地方房管局做asp门户，有新房发布、二手置换、出租求租和简单论坛等功能，我一个人从学习asp和sqlserver开始到验收到上电视只用了两个月。我原希望毕业后迅速作成功几个大项目，扬名立万，没想到现在毕业两年了，跟了两个大项目，结果都很惨淡。真是丢死人了。
现在我也不知道软件项目到底有没有解决之道了，国内很少有很成功的案例，大多数的软件工程都会延期，几乎所有的项目组都被客户的需求变化搞的痛苦万分。至少目前我还没有见到一个我认为成功的项目（验收付款并不能算是成功），太另人失望了，现在我也只能自己摸索，还是依靠自己更可靠一点。
客户同意帮我忙了，问我如何帮忙？我不知道怎么回答？
客户说要不要和我们领导谈谈，我说好呀，客户问和谁谈我又拿不准了！
banq交给我们的是技术上的领先。
robbin交给我们的是做人上的领先。
sprsong，大家一起好好向他们请教
我看过不少robbin的帖子，对于他在技术上的造诣还是非常敬佩的,感觉这是一个非常聪明的人。不过我对本文中robbin的观点不敢苟同，我认为不应该过多的把精力放在如何在领导面前表现上。俗话说“铁打的衙门流水的官”，你不会一辈子总给一个老板打工吧，切实提高自己的业务水平的才是真格的！
不是把精力放在表现自己身上，而是把精力放在如何实现自己价值身上。你光创造价值是没用的，你不让老板知道，就没有实现价值。
我一直认为：
个人的价值＝基本素质＋专业技能＋做人的技巧
我之所以比较强调做人的技巧是因为我认为我们搞技术的大多数的人的瓶颈恰恰就在做人的技巧上。专业技能再提高，被做人技巧的瓶颈限制死了也是无用。