写点什么

高泽华:从初创到上市,深挖我在声网的管理“套路”

2021 年 1 月 08 日

高泽华:从初创到上市,深挖我在声网的管理“套路”

在 2020 年 12 月 19 日举行的 GTLC · 深圳站上,声网 Agora 合伙人兼技术 VP 高泽华登台演讲,从声网做技术管理的实践出发,深入浅出地分享了技术管理的一些经验心得,着重介绍了管理中一些常见的难点和解决对策。本文为演讲内容的整理。



嘉宾介绍:高泽华,TGO 鲲鹏会(上海)会员,声网 Agora 合伙人兼技术 VP,音频编码与抗丢包技术专家,设计开发声网 NOVA/SOLO/SOLO-X 系列语音编解码器。先后在士兰微电子、摩托罗拉、虹软科技,YY 语音负责音频系统设计与架构。2014 年加入声网,负责音频、视频、工程管理和客户交付与服务等方面工作。


大家好,我是来自声网的高泽华,目前主要在负责声网音频技术的相关管理工作,很高兴能在 GTLC 全球技术领导力峰会和大家做一些分享。


在声网技术团队的搭建过程中,我相继参与过技术、交付、服务、销售、运营、HR 等方向的工作,也因此逐步建立起了有关管理工作的全局性视角。所以在今天,我想从这些经历出发,与大家探讨技术管理和业务发展之间的关联,也谈谈对技术管理的一些看法和心得。


进入正题之前,我想先介绍一下声网的管理文化,以供大家参考。声网是一家技术导向型公司,我们的 CEO 赵斌是一位管理经验丰富的大咖,早年也曾是欢聚时代(YY)的 CTO。他对声网的技术管理文化建设工作有两大主要要求:


第一,弘扬极客文化。


我们内部人员都以极客精神为荣,并且有着两个准则:永远希望自己可以做到最好,同时,也永远认为自己做不到最好。这个看似矛盾的说法,其实自有其闭环逻辑:一旦你开始自我满足,也就失去了后续的上升空间,因此难以成为该领域的绝对专家。


第二,坚持基于谷歌合弄制的组代表文化。


这里我稍微解释一下“组代表”的意思。所谓“组代表”,是指不要试图通过单一角色管理执行工作取得成绩,而是充分激发各行业各领域专家的创造性,帮助大家最终达成一致并取得更好的成果。


2020 年 6 月 26 日,声网成功登陆美国纳斯达克,股票代码为“API”,成为“全球实时互动云第一股”。我们不禁会想:是什么参与并造就了声网今日的良好发展态势?我相信,无论答案有多少个,管理文化一定占据了其中相当重要的位置。


可是,站在一名技术管理者的个人角度看,即便文化再优秀,也和实践存在着不小的差距。所以接下来,我想结合自己在声网内部的一些管理实践经验,重点探讨技术管理者可能遇到的难点及相应对策。

四大难点,锚定了技术管理者的价值所在


我们先总结一下,技术管理者一般会遇到哪些困难。在我看来,大概可以分成四个维度:


  1. 技术开发周期长

  2. 交付不可预知

  3. 效率评估难

  4. 缺少长期视角



技术开发周期太长,这个问题会在大型项目里反复出现。有追求的技术人员,可能希望用几年时间来完成一个大项目,因为周期相对较长,导致交付情况往往不可预知。加之一些可能出现的不可预测性问题,管理者很难对项目的可行性进行评估。


如何保证交付效率,同样是个沉重的问题。许多岗位都有自己的交付评估标准,比如,销售可以用营收衡量,市场可以用流量和点击率来衡量,服务可以用服务度满意来衡量,但技术工作则很难界定衡量标准。


最后,许多技术人员缺乏长期视角。一般情况下,大家能搞清楚一天、一周或一个月的计划,但通常不做一季度、一年或更长远的规划或打算,这个问题在个人发展维度反应的比较明显。


在当前的国内大背景下,这些难点导致很多公司和团队在技术方面的投入越来越少,技术结果的交付变得越来越困难。可能在贸易、销售、运营、市场、工厂管理等方面,都积累了很多经验和成绩,但在“技术成果转化”这个问题上,还做得远远不够。


比如,国内的专利数量越来越多,但将技术转化成价值,并且在世界级市场中取得认可的公司并不多。


一些公司通常会先思考“技术能给业务带来哪些收益”。如果想不清楚,就很难在技术方面有所投入和作为。


因此,如何解决上述四类问题,成为了值得每一个技术管理者认真思考的命题。

规划、拆解、筛选、众议,解决管理难题


根据我的经验来看,要解决以上管理难题,可以从规划、筛选、拆解、众议等四个方面入手。



首先,我们要做好规划。技术管理者需要具备长期的视角,尝试为自己或团队思考:一个季度内要做什么、一年内要做什么,以及未来三年内要做什么。然后,尝试去思考目标应该如何拆解、落地并交付。如果失败了,应该如何调整。


很多人会说,两三年后的事儿,太难预测了,就像新冠疫情,多突然!所以长期的规划是没有办法精细化的。事实上,计划虽有变数存在,但不代表不能执行。


越长远的规划,越难执行,所以才需要我们在后期进行调整。因此,我要求自己和团队必须有这样的思考:我们到底要在未来一年、两年、三年、十年的周期内,落地哪些工作,实现哪些成绩?


第二,要做好目标拆解。在宏大目标面前,大家通常难以找出合理的阶段性执行节点,也没有办法评估成本的消耗。所以,很多公司干脆不做拆解,选择“摸着石头过河”。


我们的方案是,团队和其管理者要集思广益,共同完成拆解工作,将大目标分解成若干个小目标,细致到一个季度、一个月、一周内可交付的内容,使得每个交付变得可衡量,最终促成团队实现“小步快跑”的发展节奏。


纵观整个行业,“小步快跑”的模式已经被应用于多个领域,它能够保证未来结果始终处于可控范围,将“不确定性”变成“确定性”。


第三,做好筛选。筛选的意义在于让自己的目标方案变得更清晰,对业务成绩有一个 60 分或 80 分的预估。很多人对自己的人生规划都比较清晰,比如:今年一定要结婚、买房,因此会主动降低其他事项的优先级。其实工作也是同样的道理,要找出优先级最高的工作,然后首先去攻克它。


那么如何找到最重要的工作呢?有一项判断标准可以略作参考:“能否用一句话将该工作描述清楚”?如果不能,就说明自己思考得还不够,因此无法提炼出真正的关键点。


另外,在执行期间,这样的“一句话描述”应该是始终不变的。如果每当有人问你,你的表述方式都不太一样,就说明自己的思考还在发生变化,对该工作的定义还未最终成型。


一旦这些工作做好了,我们通常就能交付一份好的规划。但要保证规划正确,还存在许多来自各方面的挑战。


比如,因为视角限,导致规划不全面。技术人员通常在自己擅长的领域内有绝对的权威,有时会忽视他人的视角,导致计划存在问题。最理想的情况是,汇聚各领域各视角的专家,一起讨论其中的规划、拆解是否正确,以便形成全局的视角。这就回到了我们的研发管理文化:坚持基于谷歌合弄制的组代表文化。


当然,集思广益也有问题存在:参与的人太多,可能会导致结果和预期完全不同,甚至,一个讨论的结论和最初的立意就完全不一样,完全超出了技术人对交付内容的预期。但这也恰恰证明了讨论的重要性。


最后一点,叫做“众议”。与上面所谈的问题不同,这里更聚焦组织问题。比如,很多专家和技术大牛聚在一起,虽然目标一致,但奉行的方法论可能完全不同。


有时,大家对同一件事的解读也存在诸多偏差。我常常在一些场合发现:不同层级和背景的人,在同一个目标下讲着相同的方法,却使用着不同的话语体系,导致双方很难进行有效交流。这时,技术管理者其实等于半个“翻译人员”,你要能够听懂两方的“语言”并进行快速翻译,提高双方达成共识的效率。


另外,即便大家的目的、方法和解读都一致,但是认知却可能出现偏差,在部门、专业、文化等不同维度都存在这种情况。如果你经常对比中美之间的巨型企业、互联网企业或传统企业,就会发现,无论是执行层还是非执行层,都会出现这种矛盾。这些都会阻碍“众议”达成最佳结果,所以我们必须结合具体情境,想尽一切办法来解决。



从凝聚力到决策力,管理者必备的五大能力


上面谈到了具体的解决方法,对于技术管理者而言,想要完全地解决问题,还要加强以下五个方面的能力培养。


第一个是凝聚力。这是技术管理者必须具备的能力,在遇到困难的时候,能够召集大家一起讨论解决问题。


第二个是技术能力。管理者必须紧跟技术的脉搏,一旦和技术产生了脱节,就难以跟技术人员进行良好的沟通。


第三个是产品能力。这需要技术管理者做好技术人员和用户的桥梁,主动去走进用户,了解熟悉他们的体验,比如发现编码器和前后处理的技术、一项 AI 技术会如何改善用户体验等等。对于技术而言,哪怕只是很细微的部分,只要有好的产品就值得被重视。


第四个是影响力。如果部分人或者所有人反对自己的观点,要有能力让他们按照你的想法去做,尤其是新时代的 90 后、00 后,通常很难完全支持你的决定,影响力就是让他们不支持你,也会按照你的决定去操作。



第五个是决策力。在召集大家进行讨论后,如果没有很好地达成共识,甚至出现管理者的决定和大部分人都不一致,这时需要进行冷静的分析评判,作出众议的最终决定。


对于影响力的部分也会存在一些混淆,比如影响力如何跟决策力和领导意识进行区分?通过影响力要做决策的时候,和普通的一人拍板有什么区别?


在我看来,这些方面需要加强注意。首先要向技术人员交代足够的背景,不能在大家信息不一致的时候作出决策。


其次要让每一位成员充分发言,确保每个人都有发表自己观点的机会,而不是先抛出一个观点,让大家按照自己的观点讨论,一定让大家提出自己的想法,然后推动大家的讨论。


接着要进行充分授权,什么算是授权?其实就是在大部分时间让技术人员自己选择做尝试,就算知道是错的也让他尝试,保证在试错之后会进行正确的选择。


上述提及的这些方面都做到了,就可以对技术管理的标准做一些评估,在我看来,技术管理者要交付的内容可以体现在以下三个方面。


首先是要有一个阶段性的产品,可以进行评估的内容,比如一个 Demo,一个 SDK,一个文档等等。


其次是一个可执行的路线图,比如这周做什么,下周做什么,这个季度做什么,下一个季度做什么,下半年做什么,都要有清晰的可执行路线。


然后是打造一个可交付的团队,确保团队能够实现自运转,就算是技术管理人员离开之后,技术团队也能在一定程度上实现正常运转。



最后来总结一下,我认为技术管理是一种修为,是在不断提高技术管理能力的同时,去更好地认识自己,找到自己的最佳状态。这个过程除了帮助技术管理人员本身,也可以解决生活当中的问题,甚至还可能会解决技术人员的 35 岁危机。


以上就是我的分享,欢迎大家可以和我交流讨论,谢谢大家!

2021 年 1 月 08 日 10:191099

评论 2 条评论

发布
用户头像
[嘉宾介绍:高泽华,TGO 困鹏会(上海)会员] 纠错
2021 年 01 月 08 日 11:49
回复
感谢指正,已修改~
2021 年 02 月 20 日 19:30
回复
没有更多了
发现更多内容

架构师训练营第三小结(9.28-10.4)

zjzj2017

架构师训练营第 1 期第 4 周作业

好吃不贵

极客大学架构师训练营

Python 为什么不支持 switch 语句?

Python猫

Python 编程

Redis-技术专题- 热点Key如何解决

李浩宇/Alex

架构师训练营第三周课后作业

Gosling

极客大学架构师训练营

四面阿里成功定级P6,月薪36K,分享面经(含面试题答案)

Java成神之路

Java 阿里巴巴 程序员 算法 编程语言

架构师训练营第三周学习总结

Gosling

极客大学架构师训练营

架构师训练营第四周作业

尹斌

入行架构师之前,这7项技能你要先了解一下

Java架构师迁哥

深入剖析go中字符串的编码问题——特殊字符的string怎么转byte?

Gopher指北

go golang 后端 string utf-8

Hazelcast IMDG 带你瞬间进入内存计算的时代

张磊

分布式计算 内存管理 分布式缓存 分布式内存网格

月薪60k的Java开发在阿里是什么级别?对技术能力有哪些要求?

Java成神之路

Java 阿里巴巴 程序员 面试 编程语言

实用威胁建模指南(一)

亚伦碎语

敏捷 安全设计 系统安全 #威胁建模

LeetCode题解:226. 翻转二叉树,递归,JavaScript,详细注释

Lee Chen

LeetCode 前端进阶训练营

第四周作业

极客大学架构师训练营

spring-boot-route(九)整合JPA操作数据库

Java旅途

Java Spring Boot jpa

爆赞!这份《Java核心宝典》绝对是面试复习的最佳选择

Java架构之路

Java 程序员 面试 编程语言

极客时间架构 1 期:第 3 周代码重构 - 学习总结

Null

Redis-技术专题-基础介绍

李浩宇/Alex

极客时间架构 1 期:第 3 周代码重构 - 命题作业

Null

架构师训练营第三周作业(9.28-10.4)

zjzj2017

有这些要素,架构才完整

北风

架构 架构师之道 架构方法

架构师训练营第 1 期第 4 周学习总结

好吃不贵

单例模式

魏小龙

如何高质量学习与正确运用设计模式

木香丘

学习 设计模式 实战

Serverless 多云解决方案 Malagu

木香丘

云计算 Serverless 架构 云原生 Malagu

Malagu 框架介绍

木香丘

云计算 开源 Serverless 架构 框架

缓存服务-技术专题-解决方案

李浩宇/Alex

架构师1期-代码重构作业

ltl3884

极客大学架构师训练营

架构师训练营第四周学习总结

尹斌

发几张国庆的照片

亨利笔记

容器 k8s Harbor 镜像

混合云之争的开端与终途

混合云之争的开端与终途

高泽华:从初创到上市,深挖我在声网的管理“套路”-InfoQ