我们到底遇到了什么困难

最近手头的工作不是特别忙，临近年关了正好也做做总结。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，花费大概半个月的时间。

• 为什么总是提需求？

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

• 团队人员管理。

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

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

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