互联网公司五八同城(58.com)研发效能团队建设之路

这是「二三线中型互联网公司研发效能团队规模、职能划分和优劣势分析」的一个铺垫，一个背景。因为如果不写此篇，大家可能仅得到一些经验总结，恐怕难以获取当时为啥做出那个决定。做决定要有上下文环境，要有场景才好理解。

本篇主要写了我在五八同城期间做的一些事情，介绍了五八同城的服务端一站式研发管理平台 iwork，接手英才网、安居客、赶集网的经历，从北美国际中心搬家到酒仙桥 IT 产业园，以及做移动端效能平台 sunflower。还是比较怀念曾经那个团队，那个「万能的PMO」。

1 北美国际中心

15年我加入五八同城的时候，它还在北苑附近的北美国际商务中心。当时我们在E座，五八到家在K2，无线团队(移动App）在F座。每次去北美国际中心都要从地铁 5 号线「大屯路东」下车，沿着北小河走10多分钟才能到达北美国际中心。北美国际中心的东边有个「黄草湾郊野公园」，中午吃过饭还可以去走上一圈。向南走不远是「完美世界大厦」，很多受不了长期吃美餐的小伙伴就去那边打牙祭。

当时我加入的时候，五八同城的产研人数在 1000人这个数量级，团队很年轻。当时我本着去投奔甄诚大叔的，可惜我刚去不久，甄诚大叔就去蚂蚁金服了。大叔在百度阿里腾讯都工作过，很多对于互联网团队的看法和认知都来自大叔，每次遇到犹豫不决的问题都会向他请教，他的很多观点都精辟犀利，发人深省。我和大叔很聊得来，现在也常联系。

在北美国际中心的时候，我俩座位背靠背，经常讨论问题。那个时候其实还没有网盘。文件共享一般通过ftp、samba来做，有点不便而且还涉及权限的问题。当时有一些团建的图片和外边下载的资料，我问他怎么看这个问题，他说放svn里。于是我们就新建了一个仓库专门用来放图片和文件。因为五八同城有个一站式管理平台iwork，所有 svn 的权限是托管到这上面的，只需要针对域账户做权限分配即可，非常方便。其实对于 svn 这种工具一般是存版本管理的，放代码比较合适，放二进制文件一般都是禁止的，但是如果做好隔离和管控觉得也没啥问题。格局打开了。

五八同城在研发基础设施建设这块的投入还是很早的。整体上前期五八同城还是百度技术的底子(好像百度技术是北京好多公司的底子）。负责研发管理部的江老板是百度过来的领域专家，对研发基础设施建设这块业务有很深的理解。后来遇到了她百度的同事，一个同事对她的评价是「整个百度对这块业务最懂的人之一」。

江老板的很多想法在百度经过了验证，到五八后创建了研发管理部，从0到1把五八同城这块的业务给带起来了。底子打的早打的好，后面就十分顺畅，反例就是如果底子差做的晚还要很快有结果，基本上接手的时候一地鸡毛撒手的时候鸡毛一地。

2 研发管理部组织架构

组织架构：TEG(CTO) - 研发管理部

五八同城也是腾讯系的公司，所以也有个一级部门叫TEG。TEG 还有其它的二级部门，比如数据智能部等，但是因为和我们不太相关，所以没在上图中展示出来，只展示了和我们交集比较多的架构部和运维部。

研发管理部有三个团队，主要负责四方面职能：

• PMO团队是刘总带队，一个老北京，脑袋机灵，当时开车带我去办了香港招商银行卡和富途的账户，可是亏了不少。现在我香港招行卡的联系地址还是北美国际中心。

• 平台产品是PMO团队的许晨同学负责，半个江南大学校友

• 平台研发是新跃带队，一个靠谱的帅气小伙

• 配置管理就是我们团队

当时我们团队负责的主要职责：

• 研发管理平台建设：作为平台的需求方，对业务线需求进行分析，负责方案调研、制定与技术选型，平台使用培训与推广

• 源码管理：开发模式、分支策略、基线版本等

• 基础设施：搭建、维护和管理配置管理相关系统，保证服务的稳定、高可用(Subversion, Git, Maven, Jenkins, Artifactory, Nexus, Ansible, Supervisor)

• 构建管理：建立和维护多平台构建服务器 (Java, Android, IOS, C/C++等)，保证服务快速构建上传

• 规范制定：负责规划软件配置管理策略(分支策略、发布策略)及软件配置管理解决方案、制定产研规范( JAR包管理规范、SVN授权管理规范)

• 脚本工具：完善构建脚本（Shell,Python）、备份还原策略和工具

• 业务线支持：对用户进行培训和支持，支持所有业务线业务发版

3 一站式研发管理平台 iWork

提到五八同城的产研就不能不提 iWork。iWork是五八同城的一站式研发管理平台。在很多公司svn/git手动管理的时候，五八的 iWork 已经上线，规范了产研协作流程，把规范落到 iwork 平台，大大降低了产研协同的沟通成本，极大提高了工作效率和质量。那个时候能做出来iWork，思想和系统都还是很先进的。

• 精细化的目录权限管理，通过组授权代替用户直接授权

• 自助式账号创建、密码修改、密码重置

• 权限审批下放业务线，可定制的多级权限授权流程

• 对各种开发模式的良好支持(主干开发主干上线，dev分支开发rel分支上线，分支开发分支上线）

• 流畅的研发全流程支持（需求->排期->代码->构建->提测->上线）

• bug/issue/feature 状态的自动流转、自动变更(比如分支送测 、上线后任务状态自动变更）

我15年加入五八同城的时候，上面的功能就都已经具备了。而我19年加入快手的时候，快手的 gitlab 还经常崩， svn还需要手动改密码，差距之大。好在两年多过去，我们在快手做的 Kone 也已经做得相当出色(对比三天两头被在脉脉上骂的 kdev 强太多了），这还得感谢「巨人的肩膀」，感谢五八和滴滴带来的成长。

4 接手ChinaHR、安居客

那个时候五八同城收购了ChinaHR和安居客，所以我们也开始接手这两个公司的相关所有工作。基本的思路是做好权限交接，检查系统备份还原方案以免数据丢失，保持系统稳定，先过渡一段时间后迁移到五八这边的系统上来。只接手业务不接收人。整体上这两个公司之前的技术和五八还是差了一点。留下的人也希望有人来接手，否则很多事情都做不了。所以我们团队很快就完成了这些系统的交接。

5 酒仙桥IT产业园

在北美国际中心待了没多久，公司就在酒仙桥IT产业园买了两栋楼，要往那边搬，所以涉及服务器的迁移。当时能部署一套的，我们就直接酒仙桥部署了一套服务，同时把北美国际中心这边的数据频繁的同步过去，在那边测试；不能同时部署的，最后只能直接搬服务器。

还记得一天夜里，我们(洪雷、宏伟、成龙 、赵丹、张蕾、帅华）用货拉拉叫了一辆小面，拉着几台服务器去酒仙桥了。结果拉过去后插上电显示器就蓝屏了，帅华对着蓝屏的系统，卡卡一顿盲配 IP，最后居然能访问了，震惊了我们一众小伙伴。

系统迁移过去后，我们团队的妹子们开始验证功能，中间发现有个研发都不记得的服务需要部署。好在大周末的搞了一上午完成了，又惊又喜。

6 接手赶集业务

总体上说赶集的技术实力还是不错的，在一些小点上比较有特色。比如docker compose，gitlab runner 在当时线上就都直接用上了。我们当时的做法和接手ChinaHR 差不多，先接手继续提供服务，然后慢慢过渡到五八这边的基础设施上。如果看到不错的点可以慢慢地吸收到 iWork中，类似腾讯赛马机制一样。

他们这块的业务之前也是运维兼职搞的，没文档没说明，尤其是还喜欢用一些新技术，当时还是很被动的。

7 移动端效能平台 sunflower

sunflower 就是五八同城的移动端一站式研发管理平台，可以类比阿里内部的摩天轮系统，不过我们起步可晚多了。一提到阿里摩天轮系统，业内人士就有感觉了。这个时候我们已经搬到酒仙桥IT产业园A5了。服务端效能平台 iWork 还在改进和增强，在移动端其实我们做的还十分有限。所以我们发起了代号为 sunflower 的移动端效能平台建设项目。

什么事是我们「万能的PMO」做不了的。要PMO有PMO，要产品有产品，要方案有方案，从无线团队借调过来前后端，我们就开工了。一期一个半月上线，主要做了分支管理、一键安装包、打渠道包、发布上架等功能。

8 实操经验总结

五八同城从来也不是一线互联网公司，可是在研发效能这块走得一直不慢。有的做的还是比较有特色的。总结下之所以这样，我个人觉得有以下三点原因。

8.1 人员因素：上层有意识，中层有能力

上层领导有意识，重视基础设施建设；直接领导懂业务，把控大局和方向。

上层领导还是挺有这方面意识的，很早就对研发基础设施这块进行了投入，而且是有目标有节奏的投入，支撑业务的发展。而不是眉毛胡子一把抓，甭管啥东西都直接上去薅一把。

技术驱动 vs 业务驱动
虽说好多公司都标榜自己公司是技术驱动，不知道国内真的是技术驱动的公司有几家。找一帮工程师咔咔干半年，做出来东西没人用的例子太多了。以业务为纲，说业务驱动很丢人么，逼格不够高，口号不够响？
技术可以驱动产品，但是技术绝对不能决策产品，否则容易让产品在方向上跑偏。

江老板把百度的经验带到了五八同城，从 0 到 1 创建了 iWork这个一站式研发管理平台，极大提高了产研合作的效率。配合公司的整体战略，我们研发管理部做了很多很多的事情。定规范、建平台、做支持、搞培训、对外输出扩大影响力，有策略有节奏有规划地进行着。

好像没有对比就体现不出差距，也看不到伤害，那就举几个小例子：

如果老板问你为啥要有制品库？去掉制品库，都放到 svn 存储统一存多好。

如果老板问你 nexus干嘛的？让研发自己去下载 jar包吧，我们又少一个事

如果老板问你项目版本为啥是三位？构建的包为啥四位版本号？能否统一用时间戳？

（一站式研发管理平台）iWork为啥要管源代码？拆开吧。

不要在搞稳定版本了，都发快照， iWork又可以砍掉一些功能

可惜最后江老板也走了。人一走团队就散了。江老板的离开说跟陆奇离开百度桑德伯格离开Meta一样导致公司市值掉下几百亿美金，这可能有点过了，但是她在研发管理部就是那个位置，研发管理部的压舱石。她离开后，iWork也不是当年的 iWork了，我们「万能的 PMO」也散了。这就是榜样的力量。

8.2 组织架构：职能划分清晰，组织架构稳定

公司研发效能这块业务一直在研发管理部，公司内从来没有第二个团队做类似的事情。研发效能这块业务支撑公司所有产研同学，如果没有真功夫也没点服务意识，还真做不好。好在五八同城，研发效能这块一直在研发管理部下不断发育着，从来没有被拆分。

收购英才网 ChinaHR 后，我们就接手了英才的这块业务；和赶集合并后，赶集的相应业务也都合并了进来。业务合并进来，人员一个都没留。所以团队可以不断的成长，规划得以继续施行。

基础设施的建设是需要时间的打磨的，需要历史的沉淀。内功的修炼没有吸星大法的捷径，从来不是一朝一夕。如果公司建立时间比较长，还会有很多技术债在那里，有很多坑要填，从0到1能有起色这个时间就会很长。这就要求公司、部门、团队都要有耐心，我们要把研发效能当作个业务来做，而不是找几个研发人员上来一顿代码输出当作一个工具一两个月搞定。搞定的仅仅是一堆代码，离业务成功还有很长的路要走。

研发管理部统一支持服务端、移动端、前端三端。一开始服务端和移动端在我们团队，后来前端的支持工作也移交了过来。三端效能工作本来就有很多交集，统一支持更具备合理性。滴滴的移动端效能一开始是业务线和我们 EP 共建，后来也都移交到我们 EP了。我觉得这是正确的路子。快手的移动端效能平台 keep 一开始做的不错，可惜后来负责人被拿下，现在平台移交到了业务线，不知道以后什么时候才能回来了。

8.3 时机：恰当的时间做正确的事

想要做好一件事，除了长期投入、猥琐发育外，很重要的一点是时机，在恰当的时间点做正确的事。这就需要大局观和对业务的理解了。

怎么叫恰当的时间点做正确的事呢？我觉得最重要的是要搞清楚当时的实际状况和背景后，换做另外一个懂的人也会做出这样的决定，那么那个时间点做那样的决定至少是没问题的。有些事情一旦错过那个时机，就很难做成。所以万事要提前做好准备，等待那个时机的到来，抓住它，做成它。

相关文章：

第一篇：互联网公司研发效能/工程效率团队建设和规划

第二篇：为啥研发效能团队必须独立？何时独立？

第三篇：中小互联网公司研发效能团队规模、职能划分和优劣势分析

第四篇：研发效能团队规模、职能划分和优劣势分析概述