
书名:《技术领导力:程序员如何才能带团队》
作者:周明耀
读完:2021-11-21 · 微信读书
这本书讲程序员怎样从写代码走向带团队。内容从技术领导的定义讲起,经过领导者的品质、个人职业发展、组建和管理团队,再到产品开发流程,最后落到系统架构工作上。
下面是我的划线,按主题整理。
一、技术领导是什么
管理是一种实践,其本质不在于“知”而在于“行”。(Management is practice. Its essence is not knowing but doing.)
——彼得·德鲁克(书中引用)
关于技术领导,有人把这个概念定义成一种职位,比如技术经理、技术总监。有人把它引申为技术上的洞察和优势。我则认为,如果你有能力把技术相关的资源有效地组织起来并完成一件有价值的事情,例如,发布一款产品,做一个项目,那么你就是技术领导者,或者说,你具备了一定的技术领导力。
简单来说,技术领导可能是个管理岗位,也可能不是,不重要。重要的是你要利用技术资源和团队资源把事情做成
让正确的事情,持续发生才是最重要的。
管理看起来套路很多,其实最终都是人性和策略,理解人性,善用策略,就能做好管理
一个技术领导,更多是通过对技术领域的探求打磨自己的技术敏感度和技术决策力。
如何用好当下的技术解决现实中的问题,什么阶段引入什么技术,什么时候重构,什么时候重写,如何利用技术驱动产品,如何构建技术平台……这些都是技术领导需要思考并确定的问题,这些都将依托你强大的技术背景
❑ 深入理解一门或多门编程语言
❑ 深入理解多种流行的框架
❑ 系统架构能力强,拥有复杂系统的设计经验
❑ 积极跟随开源社区
❑ 积极了解业界技术发展
❑ 沟通能力强、情商高
❑ 有产品意识,不是技术迷
❑ 会带人,服从领导,责任心强
❑ 会写专利
❑ 再会点别的更好
❑ 随叫随到、工资不高
一家企业能够生存,一定是业务开展得不错,作为技术团队管理者我们需要做到技术与业务的融合,需要保证我们的付出可以为企业带来长久的利润。只有成为“技术的业务派,业务的技术派”,才能让技术引领业务,并创造价值。这其实也是技术管理者成熟的标志。
……优秀的技术管理者,技术在前,管理在后,并不是说两者有太大的轻重差异,而是你需要花费70%的时间在技术上,只能花30%的时间在管理上,但是你需要用这30%的时间做完100%的管理工作。
二、领导者的方向、担当与品质
……管理者最重要的是给团队指明方向,包括技术方向和业务方向,还有个人成长方向。与下属相比,领导者的优势不只在于他的专业能力,还在于他的眼光和胸怀。既然选择做技术管理,你就要有成就他人的心胸,同时还要有超出一般人的眼界,能够给予团队正确的方向。同时,要保持对技术的兴趣,多关注新技术的发展,否则你很难在重大的技术决策上做出正确的决定。
我认为克服恐惧最好的办法理应是:面对内心所恐惧的事情,勇往直前地去做,直到成功为止。
——罗斯福(书中引用)
电视剧《长沙保卫战》中有一段对话,参谋长对薛岳将军说:“你若下地狱,我绝不上天堂。”这也是我在团队遇到严重挑战的时候,对所有成员说的第一句话。想做成事情,你或者你的核心下属,必须勇于站出来。
科学所以叫作科学,正是因为它不承认偶像,不怕推翻过时的旧事物,很仔细地倾听实践和经验的呼声。
——斯大林(书中引用)
作为一名技术团队管理者,你要做的是比别人更早接触新技术,更深入地理解系统架构,全面提高管理团队所需的方方面面的能力,而所有这些都需要勤奋
你在做这些决定之前,有没有做足充分的技术调研、产品调研工作,能不能尽量详细地说清楚已有框架、产品的实现原理、优缺点、是否适用于你的产品场景等,这些都是前期技术调研的工作,也是体现我们脚踏实地做事的一个环节。
庆祝你的成功,在失败中寻找幽默。别太把自己当回事儿,你放松,你周围的人才能放松。享受乐趣,并始终保持激情。
——山姆·沃尔顿,沃尔玛创始人(书中引用)
我觉得一个仔细的人,他一定也是一个善于观察的人,而善于观察、思考其实也是一个团队领导者所必须具备的品质,否则他的团队一定会在某一阶段或者一直处于混乱状态。
技术面对的是系统性问题,需要的是逻辑思维能力,是智商,而管理需要面对的很多是非逻辑思维能力,是情商。系统问题需要智商,而人是活的,你要理解人,就需要情商,情商是什么?我个人理解,情商就是如何站在别人的角度看问题。
最好的领导,思路敏捷而清晰,做事务实而高效,永远没有废话,永远雷厉风行。和他共事,绝对不会轻松。他不会讲段子哄你干活,他也不会笑眯眯地安抚你的情绪。每周的例会,是一场例行考试,每个人都小心翼翼、如履薄冰。如果顺利,他会扔个梗让大家笑一笑,然后收起笑脸继续挑战你;如果不顺利,他会打断你,生生把你拍在墙上,毫不留情,但有理有据。从此,你再也不敢造次。他不会掩藏不悦,他对愚蠢的忍耐度很低,他说变脸就变脸。如果被他认定为“不求上进”,你在他眼中就成了废物,从此不会给你好脸色。有时候,你会觉得,他简直是个刻薄冷酷的资本家,是个不近人情的吸血鬼。但事实的真相是:评判一个管理者的好坏,从来不是看测验的民意,而是看输出的成绩。良好的干群关系和群众基础,有助于达到目的,但却不是最终目标。一个好的经理人,就是要做出好成绩,对老板负责;一个好的CEO,就是要做高利润或股价,对股东负责。这才是职业的素养,这才是商业原本的逻辑。
李嘉诚教育子孙,做人的最高境界是“仁慈的狮子”。仁慈是本性,但单靠仁慈,还无法成功。要有狮子的力量,才能赚钱养家,才能保护亲人,才能反抗欺压。“做个好人”和“做个好的管理者”,其实并不冲突。
三、个人成长与职业发展
皮亚杰(瑞士)将儿童和青少年的认知发展划分为四个阶段:感知运动阶段、前运算阶段、具体运算阶段和形式运算阶段。他认为所有的儿童都会依次经历这四个阶段,新的心智能力的出现是每个新阶段到来的标志,而这些新的心智能力使得人们能够以更复杂的方式来理解世界。
工作外:除了工作以外,你可以提前几年为自己未来的发展方向布局,比如你的目标是成为CTO,那你要明白,当前你的朋友圈可能没有这样职位的人,或者没有可以让你走上这个位置上的人,那么你需要找机会去结交这样的人,或者是那些大企业的领导,也许,将来哪一天目标就实现了呢?目标总是要有的。你可以选择加入一些高管俱乐部,或者知识分子组织,比如九三学社。
第五等工程师,能够独立设计和实现一项功能的人。这是对工程师的基本要求。
❑ 第四等工程师需要有点产品头脑,也就是说他们在做一件事之前,要知道所做出来的东西是否有用、易用,是否便于维护,是否性能稳定,等等。除了要具备产品设计方面的基本知识,还要具有一定的领导才能,能从头到尾负责一个产品的生命周期。这在很多硅谷的公司里是一个高级工程师所应有的基本素质。
❑ 第三等工程师,可以做出行业里最好的产品。他们与第四等工程师有着质的差别,这不仅反映在技术水平、对市场的了解、对用户新的了解以及组织能力等诸方面,而且也反映在悟性的差异上。
❑ 第二等工程师是那些可以给世界带来惊喜的人,他们在其工作的原创性以及对世界的影响力上和后面三等有巨大差别,例如扎克伯格。
❑ 第一等工程师是开创一个全新行业的人,这些工程师不仅在技术和产品等各个方面与第二等工程师有了质的差别,而且在经验和管理上也是好手,他们通常也是企业家,并通过自己的产品改变了世界。这一类人常常是可遇而不可求的,例如冯·诺依曼
他认为杰出的程序员和一般的程序员的巨大差距在于需要多久你可以把自己的想法转变为代码。
四、组建和管理团队
管理人员是与人打交道,其任务是使员工能够协同工作、扬长避短。
——彼得·德鲁克(书中引用)
……请使用两种设计模式编写代码(考察基础编程能力)。
2)请描述面向对象的三个特性及使用场景(考察面向对象的基础知识)
3)编写数据结构相关的程序,例如“实现一个特殊的栈,在实现栈的基本功能的基础上,再实现返回栈中最小元素的操作”(考察对于数据结构的了解)。
4)编写算法设计题,例如“给定一个32位整数n,可为0,也可为负,返回该整数二进制表达中1的个数”(考察对于复杂算法的了解)。
5)请描述JVM堆、栈、方法区的用处和区别(考察对于JVM的了解)。
6)举例说明Java8与Java7的区别,写出对比代码(考察对于新技术的了解)。
7)对您使用的GC作原理性描述(考察对于垃圾回收机制的了解)。
8)举例说明某个JDK函数或者类的源代码并进行分析(考察对于技术原理的了解)。
9)说说您过去的项目经历(开始了解他的工作经历,以便后续进行提问)。
10)画出您最了解的项目的总体设计图,或者概要设计(了解他的架构设计能力)。
11)说说过去工作中遇到的最复杂的技术难题,并说出您的解决方案(考察他的问题解决能力,也可以了解他所做的项目的复杂度)。
12)工作中您最讨厌领导的哪些行为?过去的经历中有没有发生什么不愉快的经历(了解他对领导的期望)。
13)为什么离开上一家公司(可以深入聊聊,了解这个人的个性)?
14)反问他有什么问题(别小看这一题,一般来说,如果他有自己的职业规划,他一定会问你很多关于你们公司、岗位的问题,或者如果他对这个岗位很感兴趣,他也会问。反之,如果他想都不想直接说没问题,那我觉得应该多和他聊聊为什么会来面试,仅仅是为了有一份工作吗)。
成功地管理程序员最重要、最关键的因素,是在技术层面得到他们的尊重。如果没有技术尊重,那么你的每一个具体想法,都可能会遇到主动或者被动的阻碍
要得到技术尊重,关键因素包括:
❑ 理解计算机程序设计的艺术
❑ 拥有良好的过往履历
❑ 做出过技术贡献
❑ 追逐技术潮流
❑ 成为一个技术或者职业组织的活跃成员
❑ 展现出强大的个人价值
这让我想起了电影《冲锋陷阵》的最后一幕,四分卫拿着球向对方阵地冲去,周围一群队友阻拦对手球员,能力弱的以自己的身躯直接和对方一对一硬拼,能力强的干掉一个又一个对手,直到四分卫冲过对方底线。这部电影我看了很多遍,也是我带领团队的精神指导,每次看到这一幕,我都会非常激动。
每个人都是独特的,薪酬是由下面这个复杂的公式决定的:
薪酬=i*工资+j*股票期权+k*福利+l*与谁共事+m*工作地点+n*做了什么+。。。
优秀的主管要有足够的自制力,不在下属工作时瞎指挥。
每项任务都必须有且仅有一位负责人,如果有两个负责人,那就没有人负责了。开发经理的职责是确保为每项任务指定负责人,而不是亲自去完成每一项任务(开发经理可以指定其中的某一项工作由自己直接负责)。应当明确每项任务,确保为每项任务指定一个负责人,推进任务。还要定期检查以下三个问题:“是否清楚整体的目标?是否清楚你的任务对实现整体目标有怎样的贡献?对于你所负责的部分,有哪些东西妨碍你达成目标?”我自己的做法是,只有担任责任人的员工,才能在考核中得到良好或优秀的评价(前提是把事情做好,做不好就要承担责任),没有担任责任人的员工,最多只能给予合格评价。
记住,没有记录的会议,相当于没有开过。每一个重要会议,都需要有完整的会议记录,包括参加人员、讨论议题(逐一写下来)、讨论过程大体描述、每一个议题的最终结论(包含流程图)、遗留问题、下一次会议时间及议题等。
不要把每一个问题都带到你老板那里寻求解决方案。仔细地挑选你的问题,只拿那些真正重要的问题去寻求你老板的帮助。当然,如果你能独立解决问题,而不需要他的帮助就更好了。另外,你还要避免只把问题带给领导的情况,最好是拿着几套潜在的解决方案和问题一起交给他。即使你没有特别好的解决方案,或者没有找到最好的解决方案,也会让领导觉得你已经做好了自己的功课,过来找他是为了寻求他的建议和忠告,而不是直接把问题抛给他。
工作努力的人,要给予薪资方面的倾斜,即便他是亿万富翁,该多给的奖金一分都不能少,如果他经济有困难,还要更多给予倾斜。对不努力的人,无论多么困难,天平绝对不会向他倾斜。……公平、公正,是做事、做人的基本原则
有时候,我们会觉得分工和分模块是产生效率的前提,但是实际情况并不是这样。我们可以看到,所谓的“分工”被彻彻底底滥用了,他们把“分工”当成了永远只干一件事的借口,一个程序员应该能够掌握多个语言,也能够负责多个模块甚至不同的职责。如果一个程序员觉得多学习一门语言,多掌握一个模块是件很困难的事,那么这个程序员本质上是不合格的。
……开放、共享、追求极致”的团队文化。
五、杰出的程序员
……真正的技术牛人,他在做事的时候绝对是全神贯注的,否则他不可能在短时间内读懂别人的代码、找到问题原因、完成框架设计,这是技术专家的必备能力。
如果程序员的学习、工作动力主要来源于项目管理时间表、管理层的压力,或者金钱,那么他不会成为一名杰出的程序员。对大多数杰出的程序员来说,动力实际上来源于更高的追求,例如改变世界,做出人们喜欢使用的程序或产品
杰出的程序员希望并且需要为具有世界影响的项目而工作,他们希望能够感受到自己的工作是有意义的,哪怕只在某个很小的方面有意义也行
杰出的程序员偏爱能够满足他们更高理想或要求的公司和项目,他们非常在意自己所做的事情,常常为了想要的结果而超负荷工作,而不会在某种压力下自愿做低技术含量的重复劳动。
……发现最有效的进攻是眼花缭乱的传球和准确的投篮,而不是彰显个人能力的突破和扣篮。
六、产品开发过程
……开任何会议,一定不要上来就讲解方案,应该先讲解场景。每个场景先讨论背后的需求并定义清楚,这也是软件本身的意义——模拟业务;
需求评审后,由开发和测试负责人分别编写技术方案和测试用例。接下来进行技术方案评审,由开发负责人与其他相关系统的负责人一起讨论,技术方案中必须要有业务流程图和时序图。业务流程图是为了梳理开发对业务的理解,确认是否和需求一致。时序图是为了梳理本次需求涉及的系统交互。技术方案评审通过后,确认工作量和交付时间,反馈给产品经理。
重要/紧急工作>重要/不紧急>不重要/紧急>不重要/不紧急。
七、系统架构
❑ 我们这个系统的边界是什么?
❑ 我们系统由哪几部分组成?
❑ 各模块之间怎么通信?
❑ 选择什么样的基础技术?
❑ 为什么要这样选择?
❑ 技术方案未来会遭遇哪些坑?
❑ 我们的备选方案有哪些?
❑ 从技术角度这个应用将来如何持续扩展功能?
不应该一开始就承担大项目。应该先从小的、无关紧要的项目入手,并且不要去希望该项目能够做大。否则,你就会做出过度的设计,并且通常会把项目的重要性看得比它实际的要高。或者更糟的是,你会被预想的不切实际的项目规模吓得望而却步。因此,要从小规模的项目做起,把细节考虑周全,不要盲目憧憬过大的愿景或虚幻的设计。如果项目不能解决一些相当紧急的需求,那么它十有八九是被过度设计了
——林纳斯·本纳第克特·托瓦兹(书中引用)
技术人员如果要成为架构师,就必须跳出技术的视角,换一个角度去看技术。要把时间花在研究生命周期规律和业务的增长上,花在选择合适的技术上,而不只是追求新潮的或自己喜欢的技术。
……系统定位和边界要清晰,对应的业务定位和边界要清晰。
易变的、尝试中的新业务要避免影响现有业务的稳定性
新业务的支持,可以考虑新建独立微小型应用系统,以便避免改造成熟核心系统,影响其稳定性和健壮性。
请我喝杯咖啡系统之间数据要实现单向流转。系统之间尽量保证单向数据流转,确保数据流可回溯性、一致性和可追溯性。混乱的数据流转管理会造成应用架构管理的灾难。

