技术

mosn有的没的 负载均衡泛谈 《Mysql实战45讲》笔记 单元测试的新解读 《Redis核心技术与实现》笔记 《Prometheus监控实战》笔记 Prometheus 告警学习 calico源码分析 对容器云平台的理解 Prometheus 源码分析 并发的成本 基础设施优化 hashicorp raft源码学习 docker 架构 mosn细节 与微服务框架整合 Java动态代理 编程范式 并发通信模型 《网络是怎样连接的》笔记 go细节 codereview mat使用 jvm 线程实现 go打包机制 go interface及反射 如何学习Kubernetes 《编译原理之美》笔记——后端部分 《编译原理之美》笔记——前端部分 Pilot MCP协议分析 go gc 内存管理玩法汇总 软件机制 istio流量管理 Pilot源码分析 golang io 学习Spring mosn源码浅析 MOSN简介 《datacenter as a computer》笔记 学习JVM Tomcat源码分析 Linux可观测性 学习存储 学计算 Gotty源码分析 kubernetes operator kaggle泰坦尼克问题实践 kubernetes自动扩容缩容 神经网络模型优化 直觉上理解机器学习 knative入门 如何学习机器学习 神经网络系列笔记 TIDB源码分析 《阿里巴巴云原生实践15讲》笔记 Alibaba Java诊断工具Arthas TIDB存储——TIKV 《Apache Kafka源码分析》——简介 netty中的线程池 guava cache 源码分析 Springboot 启动过程分析 Spring 创建Bean的年代变迁 Linux内存管理 自定义CNI IPAM 副本一致性 spring redis 源码分析 kafka实践 spring kafka 源码分析 Linux进程调度 让kafka支持优先级队列 Codis源码分析 Redis源码分析 C语言学习 《趣谈Linux操作系统》笔记 docker和k8s安全机制 jvm crash分析 Prometheus 学习 容器日志采集 Kubernetes 控制器模型 Kubernetes监控 容器狂占cpu怎么办? Kubernetes资源调度——scheduler 时序性数据库介绍及对比 influxdb入门 maven的基本概念 《Apache Kafka源码分析》——server Kubernetes objects 源码分析体会 《数据结构与算法之美》——算法新解 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 ansible学习 Kubernetes源码分析——从kubectl开始 jib源码分析之Step实现 jib源码分析之细节 线程排队 跨主机容器通信 jib源码分析及应用 为容器选择一个合适的entrypoint kubernetes yaml配置 《持续交付36讲》笔记 mybatis学习 程序猿应该知道的 无锁数据结构和算法 CNI——容器网络是如何打通的 为什么很多业务程序猿觉得数据结构和算法没用? 串一串一致性协议 当我在说PaaS时,我在说什么 《数据结构与算法之美》——数据结构笔记 PouchContainer技术分享体会 harbor学习 用groovy 来动态化你的代码 精简代码的利器——lombok 学习 《深入剖析kubernetes》笔记 编程语言的动态性 rxjava3——背压 rxjava2——线程切换 spring cloud 初识 《深入拆解java 虚拟机》笔记 《how tomcat works》笔记 hystrix 学习 rxjava1——概念 Redis 学习 TIDB 学习 分布式计算系统的那些套路 Storm 学习 AQS1——论文学习 Unsafe Spark Stream 学习 linux vfs轮廓 《自己动手写docker》笔记 java8 实践 中本聪比特币白皮书 细读 区块链泛谈 比特币 大杂烩 总纲——如何学习分布式系统 hbase 泛谈 forkjoin 泛谈 看不见摸不着的cdn是啥 《jdk8 in action》笔记 程序猿视角看网络 bgp初识 calico学习 AQS2——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 硬件对软件设计的影响 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记2 《mysql技术内幕》笔记1 log4j学习 为什么netty比较难懂? 回溯法 apollo client源码分析及看待面向对象设计 学习并发 docker运行java项目的常见问题 Scala的一些梗 OpenTSDB 入门 spring事务小结 事务一致性 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型 java exception Linux IO学习 netty内存管理 测试环境docker化实践 netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker中涉及到的一些linux知识 hystrix学习 Linux网络源代码学习——整体介绍 zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty回顾 Thrift基本原理与实践(二) Thrift基本原理与实践(一) 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 Redis概述 机器学习泛谈 Linux网络命令操作 JTA与TCC 换个角度看待设计模式 Scala初识 向Hadoop学习NIO的使用 以新的角度看数据结构 并发控制相关的硬件与内核支持 systemd 简介 quartz 源码分析 基于docker搭建测试环境(二) spring aop 实现原理简述 自己动手写spring(八) 支持AOP 自己动手写spring(七) 类结构设计调整 分析log日志 自己动手写spring(六) 支持FactoryBean 自己动手写spring(九) 总结 自己动手写spring(五) bean的生命周期管理 自己动手写spring(四) 整合xml与注解方式 自己动手写spring(三) 支持注解方式 自己动手写spring(二) 创建一个bean工厂 自己动手写spring(一) 使用digester varnish 简单使用 关于docker image的那点事儿 基于docker搭建测试环境 分布式配置系统 JVM内存与执行 git spring rmi和thrift maven/ant/gradle使用 再看tcp 缓存系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 VPN(Virtual Private Network) Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 Go学习 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

架构

Scheduler如何给Node打分 Scheduler扩展 controller 组件介绍 openkruise cloneset学习 kubernetes crd 及kubebuilder学习 pv与pvc实现 csi学习 client-go学习 kubelet 组件分析 调度实践 Pod是如何被创建出来的? 《软件设计之美》笔记 mecha 架构学习 Kubernetes events学习及应用 CRI 《推荐系统36式》笔记 资源调度泛谈 系统设计原则 grpc学习 元编程 以应用为中心 istio学习 下一代微服务Service Mesh 《实现领域驱动设计》笔记 serverless 泛谈 《架构整洁之道》笔记 处理复杂性 那些年追过的并发 服务器端编程 网络通信协议 《聊聊架构》 书评的笔记 如何学习架构 《反应式设计模式》笔记 项目的演化特点 反应式架构摸索 函数式编程的设计模式 服务化 ddd反模式——CRUD的败笔 研发效能平台 重新看面向对象设计 业务系统设计的一些体会 函数式编程 《左耳听风》笔记 业务程序猿眼中的微服务管理 DDD实践——CQRS 项目隔离——案例研究 《编程的本质》笔记 系统故障排查汇总及教训 平台支持类系统的几个点 代码腾挪的艺术 abtest 系统设计汇总 《从0开始学架构》笔记 初级权限系统设计 领域驱动理念入门 现有上传协议分析 移动网络下的文件上传要注意的几个问题 推送系统的几个基本问题 用户登陆 做配置中心要想好的几个基本问题 不同层面的异步 分层那些事儿 性能问题分析 当我在说模板引擎的时候,我在说什么 用户认证问题 资源的分配与回收——池 消息/任务队列

标签


《技术管理36讲》笔记

2020年03月22日

简介

“管理”作为一项综合能力,是你未来的职业发展所不可回避的,至少你都需要和管理者合作。只不过因为你的角色不同,需要掌握的程度不同。你所有的职业发展,都会围绕着技术和管理这两条腿在走路,一条腿是走不远的。只要是在职场中,就有一个基本法则在发挥作用,那就是“价值兑现”,即,你能收获多少回馈,取决于你能输出多少价值。这里的回馈不仅是指物质回馈,还包括成长感、成就感、幸福感等精神回馈。做技术不重要,做管理也不重要,把技术和管理当成你职业的两条腿,在职场中输出自己最大的价值,才是最好的,才真正属于你。

要不要做管理

对公司而言,真正有价值的是你为公司解决了多少问题,而不是完成了多少工作,工作本身没有意义,解决问题才有意义。对于你自己而言,真正有价值的不是你获得了多快的晋升,多高的加薪,而是你获得了多少持续高强度训练的机会。而这两者,本质上是统一的。

  1. 你是否认同管理的价值呢?认为招聘面试、辅导员工、向上汇报、开会沟通、流程梳理、资源协调、进度推动、绩效评估等大部分管理工作,都是琐碎的“杂事”,很难从这些工作中获得价值感和成就感,甚至还对于这些工作挤占了写代码的时间而不满。认为管理的工作不如技术工作有价值,通过技术手段来解决问题才是最酷的事情。即使有很多人都认为你适合做管理,而如果你自己不认为管理是有价值的,你是不会开心地长久做下去的。
  2. 你是否对管理充满热情,并享受这些工作呢?

    1. 你是否主动地向自己的上级了解过团队的工作目标呢?
    2. 你是否主动关心过新同事该怎么培养,以及如何更好地帮助他们成长呢?
    3. 你是否享受去负责一个大项目的协调和推进?它的成功发布是否会给你带来强烈的成就感呢?
    4. 你是否思考过什么样的流程和机制可以应对团队工作中的那些疏漏呢?
  3. 你是否看重在管理方面的成长呢?

    1. 更大的责任。在互联网领域,管理者带一个团队,更多是意味着要承担更大的期待和责任。基本体会不到行使权力的快感。这是不是如你所期待呢?
    2. 更立体的视角。码代码是最简单的事情
    3. 更灵活的思维方式。在各种不确定因素中,却要去追求一个明确的目标,这对于很多新的技术管理者来说,思维方式会受到很大冲击。你想扩展你的思维方式吗?

你能收获什么呢?

  1. 你到了一个更大的平台上,你的能力和视野将得到大幅度提升。这会给你带来明显的成长感。
  2. 你不但能力变强了,你还有团队了,你能搞定更大、更复杂的事情,做出更大的成绩。这会带给你更强的成就感。

如果说你前面问我“适不适合”,主要是指“你是否可以很好地胜任”,以及“能否拿到自己想要的回报”。那么,此时你就知道要回答好这两个问题,是需要首先回答另外两问题的,即:这个选择是否更符合“你的初衷”,以及是否更能激发“你投入的意愿”

PS:如果找不到合适的方向和环境,投入会渐渐没有效率,挫败感会反噬。

丹尼尔·平克在《驱动力 3.0》一书中有说:“服从让我们撑过白天,而投入才能让我们撑过夜晚。”这告诉了我们一个很简单的事实:外驱让我们可以做好本职工作,而内驱才能让我们成就卓越。

研发leader成长手册(一)

新leader常踩的坑儿有哪些?

  1. 过程导向、被动执行。团队方向感缺失,团队做不出有效的业绩,无法带领一个团队。
  2. 大包大揽、唯我最强。没有梯队,团队成员积极性受挫,由于得不到团队成员的有效支持,自己又忙又累,做不了更大的业务。
  3. 单一视角、固化思维
    1. 习惯性卡住。遇到问题和困难,很容易被卡住,到处都是绕不过去的鸿沟。
    2. 认知层次低。由于被单一惯性思维所支配,认知层次和考虑问题的维度无法提升。
    3. 难堪重任。由于创造性地解决问题的能力不足,难以承担具有挑战性的工作。
  4. 自扫门前雪、固守边界。项目推进不畅,从而影响全局的结果。自我设限,因此个人成长受限。个人影响力无法扩展。
  5. 患得患失。

技术管理的患得患失

通晓多种编程语言的程序员,真香?如果我用一句话来定义程序员的工作,那就是“解决问题”。优秀的程序员不一定要编写出色的代码。他需要使用手上的最佳工具来解决业务问题。

核心原因是把管理摆在了和技术对立的位置,同时由于管理能力还没有强大到可以作为自己的核心竞争力,因此忧虑自己的技术会落后,从而失去生存能力。造成的后果:犹豫反复,无法全力以赴去做好管理,成长缓慢;对技术的看法太狭隘,从而影响技术判断力的提升。所谓的留后路,其实也是不学习,不成长,懒惰的表现,这是一种固定思维,而不是我们鼓励的成长思维!有时候“背水一战”是对管理者的最好的鞭策

技术能力不等同于编码能力:做技术管理,你并没有放弃技术,而且也不能放弃技术,放弃了技术是做不好技术管理的,你只是在一定程度上,放弃了编码而已。那么,都没时间编码,怎样才能做到不放弃技术呢?

  1. 首先,把技术提到更高视角来看待。做技术的时候,把技术做好就是最大的目标;而做了管理之后,你会把技术作为一个手段来看待,看它究竟能为目标带来什么。这很像在学习组装电脑,即便已经不需要关心主板、内存、CPU 的内部运行逻辑,但你还是要很清楚它们的功能是什么,接口什么样,以及从哪些维度去衡量一个主板的好坏、内存的好坏、CPU 的好坏,也得清楚在整台电脑中,哪个部件可能会是短板,等等。所以,技术转管理并不意味着不关心技术,只是更关心更大的目标和整体结果了。
  2. 其次,换一种学习方式来掌握技术。你要深刻地认识到,亲自写代码固然是很好的学习技术的方式,但是作为 leader,你需要快速掌握更多的技术,并且快速判断该如何搭配使用,所以你一定得有更高效的学习方式才行。技术管理人的技术水准的提升和保持,主要看能从周围人的身上汲取到多少信息和知识,而不再只是靠自学
    1. 建立你的学习机制。你可以想想在团队内建立什么样的学习机制,可以帮助你借助团队的力量来提升技术判断力,并结合自己的情况来创建。定期做交流和分享。
    2. 请教专家。在了解某一个领域的情况时,借助你的平台,找你能找到的最厉害的专家高手进行请教,他们之所以成为高手,一般都能给出高屋建瓴、醍醐灌顶的认知。
    3. 共创。在这个知识型工作者的时代,和自己埋头思考相比,共创成果往往会出乎你想象,特别能增长见识,你可以看看在团队中如何建立共创机制。

如果你把“编码时间减少”叫做放弃技术,那我得告诉你一个残酷的现实,无论你做不做管理,这事都不可避免。现实是,你要么做技术管理,用更高的视角来看待技术;要么你继续做工程师,也要用更高的视角去看待技术。

俗话说:“人穷则反本”,当人们遇到困难和挫折的时候,就想回到老路上去,这是人之常情。只是,你不得不面对的一个现实就是,即便回头去继续做技术,也不再是原来那个听指挥听安排就好、做好执行就 OK 的一线工程师,工作“升维”已不可避免。一方面,每个人的内心都有成长的诉求;另外一方面,公司和团队也需要你承担更复杂、更具挑战性的任务。

从借助自己的技术到借助大家的技术。做技术的时候,了解自己能做什么就好了。但是无论是做管理者还是架构师,你都需要带人做事了,这个时候你就需要熟悉团队里每个人的技术情况,知道谁能胜任做什么事情,适合做什么事,然后借助大家的技术去做事

在编写代码的时候,要记得代码是要有可读性的。这体现在别人升级代码要花多长时间才能看明白,修改起来是否简单、安全。考虑维护成本是技术管理者和架构师视野宽阔、能力成熟的体现。再次是机会成本,这是技术管理者做决策时要意识到的。即,当你把人力、时间花在这件事上,同时就等于放弃了另外一件事,而没有做另外这件事将带来什么样的影响呢?就是你要考虑的机会成本,你可能会因为这个思考而调整技术方案的选择。最后,希望你还能意识到协作成本,即多人协作所增加的时间精力开销。一个方案的协作方越多,需要沟通协调的成本也就越高,可控度越低。

归根结底,从技术实现者到技术应用者的转变,不断提升的是技术的使用能力,而技术实现能力由于投入的时间越来越少,会逐渐减弱。例如古代带兵打仗的将军,需要了解步,骑,弓等不同兵种的特性,判断战场局势,知道何时何地何人发起致命一击,但不一定亲自去拉弓射箭。既然你选择了做更大的事情,就不得不适当放弃一些细节,放弃一些技术实现能力,不断提升你的技术判断力,让团队行走在正确的方向上。

有效执行

如果确定是要拿项目结果,就需要做出确保结果的安排。要想让员工分担我们手头上的工作,要么靠梯队,要么靠机制。所谓靠梯队,就是团队里有胜任度非常好的人,可以帮我们搞定这件事,并且这个人已经是这方面可靠的梯队人才。如果靠梯队有困难,就只能靠机制了。所谓靠机制,就是设计一套方案,来专门应对某个场景出现的问题,这套方案可以指导和“搀扶着”员工做好这类工作。自己开发 ==> 交给员工开发 + 自己沟通检查成本 ==> 降低检查成本。作为管理者,如果你想抽出时间干别的,梯队和机制的建设会把你解放出来。

任务执行检查清单

有效执行四要素 细则 备注
目标不清 目标不够明确具体,至少没有具体到执行人员可以执行的程度
下级对目标的理解看似一致,实则有偏差,尤其是对进度、质量和效果的拿捏上
目标发生变化了,没有及时同步给相关的人员
每个人对“清晰”的理解会有所不同
责任不明 是否有明确且唯一的总负责人
各负责人对于“负责”的理解常常是不一致的
总负责人无效
把上级作为“客户”来看待,并另寻总负责人和这个“客户”来对接需求。
推进不力 过于依赖人的主动性,没有成形的机制
机制虽有,没有人确保执行,或大家不愿意执行
机制虽多,没有抓住关键环节
 
沟通不畅 沟通是否主动,还是总在等待
沟通是否达成一致,并就结论double check,并通报
沟通不足,广播出去了就默认对方收到了
 

多任务并行该如何应对?“重要紧急四象限”耳熟能详了,这个“四象限”对于盘点各项工作的优先级是否好用呢?大家都很清楚“重要紧急的工作要排在最前面”“重要的工作要像大石头一样做长远安排”“紧急的工作要立即着手”“不重要不紧急的工作直接丢弃”等应对策略。可是令大家最困惑的是,到底怎么判断一项工作重要不重要,紧急不紧急呢?这个前置步骤才是最难以判断的。

在实际的工作中,我们经常做的并不是梳理轻重缓急四象限,更常见的情形是,我们要把日常的工作分为两种情况:一种是计划内的,也就是按照我们的规划进行的;另外一种是计划外的,即突发的情况和任务。我们的应对策略其实非常简单:

  1. 对于“计划内工作”,看收益是否足够大。收益越大就越重要,也就越需要给予相匹配的优先级、资源和关注度;收益相对不大,就放入“To do list”,作为待办任务处理。
  2. 对于“计划外的工作”,看损失是否足够大。损失够大,就按照紧急任务安排,以止损为核心目的;如果损失可控,就转化为一个可以安排到“计划内”的工作

个人体会:“重要紧急四象限” 很有名但一直用不起来,说明不贴合实际。 我们在学习、提炼套路的时候,也注意识别、避免这类华而不实的”思维框架“。

沟通

上级更倾向于告诉你,他们想要什么;而不会主动告诉你,他们愿意用什么来交换。这不是他们“唯利是图”,也不是他们“只让马拉车不让马吃草”,而是因为评估影响并给出应对方案是你的工作,这是你最清楚且拿手的,而上级判断不出对你既有安排的影响到底多大。所以,很多上级管理者跟我说,他们默认是需要沟通的,而不是默认不沟通,最怕大家最后给他们一些“surprise”。

诚意正心:遇到冲突时,跳出自己的角色来判断是非对错,通过审视初心来做决策,很容易让自己充满力量。当然,这无关管理方法论,更多的是对职场法则的认知和理解,也正是这个最基础的哲学,给予我应对冲突的基本逻辑判断。

你的角色是由上级和公司对你的具体期待决定的,而不是你的头衔。常常有跳槽的管理者问我“技术总监都做哪些事儿”之类的问题,这显然是混淆了头衔和角色。因为即使是同一个头衔,在不同公司所需要承担的角色可能是千差万别的,所以,不要指望按照头衔去筹划自己的工作,就可以满足上级和公司的期待。那么,如何厘清自己的“角色”呢?我的回答是:和你的直接上级去约定(如果你的直接上级对你有充分的管理权限的话)。比如,我每次空降的时候,都会问未来上级一个问题:“长期我们很难约定,仅就我入职后的前三个月或前六个月,你觉得我做好哪三件事,你会对我的工作比较满意?”如果对方都没有想过这个问题,你不难发现,对方聘请你的意图是不清晰的,只是觉得应该有一个技术管理者而已。如此,未来合作关系崩掉的可能性会比较大。

管理沟通常见的五类问题

  1. 视角问题:沟通仅从自己出发,对管理者的角色和视角认知不够。
  2. 姿态问题:总是在防卫,随时准备战斗。防卫姿态对于管理者做好工作不会有正向价值,长此以往,就等于关闭了别人提供帮助的大门,任其自生自灭,这显然是个双输的结果。所以,工作中最好还是以做事为主,少考虑一些个人感受。如果就事论事地去沟通问题,反而会赢得更多合作者的尊重。
  3. 方式问题:先给人贴标签,对人不对事。
  4. 意识问题:沟通没有形成闭环。不能默认对方一定能收到,而且不能默认对方理解的和你想的是一致的。切忌把事实、判断、感受、责任、原因、方案等统统揉到一起来说了:你讲事实他说原因,你说原因他说感受,你说感受他说逻辑,你说逻辑他说责任,你说责任他说解决方案,你说解决方案他说困难……最终就成了“鸡同鸭讲”,互相的不理解和不认同。
  5. 初衷问题:只给抱怨不给建议。

方法

管理工作的底层逻辑正在从管控到激发

每一种管理方法或管理手段,都是以一定的人性假设为基础的,你认为人是什么样的人,你就会用什么样的手段来管理他。在现实的管理情境中,管理者要抛开对人性的判断,而是要在”抑恶扬善”、”抑懒激勤”的方面来制定管理措施。

把长线项目里程碑化,把日常工作项目化,让员工走一步有一步的成果,会提升员工的成就感。

员工越来越追求工作背后的价值和意义这件事是不可忽略的。所以,作为管理者你需要有能力为员工梳理清楚这个问题。