Nitro's

Jan 19, 2014 - Comments - dev internet

我们到底遇到了什么困难

最近手头的工作不是特别忙,临近年关了正好也做做总结。2013年的主要工作是一个移动互联网项目,其间还有一些零散的工作,比如现场实施、项目调研需求分析等等。从目前的情况来看,这个移动互联网项目如果是百分制,或许它还在四十五分的路上…

2012年10月份XX银行与我们正式接触,提出要做一个移动互联网方向的项目。此时的移动互联网概念正在整个业界蔓延,各大银行纷纷开始布局移动互联网,网银客户端终于有了iOS、Android版,微信也开始崭露头角,尤其是移动互联网公司越来越高的估值让每个人的心中不免骚动,都想在这一大潮中掘得一桶金。前景确实很美好,但在拿到需求说明书之后,也开始陷入了深深的思考。我们公司的主要方向就是金融行业,所以从业务角度考略完全没有问题,但之前的项目基本都是运行在内网环境下而且用户量极小,这与互联网项目相比不仅仅是开发语言、平台的差异,而是思维的转变与架构设计重建的问题。开发人员上,公司的主要开发人员是WEB方向,Android平台开发我一个人负责,UI/UE半把手凑合,iOS平台基础为0。虽然有这些困难需要解决,但是项目最终是签下来了。

项目初期目标是先出Android版和管理平台,后期看使用情况再考虑iOS、Windows Phone。就这样从13年1月份做到今天,算下来整整一年时间,但这个项目的主体开发还在继续,完整性测试还没通过。现在回头看这个项目各种滋味,如果从资金上说,项目验收通过,没完成的算是后期开发;如果从产品可用性和用户角度说,它是一个半成品。就像《精益创业》中提起的一句话,在一个项目失败之后我们常常总结到,虽然项目失败了但积累了教训。不管是成功还是失败,总结教训,不要再犯同样的错误。

  • 需求定义、技术协调问题。

项目一开始是这样分工的:我负责Android平台App的开发和API接口定义,WEB管理后台和API实现由项目经理A负责。在UI初稿定型后,我准备提起测试一个API通讯接口,A直接发给我一堆AXIS2的客户端JAR包,还有一系列客户端代码让我把它导入到Android中,顿时我就一身冷汗,这是要做什么?之前的架构设计讨论过要使用HTTP/HTTPS通讯,架构图上也标明了,况且支持HTTP协议的API使用轻量级WS中完全可以实现,业界也都有成熟的模式可以借鉴,为什么突然跑出来一堆JAR包?后来和A讨论了一下才明白,原来之前做WEB开发时就是用的AXIS2 WS,所以A想直接复用后端代码,然后把Andoid App和HTML前端做类比,听到这里,我就开始反驳,还是要按照之前定好的HTTP协议通讯最好,AXIS这种重量级的WS不适合开发移动应用,如果用WS就选择Rest-ful 这种轻量级的,完全满足我们的要求。讨论之下没有结果,只好找技术总监来定夺,最终是走了折衷方案,抛弃AXIS2不采用Rest-ful,所有接口数据从一个Servlet接入。虽然这不是一个完美的方案,但总让我面对MB级的JAR长舒了一口气。此时还处于项目的初期阶段,万幸的是我一早提出测试接口,否则后面的路就越走越远了。还是那句话,一切按照文档来,尤其是API接口和交互类的设计,一定要双方约定好交互方式、通讯方式,早沟通早定义。由于之前没接触过移动项目,所以一味的照搬技术经验,容易导致误入歧途。

  • 源代码管理工具的使用。

之前公司内部采用CVS来管理源代码,但是内部使用起来仅仅发挥了代码保存的作用,而且账号体系不完善,开发人员共用一个账号,时常出现文件丢失、冲突无法解决的问题,所以从这个项目开始我部署上SVN源代码管理,每人分配一个账号,各自解决冲突、严格代码审查。在使用初期团队内部抵触较大,整体使用效果不佳,一些开发人员还是按照CVS的思维推卸自己删除文件的责任,导致内部有些小冲突。直到前几天,在项目经理的要求下,将最新的Android源代码和文档资料又迁移回CVS管理平台。事实证明SVN在我们团队下是失败了。团队开发人员对工具的依赖性不想切换工具(此事的另外一条例证,Eclipse现在已经到4.3,但WEB开发人员来停留在3.2),对代码的责任不够强都导致了SVN无法继续使用的结果,容易但使用CVS问题依旧还会出现;开发过程没有代码审查,也导致众多Bug重生的问题。

  • 项目需求的变更。

这或许是每个开发人员最头疼的一件事,做好的功能还要再回炉重造,微博上的吐槽也是不计其数。其实在项目开发过程中需求的变更是比较正常的事,但为什么还是那么多人吐槽呢,这其中也有项目经理或者产品经理的问题。本身App在开发前期已经定好了五大功能,而且UI也设计完工,突然技术总监找我说,AA不做了,现在抓紧换上BB,过几天需要演示,然后又需要做UI又需要砍掉代码重新来过。回头想想AA功能新颖,实现不复杂,产品突出点强,完全可以与类似产品做差异化竞争,换上的BB与其他功能略微重复,给人一种转来转去的感觉。最后又重新实现BB,花费大概半个月的时间。

  • 为什么总是提需求?

这几天项目上银行甲方又提出来不少需求,现在负责对接的同事开始抱怨“为什么总是提出这多需求?”他们的需求合不合理?我们到底应该以怎么的思维理解这件事?这都是我们需要考虑的问题,首先从商务角度考虑,甲方现在提出要求是合情合理的,因为我们签的是开发运维合同,属于长期技术支持型的项目,不断修改在所难免;其次我们没有合理的安排后期进度,导致需求来一个改一个,到最后就变成一锅粥,怎么改都不合适。没有合理的开发计划和更新进程导致项目处于一种无序的状态。再者做传统软件项目的思维一时半会儿无法适应互联网模式下的“小步快跑”、快速迭代也是一大致命因素。

  • 团队人员管理。

由于公司今年项目比较多,有硬件项目需要现场实施,老的软件项目需要维护,导致团队内部开发队伍不稳定,经常出现某个模块写完之后没人再配合,转而交给另外一个人再继续开发的情况。这个问题到现在维护阶段还存在。

前几天找老总,聊了聊关于这个项目,关于公司的发展,个中滋味吧!

项目算是告一段落,但开发的路还在继续,不管是经验还是教训都是满满的一笔财富。思维或许是最难以转变的东西,这也时刻告诉自己抱有好奇心,敢于尝试与冒险,更要不断地读书学习。

Tags: n2

嘟噜(Dulu) POP3协议 中文翻译

comments powered by Disqus