工作将要满四年，在编码上的提升已经有限，很多情况下都是在做重复性工作，在业务上也只是增加对领域的熟悉性，出现了发展瓶颈。
2015财年对我来说是工作的第五年，也应该是出现飞跃的一年，在上一年中，有机会参与了项目管理，现场问题支撑，大数据HBASE/HADOOP的开发部署，当然也做了很多编码工作，总得来说还是有进步的。
在项目管理方面：
此一次吃螃蟹，首先要感谢领导的信任能够给我这次机会，项目不大，属于集成两个产品版本的工作，主要是将产品1的后台替换产品2的后台，其中涉及到了HBASE/HADOOP/STORM的相关技术。
说说经验教训：
1）如果别人都不想接的活那你也别接，很有可能是个坑，但看中机会想要锻炼的除外
2）需求不管怎么分析都不会完全清晰，尤其是在没有人同客户沟通过的时候
3）小心改变别人的开发习惯，强推改进是个很有风险的活动
4）小心挑选团队成员，技术好的一般态度不会太好，态度好的技术一般不行，学会管理和激励他们
5）别又做管理又写代码，一心不能二用
6）识别风险是作为项目管理者最紧要的工作
7）从项目开始我们就要识别工作量，同时留出变更的余量，如果发生了重大变更，那就增加资源
8）把握好开发节奏，迭代开发不一定适用于所有情况，要因地制宜，因人制宜
9）重视内部测试，重视转测试的质量
10）人只做一件事情的效率要大于同时做两件的
11）进度压力下，没有严格把关
12）太自负，没有发挥出组员的能动性
13）寻求支持的太晚
剩下的说说客观原因：
1）项目进行过程中客户突然变化，带来大量的需求变更
这个项目伊始，是为ALU这个国家的项目定制的，需求也是为了满足该项目的需求；但项目执行到一半，突然告诉说，ALU不要这个版本了，但刚好PAK这个国家也要进行升级，刚好把做了一半的东西给他们吧，客户关系不错，可以交付的。没有任何前期的需求调研，突然进行转向，蕴含了极大的项目风险。销售人员只对签单负责，不对交付负责
2）工作量估计失误
项目开始时，仅简单估计了工作量，并已经提出了交付风险，但该项目由于金额小等原因，并未受到领导重视，后来项目项转向后，工作量增加，但资源并未增加
最后说说结果：
项目最后还是成功了，在交付以及支持人员的努力下，在一次次接近奔溃中，用交付兄弟的话来说就是“终于让客户把这祖宗给咽下去了。折腾人啊！”。
在技术方面：
说实话，在技术方面并没有多少实质上的进步，部门是市场导向，产品以及技术并未得到充分的重视，缺少技术交流的氛围，感觉是由熟练工变得更加熟练了。
但是也接触了一下大数据，也弄过了Hadoop+Hbase了，虽然浅显，总是多一点熟悉。另外，在数据库优化方面也有了一点感觉。
最感觉有缺憾的是没有在系统架构上得到磨练，2015财年需要有意识的多锻炼一下。
其他：
感觉说话变得更慢了，也许是脑子学会了跑在嘴前面，这也是一种进步吧。