你的分享就是我们的动力 ---﹥

一个IT人的非典型职场十年

时间:2013-07-02 17:08来源:www.chengxuyuans.com 点击:

话说我当年从研发跳到咨询部门,其实思路很简单,就是希望可以更加的靠近一个公司赚钱的部门,追着公司的发展战略走。这种选择工作的策略,是不会有错误的。但实际上换了工作后才发现,咨询工作远没有我想象中那么容易。每一个衣着光鲜职位的背后,都有一个个苦逼的IT人。 

首当其冲的是工作性质和内容。研发的工作相对单纯, 基本上日出而起日落而息,当然有时候免不得要晚上跟阿三啊老美啊搞个conference call啥的。但基本上需要做的事儿是相对独立,以个人为单位完成,闷到屋子里面搞定。而且项目的周期是跟随产品的周期走,相对来说比较长,怎么一个大版本的发布也需要半年时间。有时候会有些跟客户打交道,也是经过了若干层技术支持的筛选,基本都是很专注的技术问题。 而IT Consulting则完全不同,纯咨询出报告项目、项目群管理、客户关系维系、测试管理等等,各种类型、各种金额规模的项目五花八门, 基本上不重样的。一切说所谓解决方案重用,都是在说谎。以为客户具体需求差别很大,客户自己的想法也很不一样。

其次是技术路线。即便你滩上一个技术类系统实施项目,那在咨询部门的技术实施和在产品部门也完全不同。IBM的产品部门基本是专注在产品技术本身, 每个工程师对产品的某一个模块很熟悉,很专注,技术实现强调产品完备性和重用性;而咨询部门则完全是另外一个路数。 他们强调的是项目范围内风险可控,因此更多采用相对来说不那么高级的技术细节。比如一个数据库访问模块的实现,产品部门可能用了一堆的设计模式,所有能外部参数化的都参数化,搞了一堆的支持模型,能够支持Oracle, MySQL, DB2.....外加zOS, AS400, AIX, Soloris, HP UX.....恨不得所有的平台都统统的搞定。而咨询项目则是特定平台的,同样模块咨询项目可能就是用简单的Java 可持久化框架分分钟搞定了,什么多平台多产品支持一概不予考虑。反倒是更加关心在系统性能上去后的各种处理,例如使用很多缓存啊、memcache啊..等等。否则系统垮了架构师是要坐牢的。因此,很负责的讲,产品架构师和系统架构师是完全不同的两个工作。

我比较幸运,来到咨询部门第一个项目就是当年全国最大的信息化项目,具体客户名我就不提了,无论是行业还是客户提了就很快知道是谁了。总之这个项目是十几亿的大型项目,而且最奇葩的是IBM是咨询,HP是实施,下包给埃森哲,用的是SAP ERP和ORACLE DB. 显然,这是一个足够热闹的项目。各大IT供应商全部到场落座,基本上各种利益牵扯在一起,打的不亦乐乎。这个项目我们是项目群管理和需求分析,也就是一个甲B方的角色,代表客户来管理各种跟我们没有合同关系的“友商”。项目大到最高峰时期有恨不得200+的人驻场工作,而各方面的利益牵扯,使得项目群管理显得尤为困难。 这个项目让我明白的最大道理,不是什么技术和项目管理本身。而是如何在项目中沟通与分析各方的立场。这点在大项目中尤为关键,每一方每个人都有他自己的立场,都源自他的利益。所谓屁股决定脑袋,脑袋反作用于屁股就是这个道理。如何制作到沟通有效,说服有理?就需要明确你的沟通目的,明确对方的立场和底线。我觉得这确实是IT人,尤其是工程师比较欠缺的一点。当然我也不是一下就学会的,都是必须缴足了学费。经常有时候开会,一句话说错可能就上了全套,然后被对方拉出来使劲打,你还话说。工程师相对单纯,但做咨询顾问不仅仅是要做好技术,而是要将技术运用在客户的特定场合。说服对方,既要靠技术,更加重要的是要靠沟通。

IT技术人员一定要学着面对客户,面的那些非IT的人员。 尤其是在做客户项目时,不能总是用IT的语言或者思路来和客户沟通。要学着用业务的思路,想想看客户为什么这么做,这么想。他的痛点在哪里?如何通过IT来解决问题。归根结底,IT是为业务服务的。银行核心系统本身不赚钱,只有银行的存贷款业务才赚钱啊~

转载注明地址:http://www.chengxuyuans.com/program_life/65309.html