10月28号，我们开了1.6项目的总结大会，包括Ting总在内，前端、后台、运维都来参加总结大会了。虽然目标基本达成，但同时也暴露出很多问题，我们希望各方能够坐下来总结一下自己或者各个相关团队的功过是非，以便能在未来做出更好的产品。1.6这个版本对于我们来说，是一个非常规的版本。在这个版本中，前端代码全部重构为MVP模式，后台也一样重构，除了资讯财务模块依然保留TCP以外，其他所有的网络接口，全部更改为http。名义上称之为重构，而实际上可以算是重做了。除了在技术上有非常大的更改外，这个版本的时间周期相对与要达成的目标来说确实太短了些，只有三个月。在三个月内，要完成前端包括Native和H5统一开户页，后台包括证劵交易系统的对接、交易行情服务的开发、全产品线统一用户中心的开发以及接入层的设计，对于任何一个团队来说，压力都是非常巨大。
很多同事会有疑惑，为什么要这么赶呢？因为我们要做的不是传统的经纪业务，我们所面对的金融市场领域变化太快了，而能我们起飞的风口确又如此的稀少，所以只要感知出一个起飞点，我们都竭尽全力去跟上它。而经纪业务线就是我们的打头兵。很多同学可能觉得我们可以先慢慢做好，然后再上线。但是现在的环境下，不能这么做。因为对于一个市场行情来说，它来了，你在不在那比什么都重要。只要大体功能运行良好，有点缺陷，不够完美都可以接受。因为我们并不是就只发这一版，版本总是会迭代开发的，慢慢变好的。如果闷声开发出来个大家都认为好的，但是市场机会已经不在了，那我们可能连存在的意义都没有了，毕竟我们的竞争对手也并不是停滞不前的。
在目标已确定，deadline已写死的情况下，连续三个月996模式，而通常都不止996……在这种人人高压的情况下，我们顶住了压力，虽然不是很完美的完成任务，但至少也算完成了。这期间有值得称赞的地方，也有很多值得改进的地方。所以，我想从“比较好的”和“不足的”两个大方面去总结一下这次项目的整体情况。
首先，我想先来总结一下，我们这次值得称赞的地方。
1、测试团队很给力。刚开始的时候，开发还是很排斥这种提完Bug穷追不舍的情况，但是越到后面越体现出测试不用心和负责任。因为后面问题越来越多，体测版本也是越来越多，开发同时又在关注着新功能的开发。所以，Bug的管理几乎全部交给测试。
2、前端APP团队现在的代码结构已经比以前好很多了，不仅仅是代码逻辑上的清晰，包括整体架构也有比较好的分层解耦了，不会像以前一样牵一发的动全身的情况了，能更好的对不同业务需求进行支撑和拓展。
3、 前期由于项目人员的变动，导致我们整个项目有一个月基本属于项目管理空白区，然后就造成了人人都是项目经理，都各自去推动相关模块的进度，已完成既定的目标，中途难免出现一些摩擦。但大家能抱着一颗把这件事做好的心态去处理某些资源的匮缺，这点是非常好的。
4、虽然有一段时间项目管理有所欠缺，但是后期我们严格按照Jira流程进行开发和问题Tracing，同时还打通了代码仓库和Jira单的连击，实现了Jira单号和相应的代码修改都对接上了，并且形成了任何事情都要录入jira的好习惯，任何事情都有记录可追踪。这对于各个部门的工作都有着非常大的促进作用。
但是这次也有比较多的不足点，非常值得大家深思的。
1、我们团队的默契度非常的欠缺，这带来了很高的沟通成本。由于我们是香港、北京和深圳三地办公。经常会出现一些比如接口联调时出现问题，大家都非常急躁；有或者大家一有问题就直接找对应的开发人员，各个都说自己的优先级最高，开发自己又有自己的任务要做，不仅容易造成多方效率低下，而且也极易引发情绪上的冲突，从而带来更高的沟通成本。比如，有同事就不理解我们1.6跟1.5好像没什么差别啊，为什么你们还用三个月去做这件事情？这其实也是开发的痛点，怎么样像非开发人员解释自己的工作内容。这个版本对于用户来说，自然是没有多大改变，但是对于我们整个系统来说，那确是一个巨大的更新。这就像建一栋大楼一样，你希望没有地基直接往上建，直到它出问题的时候再推到重来，还是我们打好地基，然后可以扎实地去开发我们高楼大厦？整体来说，1.6其实是一个打地基的版本，就是为了我们以后能够更好地进行业务拓展。我们的产品不是就单单用户手里的APP，我们的后台、运维还是各种技术文档等所有这些背后的支撑都是我们的产品，没一个的更新，都是我们产品的更新。
所以，有时候真的是隔行如隔山，如果大家对合作部门的工作没有一个大致了解，其实很容易在合作的过程中，引起一些不必要的矛盾和冲突。进行一定的部门间活动或者交叉培训还是挺有必要的，哪怕大家相互认识认识也会好些。同时也希望大家能够抱有一颗同理心，多换位思考思考，并且抱着一颗把事情做好的态度去看待整个问题。
2、我们需求的变更时机不是很合理。这个版本的需求很多都没有形成文档沉淀下来，即便有也是如同战略方针一般，并不是很细致。导致最后在开发的过程中，经常是后台或者产品经理一句话，大家可能又要修改一下。如果在前期其实影响并不是那么大，但是这个版本的需求变更有很多经常是在开发后期更改，这个不仅对于开发来说是非常影响工作效率的，同时对于测试团队来说，也是非常不利的。不明确的需求和开发，测试完全无法进行质量的把关和问题的发现。另外在三地办公已经确定的工作场景下，我们也要形成一套我们自己的工作流程机制，来完善对工作的分配和部门之间的沟通。所以，严格按照Jira单来进行工作，尽量避免私下随意沟通进行代码的更改等而导致最后无迹可寻，这个理念非常需要大家认真地落实和执行。
3、计划目标与实施目标不够一致。起初，我们定义的1.6是重构，完成技术架构的优化，产品形态上，做到用户无感知。但是在真正开发的过程中，我们其实做了很多新的需求，比如开户页面与其他业务线进行统一设计，用户中心状态因为新的开户需求而有所变更等等，而这些需求的变更又影响到三大TAB页的开发，再加上需求的不稳定，整体上来说就给我们的进度增加了很大的阻力。所以，也希望后期我们能不忘初心，已经确定的目标就不要轻易去变更，如果变更应该是各部门一起开会讨论怎么去施行，而不是像现在的样子，产品几乎要跟后台，前端分别同步需求。
希望下一次我们的版本开发逐步规范化，流程化，更好地完成我们产品开发。