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