技术

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开始学架构》笔记 初级权限系统设计 领域驱动理念入门 现有上传协议分析 移动网络下的文件上传要注意的几个问题 推送系统的几个基本问题 用户登陆 做配置中心要想好的几个基本问题 不同层面的异步 分层那些事儿 性能问题分析 当我在说模板引擎的时候,我在说什么 用户认证问题 资源的分配与回收——池 消息/任务队列

标签


《技术领导力300讲》笔记

2018年11月13日

简介

本文主要是对极客时间教程《技术领导力300讲》的总结。

你对你做的事情,所处的环境有所了解么?对它们有认识么?技术、团队、管理 这些像计算机组成原理、操作系统一样需要你去认识和了解。

《软件架构设计》搭好技术基础是“修身”,接下来就是“齐家”:带领团队打仗。做项目只是一个过程, 最终是要打造一个极具战斗力的团队。有了这样的团队,可以在公司发展的不同阶段自如的切换到不同的业务。

技术

很多leader都是从技术人员做起来的,技术人员往往会想一个问题怎么做,他解决的是 how 的问题,但是在研究战略问题的时候,我们更多研究的是 What 和 who 的问题,或者说,我们更多的是看趋势、看未来,如果看得远,就可以反过来思考,现在做得是否对。我们有时候太关注技术本身,没有站在战略角度考虑问题。

技术管理者看到的情况,经常不是“两好选其优”,而是“两害取其轻”(前者基层、中层自己就发现并解决掉了)。通俗的话讲,你面前两坨翔,一坨大的,一坨小的,让你必须选一坨吃,如果你不能迅速确定,这两坨马上各自增长一倍。每一个决策者其实都是痛苦的,他要在信息不完全明确的情况下,面对痛苦和更痛苦的事情,迅速决定用哪个方案,并为结果负责,同时为了激励士气还不能表现出任何痛苦。

学习方法我自己分为快速学习,系统学习,深度学习。快速学习是了解一个新领域,如果想进入就先系统学习,如果自己操刀就需要深度学习,成为专家。

成长最终目的还是为了创造价值,成长过程中的成就感也来源于创造的价值。创造的价值最终是服务于我们的用户,得到成就感,但同时基于人性,我们不能忽视财富,权利,虚荣心的需求。

阿里巴巴 CTO 行癫也有句话,所谓的工程师文化就是”让好技技术驱动业务腾飞”

作为一家高速增长的创业企业,事情多,期限紧是常态,碰到事情做不完的时候必然需要依靠加班。但我们不把延长上班时间作为工作进度的保障,而是依赖频繁公开的进度沟通,依赖对交付物的质量要求,使得团队成员无论是否加班,都把产出作为首要目的,避免“为了加班而加班”的情况出现。

李列为:我们处理问题的原则是:发现一个问题,解决一类问题。其实,把这句话做逻辑分解是:发现一个问题,进行归纳建模,抽象成这类问题的普遍特征,然后,设计软件模型,统一解决它。哲学和 IT 技术是相似的,哲学解决问题的逻辑是:从归纳到理论,再到演绎,IT 技术解决问题的逻辑是:从 梳理抽象逻辑,到建模,再应用到这一类的场景,都是从“特殊”到“一般”再到“特殊”的一个过程。但哲学和 IT 建模也有区别,哲学更偏向于“道”的层面,IT 建模则偏向于“器”的层面。我们常说“道法术器”, 只有道,没有器,没有具体的步骤和工具,是很难落实和执行的。我们需要用 IT 建模的思想,来帮助管理者解决管理思想落地的问题。

在具体管理方面,IT 技术,或者说,数字化管理,更具操作性,比总结的哲学理论,更量化,更可控。如今,我们又有一个新的观点,那就是:公司有制度,手中无制度,因为,制度都已经潜移默化进了OA 中。

企业向平台化发展是必然趋势,每个企业都应该是一个微服务框架,逐渐积累自己的各种能力,然后让新的成员入驻,孵化新的项目,调用平台能力,在过程中,再积累新的平台能力,螺旋上升。

王海亮:强调技术的简单可控,保持简单非常重要,因为,系统越复杂,依赖越多,越容易出故障,要确保不出故障,就必须加入更多功能,导致系统更加复杂,陷入恶性循环,所以,做任何会让系统变复杂的事情,我们都会特别慎重。在做事的过程中不断强调这些要点,并不断贯彻落实,到最后,说得多了、做得多了这些就成了你团队的文化,而文化的重要性不言而喻。PS:展现给用户的东西一定要跟用户的预期一致,不要让用户有使用/记忆成本。

开发过程被打扰的问题:

  1. 组织层面组建了技术支持团队,专门处理业务反馈的技术问题,比如线上问题的排查与解答,数据的提供与处理等。只有该团队解决不了的技术问题才会提交给技术团队
  2. 我们给每个冲刺都会预留 2 到 3 名技术人员不参与到 Scrum Team 中,我们将预留的人员叫救火团队,随时处理技术支持团队处理不了的问题或紧急需求。救火团队采用轮值方式
  3. 在沟通协作上面,不建议通过即时通讯工具沟通而转向协作工具或邮件沟通,就是让技术人员尽可能的在自己适当的时刻拉取信息,而避免被随时推送来的信息打断思路,从而确保专注。

不建议过多的注释,并且写注释一定要慎重,这点可能和很多人的建议不同,因为我认为,代码是程序员自己的语言,这个语言除了和计算机沟通外,还要频繁的和团队其他成员沟通。如果你无法用自己的语言讲清楚你的目的,那就需要尝试换种思路去讲,而不是换种语言去讲,你的语言必须简洁且通俗易懂。但有时,确实有一些非常精妙的设计,需要新人有一定背景或深度思考才能明白,这时才需要注释,注释需要说明背景及设计思路,而不要过多的说实现,因为你的实现必须是简洁且通俗易懂的。

季昕华:技术创业可以分为四个阶段。第一个阶段,做自己想做的事情;第二个阶段,去做那些不想做,但又必须得做得事情;第三个阶段:找到一群合适的人,去帮你做那些你不想做,也不擅长的事情;最后一个阶段,有机会去做那些自己内心真正想做的事情。

技术一直在不断变化,每年都有各种各样的技术趋势出现,而应对技技术浪潮,最核心的要点就是,变化的是技术,不变的是目的,这一点非常关键。任何技术都是为商业服务的,所以我们要围绕我们的商业目的、商业手段去选择所需的技术。

俞圆圆:1. 业务,或者说工程(Engineering),一点也不low,在不同时空复杂度的要求下,它会不断演变出新的技术(Technology)挑战来。2. 警惕过度追逐没有实际问题可解决的技术热点,对于团队中类似“一直在做业务,技术没有进步”这样的困惑能胸有成竹地回答。

余沛:代码是思考的产出,而文档就是思考的过程快速交付不意味着质量上的妥协,很多时候,这是一个态度的问题。以炒菜为例,优秀的厨师与差劲的厨师,用在“炒”的时间和步骤其实不会相差太多,好与坏的区别取决于用不用心,而这“用心”其实包括前期的食材、工具的准备、平时的训练、对理念和目标的思考等,这才是更重要的。在技术方面,所谓的匠心也不是单纯指在写代码时吹毛求疵,关注注释有几种写法、括号应该怎么换行,而是写代码前,有没有用心思考与梳理,这才是差距所在。

李智慧:从做开发到做架构,获得了新技能,做开发是在别人画的框里面去做你的业务,而架构是你站在全局的视角去思考问题。从另一个视角去观察和思考问题,很多关注的点和思考的点都是不一样的,比如看待一个新技术,我会考虑背后的设计和优缺点,以及为我所用时我要关注什么等等。这种视野给我带来的帮助非常大。

李智慧:学习本身其实是一种消费,每天忙着去读书,看起来是在学习,但是学完以后你的生活和工作因此改变了吗?或者说有产出和输出吗?如果没有,每天的日子还是老样子,工作和生活也没有改变,这样的学习和玩一会手机、看一会抖音在本质上并没有太大的区别。所以一定要输出一些东西,比如你在公司里面做一个项目或者做一个产品。你要能够输出让别人消费的东西,这样你就会有成长,会变得不一样。我做事情的时候,总会想我到底是在做什么,是生产还是消费,是输出还是接收。如果我是在生产,大家是不是愿意去消费我生产的东西。冬天一定会过去的,日子一定会好的。如果你在冬天的时候冻得瑟瑟发抖,那等冬天过去以后,你肯定还是那个老样子。

这个世界变化很快,转型真的是无处不在的。人们都在顺应这个时代在发展,你要主动做好这种转型的准备,而不是说因为寒冬,或者其他什么理由去转型。你要去看时代的潮流,从正向去转型,把握住方向,而不是走投无路才去转型。当然走投无路再去转,也是一种转,但是肯定是提前做好准备,并且自己思考清楚会更好。

谭待:折中不是平庸,而是为了更好的在某些关键点上突出,为此,可以在别的地方做出牺牲。

胡峰:程序员是一个专业性要求比较高的职业,我们被雇佣并要求成为一名专业人士,所以应该像一个专业人士一样行事。普通劳动者和专业人士的区别在于,普通劳动者主要被动接受指令去执行任务,而专业人士则在其领域内自己生成指令,同时在领域外还会向同事或上级提供来自该领域的输出:专业建议。普通劳动者是一种劳动力资源,他们保证执行,而专业人士则是保证选择的执行方向是有意义的,执行路径是优化的。作为专业人士,我们需要去坚持和持续地打磨专业力,守住这块阵地。

王昊:在产品经理的思维中,他们会先考虑一切都是可能的,比如飞机不用轨道就能起飞,在他们眼中应该也能实现,因为这样才能放飞自己的想象力,这点跟技术人员有很大的不同。很多东西在一开始的时候都是不可实现的,而正因为它们当初的不可实现,才给了我们更多的机会。

王东:技术驱动的几个发力方向

  1. 架构升级,包括服务化、中心化、中间件、平台化等
  2. 工程效率,包括动态化、配置化、工具化、自动化等
  3. 稳定性,通过系统保障系统
  4. 用户体验,包括性能、可用性、新IO、安全性等
  5. 运营效率,包括系统化、智能化

业务

我一直比较强调需求的预见能力,是因为很多技术人员不太能够理解这件事情对其能力提升的重要性。而实际上只有做到这一点,才能从根本上解决研发资源的浪费(把精力放在不该放的地方)和重复投入(同一个组件反复投入反复没有做好)的问题。

思维力首先是能够制定并推进技术战略。要能站在行业和公司的战略高度来看待技术发展,洞察和分享技术行业发展趋势、最佳实践,对公司的技术和核心竞争力有深刻的理解。提炼年度或更长期的关键技术战略目标,并确保相关者理解。

懂业务,看得懂各种业务上的变化(这一点我还差的好远,其实就是在产品那块没有一套认知体系和方法论)。对自己在技术上的判断有特别大的帮助,特别是在优先级、重要性的判断准确性上。

漫谈业务与平台

  1. 业务逻辑是针对特定领域的,这些代码不可能在不同的业务之间共用。平台就是要提供通用的功能。业务才是一个公司发展的原动力,平台出现的原因在于复用以降低成本。
  2. 一家公司,只要存活了足够长的时间,那么必然会进入一种「业务-平台」模式,有几个问题:

    1. 排期错位,尤其在在平台早期建设的时候
    2. 平台gap,多个平台拼凑起来并不能像搭积木一样搭起来一个业务,这中间还有大量的业务逻辑需要去实现,有大量的胶合逻辑需要去填补。这种gap由谁来填补呢?这就看谁对最终结果负责了
    3. 支持力度的问题,新的业务需求到来的时候,对既有的系统肯定会产生一定的冲击,而这种冲击是创新所必须经历的,还是说只是一个扰乱,这个问题其实很难判断。

几个建议

  1. 平台应该具有自助接入的能力,避免成为瓶颈。这包括完善的文档、接入和调试流程。
  2. 平台应该能够支持长尾的需求。要实现这一点,平台必须让业务方能够做定制化的开发。能够用小成本支持长尾需求,才是平台真正的威力所在。
  3. 平台也应该做一些垂直业务的尝试,这样才能真正理解需求,并发现业务痛点在哪。

俞圆圆:做任何决策,先问问评估成败的核心指标是什么,核心指标宜少不宜多,如果做不到,那说明我们对当前最需要解决的问题剖析的还不够深,我们对赖以生存的关键条件分解的还不够细,我们的精力和资源还不够聚焦。指标要尽量可量化。先抗住再优化,边重构边生活。持续迭代,而不是过度设计。其他人听不懂的一定不是好的技术方案

如果一个员工将自己一个季度的绩效目标划分为 7-8 个小项来评估,那这就是一个强烈的信号

  1. 他的工作很可能是没有重点的
  2. 对于当前核心任务的拆分比较混乱
  3. 团队负责人对于员工的帮助或指导可能是浮于表面的
  4. 员工或团队对于以结果导向来证明自己的贡献和价值没有信心,而正是因为缺乏这样的信心,才抱着“这么多事,总能做好 3-4 件吧,这样至少有个交代”的心理,以很多细碎的小目标来掩饰心虚。

余沛:在互联网这个开放的环境及氛围下,大多数的应用类技术,其普及的的周期越来越短、高端技术的平民化越来越快,在这种前提下,互联网公司面临的技术难点往往衍生于其自身的业务独特性。以前经常讲的高可用、高并发、自动化运维、分布式,等等,这些曾经高大上的话题,在通用解决方案上已经没有什么新鲜的难以解决的困扰,早已是很多公司的入门标配了。真正的难点在于,你的业务场景中存在的那些独特场景,以及为了解决这些特性需要的技术方案。如果一名技术 Leader 对自身的业务特性了解不够深入,则很难触达真正的痛点。你可能是一名搜索专家,能够很轻易地构建一套传统的分布式搜索引擎,但是面对机票、酒店或电商等领域时,他们对于搜索的要求、难点在哪?传统的经验能够起到什么样的作用?还需要构建哪些额外的体系才能解决这些困难?这都需要与业务一起、有耐心的深入下去

极客时间:任何决策都要作出某种选择,而选择是否正确,取决于对决策对象的认知和价值判断是否正确。决策离不开价值判断。有了团队一致认可的阶段性目标后,当团队分析一个特性或故事时,基本只要看它们与目标的相关性就可以了。在基于阶段性目标进行“价值”判断时,建议从“是否不可替代”的角度进行思考,即对每一个特性或故事都问问自己:如果暂时不实现它,我们想要进行的探索能否达到目的?用户的期望能否得到满足?是否可以暂时采用其它替代的手段达到同样目的?

揉和

黄勇

徐毅:影响效率的几个因素

  1. 软件工程师不能够聚焦编码、团队周边协作与支撑工作占比高、跨团队联动开发等耗时又低效。我们希望降低这样的开销,让员工有更多时间去编码。
  2. 打断问题,员工工作常被突发事务打断,据统计,平均每小时被打断 7 次以上,平均编码持续时间不到 10 分钟。
  3. PL 直接贡献价值少,项目管理和团队建设占比高、特性交付占比不到 20%。我们希望 PL 也要投入较多时间参与开发功能、开发特性,去做交付,而不只是做一个纯粹的管理者。
  4. 新员工写代码、老员工解问题。很多团队会让新员工写代码,出现问题后又让老员工主要解决新员工遗留的问题,但多数人都不喜欢解 bug,若是长此以往,老员工也失去了动力。

建议 PL 可以观察团队中成员的交互,看哪些人协作比较多,就可以把他们组成微战队。这样做带来的好处,除了高效沟通与协作之外,还可以减轻 PL 的管理工作,甚至可以减少一些管理者角色

从我们推行的经验来看,五星级软件工程师的高效秘诀的四个层次,用中国人的话来说就是道、法、术、器,用西方术语来说就是价值观、原则、实践、工具。我们可以这样来理解这四个层次:

  1. 道的层面:就是理念,我们认为高效的团队和个人是提升研发效率的关键;
  2. 法的层面:就是方法、套路,从活力、贡献、管理、能力、协同等维度切入改进,提升个人及团队的能力,优化协作。
  3. 术的层面:就是具体实践,我们倡导微战队、静默时间和首席工程师。静默时间就是在静默时间编程,首席工程师是把团队中的高效个人单独划分出来,组成优秀团队,由部门经理直接管理,这个团队中的同学还有一个特权,可以挑选工作。
  4. 器的层面:工欲善其事,必先利其器,要提高效率,一定要为员工提供先进、易用、贴切的工具和工具链服务。

PS:我倒不是太关心说了什么,而是这种思维方式,你一团浆糊的事情,人家怎么说清楚。

文化

余沛:技术文化的打造是一个潜移默化的过程,具体到落实的话,可以通过鼓励符合文化的行为来进行引导。以匠心为例,工程师写完代码,他认为已经合格了,完成了交付,而他的上级在帮他 Review 代码时,会非常认真,会去思考还有没有优化的空间,如果有,团队就开会讨论能够优化的部分,再给出较为全面的优化建议。而不是大家一看反正代码也能运行,就很容易的给你通过。

任事者,当置身利害之外,建言者,当设身于利害之中。

担当大事,全在‘明’‘强’二字

明有二端,人见其近,吾见其远,曰高明;人见其粗,吾见其细,曰精明。

没有任何一个作战计划在作战过程中还行之有效,但是做计划本身还是必要的

奈飞文化手册:如果你想要造一艘船, 不要召集大家去收集木材,不要划分工作并发号施令。 而是要教会他们对浩瀚无际的大海心生憧憬。

奈飞的特殊之处就在于我们在多大程度上

  1. 鼓励员工独立作出决定;
  2. 开放的、完全的、深思熟虑的共享信息;
  3. 相互之间极其地坦率;
  4. 仅仅保留最高效的员工;
  5. 避免规则。

王平:社会有其自身的道德价值观,也有其法律,但法律只能规定整个社会的道德底线,而没法定义上限。比如尊老爱幼,不可能在法律法规里一一规定到底什么样的行为是尊老爱幼的行为。如果真的企图通过流程机制或规范的不断完善细化,来解决整个管理中遇到的问题,几乎是一个不可能完成的任务,因为规则是不可能穷尽的。价值观/文化的一个好处是,能在很多灰度地带,引导大家自动选择一个相对正确的行动方向,也能避免去制定极其详细繁杂的流程和机制。PS: 道德/文化 VS 法律/流程 or 规则

王东:文化如何落地?我们提了一堆问题供大家思考:什么样的研发/测试/运维就算一个好研发/测试/运维?我们认同什么样的人?我们 Hire 什么样的人?我们做什么样的 Leader?对这些问题达成共识,提炼出来就是公司的文化。

郭炜:文化是人类群体创造并共同享有的物质实体、价值观念、意义体系和行为方式,是人类群体的整个生活状态。它是无形之手,决定了你团队的价值观是什么,你的公司能不能招聘到高级的技术人员,在我们日常流程和管理者眼睛看不到的地方,员工是怎样工作的。

持续交付

游舒帆:加快迭代脚步,将项目切小,并优先执行最有价值的部分更快交付价值:原先有个项目 A 要依序完成 1.2.3 到 10,共 10项工作,为期 4 个月,项目的价值是带来 4,000 万业绩。现在我们若要将项目切为 A1、A2、A3、A4 四个迭代项目,我们必须针对原先的 10 项工作做重新的排序,可能 A1 先做 1.3 两个需求,完成后可以带来 2,000 万业绩,A2 则完成 2.4.5 三个需求,完成后可以带来 1,000 万业绩,也就是说我们仅完成了 50% 的需求,却已获得 75% 的价值。这就是将项目切小后的好处之一,让我们总是能优先进行价值最高的工作。

王东:以早进入、并行化为例,在开始聊想法、MRD、运营计划的时候,核心产品经理、核心架构师、核心设计师要同步参与;在出商业计划的时候,基本的整体架构设计就应该已经完成了。

王东:打造项目机动组织,大家排期的时候经常会提到人员不够,我们的做法是对整个团队做一次大的封闭培训,要求大多数成员特别是高 T 的同学要非常熟悉每个系统,尤其是核心系统。当某个系统模块比较紧急需要人手的时候,就可以随时抽调。

大环境

在过往几年中,中国整个商业环境发生了天翻地覆的变化,流量红利、人口红利、资本红利三个因素都在产生着不可预期的剧变。企业使命里面第一点是要创造价值,企业想生存下来必须要持续增长,否则这家家企业就在衰减。

以前业务增长就是销售团队的工作、是产品团队的工作、是首席营销官的工作,但其实我觉得这种思维要做一个很大的变化。我们的技术负责人要站出来,做什么呢,利用技术来实现增长,用数据驱动决策。

笔者曾经参加了一个技术分享,分享人说他们正在做儿童教育领域的开拓,为什么呢?因为他们从我们公司(喜马拉雅)拿到的数据显示,儿童领域的收听时长、付费比例很高。听到这里,笔者明白了我们为什么要出一个儿童版app。

所以技术人员应该是先找一个高速发展的行业,然后在其中选一个高速发展的企业,其次才是薪资待遇之类的其他东西。不同公司提供的薪水不会差太多,大家未来都靠股票,但是股票就完全取决这家公司做得怎么样。 最好的机会当然是能够进 60 人时的百度,或者100 人时的小米,但是这个真的只能靠运气。但是如果你坚定的看好一家公司的时候,就可以有目标的去加入。对于 BAT、小米、头条来讲,1000 人规模时加入一点也不晚,这不需要靠运气,更多的靠自己的眼光和实力。

成敏:不少企业家、管理者都在他们的演讲中提到,如今是 VUCA 时代,也就是一个易变的、不确定的、复杂的、模糊的时代。这个概念其实并不是首次出现, 德鲁克早在上个世纪 80 年代出版的《动荡年代的管理》一书中,就第一次明确提出了变化对商业社会的冲击,并表示当时的商业环境已经进入高度的动荡紊态。而现在商业社会的动荡程度和当时相比,至少多了一个量级。举个例子,之前一个企业要做十年、二十年才可能成长为一个非常大的独角兽,而如今,很多创业公司短短几年之内就能成长为独角兽。与此同时,一个企业从成长起来再到失败可能也只需要很短的时间,近几年的共享单车行业可以说是很好的样本了。因此,当你不断更新自己的认知,认识了这个世界的一些粗浅的本质后,再去看待周围的事物,去做一些决策的时候,就会发现自己能思考得更深一层,有更多的想法。

创业者在创业之前要想清楚、弄明白,但其实,当你真正投入创业之后,之前想得再多还是会遇到各种各样新的情况。很多问题可能是你之前就经历过的,有相应的经验,但也有些是你之前从来没有做过的事情。这个时候,就会逼迫你在不断的决策的过程中,把每件事情都真真正正的想清楚。因为你一旦偷懒,不去想明白就去决策的时候,世界会立刻还你以颜色,你做出的决定很可能会导致特别糟糕的结果。 PS:系统设计也是如此,想不清楚的问题终究有一天逼你想清楚。

胡峰:失业原因及严重程度 变革引发的技能性淘汰 > 环境引发的萧条 > 技能仍然有用但适应不了环境变化。 中年人和年轻人本应在不同的战场上。年轻时,拼的是体力、学习力和适应能力,是做解答题的效率与能力;中年了,拼的是脑力、心力和决策能力,是做对选择题的概率。年轻时,是用体力和时间积累经历,换取成长与机会。跟年轻的大脑相比,中年大脑在两个方面的性能是下降的:计算速度和注意力。其他方面,比如模式识别、空间想象能力、逻辑推理能力等等,性能不但没有下降,而且还提高了。计算速度和注意力下降应该是对学习力有一些影响的,但丰富的经历和经验应该可以缩短学习路径,更有效地学习。回顾过往,年轻时学习的路径试错曲线要长得多。

王鹏云:顺势而为很重要,而如何理解大势并不是一个可以快速入门的知识,它需要我们持续的关注与思考理解,并融合与洞察这个行业的运行与变化,以及了解社会中各阶层、各领域的人是如何思考,如何行事的,你了解的信息越多,对宏观大势的理解就越准确、越深刻,之后再做创业方向的选择,就会更完备。

童剑:只要能够做事,不断有新的挑战,就有留下来的理由

创业

顾旻曼:对于个人偏好来讲,我会对创业者有一些期待,希望他们有充分的积累,不管是过去在学术技术上的积累,还是在产业里面的积累。创业是对过去积累的势能的一次变现,也就是说,创业者要清晰地知道自己为何而来,并且不会因为一时的市场起伏、资本的追捧或是冷落就有任何变化,他们需要知道自己将创造什么。

谢呈:一些技术转身创业的朋友聊天,以前我们总是会讨论彼此的产品,目光聚焦于小问题。后来,我们慢慢学会将思维扩大,讨论大局层面的问题,比如公司现阶段最大的瓶颈是什么?目前公司遇到的最大的风险是什么?甚至会讨论双方公司在人力方面遇到的问题。其实这样的思考方式就是从解决问题转化为发现问题,我们的思路要从代码中跳出来,去发现公司存在的问题,去解决这些开放性的问题。

谢呈:在这个时代,创业的难易,取决于你的商业模式。如果你只希望做好盈利,那你第一步就应该考虑赚钱方式,路径越短越好。如果你找的方向较小,希望做一个年营收亿级别的企业,你只需要找到一个盈利的业务机会,利用自己的优势将它做到极致。不用太担心竞争,更不用担心 BAT,它们与你根本不在同一赛道。如果你的创业方向较大,估值百亿以上,甚至希望像 BAT 一样服务上亿用户,此时你要问自己的是「为什么是你」,为什么你可以做或者为什么你是最适合做这个事情的人?

王鹏云:选择创业,就不是在别人搭好的平台和既定的规则、清晰的约束下去做事情,你只要做好自己边界范围内的事,看准边界在哪里,完成既定目标就好,或有所突破更好。创业真的是一件无边无际的事情,最底层的约束其实就是法律,除法律外,在没有约束的情况下做事,就非常容易迷失方向,跌跌撞撞踩很多坑。虽然踩坑无法避免,但我们可以尽量少踩,因此就需要我们开阔眼界,至少可以用一些常识让自自己少踩坑。虽没有经历过,但大体上有直觉,知道某件事的运行规律,这样,当你做一些具体的决策和判断时,就可以尽量遵循规律,不符合规律的就绕着它走,不是所以事情都要不撞南墙不回头,脑袋没那么硬,撞几下可能就不行了。

熊飞:to B 的一个必然的驱动力就是人力成本逐年的快速提高,人才越来越贵,生产资料比如电脑越来越便宜。其次,各行各业系统性进入供大于求。也就是说,5 年再往前,你生产出来产品就可以赚钱,大家就拼命的建工厂,扩销售团队。但是现在大家想的是,我的良品率怎么提高一点,或者我的销售费用怎么再下降一些。这些要靠软件来解决。再次,80 后的 CEO、掌门人开始接班。对于他们来说,利用软件信息化来管理,是一个必然的趋势。对于开发者来说,有几个领域是很大的机会。

  1. 数据,因为数据每年都在翻番的暴涨,过去的技术栈已经很难去服务好未来的架构了。数据还有了新的各种各样的格式,比如图数据,IOP 的数据,所以我觉得数据无论是从它的规模,还是实时性,还是新的数据格式,创业都有巨大的机会。
  2. 新的技术架构,比如说容器的生态,比如软件定义网络,软件定义存存储。在各个领域都有很多新的架构,在这些技术架构里边不管是做安全,做运维,还是做各种各样的这个架构下的产品,都有很多大的机会。
  3. 机器学习带来的一些机会

熊飞:你去创业其实是一个把自己过去的经验快速的产品化,比如你原来是在京东做电商相关的大数据,或者原来在阿里云做实时数据,在这个领域有一流的经验,快速的形成商业价值的过程。而且呢,必须是系统完整的解决方案,要避免把这个事情给科技化,它本质上是一个产品化的东西。必须要是个大市场,创业的天花板比创业的增长速度要重要几十倍,因为增长是一个复利效应,就算是每年 100% 的增长,10 年也一千倍了。所以你现在最重要的事不是说我今年把增长从 100% 提到 150%,而是可以把增速降一降,全力投入到未来把天花板再提高 10 倍的工作中去。

熊飞:你早期客户一定要去找产品价值高的客户,而不是商业价值高的客户。他虽然可能只付你二三十万,但是他特别痛,他比你还着急想尽快上线,这个是最好的客户。锻炼了产品,锻炼了业务。

Ben Horowitz:任何技术初创企业都必须要做的一件首当其冲的事情是,开发出这样一款产品,它做某件事情达到的效果至少要比目前市面上的通行的方式好 10 倍。好 2、3 倍还不够,因为那样大家切换到新事物的速度和规模都会不足。必做的第二件事是占领市场。如果说你把某件事做得比原来好上 10 倍是有可能的话,那么能做到这一点的公司不止你一个也是有可能的。因此,你必须在别人也做到了这一点之前先占领市场。能够比竞争对手好上 10 倍的产品少之又少,所以,废黜其他窥伺王位的王子要比让老国王退位困难得多。

小结

个人感觉:

  1. 首先是认知,认识业务、技术、管理。认知别人,自己,自己的角色要求等。认知环境、趋势、公司、文化等。认知过去、现在和未来,不同阶段对人、架构、团队、管理的要求。
  2. 认知完了之后,是匹配。包括但不限于

    • 一个人(岗位)与当前的岗位是否匹配
    • 当前的技术方案与可见的业务规模是否匹配
  3. 匹配完之后,是行动,以及恰当的行动方式。
  4. 行动之后是反思,进而促进认知。

博学、审问、慎思、力行。

从中学到的一个东西,就是从高级leader的视角 看很多事,就很合理了。比如

  1. 技术人员会想:技术越牛逼越好
  2. 管理人员会想:当前的业务无法“供给”大牛,也是一种错配。

就像我们要定义现在是社会主义初级阶段、小康等等,这个大判断、大决策影响着无数的小决策,比如公司不同的阶段对技术架构的选择、招人的偏好性等。

扫码购买优惠15元

笔者个人微信订阅号