实现技术领导力的秘诀——带领，而非鞭策丨Open Talk 有米科技专场

分享 | 蔡锐涛（有米科技CTO）

2016年12月17日，又拍云Open Talk有米科技专场在广州举办。此次Open Talk邀请了有米科技（834156.SZ）技术团队的4位大咖探讨技术领导力、大数据和用户画像、在线业务扩容的技术选型等话题。

今天小拍给大家整理了有米科技CTO蔡锐涛分享的《技术领导力：提升技术团队的“有米实践”》。

蔡锐涛对如何提升技术领导力方面分享了如下经验：

先来了解一下有米科技吧~

我今天更多的是分享有米科技的技术团队如何从一个大学生团队一直做到现在。我分享一些技术领导力经验，比如我们如何维护工程师的象牙塔，在每一个公司，一个团队能做深入的技术研究是非常考验人的一个事情，这也是每个CTO要做的一个事情，既要技术跟业务结合，也不能让业务去太干扰技术的发展。

有米科技的技术团队平均年龄在25岁，今天和我一起进行分享的三位同事里面，有两个毕业还不到三年。有米科技的体系比较完善，现在有120多个工程师，有1945个公司内代码库。

最近4年来，技术团队达成了以下一些成就：

关心核心技术，充分运用云服务

讲完背景再讲一下技术的领导力在有米是怎么做的。

△ 带领，而不是鞭策

我觉得作为一个领导来说， 应该是带领，而不只是鞭策 。

有米科技打造技术领导的一个核心在于“关注核心技术”。

从有米科技的创业到现在，技术团队只关注自己的核心技术，大量使用外部资源，能不用自己做的就不用自己做，能用钱解决就用钱解决。

有米科技是国内最早使用云服务的一批公司，这其中也包括了又拍云的云服务。有米科技在2016年已经把所有物理服务器转为云服务器。

第二点，有米科技非常重视强化工程师个人能力。在我们这边工作，分工不会做得非常细，运维、DBA、架构师这三个岗位在我们公司里是没有的。我们一开始创业就立下了一个规矩，不设运维岗位，我们80%时间是开发各种各样的工具做自动化的管理。

我们可能更倾向于在前端、大前端的技术方面做一个区分，最近在探讨的一个话题，就是我们整个客户端往大客户端的方向上发展。

第三个，有米科技鼓励跨领域，比如鼓励工程师去做一个前端，了解非本岗位以外，特别是上下游技术领域。

提倡技术与业务结合

有米科技非常提倡技术与业务结合，我们正在做，我也不觉得我们现在能达到这样的目标。

但是要往这个方向走，一个非常重要的就是要重视基础组件的开发。只要重视基础组件的开发，上一层做业务的工程师才能专心的做业务，目前，有米科技在公司内有统一的Web框架最佳实践方案，同类技术方案能够快速移植（比如广告系统从国内到海外），此外还有统一的Devops方案。

业务跟技术结合，最重要的一点就是避免KPI导向，有米科技采用 OKRs进行绩效评估，OA系统公开各项OKRs。现在是实验阶段，如果有相应的时间可以考虑分享大家，O就是公司、所有人的目标，整个团队的目标是什么都是公开透明的。

怎么样把公司的目标转化为产品、技术的目标，此外还要关注整个技术的目标完成情况，不能为了短期的运维发展不需要的技术……这些是执行过程中需要去平衡的一个问题。

我们坚持每个月做OKRs的梳理，关注结果也关注过程，执行OKRs需要不断去调整，这也是我们其中的一个心得。

重视分享和写作

“分享是最好的学习”，我们公司内一直在强调这个事情，每一次去做分享，受益的不是下面这帮听众，受益的是上面的分享者；因为准备PPT要收集很多资料，这是一个转化知识的过程。

我们在公司里面每周都会做一个分享，每周都会特批一到两个小时的工作时间，由公司的资深工程师带领进行分享。当然每个小组有各自的模式，有的是指定一个固定主题或者技术领域。分享这个事情我们已经坚持了三年，一直没有中断过，覆盖了前端、移动广告网络后端技术、SRE、程序化交易技术、安卓客户端技术、iOS客户端技术、设计。在很多时候，分享是提升我们整个工程师能力的一个过程。

写作是最好的思考。大家可以看一下，我们有92个空间，运行了6年，有15110篇内容，基本上每天要写两篇。假设你是一个应届生，从熟悉工作流程，到构建一个系统，写一个符合我们规范的小型项目，怎么上手，这些都基本上形成了标准化流程。

我们非常鼓励团队成员多去写，而不是空口一说。如果你真正的思考写出来，而且不是记流水账，能够让一个从来没有接触过技术的人都能看得懂，这才是真的吃透了技术。

有米科技文档里涵盖范围：

• 技术最佳实践

• 每周分享

• 技术栈/工具链、库的选择

• 系统设计文档

• 产品文档

Q & A

Q1：CTO是一个业务和技术的结合，技术有时候需要跟非技术的同事去沟通，我可能是一个相对传统的产品经理，但我觉得大数据发展以后每家公司都用得到，我可能想知道一些结果。我在得到这个结果的过程中，怎么跟数据处理、数据挖掘的同事去沟通，会更顺畅一点？

蔡：我建议在讨论需求或者想法的过程中，应该带上工程师一起参加讨论的过程中，而不是最后给到一个干巴巴的结果。有米科技是做移动营销的，基本上只要是讨论大数据交易或者数据交换，都会拉上团队的领导一起去聊一下，数据维度够不够，跟我们的互补性够不够，能不能支持营销需求。

我不建议一线工程师参加这个过程，让技术的领导参加这个过程，从产品、商业是怎么样去考虑这个问题的，只有让他比较完整地了解整个问题背后产生的原因，他才能更好配合工作。

Q2：正常都是拉上领导去沟通，然后领导去分配、任务，我理解他是怎么样跟下面负责执行的团队成员进行沟通，他想是我要一个结果，你怎么老是不给我？

蔡：这个要看团队的规模，如果你的团队规模很大，那我很难帮你解决这个问题。这里面存在的问题就是组织架构的问题，而不是一个沟通的问题，比方说组织架构已经很僵化了。组织架构一定是要比较典型、灵活，团队不要太大了。

Q3：我的问题是刚才技术团队的实践和管理方面的。如果是项目多了的话，存在一个横向的分类：前端、后端、App、大数据平台，他们之间的共同语言会更多；第二种就是分部门，Java开发部、安卓开发部等，大家没有归属感，项目很难去落地。还有一种方式：每一个项目有一个独立的团队，前端的、后端的每一个岗位都配一两个人，但来了一个新成员就没有人带。我不清楚您这方面有没有实践的经验跟大家分享？

蔡：这个问题问得很好。有米科技其实也经历过这样的一个阶段。

我们会把技术两个层，一个是针对业务的，一个是针对底层业务的，还有做内部写作优化的，就是所有项目组都可以共用的底层共有资源。在每一个业务线里有专门的技术团队，就分成两层，你可以理解为我们叫技术工程部是服务技术的，业务技术是服务业务的。

这里面当然也会存在你说的这个问题，因为每一个业务团队有各种各样的小项目，小项目里面怎么保证这里来了一个新人都没人带，有米科技的做法是支持、经验全部文档化，就少用语言等非标准化的方式来传播。

小团队里还有一个问题，就是说这个人、这个团队这个项目不行了，要失败了，那可能待不住了怎么办？这也是比较棘手的一个问题，无法避免的，除非是让他自然流失的情况下，如果你觉得这个项目不靠谱，你可以找另外的领导沟通，那个领导要你，你就可以过去了，如果发现说某一个小项目组的成员流动突然间往上涨，那可能就会考虑这个项目组的领导是不是合适了，或者说这个项目组是不是有存在的必要。

在项目管理这一块，尽可能让市场经济用脚投票。所以在新项目一定要有足够的准备和足够的自信才能去带一个项目，而不是随便想去自己做一个新的项目。这其实是另外一种鞭策，这几个人跟着你肯定是希望做出一定的成绩，而不是就看你人缘好，每天请我吃饭就跟着你干，这样的项目失败率就绝对高。脱离了市场，脱离了产品的项目，只是一味的人缘好、跟着干，这是不符合市场规律的。

Q4：你们有没有用到微服务？

蔡：有。有米科技内部主张不要过分强调太多的新兴技术的东西，我们整个策略还是取它这里面某一项技术好的一块。在技术上，有米科技是相对比较保守的。