你好，我是陈晨，现在在Reddit担任Senior Director of Engineering。刚加入的时候，Reddit只有30多人，如今已经扩张到近300人的规模了。在Reddit，我经历了一家公司从小到大的成长过程，也经历了团队大了之后重组的过程，所以今天想跟大家分享一些关于团队重组的话题。
团队重组基本上是每一个发展壮大的团队都无法避免的选择。团队大了之后会遇到很多问题，比如流程混乱、产品规划不明确、团队之间内耗严重等，而一个比较好的解决方案就是团队重组。
我刚到Reddit的时候，因为整个公司也就三四十号人，规模比较小，所以当时的技术团队是按照技术领域水平分割的，做Web的一个组、做iOS的一个组、做安卓的一个组等，这也是创业公司比较常见的团队划分方法。
这样的划分会存在一些问题，首先，当产品出问题的时候，你很难去找到一个负责人，负责把这个问题解决掉。其次，产品经理会很郁闷，他至少要跟三个团队打交道，一个简单事情的推进都要开一堆会。最后，多个项目同时进行的时候，工程主管也会变成流程的瓶颈，他需要在无数的项目之间切换，同时要协调好工程师之间的资源，这是一件很深奥的事情。
除了这些流程上的问题，更严重的问题是团队之间的信任关系会被破坏。一个好的管理者必须要把团队之间的依赖关系弱化，否则团队一旦过载，一个团队进度就会依赖于另一个团队的进度，比如说后台API开发延期，前端工程师的进度就会受到影响，继而产品进度就会受到影响。
而产品进度一旦出现问题，没法按时交付，整个技术团队就会受到高层的问责。面对这种情况，技术团队之间就极有可能互相推诿，把责任推给对方，久而久之，团队之间的摩擦变多，信任关系也就越来越差，而这对于公司的文化是致命的。
为了解决这些问题，我们的做法是将团队进行重组，按照业务方向做了垂直分割，如视频、搜索、社交、增长等，每个业务都有自己的团队，从设计、产品到开发人员，各个角色都有，组成一个极其完整的团队。
如图中所示，在整个技术组织架构中，中间是各个业务线团队，上面是一个共享的团队，负责整个公司的产品发布，下面是中间层和基础层的东西，这些东西没办法分开，我们就划分出专门的团队来负责他们，包括API Services、Native Core、Web Core等。
这样重组团队的好处是，首先，项目需求决定人员需求，减少人员浪费；其次，彼此分工明确，团队间的交流损耗降低；最后，能消除团队之间的差距，加强凝聚力。但要做好团队重组也并非易事，会面临两个主要的难题，分别是人心和时机。
1.人心
人是管理中最困难的环节，不管怎么管，总会出现一些让你措手不及的事情。我还在Instagram的时候，也遇到过类似的难题。当时Instagram到了400人的规模，也需要进行团队重组，只是在执行过程中没有很好的考虑到团队成员的心理因素，直接造成的后果就是，每两个星期就有一个iOS工程师辞职。到最后，当年跟我一起打下iOS江山的那些老员工，在半年时间里全都走光了。
很大程度上是因为他们感到不开心了。举个例子，他之前为Instagram APP付出极大心血，也全情投入，结果团队重组之后，被分到广告组去做广告了，这并不是他感兴趣的领域，而接手他工作的新人，在他看来又没有好好珍惜他之前写的代码，导致代码质量直线下降，可想而知他心里是个什么感受，必然不会好。
工程师做产品的时候，他们追求完美的性格会让他们为了一个产品而呕心沥血，也会对自己所做的东西感到自豪。而当你重组团队，把他做的事情交给别人，又让他去负责并不感兴趣的工作，他一定是感到不开心的。这时，如果管理层不跟他好好沟通，必然会导致他们失望直至最后选择离开。
所以，团队重组的时候，一定要考虑到人心，多多跟团队成员做深度沟通，在可能的情况下，尽量照顾到他们的需求。
2.时机
团队重组这件事是迟早要做的，只是早做和晚做、早痛和晚痛的区别。晚做会会影响员工的快乐程度，造成团队成员流失，就像上面提的Instagram的例子，它到团队400人规模的时候再做团队重组其实已经有点晚了。
而早做的问题在于会降低效率。团队早期的时候，很多代码是共享的，工程师之间的协同是很重要的。这时，你把他们拆分到不同的业务小组里，那么他们之间协同的成本就会直线上升。这么做可能降低了产品团队之间的内耗，但却增加了工程师之间的沟通成本，降低了效率。
因此，对于领导者来说，要找到一个恰当的团队重组的时间点，过早或过晚都不好。我的经验是，在工程师团队达到200人规模左右的时候开始分割重组是比较合适的，千万不要等到400人规模，这算是我的血泪教训了。
这里大家常常会面临的一个问题是，比如原来iOS团队就是iOS团队，大家聚在一起，遇到问题可以一起讨论，也可以一起研究新技术，但重组之后，他们被分散到不同的业务团队里面，少了原来共同成长的氛围，比较孤单，可能话语权也会变弱，心里就会有些抵抗。
这时，短期的解决方法是依靠文化，比如我的做法是，每周组织一次亲友会，把原来iOS团队的同学都叫回来，大家聚在一起交流，分享最近做了些什么、遇到什么难题，大家可以出谋划策，另外，还可以组织一些技术分享，一起学习进步。总之，要让大家感到，虽然团队散了，但心没有散，大家还是一家人，而这就需要你作为leader多花费一些心思和精力了。
长期的解决方法是用老人带新人，给每个拆分后的业务团队都配备一个至5年工作经验以上的人，把他培养好之后再让他去培养、带领下面的成员，这样每个团队会有一个领头羊，团队其他成员的成长也会有方向。所以，垂直分割对于人员的要求非常高，这也要求你跟公司在招人环节协调好，找到合适的人才加入。
最后想跟大家分享一下技术转型过程中的注意点。团队扩大到一定规模之后，很多技术大牛都会或主动或被动的选择转型做管理，而在这个过程中，他们往往会面临3个难题：
那么该怎么提高管理效率呢？以我培养Engineering Manager的经验来看：首先，要熟练使用工具，利用大量的工具，尽量把流程自动化，用工具管人而不是用人管人，这样管理压力会小很多。
其次，要分清主次，把重要的事情先解决掉，而那些不那么重要的事情就可以往后排。然后，让团队每人明确自己的职责和所有权，如果有人不清楚，你作为管理者就有责任跟他们讲清楚，一遍不行就讲十遍。
最后，让工程师驱使部分管理任务，激发他们的主观能动性，不要把很多事情都揽在自己身上亲力亲为，要学会放权。这样，也能更好的培养他们的能力。
对很多团队leader，尤其是新手leader来说，准确预估项目开发时间是一件非常困难的事情，因为项目执行过程中的各种可变因素太多了。
跟大家分享一个30%法则，即一个新项目启动的时候，你可以先让团队中有经验的老员工预估需要多长时间，然后将他预估的时间除以30%，也就是0.3，得到的时长就是项目完成开发大概需要的时间。比如他预估需要4个星期，除以0.3后大概是13个星期，也就是这个项目我大概需要一个季度的时间才能做完。在我的实践中，这个方法预估出的时间是非常准的。
一般新手管理者的系数都在30%左右，真正有经验的管理者能达到70%，但我至今还没有遇到过超过70%的人，究其原因可能在于项目开发中的不确定性太多了。如果感兴趣，不妨尝试一下。
结语： 团队重组基本上是每一个发展壮大的团队都无法避免的选择，将团队从原本的按技术方向水平划分，重组为按业务方向垂直划分是一个不错的选择。另外，在重组的时候，一定要注意把握好人心和时机，否则极有可能会事倍功半。
陈晨，Reddit Senior Director of Engineering。Instagram 最早的华人工程师，经历了 Instagram 从5000万注册用户规模到4亿月活用户的巨大转变。2015年年底加入 Reddit，用90天时间从0到1推出了 Reddit 官方移动应用，建立了移动团队，重构了公司的技术和业务平台。
（本文整理自陈晨在ArchSummit全球架构师峰会上的分享，有删减。）