有赞如何打造高绩效的千人技术团队？

本文转载自微信公众号：TGO鲲鹏会(ID：tgo-kunpenghui)，口述：崔玉松，整理：Bella Wu

由 TGO 鲲鹏会主办的全球技术领导力峰会杭州站于 4 月 13 日正式落幕，峰会现场，有赞 CTO & TGO 鲲鹏会杭州会员崔玉松带来了《如何打造高绩效技术团队》的主题分享，以下内容根据现场演讲整理而成。6 月 14—15 日，由 TGO 鲲鹏会主办的 GTLC 全球技术领导力峰会总站将在上海举行。

活动现场，有赞 CTO&TGO 鲲鹏会会员崔玉松在进行主题分享

有赞现在的技术团队成员加在一起一千人左右，组织还不是很庞大，但是发展速度很非常快。这就会导致很多问题，比如新人进来如何快速适应团队?比如内部协作效率下降等等。如何打造高绩效技术“团队”成为了管理者不得不解决的问题。

我之所以把“团队”加引号，是因为在这里“团队”不是指自己所在的团队、公司，而是需要包括管理者需要改善的方方面面。管理是一门艺术，艺术因人而异;同时管理也是一种实践，它要根据每一家企业自身的情况而定，管理本身就是因地制宜。如果你不想听别人瞎扯淡，那就把这三本书读透就够了——《格鲁夫给经理人的第一课》《管理成就生活》《管理的实践》，我建议新领导者可以先第一本书，非常经典。

杠杆点撬动团队绩效：提升核心员工的能力

高效团队的管理都具备三个基本常识，在三本书里面都有被提及过。

第一个基本常识是流动价值，一个团队具体到微观细节里就是个人，每个人的价值不一样，在每一个阶段也不一样，这个非常重要。比如，一个人入职一个月、三个月、一年、三年等不同时期的价值是不一样的。为什么很多公司面试会非常严格?因为在面试候选人的时候，候选人的价值对于公司来说是最低的，而越往后价值越高，如果不合适的候选人没有在第一时间被淘汰，那么他后面带来的损伤会越来越大;越做到最后他的可替代性越小，意味着你要花的成本就越高。技术人在写代码时价值是最低的，要进入测试阶段时他的价值又升级了。

第二个基本常识是打孔理论。举个例子，比如我是餐厅老板，怎样控制出菜的质量?我除了想给客人提供最好的服务之外，我还希望给客人提供最好的菜，但厨师其实是不可控的。打孔理论你可以想象成一个黑箱，在后面你再打几个孔，设计几个最 OK 的 KPI 来控制它，人越多协作的可能性就越低。你怎么样保证一千人、两千人、一万人的协作是正常的?这就是打孔理论。

第三个基本常识是管理杠杆点，刚才乔新亮老师(讲了很多内容，“力出一孔”这些都是管理的一部分，但不一定适合所有团队。比如说团队只有 20 个人的时候，你就不需要去做太多的管理;但是 20 个人也有自己的杠杆点，一千人也需要有自己的杠杆点，如何找到自己的杠杆点?今年我们在思考这件事，产品技术团队一千人，如果只做一件事，要做什么样的事才能让团队更高效?如果团队是一百人，做几件事难点是什么?有时候下意识的第一反应是对的，比如说一千人的时候，这个杠杆点就是怎么才能提高整个团队的绩效。我们的答案很简单，就是把核心的 50 个员工能力提升上去。这基于两方面的考虑，一方面是你培养员工，需要给他训练、培训、更多的东西;另一方面如果你认为一个员工的能力/态度差不多到顶了，那就可以考虑用更好的、更合适的人来替换。如果真的能把这核心的 50 个人能力提升上去，整个团队会往前走一大步。

虽然消除故障、bug 确实也能够改善团队，但是从宏观层面往下看的时候，你会发现它的杠杆点效果没有把一个团队最核心的东西做好带来的价值大。当然每一个团队都不一样，我们去年的杠杆点是流程和效率，因为去年增长速度很快，从三四百人一下子增长到一千人，那个时候可复制性是件非常重要的事，所以最重要的事是效率的可复制性。

用数据说话，驱动效能提升

我们认为公司应该尽早建立效能改进团队，别的公司也可能叫 PMO 团队。我们大概在两百人左右的时候就开始建立，但是我不建议公司在规模很小的时候就建立，过早地让专业的技术人来做这些事，会造成体制僵化问题，反而不利于整个团队的成长。所以我建议在一百人以下可以适当引入一些管理方法，但不一定要建立专门的管理团队。

如图所示，这就是我们建立效能改进团队之后带来的效能提升的具体案例。右边的是我们早些时候为了推这件事用看板，它的技术效果和传播文化具体一些，但问题是很难被数据化，后面会讲这部分为什么要切入到这个过程中去。

大家可以看道左边的导航里面很多东西跟乔总讲的有一些相似，管理有很多是相通的，基本都是围绕着效率、质量等来运作。

当技术团队协作范围超过 300 人时，就需要建立技术支持团队，在很多的公司尤其是互联网公司里面，比较忽视这种角色，但是在人多的时候，建立技术支持团队确实能够大幅提升效率。研发最怕打断，但只要有客户就必然有很多的需求、很多 BUG、有很多线上的故障，而在整个公司里通常来说除了 CEO，平均年薪最高的就是码农了;从事情的角度来说，当组织变大时需要有一些沟通和体系化的东西被沉淀下来，哪怕是知识型文档、处理型文档，它们可以大幅度减少开发过程中被打断。我们建立以后的效果非常明显，我们在当天产生的 BUG 当天被消除掉的就有 90% 多，在半年前这个数字是 30% 多。

但是我不建议在团队最小的时候建立这样的团队，只有在团队的协作范围变成很大时，它才能变得很有效。如果你是个百人团队，建立这个团队可能也就六七个人;但是技术产品人员大概有一千人时，他们带来的杠杆效应特别大;但如果过早介入这个团队，同样会产生一些副作用。

最后，我认为对于很多码农来说，他们应该从特别早期的时候考虑他的影响力。当技术团队有一百人左右时，就可以开始考虑做技术影响力，可能会觉得有点虚，但是虚的东西能够给团队带来更长远的影响。

比如我们在 2014 年左右就开始对外开源，我们开源的第一个东西是敏感词过滤，怎样高效地把关键词过滤掉。它会让大家觉得我是为这个行业服务，而不是仅仅为这个公司服务。这个举动在公司发展没有那么快的时候，对于大家信心提振是非常有作用的。ToB 的公司不像 ToC 那样每年增长几百倍，ToB 的公司每年五倍、十倍地增长，这个时候我要想怎么样找一些东西，为团队的每一位员工带来收获。比如我们前端开源的东西在 GitHub 上有超过一万个 star，就会有很多人慕名而来，哪怕别人工资比我们更高一些，他也愿意来。这可以给团队带来正向循环，冲着这个来的人也会比较单纯一些，整个团队后面的协作效果会好很多。

如图所示，这是另外一个东西，我认为它里面最精髓的东西是 —— 一些大规模团队是被运营出来的，很少是被管理出来的。团队运营和团队管理不一样，团队运营更多地偏数字管理、过程管理。

我现在更多地是在讲关于过程管理、效能改进方面。可以看这个图，这个是我们真实的状况，灰色的柱子代表技术人员未知的总人力投入;蓝色和绿色的柱子代表可量化可追溯的人力投入，蓝色是投在项目上的;绿色是投在日常迭代和优化上的，比如一两个小时做完的东西。有赞有一千多个工程师，他们每天在做什么?他们的时间花哪儿去了?我们都说高效的团队，高效意味着什么?我们也想知道。我们第一次统计这个数据是在 2018 年 5 月份，如图所示最左边的柱子，当时只有 10% 左右的工作是可以被追溯和量化的。我相信每个人都很忙都在工作，但是他手头上有十件事不代表那十件事应该马上做。如果你不知道他手头上有十件工作，怎么调整他的优先级?所以我们做的第一件事就是提高工作透明化水平，比如说处理一个会议、一个 BUG、一个项目，就尽可能在流程管理体系里面数据化，这样才有可能透明化，才有可能改善。近半年时间，这个比例从 10% 提升了 40%，这个依然不够，业界比较好的水平在 60% 到 70% 之间，要做到 100% 也不可能。我们都说结果导向、目标导向，很多时候过程如果没有被更多地追溯到，其实结果是没有办法被影响的。

我们还有一个数据是每一个团队成员都可以打开看见的——团队的个人化水平。这个很重要，让每一个团队有可比性，它是按照百分比算的，每个人的百分比不一样。有一些人可量化水平较低，有一些人可量化水平较高。所有数据都是相对的，我刚才讲了行业里面最好能够打通团队透明化的有 60%、70%，是否就意味着其他 30%、40% 就不好?也不一定，还是有相对的改进空间。

技术 Leader，要学会授权

同样，我们有了前面的数据百分比，在这里面寻找杠杆点就非常容易。

比如说我们在数据里面看到线上的故障和数量很多，可能它的杠杆点就在解决数据故障方面，如果我们说在其他的，如图所示，这也是我们当前最真实的一些数字，红色柱子颜色越深代表它的故障级别越高。红色的柱子下降是我们希望看到的结果。如果故障级别高，你能把团队成员拉过来骂一顿吗?不行，这这对故障本身没有太大的关注。所以，我们在这里面设计了一个积分体系和一个扣分体系，比如说团队出现了最高级别的故障就扣五分，最低级别的故障就扣一分，这样的话比故障本身更加量化，更有对比的可能性。

如图所示，右边的柱子是给每个人设定要达标的因素，比如说这个月最多扣五分，这五分有可能是最高级别的故障;也有可能是最低级别的故障，这里面也分了故障类别，上报来源，修复故障。上报来源有一个黄色的部分占比很大，黄色的部分是客户上报的故障，不是机器自动发现的，这就意味着在接下来的经营过程中要加强监控，如果没有这些数据支撑，leader 做决策时就只能拍脑袋想当然。

除了纵向组织以外，我们在今年也做了很多横向的组织。举个简单的例子，我们当时发现有很多故障导致的问题，所有的故障都必须由我来审批，结果发现故障并没有减少。后来我把这个权限给到测试负责人，当把授权重新下放的时候，每一个发布他都会仔细看，因为他要“背锅”。后来我们发现发布引起的故障大幅度减少，再我们干脆成立质量委员会来管这个事，因为当我一个人关注团队的话，团队成员会不以为然;当我们有一个专门的组织来管理和关注的话，结果会很不一样。

这就要看你最缺的哪些方面，当前最关心的是什么。如果当前最关心的是招聘，我们应该成立一个招聘委员会，由专门的人来负责。你要成立一个横向的组织，把它拉到一起，这些是能够快速解决你目前的杠杆点，以及通过杠杆点最需要解决的问题。

牛逼吹这么大，还有什么缺点呢?在所有的技术团队里面有两个最重要的角色，一个是架构师，一个是 Leader。架构师是为未来服务的，提供的是未来的效能;Leader 能够真正地提升现在的效能。

这是我们今天讲的全部的东西，希望给大家提供一个可借鉴和思考的方式。