2015年的总结

文字其实在过年以后，就写了，一直没发。

--------------------------------------------------------------------------------------------------------------------------------------------------------------

2015年，现在可以做一个总结了。

在年后，还是在准备做旧业务的迁移工作，做了10%后，4月份，胡、张、王，三人开始进入代驾的业务开发，刘一人留下继续支持旧业务。

由于我个人的意识仍然是局限在做项目的意识层面，严重的忽视了在互联网公司开发的质量意识、产品意识，仍旧使用原有的项目思维在带领团队。导致了团队的工作压力是最大的，并最终使得张，王两人离职。但是，从结果来看，他们的离职也使得我们的团队能够引入了更加新鲜的血液。从后面补充的6人来看，都能够和团队的成员一起成长，团队的凝聚力是所有的team里最强的。

但是，对我来说，我自己的思维意识仍然是一个巨大的问题。

总结来看，存在几个问题。

1. 对产品的需求管理没有做好，团队成员在巨大的开发压力下一直加班，并成为整个业务开发团队里，bug量最多的团队，当然也是代码量最多的团队。之前，我曾经以代码量最多而骄傲，不仅我们的team的代码量多，而且系统也多，6个大小系统。但是，现在我并不引以为傲了，我们欠下了太多的技术债务。前期疯狂的奔跑，后期必定要慢下来休息一下。

2016年，前期就是要巩固我们已有的功能，为我们的系统的提升做好准备。  

2. 个人的成长，没有到位。不管是技术成长，还是管理成长。自己真正的成长还是在看了很多的书以后才理解到，技术团队应该怎么样来配合产品做事情，但是在领悟到这点的时候，已经从技术管理的岗位退到了一个莫名其妙的位置（这个事情后面再说）。 在我们的业务开发最疯狂的时候，我一直在频繁的和服务端的管理人员在沟通，但是始终不能得到一个解决的方法。

这本身和我自己的性格也有关心，责任心、主动性都太强了。希望自己不让别人失望。但是，往往其他人并不会这样去想。以正常的节奏工作，更重要。

3. 过度依赖产品。

开发的环节包括了需求评审、设计、设计评审、开发、自测（集成测试）、部署等。但是有几个环节，我们自己做的不好，包括需求的评审，设计等。最初，自己的想法是，期望产品在大的方向没有问题的情况下，开发人员在开发的过程中，自己会发现其中的问题，进而优化这个产品。但是在需求管理中，往往是将这个过程提前。先判断这个需求是否需要做。个人会觉得这个是将开发和产品做了一个对立。但是，后来发现，很多的时候并不是这样想。比如：来了10个需求，开发说只能做5个，那么产品会重新考虑着10个需求，将最重要的5个拿出来做评估。 而我的思维里是，为什么产品不是一次直接将5个最重要的需求拿出呢？ 

个人的理解是我们的组织架构决定了这个现状。我们的架构是产品和技术分离，有的公司是，产品经理会带一个开发团队，这样的结构，产品自然会考虑优先做哪个。 而现在产品并不带开发，所以他们只管提需求，并不在乎开发能做多少个。这个也是我之前遇到的最大问题。

在需求的评审阶段，需要考虑这个需求的价值评估。在提测和测试的沟通太少。

4.  和测试同学的配合

之前一直关注在业务的开发上，对测试的支持不够。其主因也是在我没有能够和产品正确的撕逼。基本是全盘接受了产品的需求，并没有和产品撕逼哪些做，哪些不做。 也逼垮了了兄弟们。 同时对测试人员也有很大的影响。 在需求评审时没有叫测试，提测的质量太差。测试的抱怨很大。当时我的想法还是赶功能上线，开发可以做完，测试也一定能测完。 归根结底，还是视野太小。

以自己的创业心态在工作。这样当然是不对的。可惜，没人告诉你该怎么办。

2015年做的好的地方，做的好的地方，团队的凝聚力协作气氛很好。提测的流程准备的很好。有创新能力，构建的一个组件，能够很快的在系统里接入导入导出功能。

2016年个人需要改进的地方，

1. 对技术的敏感度，当我们在谈论系统设计的时候，需要怎么来设计系统？需要关注系统的哪些面？系统的容量，性能，存储，入口量，出口量。

2. 关注团队技术能力的提升，CI，UT，CodeReview，设计能力。尽管去年期望UT能够执行，但是最终由于工作量太多，导致UT没能够执行。今年这段时间，大家着力执行UT的时候，业务果然开始阻塞。不过这个是必然。必须是有所取舍的。

除了以上的编码方面的能力以外，对技术的学习和掌握，也需要作为技术人员的能力之一。当然，最好的方式是能够结合工作来做，其次，就是自己找主题学习了。

3. 头脑风暴的创新，对当前的工作，做一些创新的事情，需要基于我们对业务的理解。比如规则引擎，比如实时统计等等。