万字干货:需要深度阅读,只推荐给想要走技术管理路线的“老头儿”们看!

木木玩Android · · 961 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

前言

我是从 2014 年开始正式走上管理之路的,在那之前虽然也有带过几个初级程序员,但毕竟不是正式的管理职位。正式踏上管理岗是从做一个小主管开始的,刚开始只管理几个人;之后担任过一些业务线的技术负责人,管理十几二十人;最多时管理百人团队,负责整个研发部门。一路从技术主管,到技术经理,再到技术总监,中间也和别人合伙创业当过 CTO。有空降管理过现成的团队,也有不止一次从 0 到 1 组建团队的经验。

六年多的管理经验,说多不多,但说少也不少,肯定也有自己的一些心得体会,如今就用文字来和大伙分享我的一些经验总结。

我打算根据管理的三个级别来聊:技术主管、技术经理、技术总监。这里所说的这三个级别,并不是指代具体的管理岗位名称,可以简单理解为技术团队中的基层管理者、中层管理者、高层管理者,具体的再一一细说。

技术主管

如刚才所说,技术主管并不指代具体的岗位,而是指初级技术管理人员,主要负责管理某一垂直技术领域,包括管理该领域的基层技术人员。比如 Android 主管、iOS 主管、前端主管、Java 主管、Golang 主管等。有些公司也称为技术组长,而且也不一定设置明确岗位。另外,在有些小公司,管理层级少,可能就没有设置技术主管的岗位,而直接挂名技术经理,比如我的第一份正式管理岗,挂名就是 App 技术经理,管理 Android 和 iOS。那时候的我其实既是基层管理者,也是中层管理者。这在小公司很正常,甚至处于初创期的 CTO,还需要同时担任高层、中层、基层所有的管理工作。

技术主管所管理的人员一般只有几个人,多的可能十几个。如果人员超过 20 人,最好对团队根据细分领域做一下拆分。比如 App 人员如果超过 20 人,那就可以拆分为 Android 组和 iOS 组,每组再分别设置一个主管,而原先的 App 主管则可以升级为技术经理。

对公司部门来说,技术主管优先考虑肯定是从内部人员中提拔,条件不满足的情况下才从外部招聘。比如,组建新团队的时候;或当前团队都只有些初级工程师,缺乏能够独当一面的人;或团队中都是些技术宅,只想专研技术,不想做管理。这些情况下,一般就需要从外部招聘合适的人选。

能荣升技术主管的,一般工作经验 3-5 年,专业技术能力已经非常娴熟,可达到资深级别,还具备一定的架构能力,能够独当一面。学习能力、沟通能力、对业务的理解能力等,也都是比较出众的。一般可以对标阿里的 P6 级别。

想要做好技术主管的工作,也不是那么轻松的。作为一名技术主管,平时大部分时间依然还是用在了技术设计、写代码、解决 Bug 等工作,这和基层的程序员没多大区别。但是,技术主管除了需要做好这些程序员本身的工作之外,还需要花时间做开发任务的分解、分配,以及代码 review、技术设计评审、面试、和团队内外的人员沟通协作等管理工作。因此,想要做好技术主管的工作,提高时间管理的能力是很有必要的。不然的话,就会把自己搞得很忙很累,最后管理工作没做好,还影响了作为程序员本身的工作。也因此,有些人就会开始退缩,不愿意当技术主管,觉得会占用自己过多的时间,平时写代码的时间都不够,哪有时间做管理。想要在管理这条路上不断往上爬,这是必须要迈过去的第一道坎。

从程序员升级为技术主管,最核心的转变就是:从管理自我到管理他人。所以,我想谈谈关于管理他人的一点经验,主要还是分享下在选人和用人上我自己的一些做法。

关于招人选人,我有一个标准,也是我最看重的一点,那就是候选人的深度思考能力。不只是技术人员,包括产品经理、UI 设计、测试人员等,我都会考察他们的深度思考能力。深度思考能力越强的人,越能看到问题的本质,各方面的能力也会越优秀。

那么,如何考察候选人的深度思考能力呢?其实也简单,多问些为什么就可以了。比如,对于应聘架构师的候选人,可以类似下面这样层层追问下去:

  1. 问:你们系统采用什么样的架构?答:微服务架构
  2. 问:为什么采用微服务?答:为了快速迭代
  3. 问:为什么用了微服务就能实现快速迭代?答:服务间解耦,可以分小组分别独立开发、测试和部署
  4. 问:分了多少个小组?每个小组多少人?为什么这么分?答:……

这些相互关联的问题,是可以不断追问下去的,问题也并非有标准答案的,也并不是考察候选人是否知道正确答案,而是考察他是否思考过这些问题,是否有自己的一些想法。当然,候选人也不可能对所有领域的问题都能答得上来,所以尽量多方面考察,并尽量从候选人所熟悉的领域进行深入。

再说说用人方面,我比较崇尚于为下面每个人的自我成长而负责。我会去了解每个人的职业规划,为他们的职业发展路线提出建议,并在工作中不断给他们提供成长的机会,包括分配的任务、提供的技术指导和培训、定期的一对一沟通,等等。其实,从本质上来说,就是为了激发他们的善意和潜能。

我做基层管理时就已经开始实践选人用人的这些方法论,而且成效还非常不错。

符合我的标准招进来的人,做事基本都是很高效的,大多都能成为团队里的骨干成员,有时还能做到远超我的预期,有着突出的表现。不过,有时候,长时间没招到合适人选或急需用人时,我只能减低标准,这时候招进来的人,则有些参差不齐了,部分人虽然也能完成任务,但成果就是不尽如人意。

也因为我用人的方式注重于他们的成长,所以,他们也很尊重我、支持我、追随我。我管理过的团队,离职率也一向比较低。

作为基层管理者的技术主管,建议重点培养自己的以下能力:

  1. 专业技术能力:这是技术管理者的立身之本,肯定需要不断精进,如果技不如人,是无法服众的。
  2. 业务理解能力:对业务有正确的理解,甚至能理解到业务的本质需求,才能让技术实现价值。
  3. 任务分解能力:技术主管承担着开发任务分解分配的职责,如果分解不当,漏掉了一些环节,就会导致任务的延迟、质量的不可控,为项目带来了风险。
  4. 时间管理能力:管理者需要在有限的时间里高效地管理多种事情,自然就需要提高时间管理能力。
  5. 团队建设能力:管理者的核心价值就是打造出一支优秀的团队。
  6. 向上管理能力:向上管理没做好,会影响职业的发展,但切记,向上管理并不是拍上级的马屁。
  7. 领导力:领导力不同于管理力,不能靠职权,而是靠个人魅力,建议尽早培养。需要明白一点,大部分技术人员更喜欢被“领导”,而不是被“管理”。

技术经理

技术主管作为基层管理人员,更多时候只是个执行者,要求能够「正确地做事」,能够带领一线团队高效地执行上级所交代的任务。

技术经理,作为中层管理人员,主要职责则是根据高层管理所确定的目标,制定实现目标的具体计划并保证实施,还要为最后的实现结果负责。

技术经理具体的工作职责,不同公司会有所不同,但主要可能包括:制定技术规范、制定工作计划、项目整体的架构设计和架构优化、跟进项目进度、团队建设、与其他部门的协调沟通等。

对技术经理的工作年限一般要求 5 年以上,技术上对架构能力的要求高一些,本身至少也应该是个能够独当一面的架构师或技术专家,可以对标阿里的 P7 级别。不过,在具体要求上,大厂和中小厂是不一样的。大厂对技术深度的要求会更高,小厂则比较看重技术广度。但大厂基本很少对外招聘管理岗,同级别的高 P 技术岗反而会招得多。所以,大部分人只能在中小企业发展管理路线。另外,技术经理也不一定是从技术主管升上去的,也可以从高 P 的技术专家转岗的。

在管理能力上,对技术主管所要求的也同样对技术经理有要求,而且要求更高。比如,业务理解能力,技术主管更多只是停留在对业务局部的一些点和线方面,而技术经理应该精通业务,对业务应有全局观。再比如,团队建设方面,技术主管更多只是偏于对个人提供技术指导,而技术经理则需要制定具体的团队建设方案,比如制定技术培训方案,以提高团队整体的技术水平。

技术经理还有一个核心工作就是培养技术主管。如何培养呢?最核心的一点就是要懂得授人以渔,教以方法论,而不是一旦出现问题就直接帮他解决问题。技术主管上任初期普遍会存在一些不足,比如,在任务分解方面会做得不太好,经常会分解得不彻底,会导致增加很多沟通成本甚至任务延迟;面试时也不太懂得如何抓重点,会浪费很多时间;团队成员出现分歧时,也不太懂得如何妥善处理。这些都需要技术经理花时间、花精力去慢慢指导技术主管,要让技术主管明白背后的方法论,而不要简单地丢给他解决方案。

我做技术经理的时候,还担任过公司里某些业务线的技术负责人,统筹管理项目的技术研发进度,其实就是项目管理。有些公司,会设置专岗来做项目管理,一般称为项目经理。但不少公司和我一样,是由技术经理兼做项目管理的。另外,还有部分公司,会由产品经理来兼做项目管理。

其实,要做好项目管理,对业务和技术两方面都熟悉是再好不过的。毕竟,从流程来看,项目管理包含了需求、设计、开发、测试、上线五个阶段,前两个阶段是业务强相关的,后三个阶段是技术强相关的。因此,最好的项目管理人员,应该是既懂业务又精于技术的,才能更好地统筹全局。但现实情况却是这样的人比较稀少,所以,更多时候,一个项目的前两个阶段主要由指定的产品经理进行管理,后三个阶段则由指定的技术负责人进行管理。而统筹全局的人,则从两人中再指定一人,或直接由上级领导来统筹。所以,确切来说,我当时所担任的项目管理,其实只是技术层面的项目管理,统筹项目全局的是我的上级领导。

技术层面的项目管理,我主要采用敏捷开发方法,并结合 TAPD 或 TOWER 等工具进行管理。项目管理涉及到的具体事务不少,我只挑几个重点说一下:

  • 代码分支管理:建议用 Git,不要用 SVN。要制定适合团队和项目情况的代码分支管理规范,可以从简单的 TrunkBased 模式开始,在实践中再不断去优化演进。
  • 每日站会:站会的时间控制在15分钟内,目的主要是同步项目进度,发言要简明扼要、关注重点、禁止报流水账,可提出问题,但切记不要在站会中讨论解决问题,留待会后再去沟通解决。
  • 复盘总结:每次版本迭代结束后,应该组织复盘总结会,这很重要,总结成功经验,吸取失败教训,有助于提升团队能力。
  • 质量管理:这应该是项目管理中最重要但却是最难管理的一块了,其会贯穿整个研发流程中几乎每一个阶段。主要的管理工具包括测试驱动开发、设计评审、code review 等。

作为中层管理者,技术经理一般不会对基层员工进行直接管理,因此,想要管理好下面的整个团队,更需要提升自己的领导力,通过领导力而不是职权来让基层员工信服。

技术总监

高层技术管理岗,大厂和中小厂在这个级别上对管理者的能力要求,差距非常大。比如,阿里的总监级别,职级一般得在 M4 以上,M4 对应于 P9。阿里的职级体系有两条线,P 系列为技术岗,M 系列为管理岗,对应关系为:

  • P6 = M1,主管
  • P7 = M2,经理
  • P8 = M3,资深经理
  • P9 = M4,总监
  • P10 = M5,资深总监

再往上就不列举了,马云卸任前是最高级别,为 M10。

而一般小公司的技术总监,跳到阿里可能只会给到 P7 级别,很优秀的可给到 P8,能达到 P9 的绝对是凤毛麟角。大部分技术总监难以达到 P9 或 P8,很多时候是因为技术深度达不到高 P 级别的要求。因为小公司的技术总监,能力更偏向于“全能型”,优势在于广度,而深度难免会成为短板。而大厂因为分工精细化,对广度反而没什么要求,但对深度要求很高。

另一方面,大厂的高 P 们跳去小公司当技术总监或 CTO,很多人也会面临广度不足的问题,难以很好地统筹全局。因此,习惯了大公司“精细化”模式的人也未必能满足小公司“全能型”的需求。

所以说,大厂和小厂的总监,几乎是两个不同的方向。而我自己也没有大厂总监的经验,所以我在这方面的经验主要适用于中小厂。

我的总监级别的管理经验,也有三年多了,具体岗位担任过技术总监、研发总监、CTO。管理的团队人员最多时近百人,最少时则是从 0 搭建。当 CTO 的时候责任最大,但团队的人员却是最少的,最多时也就 20 多人,后来因为熊市来了,资金链断裂,融资失败,团队最终解散。担任研发总监时,管理的团队是最大的,整个研发部门有百号人,包括技术人员,也包括产品和运营人员。

作为技术总监/研发总监/CTO,最核心的能力就是能够组建和管理整个研发部门,打造出一个高效的研发团队。

先聊聊从 0 组建团队的经验,这方面我有过两次经历。从 0 组建团队,最核心的还是如何才能招到合适的人选。最优的方案就是从自己的人脉中入手,以前带过的下属,或熟悉的同事、朋友,觉得优秀合适的可以试着挖过来,每个岗位上的人员,最好都是能够独当一面,后续有能力担任技术主管的。我当 CTO 时组建的团队,有好几个核心骨干就是我以前带过的下属,他们之所以愿意跟随我,部分原因还是因为认可我的领导力。这里要补充说一下,前面我就建议从技术主管开始就重点培养领导力,因为,领导力发挥作用的时候,不只是对在职的团队成员。

次优的方案就是靠别人推荐了,最后的方案才是进行社招。而不管是推荐还是社招,有些岗位,技术总监可能不熟悉相应的技术,就难以考察候选人的实际能力。我自己倒不存在这样的问题,毕竟我自己是个全栈。但大部分总监却非如此,那么,我提供三种方案:

  1. 请技术专家帮忙面试,并给予相应的酬劳。
  2. 请技术专家出一些面试题,并提供参考答案。
  3. 总监自己花时间去了解相应的技术。

这三种方案,效果一般也是由高到低。花点钱请相应的技术专家帮忙面试是最好的选择,现在普遍都是视频面试,也比较方便。

接着,再跟大伙分享下我管理近百人的整个研发部门的一些经验。整个团队包括了产品经理、设计师、开发、测试、运维、运营等人员,需并行研发多个项目。有些公司的研发部门可能不会包括产品经理、设计师、运营人员,不过没关系,管理方法也是一样的。

管理百人级别的研发团队,第一个核心工作,就是采用合适的组织结构。一般有三种类型的组织结构:职能型、项目型、矩阵型

职能型的组织结构,即是对团队成员按不同职能划分为多个小组,比如分为:产品组、设计组、前端组、App组、Java 组、Golang 组、测试组、运维组、运营组。每个小组再分别设置一个组长,管理各职能小组的成员和相应的职能事务。主要优点就是能够发挥各职能小组的集中优势,人员调配上也有较大的灵活性。主要缺点就是在项目管理上,完成项目需多个小组相互配合,但项目经理缺少权力,协调难度较大,难以做到快速迭代。

项目型的组织结构,即是将团队成员按不同项目划分为多个项目组,每个项目组都分别有自己的产品、设计、开发、测试、运营等人员,每个项目组再分别设置一个项目经理,管理项目中的所有事务和人员。优点就是项目经理对项目可以全权负责,包括对项目成员也有全部权力,项目决策快、效率高,也可做到快速迭代。缺点则是项目组相对封闭,资源无法共享,很容易造成资源浪费,且项目之间缺乏交流,知识和经验也难以在不同项目组之间共享,对团队整体的提升造成阻碍。

矩阵型的组织结构,则是职能型和项目型的混合体,可对两种结构的优缺点进行取长补短,是目前大部分互联网公司所采用的方式。矩阵型结构,项目成员会有双重领导,职能经理和项目经理都是他/她的上级,对员工容易产生焦虑和压力。且如果权力划分不明确,两位领导容易产生冲突。

根据项目经理和职能经理权力的强弱关系,矩阵型结构还可以再细分为:弱矩阵、强矩阵、平衡矩阵。弱矩阵下,职能经理的权力更高,项目经理的角色更像个协调者。强矩阵则是项目经理有着更高权力,管理上更偏向于项目。平衡矩阵自然就是两位经理的权力都差不多,取平衡,而平衡之道其实也是最微妙的。

我这边主要尝试过项目型和弱矩阵型,从效果来看,弱矩阵型的组织架构会更加合适。至于平衡矩阵型,想要达到好的效果,需要精心建立管理体系,且对协调人的能力要求较高,而身边缺乏这样的人。另外,还有一种方案,就是让职能经理同时兼任项目经理,我曾任技术经理时就是这样,但我担任总监时,却缺乏符合要求的人。

作为技术总监,组建起研发团队只是第一步,想让这个团队变得高效,还需要做很多事情,也有很多方法,但回归到最本质上,还是要尽一切努力去激发成员们的善意与潜能。

总结

技术管理的方方面面还很多,限于篇幅,暂时就先聊这么多了。总结陈词,我只说两点:

  1. “管理的本质,是激发人的善意与潜能。” 谨记这句话并时刻践行之。
  2. 技术一定不能落下,不管是主管,经理,还是总监,最最核心的还是技术。

因为我自己是做Android开发的,所以呢,对于如果是在Android技术方面不是很自信的朋友,建议可以对照以下我总结的作为一个Android高级开发人员需要掌握的技术点,来查漏补缺(还会提供一些个人整理的学习笔记参考)。

  • 架构师筑基必备技能

目前Android APP开发主流语言就是Java语言,Java语言最大的特性就是提高了软件的交互可能性,可以说安卓手机几乎所有应用程序都是利用Java语言来进行编写的。

知识要点:
1、深入理解Java泛型
2、注解深入浅出
3、并发编程
4、数据传输与序列化
5、Java虚拟机原理
6、高效IO

架构师筑基必备技能
  • 设计思想解读开源框架

随着互联网企业的不断发展,产品项目中的模块越来越多,用户体验要求也越来越高,想实现小步快跑、快速迭代的目的越来越难,插件化技术应用而生。如果没有插件化技术,美团、淘宝这些集成了大量“app”的应用,可能会有几个g那么大。

所以,当今的Android移动开发,不会热修复、插件化、组件化,80%以上的面试都过不了。

知识要点:
1、热修复设计
2、插件化框架设计
3、组件化框架设计
4、图片加载框架
5、网络访问框架设计
6、RXJava响应式编程框架设计

设计思想解读开源框架
  • 360°全方位性能调优

在不同层次的开发工程师手里,因为技术水平的参差不齐,即使很多手机在跑分软件性能非常高,打开应用依然存在卡顿现象。

另外,随着产品内容迭代,功能越来越复杂,UI页面也越来越丰富,也成为流畅运行的一种阻碍。综上所述,对APP进行性能优化已成为开发者该有的一种综合素质,也是开发者能够完成高质量应用程序作品的保证。

1、设计思想与代码质量优化

2、程序性能优化

  • 启动速度与执行效率优化
  • 布局检测与优化
  • 内存优化
  • 耗电优化
  • 网络传输与数据储存优化
  • APK大小优化

3、开发效率优化

  • 分布式版本控制系统Git
  • 自动化构建系统Gradle

4、项目实战

  • 启动速度
  • 流畅度
  • 抖音在APK包大小资源优化的实践
  • 优酷响应式布局技术全解析
  • 网络优化
  • 手机淘宝双十一性能优化项目揭秘
  • 高德APP全链路源码依赖分析
  • 彻底干掉OOM的实战经验分享
  • 微信Android终端内存优化实践
360°全方位性能调优
  • Android框架体系架构

Android框架体系架构(高级UI+FrameWork源码) 这块知识是现今使用者最多的,我们称之Android2013~2016年的技术。

Android开发者也往往因为网上Copy代码习惯了而导致对这块经常“使用”的代码熟悉而又陌生:熟悉的是几乎天天在和它们打交道, 天天在复制这些代码 ;陌生的是虽然天天和这些代码打交道,但是并没有深入研究过这些代码的原理,代码深处的内涵。

本篇知识要点:
1、高级UI晋升
2、Android内核组件
3、大型项目必备IPC
4、数据持久与序列化
5、Framework内核解析

Android框架体系架构
  • NDK模块开发(音视频系列)

NDK(Native Development Kit缩写)一种基于原生程序接口的软件开发工具包,可以让您在 Android 应用中利用 C 和 C++ 代码的工具。通过此工具开发的程序直接在本地运行,而不是虚拟机。

在Android中,NDK是一系列工具的集合,主要用于扩展Android SDK。NDK提供了一系列的工具可以帮助开发者快速的开发C或C++的动态库,并能自动将so和Java应用一起打包成apk。

本篇知识要点:
1、NDK开发之C/C++入门
2、JNI模块开发
3、Linux编程
4、底层图片处理
5、音视频开发
6、机器学习

NDK模块开发
  • Flutter学习进阶

2020 年无疑是 Flutter 技术如火如荼发展的一年。

每一个移动开发者都在为 Flutter 带来的“快速开发、富有表现力和灵活的 UI、原生性能”的特色和理念而痴狂,从超级 App 到独立应用,从纯 Flutter 到混合栈,开发者们在不同的场景下乐此不疲的探索和应用着 Flutter 技术,也在面临着各种各样不同的挑战。

本篇知识要点:
1、Flutter跨平台开发概述
2、Windows中Flutter开发环境搭建
3、编写你的第一个Flutter APP
4、Flutter Dart语言系统入门

......

Flutter学习
  • 微信小程序开发

微信小程序作为现在比较火的编程开发应用场景之一,深受市场的青睐,这让不少开发者眼馋不已。但是对于初学者来说,就完全摸不着头脑了,不知道微信小程序开发制作需要学习那些知识,有需要的朋友可以参考本篇。

本篇知识要点:
1、小程序概述及入门
2、小程序UI开发
3、API操作
4、购物商场项目实战

微信小程序开发
  • Android相关源码解读
    只要是程序员,不管是Java还是Android,如果不去阅读源码,只看API文档,那就只是停留于皮毛,这对我们知识体系的建立和完备以及实战技术的提升都是不利的。
Android相关源码解读

Android相关源码解读部分内容

需要以上完整学习笔记pdf的朋友,烦请顺手 点赞+评论 支持下我,然后点击这里免费自取


有疑问加站长微信联系(非本文作者)

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

961 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传