在即将结束的2015年中，我在公司经历了从2.14到3.0几个重大版本的迭代开发，看到公司的迅猛发展。与此同时也希望在公司平台发挥自己的最大能力，公司的成功带着个人更进一步。
提高工作效率，更快编码和更少的bug
关注组员喜欢的技术、产品、语言，多给组员在工作中学习有兴趣的新知识的机会。比如，鼓励组员去参加training或者上相关的课，或者多组织公司内部的主题技术讨论，互相交流。程序员这拨善于创造的生物，如果不是喜欢探索和实践新事物，那么也在这行干不长久。学到新技能都会跃跃欲试，自然生产力上会有所反射。
激发对产品的热情和主动性。如果能够在最大程度上采用buttom-up的模式，让组员参与到产品从出生到设计到成型的过程中，让他的想法能得到实现，就会产生巨大的动力去完成它。如果做不到buttom-up，那么至少”循循善诱”，引导组员思考出你想要的解决方式和功能，让组员感同身受，而不是直接给要求，这样组员更能够把产品看成自己的东西，从而更愿意去完善提高它。
提高对工作的掌控力和自豪感
错误要大家一同分担，功劳要明确出处。做好了一个feature要公开化的让团队知道谁是这个feature的负责人和主要工作者。一旦出问题了要表明团队的每个人都有职责监控和保证产品的质量，共同讨论解决方案。如此一来，多完成，完成的好的话会建立好的名声；发现问题及时提出，不用担心得罪人，还会得到鼓励和赞同。
给组员的时间安排留出空间去做技术提高。是个程序员都有自己写程序想要遵循的原则和风格，有些从engineering的角度上来说是对的事，在工作中往往会被忽略掉或者来不及做，因为从产品的角度出发，公司总希望用最小的成本做出最多实际的成果。这会使我们产生总是在赶活，没有办法按照自己的方式做好一个东西的感觉……给组员适量的空间和时间专门用来完成他们认为必要的技术尝试, 比如把code写的更标准更好用，增加一些debug的功能，完善模块化组件，优化代码结构……等等，能够完成这些工作不仅提高团队整体开发效率，奠定一个好基础，也会让大家有种“项目尽在掌控中”的自豪感。
减少外界干扰
尽量保证组员的工作不被打乱或者打断。开发团队为什么要有PM？不就是为了保护程序员的工作不被随机打扰嘛？当然能做到这样的团队并不多，因为确实很多问题只有程序员能回答，有些事情也确实很紧急，只有程序员能立刻解决。但是PM可以尽量减少这样的干扰。比如在组员遇到blocker时及时沟通处理解决路障；过滤掉优先级不高的临时要求，了解产品和项目的技术结构和每个功能的原理及做法、以便于节省组员的时间不用去做很多重复的讨论和解释。 程序员鲜少有喜欢天天去各种会议上和人吵架的，帮助组员腾出时间让他专心写程序，自然会有优质的code和产出。
在生活上增加程序员的便利。前面说的很多公司提供的各种福利和基础设施都是基于这个目的，当然也可以私下和组员搞好关系能帮忙时多帮忙，能交流时多交流，很多时候会换来一定程度的“友情回报”，至少不会因为理所当然的要求导致组员心理抵触而降低工作效率。
提高团队凝聚力和执行力
带领团队，基本上就是两种模式，李广模式和霍去病模式，两人都是汉武年间有名的大将
- 李广带兵，同吃同住，平时体恤下情，战时身先士卒，自己本身勇武过人，和士兵打成一片，有很强的感情纽带，这样的团队的凝聚力是最强的
- 霍去病带兵，自己是吃随军御厨专门服务的，平时鲜衣怒马，高高在上，拥有绝对权威，然奖罚分明，令行禁止，底下兵的待遇优厚（地位，饷银），容纳了不少能人异士，依靠律条管束，糅合，激励军队。这样的团队，执行力是最强的。
两种模式都是好模式，理论上也有融合的的可能。实际上其实是，对于团队来说，感情带来凝聚力，规则（规章）带来执行力，关键问题在于两者的平衡。那么问题其实很简单：有感情的团队，有凝聚力，有良好的，执行效果好的规则的队伍，有执行力，处理好两者的平衡，凝聚力和执行力可兼备
