让我欢喜让我忧—我的IT情结

 

1       中国IT企业的普遍现状

1.1          程序员真的要”30而终吗?

在我的朋友圈中只有极少部分仍然进行编码工作;有一些对技术特别热衷的要么是进行公司的产品和框架的开发;要么是因为兴致爱好搞一些共享软件。能在IT企业里工作其实对我们大家来说,可以接触各种新观念,尝试各种新技术,是比较有挑战和刺激的行业,其实很少有人从心里会喜欢类似制造业那样缺乏创制的工作环境的,对于设计工作,是技术也是艺术,是难以割舍的情怀。

虽然在其他业界人员眼里看来的IT人员是先进高科技的代表,带着骄傲神秘的光环,但是再深入看看他们的生活,除了少数的激情派紧跟技术潮流外,大多数多是在月光下拖着疲惫的身影回到家中,虽然桌上放着想要看看新买的书籍杂志,但是就难以静心看上几页。

尽管大家全力投入开发,但是通常我们无法按时交付们的产品,勉强按时交给客户的,通常也是“货不对板”,紧接引来客户的频繁不满的不满投诉和老板的恼怒!看看很多IT企业居高不下的人员流动率,就可以或多或少地感觉到这种生活的无奈!难怪<<人件>>在那么多程序员心中引起那么强烈的反响:IT人的生活需要素质吗?如何确保给员工一个有利保持激发创造思维的氛围?

难道在中国IT技术人的30岁就要考虑转做管理人员或去进入其他传统行业吗?

 

2       原因分析与对策

2.1          客户方面

和许多中国IT企业人交流的第一感叹是:客户不成熟是导致中国目前IT项目难以走入正轨的主要原因。笔者认为有一定道理,但是不能怪客户, IT企业间的恶性竞争和只顾眼见的短视行为也是很重要的原因。

从我参与和听说过的成功项目分析来看:只要客户从心里十分重视,将系统当成企业生产环节的不可缺部分,则项目通常已经八成有成功的希望了。从早期的银行和电信、航空系统的成功建设就不难说明这一点。这类客户行为上看基本有两个特征:

存在客户方的项目核心小组,责任落实到人;

关注过程,中间产物环节层层把关,请内外专家充分论证;

有些至关重要的系统,如电信的计费系统,往往是客户专门成立一家软件开发公司。但是从社会整体来讲,不利于社会的专业分工,成本也很高。广州移动在IT的外包上一直控制得较好,牢牢抓住自己核心竞争优势,是其他企业学习楷模!

记得那次和高展先生的触膝长谈,他认为中国企业的在没有跨越工业化的时代,就直接进入信息时代,他在电子商务泡沫破碎前向我预言B2B电子商务在中国其结果必定是昙花一现,看来他说中了。但是这几年马云手里的阿里巴巴越做越大,我也打心眼里佩服在那段寒冬岁月里他的那份坚强。希望在10年内看到中国企业的真正的B2B电子商务时代的来临。

企业要想借助IT提升竞争力,就首先要在自身的流程上不断梳理和改进;否则配套的信息系统就难免成为电子单据的积累,信息系统的维护成本没有能够有效地降低整体业务运作成本,必然造成与国外同行企业的实力拉大的不利局面。韩国最大的软件公司之一在2002年拥有6千多人的设计和控制队伍,后来还成立了专门的顾问公司,它的组织很特别:绝大多数是博士学历,还有从设计和管理中挑选出较多10年以上的优秀实干人才加入。当然他们拥有多套先进的顾问方法,考察中看到他们给韩国某大企业做方案就动用了几十人的团队历时半年考察了近十个先进国家的先进业务流程并规划了该企业的未来流程设计。这是一个高附加值的项目,当然新的规划不但对制度和流程进行了完善,还借助了先进的条码、数据仓库等软的先进技术来提升竞争能力。在中国,先生的全程建模思想是多数企业一个比较适中的选择。(虽然先生的”UML三大硬伤在中国IT界引起渲然大波,甚至引来无数个人攻击,但我觉得那毕竟是学术交流,大家都不应该存在人身的攻击才好,我本人就喜欢用UML中最常用的那些表示法,可是近来好像什么都强调要统一,越来越多东西的包含进来了。比如一些关于多进程表示或者嵌入开发的表示多数人就从来没有用过,当一个工具掌握它并能应用的成本和带来的收效不明显时就要考虑是否值得。中国大部分程序员也许没有几个人精通MS Excel的高级应用的,但大家还是紧跟升级的步伐,MS当然是到达了自己的商业目的,但是试问如果每个人都是花钱购买正版软件时也许会理智一些了)

我见过好几个国内的物流公司,有一两个兼职信息负责人已经是不错的,他们有业务方向上的粗略规划,但是基本没有细致的运作规划,更谈不上系统建设规划了。通常他们要给国外的知名企业做配送,而国外的大企业是非常看重系统建设,就出现了信息接口推动企业信息系统建设的局面。但是如果这些企业真正重视信息系统建设,纳入运营规划中,创造良好的企业信息系统需求拉动力,就会在市场竞争中处于有利地位,也避免仓促上马信息系统带的后续维护和扩展艰难、甚至推倒重来的骑虎难下的尴尬局局面。

更有些糊涂客户,招标时就只强调开发方的资质、证书;以前的产品;开发队伍的学历等,而对一个开发商如何把需求转换到产品的过程能力是基本上没有认真考察的。其实证书可以买来,产品可以借来,团队成员也可外借拼凑,而当企业把一个不现实产品功能期望加在一个非常滑稽的进度要求上并以合同方式确定后,一个痛苦的团队就此诞生!正如Brooks<<人月神话中>>那些在焦油坑里挣扎的一群笨熊。而客户也只能是生米煮成夹生饭,将就用吧。偏激的领导往往由此下结论:IT言过其实,并无大用,今后尽量减少系统建设投入!

如果企业比较聪明,他可以先花小钱请一个今后不会进入开发投标的公司来给他做专业的业务需求和开发需求规格;或者可以请专业的管理顾问公司去考察开发商的过程控制能力,通常一个好的过程比看到一个现有产品更加让人放心,因为过程能力决不是一天半月可以造出来的。

2.2          企业自身

说完客户这边的情况,再来看看国内多数IT企业的现状吧:

以前俗话说盖楼工人没房住,鞋匠没有好鞋穿,这用来比喻目前的很多中下IT企业再形象不过了。IT企业面临两难:找卖家难;拿到项目开发控制难,通常一点可怜的利润又给一年免费维护(实际上不单是维护,少不了功能变更与新增)全赔进去了。

为什么找卖家难:做通用产品吧,前期投入过大,有盗版又满足不了客户特殊要求;做项目吧,产品质量差、维护没有服务好,老客户就难以回头;试问中国IT企业有几个老板能说清路在何方?

开发管理难:技术人员都是知识分子,不是简单的工人。他们有思想,向往创新,看来在管理能力不够的情况下简单模仿软件工厂很可能是难以凑效的。即便有很强的管理能力下,员工有激情和只是工作挣取生活费用两种心态下的开发效率简直不能同日而语。一般项目的风险很容易得到各相关部门的高度配合[如制造飞机、海上油井开发],而在软件企业,项目计划和风险计划通常是无人问津。计划书通常只是应付客户,难得有人去更新。到了某一天,火星终于擦出,火势迅速向四周蔓延,于是就又开始上演一场英雄救火的壮观场面,通常还能把企业高层卷入其中。在此期间,英雄们终于可以在老总面前使出十八般武艺。救火行动完成后通常还会得到企业的荣誉勋章和实惠奖赏。遗憾的是通常这些英雄们在几次展示后也觉得很累,并且有越来越多解决不了的问题出现,但又不能辱没了自己胸前的勋章,于是默默选择离开。更加可悲的是很少有高层在救火完成后及时总结原因,找出下次避免的措施,他们要么投入另外一个火场,要么冲到一个正在犹豫的客户那里去拍胸脯去了。

实施难还表现在销售人员和技术人员地不协调上:如果销售人员或客户关系人员没有技术背景,情况就更加糟糕,他们为了完成本身的业绩,引导客户在偏离初衷的道路上越走越远,等到产品实际运行时已经造成了双方的巨大浪费。在系统运行时又不去引导客户现实理智地使用系统,成了不受控制的变更的传话筒,有时甚至在技术人员面前俨然成为客户代言人,将已经比较绝望的技术人员逼到造反为止。而技术人员要么不关注成本过于热衷新技术或新开发工具,拿客户的项目,公司的信誉当成技术试验田,为自己今后的技能再添一章;那么就是只关心自己目前的能力是否可以实现,将那些对客户真正有用的需求(今后公司发财的机会)拒之门外。

由于多数IT企业没有充足培训机会和完善的福利保证,为了平衡加班的损失,企业通常要每月花费好几千才能请到一个合格的开发人员,但是开发人员通常都会说自己很忙,以下是在许多IT企业对话记录:

经理问:“忙什么?”答曰:编码和调试

经理再问:“那块业务?”答曰:关于领导的统计

经理又问:“哪个统计?”答曰:客户欠款统计

经理不满意追问:“完成多少?如何计算的?何时可以完成?”答曰:”90%,凭经验估计的,大概3天吧

但是三天后重新问起,答曰“完成99%,正在寻找一个难找的Bug,估计是开发底层通用模块的人没有严格测试,不能确定到底还要几天可以排除,已经加班2天,争取再加2天搞定。”

中国的IT企业实在是问题确实不少,所以无法一一列举。各位领导也开始寻找致病的灵丹妙药,有可能比当初秦始皇和清朝雍正皇帝寻找长生不老要更加急切些。于是RUP\XP\CMMI等概念也都慢慢传到了中国。可惜他们生来就带用美国的血统,所以在中国的文化背景下往往给歪曲了,中国IT市场毕竟要经过一遍混乱、一次大浪淘沙,最后“剩者为王”。

2.3          出路思考

笔者经过几年的苦苦思索,也琢磨着搞一套企业统一开发模式,但是我最终还是否定了自己这个想法。就像易经里那个太极图所示,任务事情的对和错都是相对的,可以在一定条件下转换。只要企业自己有一个上进的决心和行动,就会总结出越来越高效的过程。只有自己才能决定自己的命运。

我个人认为在企业中,首先要把技能系统建立;再适机逐渐地把预防为主的管理系统建立起来。这两个系统和企业的产品最终是企业重要的软资产,这两个系统可以通过知识管理系统体现出来。在项目中,最关键的是BA(业务分析员)[帮企业进账]、项目经理和技术总负责[帮企业控支出]IT企业的最大浪费通常在需求开发和和变更失控上引起的;其次不重视设计、不重视预防性质的评审工作是引起大量的修改返工的直接原因。

读过国内外一些IT和非IT界的前辈的作品后,我终于认识到自己知识是多么的狭窄,我试着今后将自己的一些想法总结出来,和大家共同探讨;希望我们可以相互启发,给探索者留下一点什么。

posted @ 2005-09-28 10:07  成为-行动-拥有(BeDoHave)  阅读(801)  评论(2编辑  收藏  举报