关于技术团队的相关话题，大家也都是在摸索中总结出怎样做是好的、怎样又是不可行的；但是可以确定的是：团队这个基础设施的建设是不容忽视的。

业务速览

蘑菇街是一个专注于为时尚女性消费者服务的电子商务网站，从一开始的导购平台，到后来转变成为导购加女性垂直电商平台，一路走来，受到万千年轻女性的青睐。蘑菇街也随着社会潮流的不断发展而在相应地提升它给用户带来的服务体验，目前它的业务有几个特点，包括内容驱动的“新时尚全媒体”、解决女性用户搭配痛点、潮流好货、品质升级、创新“网红 + 直播 + 电商”模式、抢占“短视频 + 电商”新风口。

技术团队发展历程

在业务不断发展的同时，蘑菇街的各个团队也在稳步发展着，其中，关于技术团队的发展，我认为，从最初成立到现在，技术团队经历了两个大的阶段。

 第一个阶段

这个阶段从研发团队成立到 14 年年底，网站主要基于 PHP 技术构建，这时主要的目标是能快速支撑业务的变化与发展，每个研发同学的分工不是特别细，大家都一起维护着一个比较大的主站应用。

团队也没有设置专职的测试岗位，新功能上线前主要靠开发自身以及和运营、产品一起来测试。一切都是为了能够更加快速。这个阶段，沟通协作是最高效的阶段，招人方面也相对难，也需要团队的成员能尽量具备多重技能，一些方案没有办法做得特别深入，更多还是以解决现有问题为主。

 第二个阶段

公司也在 13 年年底，14 年年初从导购平台升级为导购加电商的平台，并且开始做支付相关的功能，业务变得更加复杂。

随着业务的发展，人员也相对之前有了增加。这么多人在一起维护比较集中的系统，效率变低了。而且让一个同学去全面了解整体业务也变得很难。

对接业务的团队垂直化、支撑的团队平台化是这个阶段的一个变化。应用数量也开始在这个阶段变多起来。每块业务有持续、明确的团队对应，负责具体业务线的开发工作，而底层有通用的业务和技术平台来提供支撑，避免了很多重复建设。

并且这个阶段考虑到业务自身的复杂性，建立了专职的测试团队来保障质量。后端系统开始从集中式应用走向分布式应用，这个变化主要是为了实现前面提到的业务团队的垂直化和支撑团队的平台化，这个时候系统已经不再是集中的一个应用了，变成了一个分布式系统后，我们就需要解决诸如应用间的同步、异步通信等问题。底层的数据库也遇到单个业务需要多个库的情况，整体就进入了分布式系统的时代。技术栈也从 PHP 迁移到了 Java。

在前面提到的工作之外，近期从整个研发部的层面看，会有一个重点：

 提升资源使用效率

当我们的线上机器数不多的时候，投入人力来研究如何提升效率的收益会比较有限，而随着业务规模的扩大，我们线上机器的数量也持续增加，在这个阶段，必须要重视线上机器的使用效率了。

对于我们来讲，提升机器效率有两条路，一个是目前每个大厂必然选择的道路，就是做混合的部署，把对资源的需求不同 (比如有的应用是需要大内存，另外的是需要很多 CPU)，或者对同样资源需求的时间点不同 (都是 CPU 密集的，但是有些应用白天特别消耗 CPU，有些是晚上比较消耗 CPU) 的应用做混合部署，目的是让全天机器的各个资源都不会明显闲置。

另一个方式是弹性，对于在线系统来说，每个应用在一天内的压力是波动的，那么理论上在高峰的时候需要更多的机器，在低峰的时候就需要较少的机器，那么如果我们的系统可以比较灵活地做到弹性 (事实上对无状态的是比较好做的)，那么是可以提升资源的使用效率的。

这里有个问题，比较低峰的时候需要的机器少，那高峰的时段多使用的机器怎么办？这个需要的就是私有云和公有云的结合。对于大厂，这一条路就没有办法选择了，他们更多的是采用第一条路，我们目前主要投入在第二个方向。

如何快速融入团队

 不同团队间的融合

说到如何快速融入一个团队，我这里举个例子。16 年在美丽说和蘑菇街融合之后，我带领技术团队对蘑菇街、美丽说的底层架构及后台系统进行了整合。融合后，整个技术团队是一个垂直加水平的结构，垂直指的是有技术团队对应具体的业务线，比如美丽说的业务是一个独立的应用开发团队负责，也只负责支持美丽说业务的发展。而蘑菇街也是一个独立的团队负责蘑菇街的业务的相关开发工作。

在蘑菇街的业务开发团队内部，对于电商、导购又会有团队上的分工，会分成独立的团队来对应，而不论美丽说还是蘑菇街的业务，或者蘑菇街的细分的不同业务，都会有需要共同解决的业务的需求和技术上的需求，比如大家都需要用到用户的注册、登录、管理等功能，比如都需要用到交易、支付、促销等支撑，这些就不需要每个业务线的开发同学各自做一遍，而是会形成通用的业务平台层来解决。负责这些不同业务平台层的团队就是水平的。

在偏技术方面，怎么解决分布式的问题，解决存储、缓存的问题，包括虚拟化、大数据平台的问题，对于不同的业务线也都是通用的，那么也会由专职的团队负责，对上层的应用开发团队提供服务。

在整体技术架构确定后，就会遇到有同学的职责会发生变化，以及可能的团队融合的问题，对于做应用开发的同学来说，因为都还是负责原来各自的业务开发，融合更多的是技术体系的融合，会需要学习底层平台的工作。

而之前负责偏通用的业务平台或者技术平台的同学，会存在着技术和团队上的融合，这个过程，最重要的是能把我们希望融合后的技术架构说清楚，以及融合后的分工说清楚。

 新人融入团队

前面提到的融合是很少的，更多的融入团队是一个新人（不论应届毕业还是之前有过工作经验）加入一个公司。我自己之前也经历过多次加入一个新团队，最近的一次就是我自己加入蘑菇街。我觉得对于新人来说最重要的是一种开放的心态。

每个人都会有自己的积累和习惯，但是不论你曾经有多少经验和积累，在融入团队的时候，需要开放和主动。每个人都有自己的经验和经历，也都有比别人有优势的地方，但是到了一个新的环境，我们应该先把自己过去的经验和经历放一放，更多地去了解现在的环境和团队，看看现在的环境有什么急需要解决的问题，现在的团队有些什么样的积累和缺失，然后看看自己如何能够给到帮助。

对于一些和自己之前经验不同的做法，应该是空杯心态去了解下原因，千万不要觉得和自己之前不同的做法就是有问题的，不能有这个预设。同时这个过程中需要更主动一些，最好也通过一步步地解决问题来建立相互的信任。

真诚与尊重是管理的要点

关于领导如何去对技术团队进行管理，我觉得最重要的是 真诚 和 尊重。

我个人虽然带的团队的人数也算不少，但是我并没有去系统地学习过管理。从我的角度，我认为带团队不是去管，而是去帮助，应该是在思考如何带着团队拿结果的过程中帮助团队成长，帮助团队中的成员成长。

而对每个成员，需要的是真诚和尊重。最初开始带很小规模的团队，更多的考虑是如何把事情做好，真正放在成员上的心思和时间比较少，放在团队成长发展上的时间也少，而现在则花在成员和团队成长上的时间会更多。

相对于之前，目前更多的是希望能通过一些机制来保障团队和成员的发展与成长。比如在我目前的几百人的团队中，有直接向我汇报的，有不直接向我汇报的 Leader，然后更多的是一线员工。那么对于直接向我汇报的同学，更多的是平时及时地沟通，包括周会以及周会之外的一对一的沟通。这些沟通是以解决问题为主的，包括他们自己团队的问题以及具体在事情层面上的问题。

对于不直接向我汇报的 Leader，主要解决的是 Leader 成长以及 Leader 之间熟悉度的问题。Leader 的成长，一方面由他直接的 Leader 回去关注和培养，另外从研发部层面会有 TLD 这样的一个 Tech Leader 发展计划来承载，在 TLD 中会有培训的形式，也有沙龙的形式，内容更多围绕的是偏管理方面的话题。

另外一方面会通过整个研发部的 Leader 一起团建的方式去拉近大家的距离。而到一线员工，给到更多的是内部的培训和分享的机会，尤其是分享会更多些，大家可以根据自己的兴趣去参加。并且在今年开始开放了下午茶，给平时不太因为工作能跟我有交集的同事一个和我 1 对 1 沟通的机会。尽量可以沉淀一些机制，而不是去非常依赖我或者某个 Leader 自身。也就是说希望能造钟而不是仅仅报时。

选拔成员

上边说到的是团队内成员如何去管理、如何去融合，关于技术团队，还有一个重要的点也不能忽视，那就是招人。如何招人，招什么样的人，这是个很多公司领导需要好好考虑，并且也很难决断的问题。

 怎么组建团队

先从广的角度来说一下团队组建需要什么样的人。对于这个问题，我的看法是从我们要解决的问题出发，找合适的人。我们组建团队，成员要么来自于已经工作了有经验的人，要么来自于即将走出校园的应届生。对于新组建的团队，一般来说肯定需要先从市场上找有经验人的来先作为团队的种子。而对于我们这些已经过了初期组建阶段的团队，我更倾向于主要靠应届生来补充我们的队伍。

更倾向于应届生的原因是，每年都会有应届生要找工作，这本身就是一个比较合适的时间点，而对于社招，很多时候是需要看机会的，可能是因为要换城市，或者说原来的公司业务上有较大的调整等等因素，会导致一些在职人员选择看新的机会。

说到从问题出发，找合适的人，这里面首先需要的就是要定位清楚自己希望建立的团队来解决的问题是什么。比如如果说现在的业务到了非常大的规模，然后也做了很多的尝试，可能这个时候是需要付出比较大的代价找到业内顶尖的科学家来解决具体问题。

而如果业务规模没有到这个阶段，即便愿意付出很多也未必能吸引到这样的候选人，因为候选人自身也有自己对于岗位机会的诉求。而一定要找这样级别的候选人，很可能最后花了很多时间也没有找到。

我说的合适，更多的是岗位机会、岗位要求和候选人的经验和诉求的匹配。从我的角度，候选人希望得到的机会和公司可以给与的成长空间的匹配度是最重要的，我讲的合适也是指的这个部分的匹配度。

 应聘者需要什么能力

具体到对一个应聘者的要求，下边我以招聘架构师为例，简单说一下我个人觉得主要应该关注的应聘者的几个能力：

1、逻辑的严密性。架构师的工作是要去负责某个甚至多个系统的整体架构的设计，这是整个系统能正常运转的基础，如果这个部分出现了纰漏，那么带来的问题会影响很大。

架构师主要负责整体系统的架构，这就像造房子的整体结构一样，并且在做架构设计的时候，很多是在白板上或者脑海中的推演，这个时候的逻辑上的疏忽和遗漏，带来的可能就是开工后的返工，会有很大的成本。

2、对关键细节的把控。架构师不是飘在天上的，自己设计的架构的关键细节是需要非常清楚的，在架构设计完成后，关键部分的功能实现方式可能是有不止一种的，不同实现方式则有可能对稳定性、性能和扩展性等有不同的影响，而且关键细节本身也决定了实现的质量，架构师是必须要关心的。

3、沟通能力。相对于具体代码，沟通架构的要求会更高些，这就需要架构师有比较好的沟通能力，能够把设计的架构讲清楚，把其中关键的环节和要点讲清楚，尤其在互联网行业，软件工程的过程不会有非常多和严格的文档的工作，这个时候就要求架构师一定得把架构设计沟通清楚。

4、开放的心态。能接受别人的意见和建议很重要，我们很多架构师也并不是什么样的系统和问题都经历过的，在工作过程中很可能会遇到关于架构上的挑战和探讨，这个时候，如果很封闭，就可能错过了别人给的好建议，这样在后期发现再改，成本就很高了。而且架构设计，除了自己在实践中提升，相互的切磋也是互相学习的好机会

展望

对于团队今后发展的一些想法，我觉得主要可以从三个方面去谈一下。

1、团队始终需要保持对行业热点与发展趋势的敏锐度，以及对新技术的可实践思考；关注技术与业务场景的结合，更方便在合作过程中上下游的沟通。

2、成员在宽度和深度的发展。相对于规模很大的公司，我们目前的阶段是需要成员在技能上要扩展自己的宽度，并且在我们场景下去深挖技术。美联现在还不是一个很大的公司，有一些业务还在探索，需要快速地尝试。

我们需要的是每个同学有自己的专长但是又对周边的技术有所了解，这样可以快速响应业务的需求，而不是去做过于细致的分工，每个人就守着自己比较窄的一块地，把这一块的事情朝着 100 分去做。

3、希望每年可以有比较大比例的新人补充来自于应届生。前面在讲建立团队的时候也提到过，每年都有应届生要进入工作岗位。这是一个固定补充新鲜血液的来源和时间，应届生本身的可塑性更好，而且我们对自己的培养体系也比较自信，所以对于比较批量的招聘，还是会以应届生为主；而社招，更多是解决我们需要的战力的问题。