在3月底的时候，第一次接触后向流量经营平台，一个新项目，当时有点紧张和欣喜，欣喜的是我可以负责一个项目，这是一个新的锻炼机会，紧张的是我不知道怎么去做好一个项目，这对我来说是一个全新的挑战。
1.需求接触
当时域经理，就发了一个原型图给我看，我看了一下，什么后向流量、移动网络加速，一点概念也没有，当时就懵了，紧接着域经理和部门经理去开会，就这个项目讲了一大堆，当时是对着业务流程图讲的，会议结束的时候讲到了CRM与能力开放（CSB），计费，当时的后向流量系统之间的关系，由于我对CRM域的业务不熟悉，所以也只听懂了是做流量代理这个平台。写这些文字的时候，差不多两个月了，这时候已经完全理清了系统之间的交互。，
第二次我记得是参加了一个需求分析会，其实需求专门有人做的，我们开发承接方，我的任务就是将需求搞懂，将需求转化为代码，表结构，进行任务分配。记得当时也听了云里雾里的，尤其是涉及到其他平台，就更加听不懂了，好在测试给我发了文档，否则我就更加听不懂了，这时候开始有很多疑问了，比如流量的计费，其实有疑问是好事情，证明自己对别人的需求设计开始有了自己的想法，当时下午就整理了好多疑问，一点一点的讨教老大。老大很耐心，又给我说了一遍整个流程，我的理解又加深了一步。紧接着是清明的前一天，是我对需求的消化阶段，由于我要负责整个项目的表结构设计，兼顾需求和开发，所以我要比任何人都要了解需求，避免二次开发，我又问了一次老大，后来就清明回去按照自己的理解去想表结构了,这是我第一次挑战整个项目的表结构设计。
2.开发准备
说到开发准备，我一个人肯定是完不成的，毕竟工作经验也只有一年多，技术架构又不是特别了解，老大说采用分布式架构，这是我第一次了解dubbo和zookeper,后台的业务层都发布到zookper注册中心去了，dubbo是对zookper的一个管理，就像Apache对tomcat管理一样，就像卡车上装着很多桶水一样的道理，redis缓存框架也不是特别了解，因为涉及实时入库，不断更改次数的操作，担心锁表，所以用到了redis,当时有个技术人员负责搭建框架，一个人负责测试环境的准备，我依旧负责表机构设计，和每个人分工，并写了一份开发文档，具体到每个人做的功能，涉及的表，因为开发者不需要了解需求，我只能需求转化为概要设计说明书。
3.项目开发
说到项目开发，我自己也参与了项目的开发，不过我是纯后台的，不涉及到页面的展示，但是如果真正做一名项目经理，亲身经历告诉自己，不要参与开发，项目经理的任务就是将表结构设计好，概要设计写好，在项目开发的过程中，帮助他们弄懂需求，当涉及到与其他系统接口交互比较多的时候，协调能力是解决项目的关键，说实话，白天沟通，晚上写代码这种情况就是我的写照了，不是因为太累，而是因为人的精力是有限的，到了晚上写出来的代码出错的几率很大，但由于项目成本的原因的，一个人身兼多职也是很正常的。项目开发一个月就结束了，这时候才真正体会磨刀不误砍柴功，需求很重要，设计很重要。
4.测试上线
测试上线阶段其实特别关键，对于测试人员这个阶段比较痛苦，尤其是bug很多的时候，但对于开发人员相对前期有个缓冲期，测试的时候不仅仅要考虑功能，考虑浏览器
，考虑用户的体验，但很多开发人员是根本不会考虑的，如果开发人员能考虑到这一点就完美了
5.风险
很多时候任务由于种种原因没有按照规定的期限完成，服务器没有下来，与其他系统交互的时候，其他系统未按时上线，影响了本系统
6.系统交互
一般情况下接口调用能力开放平台，调用计费，然后计费将渠道号和客户标识同步给CRM