研发团队管理心得

自述

        2016年6月进入公司以来，经历了团队从无到有，从三个研发，发展到目前13个，团队分成后端、前端、android、IOS、运维。刚开始接手团队，简直一团乱麻，没有规范，没有技术储备，没有后备资源储备，连HR都没有，公司内部各种奇葩乱象都有。最大的感受就是公司战略在不停的改变，对应的团队建设也随之改变。我在公司负责技术部，我在管理上只能算是新手，我们的流程也不规范，问题也是多多。到目前为止还没写过详细设计，发版后代码备份总是有问题，开发时间总被压缩，外部事务所占大于内部工作时间，这也是个教训，下面我来总结一下经验。

团队配置

        每个技术都希望跟一帮牛人一起工作，然而一个全是牛人的团队，对大多数人来说都只是梦想，我从业这么多年想过无数次，却一次都没幸遇到。后来我放弃了，团队固然要牛人，但是牛人也不是满大街跑，对一个10多人的团队来说，有4、5个精英就够了，其他的用有点经验的、经验少的、甚至实习的都没关系，这样就能组成团队梯队。团队梯队很重要，核心功能必须要精英来完成，放手给没经验的也不安心啊。最重要的一点建设团队的时候要考虑好对团队有什么样的期望，产品不是一版就做完美的，初期只需要能推就行，所以有一两个骨干做核心，两三个做做普通业务，至于更低的可以当半个人用，做些边边角角工作。

团队培养

        团队培养不一定就是技术能力提升，个人技术能力固然重要，但是一帮牛人在一起，也不一定能做出牛逼的产品，一个团队最重要的是对所做产品的认识，只有认识到产品才不会做无用功。一个牛人对高并发有很深的认识，但是对产品意图却认识不到，让他来做项目绝对会失败，不是技术不行，是对产品认识不够，项目初期能上线才重要，就算明知有高并发问题，对项目初期又有什么影响呢，高并发和性能问题让负载均衡去解决吧。能确定产品方向，就可以确定技术方向，技术培养方向决定跟产品方向一致，而且进度大致差不多，不要好高骛远。团队培养是要公司支持的，首先要有人，其次要花时间，在其次要制定制度，有奖有罚，但是大多数公司只有罚没有奖，慢慢的培养就变成了形式，毫无价值。团队培养可以提高效率，但是不是马上见效，产品认识只能提高团队稳定，对效率提高真心不行，其他硬条件上不来，没几天这种认同感就下去了，这需要花太多的精力去画饼。

团队分工

        每个人都是独特的。一个产品技术面很广，每个人熟悉的可能都不一样，如何合理的分配是非常重要的，我们公司还好，因为所有人都是我面试的，我对每个人侧重点都有一些了解。有一种人非常适合中小团队，他们什么都懂点，什么都不太精或者只有一个点稍微熟一点，这样的人非常适合项目初期，有一半这样的人，至少项目初期几乎零风险了，在初期要尽快补充精英进来，中期解决性能问题必须要精英。产品理解快的可以负责更多的业务，给他们更多的资源，项目理解慢的只能慢慢淘汰，很现实很残酷。产品认识达到的情况下，在看技术水平，这样产品出来质量才高，BUG才能更少。

团队忧患

        管理团队一定要有忧患意识，在什么样的公司做管理最轻松？规章制度明确，福利待遇不低于平均水，对待员工宽容的公司比较好做，也是我想象中的公司。如果这些都没有，那么要注意了，尤其在决策改变，或精英离职的时候。他们可能造成人员流失，甚至连锁反应，对于中小团队或没有储备资源的团队来说是致命的。所以团建就很重要了，当然这需要公司支持，怎么选择仁者见仁了。

团队规范

先说说这里面我吃过的几个亏。
        第一次，因为代码一个地方管理，服务挂了，怎么也启动不了，重装都不起用，后来只能拿一个人的本地版本当最新版本，光技术内部就改了两天，然后各种回归测试。后来聪明了，GIT服务器上的代码有两个地方备份。
        第二次，因为发完线上版本后没有做代码备份，开发任务还在继续，然后线上各种临时改需求，都没办法马上修改，只能放到下个版本中修改。后来每次上线都备份代码，线上修改用备份代码，提交后继续备份，同时更新当前开发版本中的代码。

        第三次，BUG修改过程中，有几次因为开发人员都不熟（开发的人离职了或已经没法追究了），然后就开始踢皮球。这种问题，每个团队可能都有，在士气地下的时候，没人愿意改自己不熟的BUG，其实认真读读别人的代码都是可以解决的。后来制定规则，类似问题以奖励方式，全部解决了。（需要公司支持）