一位Team Leader一年的工作年终回顾
本文源自小乐同学投稿，针对一年工作做个回顾，由一个程序员变成项目负责人，之间的转变值得体味，是不是有种似曾相识的感觉？
时光荏苒，光阴似箭，不知不觉在技术部渡过了一年的时光。俗话说，总结过去，展望未来，有总结才有进步。回顾2017工作中的点点滴滴，有快乐的时光，有苦逼的加班，也有无助的迷茫，当然也少不了收获。不管怎样，我始终信奉：有付出才有回报。
工作清单
1月至3月，主要是参与A项目的后台开发，涉及资料模块，组织架构模块，报表模块及人脸识别接口验证的开发。
4月至5月，工作调整到A项目风控模块的独立，参与zookeeper+dubbo的部署及调试，抽离模块代码独立部署应用，系统交互通过dubbo调用。
6月至今，负责参与B项目后台、APP、微信等渠道的开发。
项目总结
5月有幸成为B项目的项目负责人和团队一起带领项目往前跑。实话说，我是第一次严格意义上的带项目，内心比较忐忑，当然也很期待。任何事都有第一次，想着既然把活接了，就认真的干。
接下来主要说说B项目项目的大致情况，主要以项目的进度描述各个阶段的状况及对这方面的总结与反思。
第一阶段：第一版本开发
app是原生与H5混合开发模式。第一版需求大家干劲十足加班加点终于6月底如期上线。但上线后app因混合模式问题比较多，所有没有对外发布，只是内部测试使用。紧接着开发第二个版本，开发过程中，公司负责人体验产品，发现产品载体为app不是开始商量的轻应用（微信公众号），所以第二次迭代就是赶微信公众号开发，7月底一起发布。因时间关系，产品设计微信公众号的原型和app相似度非常高，导致微信端像个app一个，也一定程度上导致公众号没有利用微信先天的一些优势。可以说这是先天不足吧。而造成这一情况的原因很简单，沟通不透彻。
关于沟通不到位的问题，在后续开发中团队一直存在这个问题。都说中国政府的会议多，但有时候我觉得有效的会议是很必要的。又是一轮加班加点，7月底微信公号和app优化版按计划上线了。产品功能虽然不完善，体验也不流畅，但勉强也能用。这一阶段的总结是任务比较赶，团队也处于混沌状态，但大家有干劲。
第一阶段除了任务的分解和分配后，我对对项目阶段性进度的掌控，对产品需求改动的过滤，对团队人员工作饱和情况的认识都是不足的。可以说我对团队管理为零，一是自身角色还没适应，二是时间因素。这一阶段白天基本是开会讨论已知需求的合理，然后晚上就敲自己任务的代码，导致没有时间和精力去关心其他人。
这一阶段任务赶，除规定上线时间外，更多的是开发阶段需求的变化导致反复返工。需求的反复变化而且通知渠道不唯一导致各个端对应开发人员对同一需求是不同步的。问题也很突出，原型，UI，接口数据，前端页面，测试用例各自为政，到最后不知道哪个是最终确定的。各个端不同步的问题虽然后续逐步有改进，但目前而言依然无法根除。最开始想着需求定了开发过程中就不让改了，但实际上是不现实的。后面总结会的时候提出，有变动产品通知相关人员，虽然有时候口头传达会扯皮，但情况有好转。
第二阶段：高频次迭代开发阶段
因前两个版本把大部分功能实现了，后面的迭代功能不多，时间也充裕些。而且针对第一阶段的问题也开了总结会，大家都知道问题的存在，也提出了解决方案。本想着紧接着新迭代的开发应该会比较顺利，可实际结果总是让人意外。前面端任务的延期导致上线时间延期，虽然后续的任务端尽量加快项目流程。不同步问题仍然严重。
线上反馈的体验不流畅，主要是app是原生和H5混合开发，而且产品设计交互的时候是以原生app的角度设计的，有些交互性能极差。公司混合开发属于首次大规模应用，技术储备和技术解决方案不足。iso，Android与H5一直在磨合，后面h5优化与Android混合效果流畅，但与ios的兼容目前一直存在性能问题。上线后，用户量少，运维推广不利，app和微信体验差，综合一系列原因，大家也没开始的热情。项目问题解决方案很好，但实际执行起来就大打折扣。团队成员执行力不够，没有引导培养出很强团队凝聚力。
关于如何增强团队执行力，和团队凝聚力，我一直在思考并尝试。我认为作为一个项目团队，大家的目标应该是同一个方向的，这样大家的合力才有最大发挥。团队执行力能确保上层决策得到贯彻的执行，同时也体现团队的活力。
我也一直在想，作为项目负责人，我在团队中的作用在哪，我该如何定位自己，哪些事情我要考虑，哪些事情需要放手。但有一点是很明确的，保证项目顺利并尽可能完美的走下去。这样的思考有时让我困惑，我知道这些困惑会一直存在，这也是我需要加强学习并实践的地方。
