十多年中台的探索、经验、教训及组织管理办法

这是中台系列的第三篇，第一篇《 什么是中台，什么不是中台》厘清中台概念，第二篇《 怎么建设中台》介绍了建设中台的方法，这篇介绍网易杭研在中台道路上十多年的探索和经验教训，并补充在中台组织管理方面的方法。

今天的网易已经到了大学毕业的年龄，游戏、零售、音乐、教育、门户、邮箱、网易云等业务板块都有了明确的形状。时间倒流回到14年前，那时的网易8岁，才上小学二年级。当时的网易，已经有最大的中文邮箱和广大的邮箱用户，三大之一的门户，还有开创了风气之先的现金流业务 — 游戏。就像一个二年级小学生算是会读书识字了，但还有很多的知识要学，充满利国利民的抱负，网聚人的力量，做美好生活的缔造者。

05年，机缘巧合下，我们团队成了网易杭州最初的团队（更精确的说，游戏技术大神云风比我们更早就在杭州建了一个小的游戏工作室）。当时的网易已经在互联网技术上碰到了瓶颈，游戏的点卡Oracle数据库已经不堪重负，相册的数据库堆在一个700G的MySQL里眼看要玩不转了，相册十亿级的文件用NFS搭出来的分布式存储集群问题频发。

但公司意气风发，MSN Space引领的UGC和Web 2.0风起云涌，网易相册非常成功已经是第一大中文在线相册，岂能受限于技术？当时的网易，在北京布局了有道做搜索，在杭州布局了杭研做互联网创新业务。当年第一次在北京见到丁老板的时候，老板鼓励我们在杭州任何与互联网相关的业务都可以试，印象最深的例子是自行车联网，当然这个事情我们后来没做。

虽然技术是很大的瓶颈，但当时老板就认为技术研究和业务不能分开。当时主要是看到Google没有专职的研究部门，技术高手和业务是在一起的。所以，研究院就同时背上了业务创新和技术研究双重职责。环顾四周，网易杭研似乎真可能是中国互联网第一个企业研究院，而且是业务实干型的研究院。十多年来，杭研培育了无数业务，比较成功的有考拉、严选、音乐、云课堂、Lofter、云阅读等，早期的博客和相册也不错，只是早就过时了。自然不成功的也不少，比方印象派、梦幻人生（SNS）、网易手机邮（不是手机号码邮箱，是一个比微信更早的类似微信的产品）、网易Popo、易信等，因为互联网是一个VUCA的时代。

研究院的骨干几乎统统来自浙大计算机，都是06年刚毕业第一份工作就到杭研。说实话，杭研当时搞技术不输国内任何人，但业务sense是一般般的，一群工科男嘛。即便在十多年后的今天，要说业务敏感度、运营能力，仍然压力很大。

但工科直男有工科直男的思维，那就是追求体系化，极度讨厌重复建设。因为06年杭研刚正式成立就有好几个业务要并行做（博客、相册、POPO），而哪个能成哪个不能成，也说不准。所以我觉得杭研得是铁打的营盘，业务很可能是流水的兵。我们得考虑把这个营盘打造的好一点，让来的兵成长的更快一些，各方面的战斗力更强一些。这样，打胜仗的概率肯定就会上升。

基于这样的思路，第一年我们专心解决海量数据管理的核心技术难题。06年9月1日，随着网易博客的正式发布而上线的DDB、DFS分别解决了分布式数据库和分布式文件存储的问题，当时在国内是最早的。当时做博客差不多20个人，做DDB等平台也有15个人，在基础技术上的投入按比例看可谓巨大。07年我们又投入做了MapReduce系统NEMR、融合多维查询系统等。这几个系统在当时的环境下，基本上就把主要的技术挑战解决了。

既然技术上可以通过专职的团队做的很好，那么其他方面也应该可以。这样，杭研就走上了一条不断建立共享能力团队的发展之路，我们希望这些共享能力综合起来，能够形成一个强大的创新中台（当然之前没有中台这次词，叫平台），提高创新的速度和效率，提供成功率。

07-08年最早成立的非技术类共享能力团队是用户体验和软件质量，因为我们希望每一个杭研的产品的交互体验和质量都能过关。当然这很大程度上来自于老板的压力，这方面的问题一出很快就会被老板看到，被老板K的滋味当然是很难受的了。用户体验和软件质量团队一直延续到今天。

09-10年主要建的是数据挖掘、内容安全、移动研发。因为内容安全大量用到数据挖掘的算法，所以数据挖掘和内容安全这两个团队一开始是在一起的。内容安全这两年主要拼死啃一个硬骨头：邮箱反垃圾。后来通过机器学习算法比较好的解决了，直到今天邮箱反垃圾的核心算法还是杭研的团队在做。内容安全后来发展成了全集团的信息安全部，负责网络安全、内容安全、业务安全、系统安全等主要的安全工作。其中内容安全方向除了邮箱，还服务了音乐、新闻、Lofter等几乎所有互联网产品，不但提供算法和系统，还负责安全策略的运营和人工审核。数据挖掘方面则是在博客里面做了很多个性化推荐、标签推荐等尝试。后来这个团队逐步逐步做成了数据挖掘部，业务范围最广的时候负责了新闻、音乐、考拉、云课堂、Lofter、网易花田等绝大多数互联网产品的推荐和搜索，为业务指标负责。移动研发部则阶段性负责了杭研所有移动互联网新业务，如网易云阅读、网易手机邮等。

11-14年又建了项目管理、商业智能、运维部等，从原来偏技术开始走向管理和运营。项目管理部是PMO的概念，一方面培养并派出专业的项目经理到各个业务负责项目管理工作，确保研发项目的交付，另一方面这两年也开始主导研发效能工具的开发。商业智能部曾经负责了音乐、易信、教育等所有杭研体系业务的数字化运营分析工作。运维部负责了考拉、音乐、金融、新闻等业务的运维保障，包括了SA、DBA、PE和运维平台研发、运维体系建设等职能。

15年开始投入建设集团级的用户中心。以统一的账号体系为基础，整合多业务的数据，实现用户标识的统一，并建立起规模较大、覆盖较全、准确率较高的用户标签体系。

我们称这些部门为专业服务部门或专业能力部门，目的是专注的培养某一方面的能力支持业务发展，同时提升人均效能，降低成本。这些部门根据中台是支撑多个前台业务的共性能力组织的定义，很多都具备一些中台的属性，特别是用户中心、数据挖掘、商业智能、移动研发、内容安全这几个。在长期的摸索中，每个中台除了形成了不少的技术和方法论（一般都要求每个部门出一本白皮书）沉淀外，也积累了一些组织方面的经验。

组织方面最基本的一点是“专人就位”。所谓“专人”，指的是支撑每个前台业务的一定有一个专职的团队，即便只有一个人。所谓“就位”，指的是支撑前台业务的专职人员一定要坐到业务团队中间去。第二点是考核要实现某种程度的挂钩，至少要给予前台业务打分的权利，有时候甚至会直接跟前台业务的某些KPI挂钩。

但是如果只是把某一个方向专业的人集中在一个部门，那这个部门只能说是一个职能部门，甚至大家觉得你就是做人力外包的，要么不创造多少价值，要么觉得你培养的人挺好，挖过去。这自然跟中台的概念相去甚远，这样的部门也就不会有长久的生命力。

如同阿里的共享业务中心在初期地位低、压力山大一样，每一个专业能力部门的建立已经不易，但发展挑战更大，因为这些部门都不直接创造价值（中台都不直接创造价值）。所以每个部门都在拼命的思考怎么沉淀核心能力，而不只是一些某方面专家的集合。

经过多年的分分合合、起起落落，就大致摸索出了一套建设中台组织层面的方法论，今年云创峰会上大致有过介绍。在我看来，一个标准的中台组织必须有一系列的可以共享的能力沉淀，这些能力沉淀要通过团队、技术和方法论三种方式。团队方面，就是一系列的能力组，比如对数据挖掘中台专业的NLP、视觉算法和标准化的内容加工团队就是能力组，再比如对质量中台专业的性能测试、移动端兼容性测试等团队就是能力组。技术方面就是要尽可能的将能力和知识软件化、产品化，如项目管理部要主导研发效能工具等。方法论方面就是要形成流程、规范、check list、最佳实践等各种方法论。

一个团队共享能力建设的越好，价值就越大，也就越像中台；共享能力建设的不好，价值就越低，也就越像职能或后台部门。

虽然中台概念上只应该包含共享的能力，但这样“标准”的中台部门也经常会遇到与前台业务结合不够深，合作不够顺畅的问题。这时我们经常采取阶段性的把相关前台的部分团队也整合到专业能力部门的做法，这样在中台部门就有了一个个定向支持对应前台业务的定向组。这就形成了我所称的“胖中台组织”。阶段性的让中台组织长的过胖一些，让中台和前台的边界在一个组织内磨合，过两年在看哪些是属于中台的骨骼，哪些是属于前台的肉，搞清楚了再把肉重新分到前台去。这样，胖中台组织瘦下来，又变成一个标准的中台组织。

不过即便有了这些方法，我们觉得中台的建设仍然是非常难的一件事。特别是集团和杭研业务的多元化使得要建设业务属性非常好的中台往往没有条件，所以，在很多时候，我们会选择尽量的将专业能力部门的能力下沉到工具和方法论，而将之外的团队重新分流到各前台中去。我觉得这样的管理也应该是合理的，并非说一个中台组织建立之后就必须长期存在。建中台组织是为了做好某方面的能力，如果这方面的能力大部分都可以软件化、方法论化，那么为什么还要维持一个中台组织呢？这时可以把中台退化成为平台组织。

这是杭研在中台建设的一方面，另一方面，考虑到业务多元化的现实，不如选择和各个业务合作，更好的支持各业务建他们的中台。这方面严选的数据中台走在集团前列、考拉的业务中台走在集团前列，都是杭研的老师。杭研则专心做好中台的技术支撑，让考拉、严选、音乐等的中台建的更顺、更好、更快。这次云创峰会推出的网易猛犸6.0和新版网易轻舟，就是在这样的背景下打磨出来的数据中台和业务中台的支撑技术。

这也是我对中台建设层次的观点，企业级或者事业部级都可以建中台。杭研建的那些中台可以说是企业级的，但杭研支持考拉等业务建的中台都是事业部级的。一般而言，事业部的业务发展到一定阶段，都可以建中台，也相对比较好建；企业级的中台就要看公司的战略和业务的状况，建设难度也更大。

中台是一个新的名词，但并不是一种新的实践。杭研迫于要并行发展多条业务线的压力，加上理工科厌恶重复建设的思维，不断的建设各种专业能力组织，从而走上了一条摸索建设中台的道路，再到后来一些业务发展大了，又支撑着各业务建他们的中台。这里面经验有一些，教训也很多。很容易失败！

我始终认为，要把营盘打造的好一点，把能力打造的好一点，以便组织能更快速的响应变化，是对的方向。我们面临的是一个VUCA的时代，控制论告诉我们及时反馈、调整才能到达目标，越来越多的市场变化因素使得顶层设计和长期预测变得不可能。更进一步的看，能力建设本身也要灵活，因为建设能力也需要投入和成本。技术上，绝不要重复造轮子；组织上，要根据情况在胖中台组织、标准中台组织、平台组织之间灵活切换，不要担心组织调整影响到了某些人，调整带来的重新分配对大多数人来说都是更好的去处。