小程序员工作一年多的感想

我是某大型项目甲方的一个小小的程序员,才开始工作不到一年,通过这一年来对项目的了解深入,感触越来越深。

大致说说这个项目吧……

项目的目的是为公司全国业务提供统一平台,数据集中到总部。(我在这一年来的了解以后觉得这个最初的构想就是错的,当然这是事后乱侃……)

项目的特点……
全国各地的业务流程其实并不一样……应该说,是大不一样。虽然经过咨询公司一年多的梳理(仅对几个比较大的城市的业务进行了了解的情况下)理出了一个核心的业务模式和流程,但是基本上,每个地方实际工作都与这个核心模式和流程千差万别(我听一个到各地去实施的人员跟我说,你在上海和深圳跟业务人员提到A这个常用的业务名词时,两地的业务人员基本上想到的是完全不同的东西,可以想见这个差别有多大)。因此,想在一开始对各地流程进行详细摸索,做出一套完整的需求分析是绝对不可能的事情……当然你更不能指望公司强制各地公司使用一套流程之后再开始做这个项目。于是只能在各地循序渐进,一个地方一个地方地加到系统里来。这就造成有的地方已经进入实际生产,有的地方还在试运行,有的地方还在采集需求。

目前数据库已经有了800多张表,上万个字段,程序也已经渐渐显出乱象……我对这个项目越来越悲观了。

另外……我发现,在甲方做IT部门有个极郁闷的地方,就是你永远不会有效益,永远是错误中心和成本中心,永远被业务人员鄙视,你不会有功只会出错!

那么请问各位的是:
1.如果你来面对这个项目,从零开始,你会如何做?如果要你现在开始接手这个项目你又会如何做?
2.你如何面对甲方IT部门不会有功只会出错的问题?

你是个很有想法的程序员,个人感觉很不错的!
我还是大三的学生,虽然也在做项目,并且在负责一个项目。但是项目毕竟千差万别,而且我是初出茅庐,我的项目也不涉及到这么复杂!
你这个项目貌似采集需求真的很难,这种项目真的比较棘手,就像一个火车站的售票系统一样,这都是很难开发的。
不会有功只会出错我不明白你的意思,难道你们项目管理有问题,我觉得领导的魅力不能去责备人,而是去鼓励人!
不会有功只会出错是针对用户(也就是业务人员)来说的。
在非IT公司里,所有的利润都是业务人员挣来的,跟IT人员无关。因为由于IT带来的效益是无法区分出来的。

你给业务人员的印象就是:我们养着你。你花了大笔的我们挣出来的银子,给我们一套看似好用却漏洞百出的系统,另外由于必须使用这套系统,我们不得不放弃原有的系统,工具,以及某些工作习惯,包括某些我们能够向总部隐瞒的虚报的等等猫腻。这给我们工作带来极大不便以及利益损失。

你不会知道你的系统究竟带来了多少效益,因为说不清楚。但是能说清楚的是你的系统出了多少次bug,多少次事故,给我们带来了哪些哪些问题。

这里双方问题,一个巴掌拍不响。

既然是双方问题,就是沟通问题,可以做得更多的当然IT软件这边,我们可以找出一套随需而变的快速方法,然后跟随客户甲方要求,如果你能敏捷做到这点,相信客户甲方不会给你白眼,而是主动积极配合你,因为你让他们看到了希望和进步。

这套方法就是OO。

楼主的描述很像建行的CCI系统,我去初做这个系统的时候也有这个感觉。
不过,国企跟民企就是不一样。
我比较多,花了也不是自己的
感谢banq大哥的回复,不过我觉得很多事情不是技术问题能解决的。

从实施的过程来看,很多分公司是抵制上这个系统的,原因很简单:系统对多个方面的业务流程进行了一定的规范和管制,并且因为数据大集中,业务和财务数据更加透明化,因此各地分公司做猫腻的可能性减少。用户提的相当一部分的所谓增加灵活性的需求其实都是希望能规避这种透明化和管制。

有这种利益背景的情况下,当然用户会很不配合,很苛刻,消极怠工,告状,甚至找碴吵架等等等等。而你不能指望更高领导层能明察秋毫。

另一个问题是:OO固然好,但是由于过于灵活,很多事情的决定是case by case的,因此需要一个非常强悍的架构设计师来拍板,倘若没有这么个人,或者有好几个这样的人都很难办。

举例而言,前一阵我们这里讨论了对系统的某种改造,类似贫血模型和充血模型的问题,无疑,充血是非常OO的,但是由于case by case的特性,结果就是会有无穷多的争论。因此大家讨论来讨论去,还是回到了贫血这个不是很好的归宿。

BTW:我们是甲方的IT部门,客户是我们公司内部的。
[该贴被sleepinglord于2008-06-06 10:01修改过]