史海峰:成为技术领导者 从技术到管理的必经之路丨声网开发者创业讲堂 • 第 5 期

前言

史海峰,曾在神州数码、亚信联创长期从事电信行业业务支撑系统集成工作,参与中国移动、中国联通多个项目,具有丰富的大型业务系统研发实施经验。

曾在当当负责总体架构规划、技术规范制定和技术预研推广,参与多个重点项目的方案设计,在项目中对系统架构进行持续改造优化。负责技术委员会组织管理工作,发掘最佳实践、推动技术革新、开源产品,组织内外部技术交流。

曾负责饿了么技术创新部产品研发团队,完成多个创新性业务项目及技术产品。

曾在贝壳金服负责小微企业生态金融服务产品规划、技术团队管理、系统建设。

多次参加业界技术大会,包括ArchSummit、QCon、SACC、TOP100、SDCC、GITC、MPD、GIAC、CSDI 等,任讲师及出品人。
在声网开发者创业讲堂 • 第 5 期中,我们特别邀请到了史海峰老师,以「成为技术领导者,从技术到管理的必经之路」为主题进行了分享。

*本文基于演讲内容整理,为方便阅读略有删改。关注「声网开发者」公众号回复关键词「JT0924」,即可领取完整版 PPT。

01 技术领导者的挑战

1、Manager 和 Leader

创业有不同的分工和维度,有的人可能是单打独斗,而有的人可能在初期就已经组建了团队。在技术维度也是如此,有的公司可能一开始就有一定规模的团队,这种情况下资源是比较充裕的,解决问题的效率就会更高。而对于一切从头开始的技术团队来说,这个过程就很艰难了。在这个过程中,leader 的能力就显得尤为重要。如果在没有做过 leader 的情况下组建创业公司会面对很多问题,比如怎么分配任务和提要求?是否选择新技术?产出不给力的情况下加班有用么?对于负能量坏消息,说还是不说?上级和业务到底想要什么?团队内部问题怎么解决?等等。

可见,要想做好一个 leader 是存在很多困难的,那么如何解决这些困难,顺利带领团队走向成功呢?首先要明确 manager 和 leader 有什么区别,有很多同学在刚开始的时候并不能理清两者的关系。区别具体如图 1 所示,简单来说,做 leader 就是要让其他人能够主动跟随,而不是仅仅因为级别,但 manager 则是级别驱动的。当然,这并不代表管理是错误的,这只是一个概念的区分。

■图 1

2、什么人不适合带团队

了解了 manager 和 leader 的区别后,我们就要思考什么样的人不适合带团队,每个人都有自己的特点,不适合带团队的人主要具备以下几种特质:

  • 不擅长、无意愿沟通
  • 喜欢单打独斗、不善于协作
  • 自我认知偏差
  • 以自我为中心,我行我素,性格偏激
  • 技术牛但讲不出来
  • 优柔寡断、心太软
  • 唯技术论
  • 德不配位
  • 人格魅力不足

3、什么人适合带团队

既然有的人不适合带团队,为了团队的发展,我们就要选择适合的人来做这项工作,那么一个成功的技术领导者需要什么样的特质呢?具体包括以下几种:

  • 承担责任,不找借口
  • 追求卓越,高标准要求
  • 平等、服务心态
  • 负能量自己消化
  • 习惯不完美
  • 快速决策
  • 以德服人
  • 守正出奇

4、使命是什么

明确了 leader 的特质之后,还要了解团队的 leader 的使命,我总结下来就是:成就公司,成就团队。那么带团队需要做哪些事情呢?对于一个技术团队来说,基本上就是管人和理事。对于个体来说,管人就是选用育留;对于组织来说,则是要有很强的组织效能。理事包括产品规划、项目管理、系统架构和技术规范。这些都是体系化的工作,要把它们都做好很不容易,很多公司都只在某些方面达到了标准,但只要实现了最终业务,就可以忽视掉其他问题,因此要习惯不完美。


02 从技术到管理

1、技术 vs. 业务

一般来说, leader 是团队的技术代表,但在很多情况下 leader 面对的问题不是技术,而是业务,因此 leader 需要明确自己的位置。技术 leader 要把自己作为一个技术的商人来推销自己的技术,使客户理解其技术价值,进而为该技术付费。因此,我们要首先了解技术跟业务的关系,具体如下:

  • 技术为业务服务,业务战略决定技术战略,业务架构决定 IT 架构
  • 技术支撑业务的前提是业务需求明确
  • 技术驱动业务的前提是技术理解业务,要使业务信任技术

2、康威定律

康威定律其实是一篇文章,大家感兴趣可以去搜一下。这篇文章介绍了很多观点,但是其中有一句话是比较出圈的,所以就是成为了一条定律。这条定律说的是,设计系统的组织,最终产生的设计等同于组织之间和之内的沟通结构。因此,设计系统的组织,最终产生的设计等同于组织之内、之间的沟通结构。假设有四个部门,常见的做法是将系统分为四个子系统,分别提供给这四个部门使用,然后将其再串联起来。如果你想打破这种模式,就得先调整组织,因为需求都是组织产生的。这里给大家展示图 3 的漫画。漫画中的人物正在思考,根据康威定律,系统架构是由组织决定的,而组织是人力资源决定的,原来是人力资源部在设计组织架构,最终决定了系统架构。虽然是个笑话,但也有一定道理。

■图 3

3、系统 vs 团队

既然理解了康威定律,那么系统和团队有哪些异同呢?如果你的系统设计经验比较多,做技术的时间比较长,就会有一个系统的概念,发现团队也是一个系统,只不过组成成分是不同的,两者的关系可以总结为以下几点:

  • 团队是由人组成的,而系统则由软硬件组成。但是每一个人都有自己的职责边界和自己的功能,所以这是有共性的。
  • 系统包括 CAP 原理、分布式、自适应等理念,相对应的团队也有人月神话,自组织、补位等说法,因此两者是比较接近的。
  • 系统强调高可用、稳定性,因此需要做冗余、备份,团队也是一样的,人员也有 A/B 角之分。
  • 系统有规范、设计原则,相应的团队也有流程、机制、文化。
  • 系统需要监控,而团队也有自己的管理运营数据。虽然某些团队的数据可能有点少,但是我认为不管是什么数据,有总比没有强。
  • 系统有 MQ、SOA 或者 RPC,而团队之间也需要沟通协作。
  • 不管是团队还是系统,它们都是有生命周期的。团队的生命周期不是指人的生命周期,它由企业的生命周期决定。
  • 系统是死的,但人是活的,所以系统是确定的,但人是不确定的,不确定不是坏事,也可能超常发挥。

4、技术专家/架构师 vs. 技术领导者

作为一个技术专家或者架构师和做一个技术的 leader 有什么关系呢?主要包括以下几点:

  • 面对的对象是不同的。技术专家更多的是对事, leader 更多的是对人。
  • 面对的风险都是不确定的。不确定性是世界的常态,但是我们需要用确定性的方式进行收敛,能够让不确定性变成可控的方式。不管是人还是系统,都是一样的,只不过系统没有那么大的弹性,所以很多时候系统更可信。但是这不代表人不可靠,人在极端情况下能够做出来极端的事情,可能创造奇迹,也可能带来非常大的破坏。
  • 责权是不同的。leader 要做资源的分配和奖惩,但是技术专家或者架构师,更多时候是靠自己的影响力带领同事一起做任务
  • 标准衡量任务的成功与否。这要求技术和 leader 要有成熟的技术解决方案和领导力。

5、组织发展对组织管理的要求

了解了专家和 leader 的异同之后,我们再来看一下组织需要什么样的 leader。刚才说到企业有自己的生命周期,所以它在不同的阶段有不同的要求,图 4 中列出了几张图,从中能看出不同的规模,对于管理的要求有巨大的差别。

■图 4

换句话说,几个人的小团队和十几万人的团队, CEO 的管理能力要求是不一样的。此外,大家要对组织的发展周期有一个概念,作为组织的 leader,在组织从成长到成熟再到发挥状态的过程中,不同的阶段其发挥的作用是不一样的,leader 也不能解决所有的事情。


03 领导力进阶

1、能力结构分层

如何提高 leader 带领团队的水平呢?首先各层次的管理要求的能力是有区别的,如图 5 所示。初级的管理人员一般要求的是业务知识/技能,中级的管理人员则更多开始要求企划力,高级的管理人员的要求是有先见性。先见性是指看得更远,能够预想未来的事情。所以公司的领导可能很多时候都在看十年以后的事情,眼前的事很早以前就已经决定了,除非遇到异常情况需要紧急处理。

■图 5

技术条线也是一样,一开始基层看重的是工程能力、解决问题的能力,对于抽象能力、规划和决策能力的要求是没有那么高的,越高级别的管理人员对于后面提到的这些特质的要求越高。管理人员需要靠团队,最终能快速决策,找到解决问题的路径,这些是综合能力的体现。带团队(做技术也一样)的路一定是越走越窄的,因为要求越来越高,能走出来的那条路越来越窄。

2、领导力成长

关于领导力的成长我分成了四个部分,那就是心态、套路、聚焦和成长,接下来我将对这四部分进行详细的介绍。

1)心态

首先如果没有一个良好的心态,那么当 leader 的压力就会显得非常大,因为以前只需要管好自己就可以了,现在的情况则不同,成员需要 leader 的领导。

要想拥有好的心态,就要敢于担当,能信任成员,能放权,能够接受缺憾,关键时刻能够做取舍,能够从小的地方发现大的问题,能够果断决策,做到真诚、平等、坚持。这些看起来有的时候是心态,其实也是人所展现出来的优良品质,它能够让别人感受到 leader 的领导力,进而愿意跟随。如果 leader 自己的心态没有调整出来,那么成员是会感受到的,如此下来,他们可能会放大 leader 身上的小缺点,对于错误的容忍度也会降低。

2)套路

套路就是一些管理动作,做事情一定要有一个相对来说比较确定的节奏和套路。不管是人才盘点,还是晋升、激励、例会、个人目标和不断的持续反馈,又或者是复盘、总结等都是基本套路,如果把这些变成在管理周期之内该做的事情,按部就班地进行,一切都会变得理所当然。一个团队需要组织,也需要很多内部的固定机制来确保成员的信息互通,确保大家的理解和认知对齐目标,使其能够不断地优化解决,以提高自己的整体的水平。

更进一步来说,还要更好地关注业务,关注组织层面的工作,以及技术的方向、资源的分配、跨组织的协调、原则和规矩等。将这些管理套路向下贯彻,使下一级别的管理者复制能力,就能把团队带领得更好。

3)聚焦

聚焦是指就是基本动作完成之后,还要有一些关注点。关注点一方面是各层次的信息透明度,也就是要公开透明,但是一般情况下信息传递一定是有衰减的或者说会有噪音产生,在这个过程之中,要确保哪些信息能触达到哪些层面、哪些信息没有必要。比如好的信息应该让所有人都知道,不好的信息就自行吸收消化,让成员知道自己该知道的就可以了。另外,还要做好中继,就是要放大重要的事情,并向团队反复强调。接下来是穿透,刚才说了很多套路,但有时候要不按套路出牌,能够把层级打穿,看到最前面发生了什么。业务价值也是很重要的一点,业务价值有它的合理性和业务模型,人也是一样,对于不同职责的人,要求是不一样的,要关注人性化层面的问题。我们还要保证时间效率,管理好自己的时间并不断优化。最后就是包容,要换位思考,不要拿自己的标准去要求所有人,因为一般来讲, leader 的能力比大多数人强,因此会很容易发现别人的缺点,而忽视优点,这样的做法是不合适的。

4)成长

成长的关键在于实践,对于带团队,不管是否有一个很成熟的管理理论体系,最终还是要实践出真知,再好的理论也必须拿出成果来证明。在成长过程中会遇到很多问题,刚才提到了不确定性,我认为我们要接纳不确定性、应对不确定性。作为一个 leader,要比一般的团队成员面对更多的不确定性,此时要成为一个团队的表率,处理这些未知的情况,这就意味着要不断成长。我们可以多借鉴行业前辈积累的经验,这里我给大家推荐了一些书(如图 7 所示),当然不是说所有书都看,每个人各取所需。

■图 7

很多同学会觉得关于技术管理好像没有相关的图书,好像也没有一个专业叫技术管理,但其实技术的管理在行业内是存在一些积累的,作为一个 leader 你一定要去了解这些信息,这些东西是能够跨越时间的,因为人没有变,行业最基本的逻辑也没有变,虽然技术天翻地覆了,但是技术管理这件事已经经过了几十年,所以有很多东西是可以去借鉴学习的。


04 总结

我今天分享这么多,最后提一些问题供大家思考。如果对于下面的问题大家都能有明确的答案,那么相信你距离更为一个优秀的团队 leader 也不远了。

  • 怎么保证交付质量?
  • 怎么提高团队满意度?
  • 自身还有什么不足?
  • 1 年后要达到什么水平?
  • 通过哪些手段达成?
  • 你的管理风格是什么?
  • 你的时间怎么分配?
  • 你最常用的管理动作是什么?
  • 你开过人么?对方是否接受?下次怎么开?
  • 没有你的话,团队能否正常运转?
  • 团队还有哪些改进空间?


问答环节

1、作为一家公司的空降 CTO,如何带领一二百个人的技术团队?

从我的角度来讲,首先你要要想明白这个公司为什么要找一个空降的人?为什么要找你?你要解决什么问题?现在这个团队处于什么样的状态?这个团队是不是你能够影响的?或者说其中是不是有一些组织问题是你要解决的?这几方面是一开始就要想的。最重要的一点就是信息,你做任何判断都要充分了解多维度的信息,这样才能确定你的判断和分析是对的

2、作为技术管理者,如何考核或管理程序员的结果和产出?

技术工程师不是流水线,不像拧螺丝那样有标准可以量化,因为每个人都有自己的发挥空间,因此我们考核其工作的时候,要从两个维度看待:第 1 点,考核是一个公司持续运转的必要机制,组织希望自身发展更好,为此而要求每个人能够不断提高。第 2 点,绩效考核的量化是一定要有指标的,当然不见得是追求代码量、 bug 数等,我们要尽量在不同的阶段看不同的结果,在不同的维度考核的标准不同,要服从考核标准。从这个层面来说,这只是对一个阶段的工作成果进行考核,而不是给个人打标签。

推荐阅读
相关专栏
开发者实践
137 文章
本专栏仅用于分享音视频相关的技术文章,与其他开发者和声网 研发团队交流、分享行业前沿技术、资讯。发帖前,请参考「社区发帖指南」,方便您更好的展示所发表的文章和内容。