研发团队管理心得

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

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

团队培养
        团队培养不一定就是技术能力提升，个人技术能力固然重要，但是一帮牛人在一起，也不一定能做出牛逼的产品，一个团队最重要的是对所做产品的认识，只有认识到产品才不会做无用功，技术培养方向决定跟产品方向一致，而且进度大致差不多，不要好高骛远。

对一个初创团队来说，项目能上线才重要，就算明知有并发和性能问题，只要不影响主业务就可以果断上线，至于问题后期资源多了慢慢优化，公司发展不顺，项目问题解决在好也是白搭。

团队培养是要公司支持的，公司管理制度对团队影响巨大，糟糕的管理制度诞生不出好的团队。团队不是一天就组成的，经历无数次磨合才会形成真正的团队。

团队培养首先要花时间，在其次要制定制度，有奖有罚，但是大多数公司只有罚没有奖，慢慢的培养就变成了形式，毫无价值。团队培养可以提高效率，但是不是马上见效，产品认识只能提高团队稳定，对效率提高真心不行，其他硬条件上不来，没几天这种认同感就下去了，这需要花太多的精力去画饼。

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

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

团队规范
明确的规范可以让团队减少很多没有必要沟通，基层开会研究规范的一定是管理者的失职。团队规范一定要符合公司发展，符合团队整体水平。初创团队，工期砍掉一大半，还要要求系统上线后，可用性达到5个9，这明显是不可能的，这是跟自己过不去。

制定规范是可以根据不同的时期制定不同的标准，一定要记住不要限制过程，我们制定规范只是需要结果，对于过程不清楚或者有问题的，可以给出参考建议就行，管理过程是一项浩大且不讨好的工程，互联网是一个自由的行业，每个人都希望有自己的空间，相对的给一些空间同时要求更好的结果，大部分人还是愿意的，但是反过来一定会怨声载道士气低落。

有几个非常重要的结点一定要把握好

1、制定可用性标准，明确最佳上线时间，先要质量及周期自己心里有数

2、产品需求确定时间

3、开发周期确定时间

4、UI、架构设计周期及整体思路

5、迭代计划

6、联调时间

7、提测时间

8、上线时间

产品确定并评审后如非必要一定不要改动，否则后面计划全部要变动。很多小公司都是老板是产品经理，产品说改就改，针对这种情况，也是有办法的，这是控制迭代周期非常重要了，迭代周期越短越灵活，但是前面提到过，我们是已结果为向导的，中间过程难免会出现个人空档，迭代周期短，就会出现频繁空档，虽然每次少但是拉长以后就会发现浪费了很多时间。

开发周期可以下方给团队内部评估，越细致评估越有效，风险越低，一定要给高风险模块预留充分的缓冲时间。一般高风险都出在三方对接上。

设计时间一定不能省，无论你有多牛逼的架构师、UI设计师总有失误的时候。一旦这个阶段有问题，那么影响的就是整个项目。所以无论付出多大代价一定要把这的风险降到最低。

后续几个过程都属于开发过程，对于开发出生管理者基本不会出问题。只要做到结果至上就行，过程中没什么是不能容忍的。
————————————————
版权声明：本文为CSDN博主「源码猎人」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/nan8426/java/article/details/72932108