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

2次阅读

共计 5604 个字符,预计需要花费 15 分钟才能阅读完成。

前言

史海峰,曾在神州数码、亚信联创长期从事电信行业业务撑持系统集成工作,参加中国移动、中国联通多个我的项目,具备丰盛的大型业务零碎研发施行教训。

曾在当当负责总体架构布局、技术规范制订和技术预研推广,参加多个重点项目的方案设计,在我的项目中对系统架构进行继续革新优化。负责技术委员会组织管理工作,挖掘最佳实际、推动技术革新、开源产品,组织内外部技术交换。

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

曾在贝壳金服负责小微企业生态金融服务产品布局、技术团队治理、零碎建设。

屡次加入业界技术大会,包含 ArchSummit、QCon、SACC、TOP100、SDCC、GITC、MPD、GIAC、CSDI 等,任讲师及出品人。

在声网开发者守业讲堂 • 第 5 期中,咱们特地邀请到了史海峰老师,以「 成为技术领导者,从技术到治理的必经之路 」为主题进行了分享。

本文基于演讲内容整顿,为不便浏览略有删改。


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 年后要达到什么程度?
  • 通过哪些伎俩达成?
  • 你的治理格调是什么?
  • 你的工夫怎么调配?
  • 你最罕用的治理动作是什么?
  • 你开过人么?对方是否承受?下次怎么开?
  • 没有你的话,团队是否失常运行?
  • 团队还有哪些改良空间?

05 问答环节

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

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

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

技术工程师不是流水线,不像拧螺丝那样有规范能够量化,因为每个人都有本人的施展空间,因而咱们考核其工作的时候,要从两个维度对待:第 1 点,考核是一个公司继续运行的必要机制,组织心愿本身倒退更好,为此而要求每个人可能一直进步。第 2 点,绩效考核的量化是肯定要有指标的,当然不见得是谋求代码量、bug 数等,咱们要尽量在不同的阶段看不同的后果,在不同的维度考核的规范不同,要遵从考核规范。从这个层面来说,这只是对一个阶段的工作成绩进行考核,而不是给集体打标签。

浏览更多

1)要理解更多对于声网 SDK 和其余应用案例,请看这里的开发者指南:

https://www.agora.io/cn/community/blog?categoryId=119&offset=0

2)理解咱们的更多 demo 和案例:

https://www.agora.io/cn/community/demo

3)还能够退出声网 RTE 开发者社区和咱们一起探讨交换:

https://www.agora.io/cn/community/

正文完
 0