中台反思：提质增效

企业文化与领导团队并不对等，之所以把两者放在一起是因为它们都能决定企业的生死存亡，“皮之不附,毛将焉存”，固将之视为提质增效最重要的因素。需要承认的是大部分企业没有文化可言，领导团队代表了企业能力，知名如Google的“Don’t be evil”，阿里的“客户第一，员工第二，股东第三”，也不过是沦为了茶余饭后的谈资。想靠企业文化带领企业走得更远很难，关键还是在于领导团队能力，比如乔布斯置于苹果、纳德拉置于微软、柳传志置于联想。

因此聚焦而言，提质增效首先要反思的是领导团队是否有不足，这包含如下几点：

组织架构是提质增效最为核心的、涉及范围最广的因素。概况而言这涉及到的是组织形态及配套的绩效体系，而不同的业务、行业、地域、企业规模下差异很大，务必因地制宜，万不可邯郸学步。但有几个优化的方向具备一定的通用性，我们将展开讨论。

对于初创公司而言，“快”往往是其最核心的诉求：快速出产品、快速试错、快速占领市场、……，另外由于团队规模较小，因此组织形态上可完全趋于扁平。公司领导者的一些想法可以直接与所有员工沟通，避免层层转递的信息延时及失真。

公司上规模后往往会是“稳”字当头，先求稳再求快，彼此团队规模也逐渐增加，所以自然地会按专业线划分市场、产品、研发、保障等多个部门，按地域划分不同的管理单元。精细化的组织架构有利于大家各司其职，确保公司日常运作的稳定，但是过多的单元划分必定导致过长的传递链路，所以如何稳中求快成为了组织架构设计最关键的目标。

对比上述两种组织形态，我们改进的方向几乎都是向着 “在责权明确的情况下实现组织扁平化” 。我们常听到的网格管理、划小经营、阿米巴等形态都是对其的探索与落地。比如如上图所示，一些公司会尝试将研发部门拆分到各业务线，以业务线为单位串联整个流程，但这种“简单化”扁平处理会导致如下问题：

怎么破？这时“中台”就逐步走进了大众的视线，中台是什么能干什么在不同语境下有不同的解读，从提质增效的角度看中台是组织架构演进的一种比较有效的方案。怎么理解呢？

首先我们要肯定“组织扁平化”是一个正确的治理方向，但简单粗暴地处理会导致上述问题，但当我们引入中台做能力分层之后就可扬长避短，在稳与快之间找到平衡。

如上图所示，这是中台组织架构的常见形式，两个比较大的特点一是市场、产品、研发等专业部门是虚拟形态的，实际上的组织架构是一个中台部门及多个业务线组成的各前台部门。

中台部门由中台产品及中台研发团队组成，负责核心的、稳态的需求研发及基础的、公共的、领域的能力建设。一个强大的中台部门可支撑起企业绝大部分的需求场景。各前台部门由市场、产品、研发三大类人员组成，可形成类似阿米巴的细胞组织，业务导向。由于中台已支撑起了核心的功能需求，所以每个前台部门只需要少量的产品及研发人员专注于差异化的功能需求实现即可。有了这样的架构后，会向中台输送高岗高P的产品、研发人员以形成稳定的支撑能力，而各前台部门则只需要相对基础的产品及研发人员，在规范化研发的前提下前台产品及研发人员的流动对业务的影响有限。这就是所谓的稳与快之间的平衡。

我们再看下上文提到的问题如何化解：

“专业认知的差异导致矛盾频发”，中台部门有健全的产品、研发团队可避免这一问题，前台部门只涉及相对简单的差异化能力建设，几乎不用涉及业务抽象，可1比1的按需求编码，很少会涉及无法实现的复杂的需求(有的话可由中台团队消化)，所以矛盾并不会突出。

“员工成长受限”，产品与研发拆分到两类部门后有了明显的晋升方向，中台部门自成一体，不存在成长受限，对于前台部门的产品与研发而言，如果想在专业线深入可转入中台部门，如果想跨专业发展可继续在前台部门磨砺。并且还有产品、研发两个虚拟部门提供培训、交流等专业氛围建设。

“业务线各自为政导致建设重复、标准不一”，解决这一问题是中台部门成立的初心，通过中台统筹管控产品建设，标准规范。

这里介绍了中台化的组织形态，对应的我们也需要一套适配的绩效制度，这点非常重要。首先必须明确的是传统的KPI考核有诸多的弊端但也并非没有可取之处，OKR、北极星指标等相对较新的评估方式有其行业先进性但不可避免的也有诸多的前提条件限制。如上图所示，对于中台化的组织可尝试在企业层面推行北极星指标，明确当前阶段企业战略相关的绝对核心指标，比如GMV、DAU、订单量、……，该指标需要层层分解到各个部门。中台部门可以以OKR为主导，在北极星指标的要求下给予更多发挥的空间，提升员工的主观能动性，在保障需求支撑的前提下更加关注质量、性能、流程规范等非功能性要求。前台部门直接对业务负责，所以KPI会是不二的选择。

团队管理是影响提质增效的另一个关键因素，团队管理的核心是对人的选、育、用、留。

“选人”是第一步，很多公司都重视新人招聘，建立了完善的招聘流程制度。这一步最要警惕的是真假能力辨识，以IT行业而言，各类面试宝典、Leetcode题库满天飞，一般的以预设题库为主导的面试很难筛选出真正符合的人，一个比较推荐的招聘方式是一、二面以题库为主以达到快速过滤不符合要求的人，而后续面试需要包含两大问题，一是以面试者经历导向，抓某几个点深入探讨，二是以实际岗位需求导向，让面试者设计需求实现方案。当然这对面试官会提出很高的要求。

“育人”是团队整体能力提升的关键之一，同样的很多公司也会有完善的导师制度、培训机制。这里要注意的是培训的投入与产出是否合理，一般而言培训师都是高岗员工挂职，对公司而言一场培训的成本不低，但往往培训的效果很难符合期望：主动参训的人少、现场互动少、听得懂的内容少。为什么？核心在于一是培训内容的设计及受众上需要聚焦，过于通用化的、“老少皆宜”的培训不如让员工自行去找资料学习，并不需要“重复造轮子”，每次培训不在于人的多少，要找对受众；二是培训的形式需要开放，好的培训不是一个讲师对一群学员，而是一个主持（引导者）与一群参与讨论的人。

“用人”，用对人是提质增效最核心的考察点，而用对人的关键又在于找对中层管理者——部门、业务线、项目群等不同维度的负责人。中层管理者的聘任可以参考 忠诚、能力、产出、格局 这四个维度。对公司忠诚视为第一要素，一般比较忌讳“空降”，从能做事的老员工中提拔是首选；能力也很重要，专业能力、沟通能力、文档能力等需要考察，尤其是专业能力置于研发团队之中，管理者要能亲历亲为，能做架构能写代码能修Bug，简单而言，成为管理者的前期是成为专业领域的佼佼者；产出也很重要，但因产出受限于多方面影响，“只看结果不看过程”是极不负责的评价方式，所以这里将产出放到第三位，要考察排除外界干扰后候选者过往工作的实际成果；格局可能是比较被忽视但又很重要的一点，好的管理者功劳归大家，责任自己担，好的管理者会力荐有能力的下属去其它需要的团队，而不是把有能力的人约束在自己的团队内，好的管理员欢迎比自己有能力、比自己待遇高的下属，不让自己成为团队的天花板。

在研发团队内，因为专业性要求高且团队“单纯”，我们应尽量避免纯管理工作的岗位，一般而言都是架构师兼任管理工作，笔者更倾向于将“Manager”换成“Coordinator”以弱化管理属性。

“留人”简单而言一是不要等员工提离职才想起要沟通、要提高福利，很多企业都是这样，这是管理的大忌；二是对于表现不佳的员工要及时指正并书面留底，给予换岗换项目的机会，确定不合适时快速交接。企业间员工的流动很正常，平时要做好AB角，对于核心员工要有区别对待，要分别从待遇、福利、团队氛围、工作内容、私交等多方向予以关注。一流的管理谈感情，二流的管理谈理想，三流的管理谈待遇。

研发管控也是我们重要考察的因素，它涉及项目产品从立项、需求分析、到技术架构、编码开发，再到测试发布、部署监控等研发全流程，有包含业务、产品、开发、测试、运维、QA等多个角色共同参与，管控之复杂不负于软件“工程”之名。既然是工程自然会有标准可寻，国际国内有各种标准，比如CMMI、保等、ISO等都有不同层面的涉及，在实施上各类敏捷管理大行其道，而目前流行的DevOps更是研发管控理念的集大成者。

这块可展开的有很多，与提质增效相关的几个要点一是要自动化，让机器代替人工以降低流程的复杂度，减少人为干预，比如现在的CICD都可实现比较高级的流程自动化，但在微服务及云原生架构下做得还很不够，有机会的话会单独成篇详细描述；二是要标准化，标准化意味着成本可控，大家都按这个规范做，换个人也没有学习成本，标准化也意味着成熟稳定，有业界经验可寻，避免出了问题两眼抓瞎；三是关键节点管控，完全自动化的流程必然会有瑕疵，比如自动化测试代替不了人工验收、代码质量扫描代替不了人工审计，在研发的关键节点必须要有干预，常见的我们需要有需求PRD评审、UI评审、架构设计评审、核心代码审计、用例评审、转测评审、交付评审等多个关键节点审核及迭代复盘会议。

最后一个因素是技术架构，技术架构本身是个很宏大的话题，聚焦到技术架构对提质增效的影响可分为两个方面：可依赖架构、敏捷化架构。

架构的可依赖是很高的要求，涉及可迭代性、稳定性、性能、安全等多个领域，不同领域又有许多考察点，如下图所示：

以上这些为常见的考察点，每个点都可以展开讨论，其中很多内容在笔者3年前写的《微服务架构设计》（ https://github.com/gudaoxuri/Microservices-Architecture ）中有涉及，本文不再赘述。

架构敏捷性在近年逐步被重视，以中台化架构而言我们期望构建“大中台小前台”把基础的共性能能力都在中台实现以更好地支撑前台的敏捷交付，但随着中台越做越“厚”，中台本身也希望能进一步敏捷，所以又出现了中台的分层拆分，另一方面中台对前台以服务方式的支撑并不满足前台敏捷的需求，因此中台也逐步在以SaaS为重心的模式下引入了aPaaS能力，以实现低代码方向的对前台应用从0到1的完整交付能力。另外中台能力的拓展又导致了中台应用场景的泛化，原本中台只属于中大型企业才需要的能力，但aPaaS的方向建设使得中台有能力去构建前台应用，可以把其当成云IDE使用，所以这会受到众多中小型企业的欢迎。但这也带来了一个问题：中台的交付形式从单一的云服务变成了服务 + 产品，此时中台需要支持本地化部署，并且运维成本要可控。

这要求我们的中台建设一是架构上要按领域拆分、分层，形成一个个可选配的组件，二是需要扩展实现aPaaS能力，三是在功能增加的前提下要实现更简单的部署，更低成本的运维。业界比较知名的几个中台产品动辄至少需要4、5百核CPU资源，我们也可以匡算一下自己写的中台服务，一个Spring Boot服务少则4C8G、300MB，实现基础的服务权限、用户触达、流程设计、调度任务等多个中台产品至少包含15个微服务，每个微服务3个副本就需要180C360G、13G的资源，这样的资源需求在产品化推广上几乎是灾难。

所以我们需要反思敏捷化支撑下的技术架构，留下几思考：

如上文书，提质增效涉及的点非常多，这是一个系统性工程，但也正是因为涉及的点很多，我们可改进的空间也很多。在不同的公司中研发部门多半是成本中心，所以往往会被领导、业务部门指责质量、效率低下，此时我们要明白的是这需要自顶而下的分析，只有上下配合才能事半功倍，需要从以下几个方面分析优化：