写点什么

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

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:191043

评论 1 条评论

发布
用户头像
[嘉宾介绍:高泽华,TGO 困鹏会(上海)会员] 纠错
2021 年 01 月 08 日 11:49
回复
没有更多了
发现更多内容

技术人员如何写好周报

猿话

超越身边80%的人,其实没有你想象的那么难

架构精进之路

认知提升 成长笔记 日更挑战 28天写作

Python列表对象入门

老赵

28天写作

APICloud AVM多端开发 |《生鲜电商app开发》项目源码教程

APICloud

前端开发 移动开发 APP开发 APICloud

9. 细节见真章,Formatter注册中心的设计很讨巧

YourBatman

Converter ConversionService Formatter

架构师训练营第十三周笔记

李日盛

笔记

训练营第十三周作业

大脸猫

从姚安娜出道说起

三只猫

28天写作 社交泛娱乐

也谈Python编码格式

ITCamel

Python 编码格式

技术创新是PC市场发展基石,英特尔占据明显领先优势

intel001

【得物技术】代码覆盖率原理与得物app实践

得物技术

测试 原理 代码 得物技术 覆盖率

区块链2021狂想曲:迎接以技术为名的春天

脑极体

我们为什么打比方

石云升

28天写作 确认偏误 打比方

架构师第八周总结

Geek_xq

电商网站商品管理(二)多种搜索方式

escray

elasticsearch elastic 28天写作 死磕Elasticsearch 60天通过Elastic认证考试

一文带你学会AQS和并发工具类的关系

伯阳

AQS java 并发 ReentrantLock 多线程高并发 lock锁

案例研究之聊聊 QLExpress 源码 (七)

小诚信驿站

聊聊架构 规则引擎 28天写作 QLExpress源码 聊聊源码

安卓开发实战!闭关在家37天“吃透”这份345页PDF,成功定级腾讯T3-2

欢喜学安卓

android 程序员 面试 移动开发

使用 kubectl-rabbitmq 部署和运维 K8S 上的 RabbitMQ 集群

郭旭东

RabbitMQ kubectl kubectl plugin

[5/28]产品运维保障体系的质量实践

俊毅

架构师第8周作业

Geek_xq

矿机挖矿软件系统开发|矿机挖矿APP开发

开發I852946OIIO

系统开发

在GitHub中向开源项目提交PR的过程

worry

GitHub pull request

2021字节、华为、滴滴Java内部面试题(含答案),新鲜出炉!

比伯

Java 编程 架构 面试 程序人生

阿里表哥甩我一份Redis笔记,看完还进不了阿里让我卖豆腐去

互联网架构师小马

Java 数据库 nosql redis 面试

PHP转JAVA开发30分钟实战攻略

dothetrick

Java php

华云大咖说|企业混合云构建之道

华云数据

云计算 桌面云

二本学渣考研失败,为什么Android要采用Binder作为IPC机制?已开源

欢喜学安卓

android 程序员 面试 移动开发

为什么印度不会成为世界工厂?

JiangX

印度 28天写作 世界工厂

使用nodejs和express搭建http web服务

程序那些事

HTTP nodejs 异步IO 程序那些事 web服务

这份30天获得40k+星,多次登上榜首的算法宝典,带你刷爆LeetCode

Crud的程序员

程序员 架构 算法

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