交行新一代托管平台项目的总结
2012-02-26 22:36
267 查看
马上要离开这个一起奋斗了一年多的项目组, 一年多来我只能对所付出的辛苦用四个字概括:一言难尽。如今我就像一只小鸟,它飞出疆界,脱离了同伴,振翅往自己梦想的地方,应该说它是幸福的,因为有了一片广阔的蓝天,可以自由飞翔,然而,离群的痛苦,旅途的险阻,却也是不得不付出的代价。更危险的是,它飞向的地方也许并没有丰腴的虫子、想象的盛宴,可能最终得到的是荒芜一片。虽然风雨中的疾行能锻炼出结实的臂膀,坚强的意志,可过程毕竟痛苦,何况有了目标,却缺少航线,凭自己去感觉、去探索,绕道、错道亦在所难免,其中艰难可想而知啊。
不扯那么远了,我还是谈点自己的想法吧。这段时间看了些书,我深刻感觉以前视野太狭窄,知识也闲肤浅,欣欣然享受着“健康的疲惫”,放纵自己看电视看到晚上12:00以后、晚起,以为自己已经有理由这么做。现在想来,有点伤感,项目虽然快接近尾声,但内心却感觉一天比一天空虚,不知道自己到底为了什么,虽然自己从大学毕业至今,项目到做了不少,可是觉得自己在业务领域比较肤浅,自从进入交行,自己开始对金融行业产生了浓厚的兴趣,在工作之余我也在努力补充基金、托管方面的知识,最近我也咨询了几所学校的金融学专业,想读个在职研究生充实下自己,虽然有学校说可以免试入学就读他们的学校,我还想仔细的斟酌下。现就托管平台项目谈谈自己的所得和开发中出现的一些弊端谈谈自己的看法。
2010年12月1日,交行新一代托管平台项目组正式进场,标志着公司的新一代托管业务的解决方案获得客户认可,正式开始了方案实施的阶段。一年多以来,项目从工作任务分解到需求设计,从架构定义到接口实现,从系统完成经过SIT、UAT、业务人员的测试到上线,从业务建模到前台Flex组件的编写,项目组成员团结一致、紧密配合,实现了项目初始时期的适应性目标。项目成员与客户现场人员一起努力,经历过几次迭代开发,终于于2012年2月16日上生产线了。但是在开发过程中也呈现了一些弊端:
第一:没把握好需求,客户方提出的需求不明确;需求如何去细化把握,首先需求是要以层次去划分的,最简单就是上中下即管理层的关注管理理念及方向、中间管理层关注的整体流程以及各个模块的之间的依赖关系,最后是操作人员的操作细节,整个过程是由上而下去细化的,管理层提出的理念基本上就是这次项目的目标,这个很重要,基本上是项目的大的方向,中间层的管理流程是最复杂也是最容易出问题,一般在这方面出现的问题最多。到了操作人员基本上就是界面上的东西,就是这里应该多一个字段,那里改个什么标识的,但是不能够end
user 影响key user,最后把整个方向都改变了。比如此项目中的中登场内交易就因为当时开发需求不明确,导致曾经一段时间同事们加班、加点去完成,有的页面都出现重做的情况;
第二:程序管理上有点混乱,大多数开发人员都是自扫门前雪,休管他人瓦上霜。在开发一个新项目时,一定要把框架搭好,比如:搭个鸡窝你也要考虑选址,材料,大小等。如果你不想浪费你的时间,一定要把框架搭好,如一个方法实现一个功能,当然这个方法会调用其他的辅助方法,特别是写底层方法的人,你的方法都是写出来让大家调用的,别人实现一个功能还要调你N个方法,你说别人爽不爽,让别人爽了,才是真的爽,一个功能一个方法,看起来也清晰,总之百利无一害,当然要达到这个程度还是要一定的积累的,把事情做得更好当然也需要更多时间,但我们开发中最缺的就是时间。有的开发人员在写接口时,没有考虑到他人可能也会调用此接口的可能性、异同性,导致本来一个接口可以解决的问题出现多个接口。
第三:对UAT所提的bug没有经过严格的审核,就直接交给开发人员去修改;由于测试人员对系统的表现感到模糊,常常按自己所认为的系统缺陷去提bug,后来修改后客户发现,第一个版本才是他们想要的。这样就导致无效bug的提交。一个项目做完后,要升华一些知识和方法论以及资料,简单来说是取完水要架根管子,每个项目做完会有一些测试案例、安装文档、会议记录、流程图等,这些是项目资产,不要每做一个项目,所有的东西都要从头来过,例如测试案例,只要整理一下,下一个项目还是可以继续使用的,只要把修改点加上去,节省很多时间。
第四:有时项目的需求一直无法落地,除来一些业务原因外,应该说在获取需求的过程中我们缺乏一些好的工具,我们的业务场景(包括正向的流程与逆向的流程)整理不够完善,这些可以和测试案例一同整理,在此项目中,很多讨论都停留在文字和口头的叙述方面,其实多做一些流程图、用例图、系统集成架构图会,更直观,业务员看了后更容易看清楚系统的模型。
第五:程序是持续优化的过程,只要系统存在,优化的需求就不会中断,但是,这种需求的修改是要按版本来规划的,绝对不能够东一个补丁西一个补丁去做,这样做程序缺乏稳定性,并且测试和考虑也不充分,风险很大。
最后,我认为作为一个程序员,我不太赞成长时间的工作,就算是项目很忙,也不需要加班到晚上九点多吧,我考虑到四点:
1:长时间工作效率不高
2:程序员也是要有自己的私生活的
3:业余时间学程序员自己也想学知识,充电
以前晚上加班的时候问题解决不了了,我还在那里死磕,弄到很晚,、好多次问题都是在公交上解决的,大家都是用脑的人,别信那些说自己以前是多么的疯狂,弄到几点几点的,很牛X的牛也是要合理的休息的,会利用自己时间的人总是让我很敬佩,刘未鹏有本书叫《暗时间》,我只看了目录,结合书名和目录我想他就是将怎么充分利用自己的时间的,不用总是对着电脑在那里敲,反复的敲,我还是比较赞成文思涌泉,闭目养神什么的,渴望一个自由的空间,而不是感觉有一双双眼在看着你的工作环境,程序是一个创作性的工作,不是苦力,我们会经常看那些离开你的电脑,远离你的电脑去做开发这样的文章。不就让我们多动脑,多思考吗,古人总结很多的,现在越来越觉得古人总结的一些道理真是太好,太神奇了,让我感触最深的一句就是“温故而知新”,因为N年前发生的很多事情我还记得很清楚,离题了。
这是我晚上加班回来洋洋洒洒的写了这么多,由于时间仓促,语言不是组织的很好,在即将离开项目组时没想到自己发现了这么多大大小小的“坑“,而且几乎每个“坑”都跌到过,都留下了伤疤。看着满身的伤疤,立刻感到自己又“强壮”了许多,“彪悍”了许多。在这里再次感谢整个项目组成员,还有胡经理,是你们造就我一天天的“彪悍”,我更希望整个团队变得更“彪悍”。
不扯那么远了,我还是谈点自己的想法吧。这段时间看了些书,我深刻感觉以前视野太狭窄,知识也闲肤浅,欣欣然享受着“健康的疲惫”,放纵自己看电视看到晚上12:00以后、晚起,以为自己已经有理由这么做。现在想来,有点伤感,项目虽然快接近尾声,但内心却感觉一天比一天空虚,不知道自己到底为了什么,虽然自己从大学毕业至今,项目到做了不少,可是觉得自己在业务领域比较肤浅,自从进入交行,自己开始对金融行业产生了浓厚的兴趣,在工作之余我也在努力补充基金、托管方面的知识,最近我也咨询了几所学校的金融学专业,想读个在职研究生充实下自己,虽然有学校说可以免试入学就读他们的学校,我还想仔细的斟酌下。现就托管平台项目谈谈自己的所得和开发中出现的一些弊端谈谈自己的看法。
2010年12月1日,交行新一代托管平台项目组正式进场,标志着公司的新一代托管业务的解决方案获得客户认可,正式开始了方案实施的阶段。一年多以来,项目从工作任务分解到需求设计,从架构定义到接口实现,从系统完成经过SIT、UAT、业务人员的测试到上线,从业务建模到前台Flex组件的编写,项目组成员团结一致、紧密配合,实现了项目初始时期的适应性目标。项目成员与客户现场人员一起努力,经历过几次迭代开发,终于于2012年2月16日上生产线了。但是在开发过程中也呈现了一些弊端:
第一:没把握好需求,客户方提出的需求不明确;需求如何去细化把握,首先需求是要以层次去划分的,最简单就是上中下即管理层的关注管理理念及方向、中间管理层关注的整体流程以及各个模块的之间的依赖关系,最后是操作人员的操作细节,整个过程是由上而下去细化的,管理层提出的理念基本上就是这次项目的目标,这个很重要,基本上是项目的大的方向,中间层的管理流程是最复杂也是最容易出问题,一般在这方面出现的问题最多。到了操作人员基本上就是界面上的东西,就是这里应该多一个字段,那里改个什么标识的,但是不能够end
user 影响key user,最后把整个方向都改变了。比如此项目中的中登场内交易就因为当时开发需求不明确,导致曾经一段时间同事们加班、加点去完成,有的页面都出现重做的情况;
第二:程序管理上有点混乱,大多数开发人员都是自扫门前雪,休管他人瓦上霜。在开发一个新项目时,一定要把框架搭好,比如:搭个鸡窝你也要考虑选址,材料,大小等。如果你不想浪费你的时间,一定要把框架搭好,如一个方法实现一个功能,当然这个方法会调用其他的辅助方法,特别是写底层方法的人,你的方法都是写出来让大家调用的,别人实现一个功能还要调你N个方法,你说别人爽不爽,让别人爽了,才是真的爽,一个功能一个方法,看起来也清晰,总之百利无一害,当然要达到这个程度还是要一定的积累的,把事情做得更好当然也需要更多时间,但我们开发中最缺的就是时间。有的开发人员在写接口时,没有考虑到他人可能也会调用此接口的可能性、异同性,导致本来一个接口可以解决的问题出现多个接口。
第三:对UAT所提的bug没有经过严格的审核,就直接交给开发人员去修改;由于测试人员对系统的表现感到模糊,常常按自己所认为的系统缺陷去提bug,后来修改后客户发现,第一个版本才是他们想要的。这样就导致无效bug的提交。一个项目做完后,要升华一些知识和方法论以及资料,简单来说是取完水要架根管子,每个项目做完会有一些测试案例、安装文档、会议记录、流程图等,这些是项目资产,不要每做一个项目,所有的东西都要从头来过,例如测试案例,只要整理一下,下一个项目还是可以继续使用的,只要把修改点加上去,节省很多时间。
第四:有时项目的需求一直无法落地,除来一些业务原因外,应该说在获取需求的过程中我们缺乏一些好的工具,我们的业务场景(包括正向的流程与逆向的流程)整理不够完善,这些可以和测试案例一同整理,在此项目中,很多讨论都停留在文字和口头的叙述方面,其实多做一些流程图、用例图、系统集成架构图会,更直观,业务员看了后更容易看清楚系统的模型。
第五:程序是持续优化的过程,只要系统存在,优化的需求就不会中断,但是,这种需求的修改是要按版本来规划的,绝对不能够东一个补丁西一个补丁去做,这样做程序缺乏稳定性,并且测试和考虑也不充分,风险很大。
最后,我认为作为一个程序员,我不太赞成长时间的工作,就算是项目很忙,也不需要加班到晚上九点多吧,我考虑到四点:
1:长时间工作效率不高
2:程序员也是要有自己的私生活的
3:业余时间学程序员自己也想学知识,充电
以前晚上加班的时候问题解决不了了,我还在那里死磕,弄到很晚,、好多次问题都是在公交上解决的,大家都是用脑的人,别信那些说自己以前是多么的疯狂,弄到几点几点的,很牛X的牛也是要合理的休息的,会利用自己时间的人总是让我很敬佩,刘未鹏有本书叫《暗时间》,我只看了目录,结合书名和目录我想他就是将怎么充分利用自己的时间的,不用总是对着电脑在那里敲,反复的敲,我还是比较赞成文思涌泉,闭目养神什么的,渴望一个自由的空间,而不是感觉有一双双眼在看着你的工作环境,程序是一个创作性的工作,不是苦力,我们会经常看那些离开你的电脑,远离你的电脑去做开发这样的文章。不就让我们多动脑,多思考吗,古人总结很多的,现在越来越觉得古人总结的一些道理真是太好,太神奇了,让我感触最深的一句就是“温故而知新”,因为N年前发生的很多事情我还记得很清楚,离题了。
这是我晚上加班回来洋洋洒洒的写了这么多,由于时间仓促,语言不是组织的很好,在即将离开项目组时没想到自己发现了这么多大大小小的“坑“,而且几乎每个“坑”都跌到过,都留下了伤疤。看着满身的伤疤,立刻感到自己又“强壮”了许多,“彪悍”了许多。在这里再次感谢整个项目组成员,还有胡经理,是你们造就我一天天的“彪悍”,我更希望整个团队变得更“彪悍”。
相关文章推荐
- 内部劳务队伍信息管理平台——项目总结
- 手机平台项目中的问题及经验总结(一)
- 贵州高速公路总公司——机电管理平台:项目总结
- 社交平台舆情分析项目的总结和感想(SELENIUM,NLTK,贝叶斯分类器)(一)
- 分布式版本控制系统Git与项目托管平台Github相关概念、操作方法、开发流程与常用命令
- 某教育平台项目开发之--使用SSM框架开发过程遇到的问题总结
- java二手书交易平台 项目个人总结 2013年12月23日,7:01:55
- 项目代码托管平台汇总
- 总结:接入第三方平台登录注册项目
- *知识总结*业余项目[易冲平台]
- Github网站加载不完全,响应超时,如何解决 Github是一个代码托管平台和开发者社区,开发者可以在Github上创建自己的开源项目并与其他开发者协作编码。毫不夸张地说,高效利用Github是一
- 项目总结-EMOJI表情处理详解(ios,android平台兼容)
- 贵州高速公路总公司——机电管理平台:项目总结
- 在开源中国托管平台上新建项目
- C665x视频处理平台项目总结
- 基于TMS320DM6437平台嵌入式智能工业相机项目总结
- Git学习总结(3)——代码托管平台简介
- OLAP --ODS项目的总结 -- 平台选型,架构确定
- 一体化仿真平台项目总结(一)