您的位置:首页 > 其它

今年冬天有点冷(2)

2008-02-03 17:14 232 查看
我本身不想把年终总结写的想悼词一样,可是现实的确残酷,活生生把人往死里整,身体没死,精神已死上好几回了。以前抽象性的认为当程序员很苦,但这种苦也就是身体上要忍受熬夜加班的苦而已,结果不尽然,更多的痛苦是需要精神来承担的,华为过劳死的人,我觉得不是不眠不休累死的,而是在精神的高压下,活活熬死的。一年来也就做了两个项目,一个是之前提到的,另一个就是规定要在一个月以内完成的。
前者,因为大部分都是我一个人在做,特别到了后期,想叫人帮忙也无从下手了,打比比方,好比我在一个违章搭盖的破架子上,横七竖八的结了好多了网,把我自己也给困在了里面,我在里面绝不敢乱动,更加不敢让别人乱闯,起码现在纵横交错的还能勉强用用,万一发神经的动了哪根主干网,我可以投江自尽了!客户不好惹。重构?想都不敢想,这个系统算不上什么大的系统,但硬生生做的比任何系统都复杂,用几个模块积木搭拉起来的,动哪里都有危险,想重构,没这个人力也没这个精力,更加没有这个必要,整个三年的维护费用三万,呵呵,相当赔本的买卖。对这个项目做一个总结吧:
A、无需求上马,在本来的一个研发半成品上面挖空心思,盲目乐观的认为这个项目很简单,匆匆上马,没有任何的需求报告,没有任何的方案设计,导致前期推进艰难,后期境况凄惨。
B、客户沟通严重歧义,在开发人员不能及时很好的跟客户沟通的情况下,遇到了甲方没有任何技术背景的技术人员和保守谨慎的分管领导,化学反应非常剧烈,前期两个月的时间竟然纠缠在首页页面的美工上面,几度返工。
C、客户支持不够,开发过程中的很多问题,不是推卸责任,是因为硬件网络的问题,这些方面因为客户没有人员可以解决,为了改善这些问题我们这些开发人员不得不充当硬件维护人员的角色,帮忙铺设网络搭建硬件设备,偶尔还得帮忙维修操作系统(~_§)。
D、没有经过严格测试匆匆上线,导致BUG满天飞舞,给使用者和甲方人员造成了恶劣的印象,对方表达了应该有的不满,我们也表达了应该有的委屈,就这样造就了开发人员和甲方的分歧,这种隔阂情绪持续了相当长的一段时间。
E、需求变更频繁,这样讲其实是不准确的,但毕竟好理解。不准确意思是原本就没有做好需求分析,只是拿套还只适合在研发室里面待着的系统,来生拉硬套,结果是可料的。而且作为一个软件供应商,所谓的需求变更频繁,那是结果,只能说是没有做好需求分析,真正的兢兢业业、一丝不苟的把需求理解透彻了,充分了解了用户的要求和习惯后,需求就没有变化的道理了。对于这个项目来讲,用户在界面和使用习惯上面的频繁变更,加上内部使用人员的意见不一致,美工和功能一改再改,为项目的无限延期盖了一个浓浓的大红戳。
F、无任何的项目管理过程,当然这样也是因为前期规划将时间压缩太大,无法形成项目规范,那时候老板不懂磨刀不误砍材工,结果刀没磨,材也没砍的生脆,半死不活的,整个团队进退两难。这应该也不能赖老板,本身不是作为一个技术主管,一切从商务考虑无可厚非,加上太过信任之前研发这套系统的人,盲目乐观的把我推入了悬崖。
G、没有为开发人员提供良好的环境,这里包括了开发环境和生活环境,开发环境不要讲了,自己带着笔记本到了一间狭小的办公室、拉条网线就开始办公了,两个人的办公室,一度挤进了7个人,喝个水都难,艰苦条件可想而知。生活条件嘛,前面提到过的套房,房间倒是不错,条件还是艰苦,天天只能带着矿泉水去喝,没有办工桌就随便拉条茶几凑合着。
H、额外的待遇问题,作为外派入驻的技术人员,公司并没有提供有力的后勤保障,我们这些人基本上都是用自己的,除了交通费能报掉一些,开销还是相当的大,而公司以高额的项目奖金作为幌子拒绝为员工发放补贴。可事后证明,除了我发了可怜的奖金以外,其他人为0,也就是相当多的人白干了(只能说公司没亏本,我们这些人瞎忙活了一年)。
总结:没有什么软件项目是简单的,想去做一个集成度相对较高的系统,必须有一套相对成熟的平台,有一个相对分工完整的团队,无论时间多么紧迫,哪怕天塌下来,也要事先了解用户的要求和习惯,没有要求为他们制定要求,没有习惯就自己观察他们的习惯。团队必须有更用户沟通的机制,形成书面的文字汇报,制定完整详尽的进度表而不是忽悠表,根据情况据理力争,为开发和测试留足时间;切记上线前有套完整的测试流程和方案,减少BUG的出现量,给用户足够的安全感,这样后续的工作才能有条不紊的展开。最后一条,软件是给普通人用的,而不是给技术人员用的。
对个人的总结:任何时候做好技术积累都是很重要的,无论是硬件、网络,软件技术上在深度的基础上,加上广度的涉及是十分必要的,因为项目开始的时候你不会想到有什么问题在等待你的眷顾。团队协作是很有必要的,单枪匹马到最后只会十面埋伏。跟用户沟通必须有充足的耐心,像对待一个婴儿一样(在技术上当他们是婴儿不过分),避免谈及技术上的问题,直接引导向解决方案的讨论,在复杂性、期限之间寻找适度原则。谈判是很需要技巧滴,加强锻炼很有必要,在用户无限追求大而全的境况下,必须能巧舌如簧,尽量不损害双方合作的情况下,为乙方多争取一些利益。不到万不得已,不要吵翻。
都不知道扯到哪里去了,这是今年的第一个项目。
第二个项目是老大带着我们一帮四个人又入驻开发,住的地方还是原来的房子,顺便提一下,那套房子一个月的房租都有一千多,基本上也就我曾在那住的比较久,平时基本上就空着在那浪费和装灰尘。这次更倒霉的是,办公地点离宿舍更远了,基本上都得打的回去。一个小项目,信息管理系统,这次境况好点前期需求有了充足的准备,人员也配备的很整齐,因为甲方本身有套类似的系统,所以项目基本上没有什么难度,但中间的波折也是不断。五一的时候,公司不由分说的就把我们给派下去了,我的十一这样毁了,就像当初五一毁了一样,又说要一个礼拜完成,我心里默默的祈祷这次不要变成十个礼拜。不需要我负责设计方案,所以基本上没有什么压力,分了功能模块就开始设计了,但当决定要用什么框架的时候,犯了一个不可饶恕的错误—我毛遂自荐了一下,提议用一个我曾经使用过的struts开发平台框架,老大当时没发表什么意见,说他无所谓对他来说什么框架都一样,我们几个也就着手准备了,时候证明老大心里还是不爽的,因为他想用他自己的东西,压根就不会理睬我拿出来的东西。
当时我义无反顾的用了我选的那个框架,可是开发了几天后,频繁的被叫去训话,说我做的方法有问题,在一次比较严重的事故以后(时候证明不是我的问题,是谁的问题很明显)我实在受不了了,把框架剔除了,又把原来做的东西移植到老大的平台上,其实也就是JSP模板页面+JDBC封装,注意我用的是“模板页面”而不是页面模板,页面模板可以理解成一个技术,但模板页面就只是一个页面而已,复制粘贴文件以后改参数代码,就做好了一个增删改查,呵呵,写到我头皮发麻。本来简单的技术也没有什么问题,可是越往后做问题就来了,当需要不同用户显示不同页面的时候,页面上夹杂了if else的点点繁星,到最后的个人做的东西只能由原作者来改了,因为别人压根就看不明白你要写什么,没什么人会在jsp页面上写注释吧。
对老大一个比较称道的方面是,在测试方面做得比较严格,上线前能把个个功能点全部检测一遍。不过也仅限于人工测试,手动输入数据,手工验证是不是准确。一切都以原始的方式来开发。我明白了一个道理,技术上不是以先进不先进来区分好坏的,区分的标准在于你执行规范标准的力度有多深,再原始的方法使用不恰当,性能效率一样不行,好比JDBC够原始、底层,用不好还是慢如蜗牛。
做完系统唯一有成就感的就是,开发了一个模板替代法的Excel导出模块,用了一个投机取巧的方法来实现。但因为开发周期太长,还是被老大给训了。最后项目刚刚好一个月的时候完成了,总体来说客户还是认可的,满意是不能说啦,让我这个开发人员去用这套系统我都有点头晕。从这个角度JSP绝对不适合web2.0,因为web2.0需要太多的人性化设计,除非对JSP进行封装再一次的封装,这方面我觉得JSF倒是可以作为一个替代者,又扯远了。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: