关于工作的一二事

  慢慢的发现javaeye的博客已经沦为一个转帖工具了，全是转发别人的文章和技术贴，完全没有自己的东西也不太好，今天趁着老大不在，来简单的说两句吧。
  记得还是在做开发的时候，曾经看到过一篇从侧面讨伐需求工程师的文章，在作者看来大多需求的人，既不能引导客户，也达不到彻底理解业务，设计业务架构的高度，所以戏称需求分析师为--需求整理师。当时正值我也对做需求的人抱怨颇多的时候，所以很想把文章转到自己的QQ空间中，让那些做需求的看看好好反省一下。随着时光流逝，当我今天真正作为一个需求分析师出现在客户面前时，我才真正体会到当前需求人员的不容易，如果以后有机会见到他们的话，我想我会想他们道歉的。做了几年开发的我多少对于框架有一些了解做起来都如此吃力，更不用说刚毕业的实习生和从测试、维护转行做需求的他们了，现在想想他们已经做得很不错了。能挨住客户的骂不说，研发的人也是不能得罪的，真是要处处小心啊。特别是我，还时不时的跟他们吵架，实在是不应该。做开发的确累，而且做需求不断变化的开发更是难上加难，今天东明天西，后天来个西北偏北也说不定，归根结底不是他们在变，而是客户的意图在变，作为需求的传达者又何罪之有呢。说着说着已经不再是为当年的需求人员平反，好像反而是在为今天自己的处境诉苦呢。
  其实当初跳槽来做需求，一直告诫自己步子一定不能迈的太大，应该从技术慢慢地过渡为一个业务人员，但是没想到最终还是迈大了，其实从软件工程师到需求分析师还是有不少步骤要走的，比如项目经理、架构师都是比较不错的方向。可当时脑子比较热的我，天真的以为做一个精通业务懂技术的需求人员要比做一个精通技术懂业务的开发人员好很多，事实的确前者好些，但对于目前未能积累一定业务知识的我，显然还是自己的本行--技术更重要些，可能我现在意识到这一点还不算晚。
  对于今后我不敢奢望很多，但我觉得是时候把技术捡起来了，当然不能全部扑倒技术的海洋中去，而且在技术上提高，主要研究业务表达和文档协作、原型制作能力。在《大象UML》书中，作者对绘制UML图简直达到了出神入化的地步，但在一些篇幅也能看到，作者对开发框架和系统架构也是非常了解，不管作者是后续学习还是也是从开发转型后做架构师的，总之技术和业务永远是不可分离的，《人人都是产品经理》书中也传达了相同的技术知识。技术服务于业务，这是我听过最多的一句话，因为在我的思想意识里总是认为公司的高管坐在一起的时候，在讨论公司今后业务的发展方向的时候，总是先确定要做的业务发展方向后，再确定用何种技术来实现，或者说有无相应的技术作为支撑，即脑袋决定屁股。但我忽略了一点，不管高管做什么样的决定，最后还是要问问技术经理或者CTO，这样做能不能实现，要投入多少资本，做起来难不难，所以脱离实际执行力的idea显得还是那么苍白无力。