技术

并发的成本 基础设施优化 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可观测性 MVCC 学习存储 学计算 Gotty源码分析 kubernetes operator kaggle泰坦尼克问题实践 kubernetes自动扩容缩容 神经网络模型优化 直觉上理解机器学习 knative入门 如何学习机器学习 神经网络系列笔记 TIDB源码分析 《阿里巴巴云原生实践15讲》笔记 Alibaba Java诊断工具Arthas TIDB存储——TIKV 《Apache Kafka源码分析》——简介 netty中的线程池 guava cache 源码分析 Springboot 启动过程分析 Spring 创建Bean的年代变迁 Linux内存管理 自定义CNI IPAM 扩展Kubernetes 副本一致性 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之编排对象 源码分析体会 自动化mock AIOps说的啥 《数据结构与算法之美》——算法新解 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 ansible学习 Kubernetes源码分析——从kubectl开始 jib源码分析之Step实现 kubernetes实践 jib源码分析之细节 线程排队 跨主机容器通信 jib源码分析及应用 为容器选择一个合适的entrypoint kubernetes yaml配置 marathon-client 源码分析 《持续交付36讲》笔记 mybatis学习 程序猿应该知道的 无锁数据结构和算法 CNI 为什么很多业务程序猿觉得数据结构和算法没用? 串一串一致性协议 当我在说PaaS时,我在说什么 《数据结构与算法之美》——数据结构笔记 swagger PouchContainer技术分享体会 harbor学习 用groovy 来动态化你的代码 《深入剖析kubernetes》笔记 精简代码的利器——lombok 学习 编程语言的动态性 rxjava3——背压 rxjava2——线程切换 spring cloud 初识 《深入拆解java 虚拟机》笔记 《how tomcat works》笔记 hystrix 学习 rxjava1——概念 Redis 学习 TIDB 学习 分布式计算系统的那些套路 Storm 学习 AQS1——论文学习 Unsafe Spark Stream 学习 linux vfs轮廓 mysql 批量操作优化 《自己动手写docker》笔记 java8 实践 中本聪比特币白皮书 细读 区块链泛谈 比特币 大杂烩 总纲——如何学习分布式系统 hbase 泛谈 forkjoin 泛谈 看不见摸不着的cdn是啥 《jdk8 in action》笔记 程序猿视角看网络 bgp初识 mesos 的一些tips mesos 集成 calico calico学习 AQS2——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 硬件对软件设计的影响 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记2 《mysql技术内幕》笔记1 log4j学习 为什么netty比较难懂? 回溯法 apollo client源码分析及看待面向对象设计 学习并发 从一个marathon的问题开始的 docker 环境(主要运行java项目)常见问题 Scala的一些梗 OpenTSDB 入门 spring事务小结 事务一致性 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型 java exception Linux IO学习 network channel network byte buffer 测试环境docker化实践 netty(七)netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 mesos深入 Macvlan Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker中涉及到的一些linux知识 hystrix学习 Linux网络源代码学习——整体介绍 zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty(六)netty回顾 Thrift基本原理与实践(二) Thrift基本原理与实践(一) 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 Redis概述 机器学习泛谈 Linux网络命令操作 JTA与TCC 换个角度看待设计模式 Scala初识 向Hadoop学习NIO的使用 以新的角度看数据结构 并发控制相关的硬件与内核支持 systemd 简介 那些有用的sql语句 异构数据库表在线同步 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 mesos简介 缓存系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 VPN(Virtual Private Network) Kubernetes存储 Kubernetes 其它特性 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 使用etcd + confd + nginx做动态负载均衡 如何通过fleet unit files 来构建灵活的服务 CoreOS 安装 CoreOS 使用 Go学习 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

标签


2020年终小结

2020年02月23日

简介(持续更新)

日常记录,年终汇总为文章

学习并不是追求更多的知识,而是要寻找更好的决策依据。

在刚毕业的时候,讲收获说的都是学了什么新东西/技术,去了什么地方。在2020年,无论是技术还是生活, 更多是寻求突破/颠覆/打碎三观。因为人到一定程度,百利无一害的事情几乎没有了,花几天时间学习一个新技术在刚毕业是一个绝对正确的事情,但工作之后这样做可能牺牲了家庭生活/个性发展的时间。 这个时候,要求人更深刻,面对一件事,粗略的判断有利还是有害是不够的, 你甚至要给这件事精确到十分制的判断,个别事情要百分制的判断, 你必须判断出来 这件事是6分,那件事是5分,然后决定先做哪一件,以多大的决心做哪一件事(有时候判断事情更有价值,但不去做或投入不够,跟没有做出判断是一样的)。亦或者有一种淡然,为一种选择(意外着另一个放弃)承担后果。 更深刻,要求你更多的体验,也就是更多的行动/尝试,这样才会对生活有更真实的感受。

作为一个有经验的开发来说, 单纯某个技术的学习 对我慢慢没有挑战性和吸引力,并且也有小伙伴给我分担具体的事务,那我的精力投向哪里?成长体现在哪里呢?

一定要带出来小伙伴 挡一下。

The master has failed more times than the beginner has tried.

沟通

沟通的本质是扩大共识 ==> 重要的是先观察对方的认知和想法

单纯的挣扎于某个具体问题,缺乏对事情的高层次认知,想不到/做不到从具体问题提炼共性问题,摸索共性方案进而解决具体问题。

核心竞争力 一开始是解决事儿,再后面是解决人,最后是向下兼容的能力

为什么程序员普遍不喜欢交流?工作被打断严重影响效率;交流不能直接帮程序员完成工作。网上有个段子,说程序员和产品经理在开会,讨论到下班才结束。产品经理一看正好到点了,就欢欢喜喜地闪了,留下程序员拿着需求挑灯加班。我们排斥的不是交流本身,而是厌烦交流中时间的“浪费”。别管程序员嘴里怎么说,心里其实明白,归根结底,还是因为我们觉得这些事情影响了自己的“利益”。那为什么我们还要交流呢?我就写我的代码,写完下班不是挺好的吗?其实这就涉及到一个长期利益和短期利益的问题了。交流的好处可以从两个方面来说,一个是输入,一个是输出。

  1. 输入。在一个公司里实现成长,就要时刻保持自己获取信息。如果能够重视平时的交流,交流的时候多主动思考。只有足够的信息可以在脑子里碰撞,创新的火花才更有可能出现。在外人看来的灵光一闪,背后可能有很深的积累。
  2. 输出。现在已经不是一个酒香不怕巷子深的时代了。不要让自己做一个小透明,做的事情要让别人知道。同时,也知道别人在做什么,别人遇到了什么问题。别人的问题,就是你潜在的机会。程序员的工作就像是产品。好的交流就像是包装,广告,公关和营销。有了好的产品,还要有好的包装,突出产品特点的广告,及时的公关和合适的的营销,才能赢得市场。

人和人之间交流最重要的一点就是换位思考。站在对方的角度理解自己表述的内容,看看能否被正确地接纳和吸收(而不是努力的想把自己的想法表达出来,表达show自己,自己说爽了就行了)。所以我们在交流的时候,首先要进行快速的角色转换,找到对方和自己认知的“最大公约数”,英文叫做“on the same page”。然后对于交流中需要补充的知识做简单的介绍,比如系统特点,专有名词的介绍等等,避免受众一路带着问号听你说,最后对话变成了“鸡同鸭讲”。充分的交流,并不是“就知道动嘴”,而是一个获取信息,加工信息,给出信息的过程。

我们不能玩霸道总裁向,不能说“我不要你觉得,我要我觉得”。而是要玩霸道码农向,要说“我不要我觉得,我要你觉得”。快给我觉,我说的这个怎么样,有没有感觉,这个 feel 对不对。不对我们继续聊

上下沟通

一个事情2天干完是惊喜,4天干完是完成任务, 一周干完是能力一般,一周干完还到处漏水 不能留。

有的人不喜欢折腾代码,你非得让他一直重构,来回三四遍整的双方都很累,是不是一定要坚持呢?这个时候只能说卡死上下游, 控制影响范围。他可以做出选择,也必须接受结果。

什么是灵性?

  1. 知乎一个回答:灵性是一种感受力,对眼睛看不到的事物的一种感受力。是一种悟性,一种表达能力。越有灵性的人越会关注和周围现实世界无关的东西,越不会只关注菜价或明星八卦。
  2. 我自己的想法:很多人对身边发生了什么未知未觉
  3. 一leader 想法:灵性是举一反三的能力
  4. 一leader 想法:你问他问题,问一个说一个,绝不多说的那种,一般灵性都不太够。PS:很多人可以把一个复杂的问题回答的很简单,其实都是些很正确但没用的话。

协作方沟通

搞明白自己怎么想的/立场/决心,更要搞明白对方怎么想的/立场/决心。

  1. 诉求完全相反
  2. 诉求有一点重合,有一点相反
  3. 诉求大体一致

做事要想明白,还要想的深刻,还要有很大决心,光想明白没有决心是不够的。

当协作方提出过高要求的时候,摆出困难、成本、摆出已有的安排、要求业务方需求打个折,大部分时候都是可以收获一定的理解的。但直接拒绝,或者拒绝沟通,对方就要跳起来了。

向上沟通

你一定要让领导做选择题,而不是问答题、论述题。领导交给你的任何问题,你一定要有自己的想法,并且基于自己的思路提供一个或者多个可行的解决方案,并且需要知道每个方案的优缺点,并基于自己的判断在这多个方案中有一个自己认为最好的方案。跟领导汇报时,需要带着方案去汇报,而不是直接找领导讨论。

多做反馈,也能够更好地体现工作的积极性,代表你是在认认真真工作和思考的。多跟领导反馈,也让领导对你有更深刻的印象,更容易形成比较好的上下级关系。当领导遇到问题时也更愿意找这些积极主动的员工来帮忙处理,你可以得到更多的历练和成长。可以说,及时恰当反馈对员工是百利而无一害的。

职场中最忌讳的是沉默寡言,不做任何向上反馈。千万要记住,不要等着领导来找你。一旦领导过来找你,很可能不是什么好事,要么是工作中你出了什么问题,要么是领导想知道你最近在干啥,这可能都不是好的现象。

组织

不要为某个人烦恼,从流程上、分工上、组织上标准化、数据化、规范化,让强的有发挥空间,弱的拖不了后腿。

不同角色工作上真正的差异是上下文的不同。你和你职业台阶中的上一级那个人,差异到底是什么?也许你会说,他比我来的时间长,或者说,他每天的主要工作就是开会。如果真的是这样,那是不是只要你凑足这个条件,就可以到达他的位置呢?显然不是。你在项目里打杂,你只能关注到一个具体的任务,而项目主力心目中是整个系统。虽然写的代码都一样,但你看到的是树木,人家看到的是森林,他更能从全局思考。有的问题解决靠技术,有的问题解决靠对需求的理解。在一个特定的产品设计下,我总觉得设计的技术方案有些不优雅的地方,而只要产品设计微调一下,技术方案一下子就会得到大幅度提升。在这种情况下,我会先去问产品经理,是否可以这样调整。只要不是至关重要的地方,产品经理通常会答应我的要求。为什么你的工作总能让老板挑出毛病?没错,工作的上下文不同,看到的维度差异很大。单一维度的思考,在多维度思考者的眼里几乎就是漏洞百出的。为人做事同样要不断扩展自己的上下文,这也就是我们常说的涨见识

团队维护的成本除了实打实的薪资支出,还有文化建设成本。工程师们都号称需要宽容自由的环境,形式上看就像是花钱请了一群野马,这也是成本,或者说风险。因为真正优秀的工程师才会在宽松环境下创造出远大于成本的价值,而普通工程师有可能在宽松自由的环境下逐渐废掉。给团队维护一个宽松自由的环境,就需要有一些非常明确地验收工程师成果的机制,这种技术文化建设也不是一朝一夕的事情,需要付出很大的精力。

作为技术团队,对候选人的智商考察,是很重要的。技术工作有一定的智商门槛。这里强调一下,做技术工作,不是智商越高越好,而是过了门槛就好。到了实际工作里,只要智商达到一定水平,具体的工作贡献,和个人的情商、动机关联更高。工作做的更好、发展更快的,往往是那些情商更高的人。

  1. 我们遇到的每一个问题都不是小问题,只要没有被提出和解决,就有可能反复出现,消耗我们的精力。
  2. leader的很大一部分任务就是理清事情,排列优先级,让自己的手下去做事情。程序员能控制的就是如何安排和使用自己的时间,而leader要对手下所有人的时间负责

管理

先让别人干,自己晚点跟进下就好了,不要在最开始就介入

分析任何问题都要有系统化思维。比如阿里将人分为四种。李智慧将人分为

   
新手  
高级新手 高级新手不觉得自己是高级新手,碰到新问题,要么束手无策,要么老办法解决新问题
胜任者 主动性
在遇到新问题时,会积极寻求新的解决方案去解决问题
精通者 自我改进
反思精神以及全局思维:为什么会出现这样的问题?如何避免类似问题再发生?这个问题在更宏大的背景下处于什么位置?还有哪些类似的问题?
工作中最重要的不是规则,而是对场景的理解
专家 专家把过往的经验都融汇贯通,然后形成一种直觉,然后用最直接、最简单的方法把问题解决

管理是通过他人完成任务的艺术。正因为如此,有些成熟公司如京东就有规定,如果你没有培养出可以完全顶替你位置的人,你是不能晋升的。

没有指数级扩张,技术管理机会越来越少

试图用自己擅长的技术去解决所有问题,就是手握锤子去寻找钉子。始终坚持从问题场景本身出发,探索适合的、简单直接的的技术方案。

对于程序猿来说,当你看到一个概念的时候,最好去看下代码,这叫“知行合一”。一篇文章要写的透彻,一定是文章和代码实现相结合。

鱼是最后一个看到水的:问题 = 期望 - 体验。

  1. 很多小伙伴他倒是很努力在憋设计和代码,但还是看的东西太少,对“期望/理想状态” 缺乏想象力,只能想到基于已经会的技术最好能达到什么效果。容易被现状所限制,每一次的加需求,都是在“理想状态/假设一行代码都没写的视角” 重新审视系统。
  2. “如果做事想让你的领导满意,就必须以高两个层级的视角来看待和思考现在的工作,并作出行动”。视角越高,“期望”越大,就越能发现问题。

一线技术管理新人的困扰

  1. 当爹又当妈。培养骨干顶上来,以便聚焦自己的事情。
  2. 自己做到 90,还是让组员做到 70 分?定目标给方法,定期检查做指导,结束做复盘。

技术管理的价值:

  1. 事儿的产出:要比小伙伴看得更高更远,梳理业务需求和技术方案选型
  2. 人的成长:制定踮脚就可以实现的目标,并进行复盘(扶上马,送一程)

很多事情,甚至包括codereview、设计review 你不一定需要自己做,但要确保有人做,确保有人有时间做。每个人的工作时间可以说是leader掌握的最有价值的资源了。培养人才和为公司创造价值这俩目标,都需要用到组员的工作时间。PS:下文 “商业设计和组织设计是一号位不可推卸的责任”,作为leader,至少要想好一个月的计划,如果不清晰就时时刻刻琢磨想清晰,并根据实际合理调整。让小伙伴知道近一个月的事情,才能找到工作节奏,才能知道今晚该不该走的晚一点。

人最持久的动力一定是从自己做过的事情上得到的,而不是来自于外界,所以我们更多是帮助小伙伴找到这件事,做成这件事。PS:比如说我想说服小伙伴要交流, 我们在为一个feature 非常烦恼的时候,我实地找了下需求方,需求方说我们纠结的feature他们用不上。我们之前为难的时间越久, 小伙伴的体悟就越深刻。 让他体会到正反 两个实践的经验教训。

从运维到技术运营的 14 年修炼之路2010 年随着国内云计算的起步,我接受了更感兴趣的运维管理工作,与用友的前沿团队一起实现 IaaS、PaaS 平台的投产运行。我遇到了另一位良师益友,他让我感受强执行力已经不能带动团队快速前进,更需要的是广阔的专业知识、自驱力的强大、充分的信任、业务的体系与格局。我要从基层程序员的纯编程角度上升到更高维度,从写好代码到思考客户真正的需求,甚至从公司成本等多角度地开始思考业务背后的意义。

管理岗一般是不做具体工作的。换句话说,管理岗除了具体的事情,所有的别的事情都要管。经理每天的工作都可以说是在救火。人永远不够用,事情永远都很急,技术债务也在一天天成为发展的掣肘,线上生产问题还会时不时的凑个热闹。经理要组织协调各种资源,在有限的人和有限的预算内,把事情安排到内外各方都能接受甚至满意。

精力

不要总是解决同样的问题,不要是总是回答同样的问题。多写文档。

收敛精力:java 只管设计不介入,容器化好好搞一下。

所谓的算法优化,其实就是尽可能利用已知的信息,少做不必要的事。插入排序并不会因为干的活多,就比快速排序得到更高的评价,因为它们比的是谁排得快。工作效率高,不是因为代码写得多,而是有效工作做得多。做本质复杂度(Essential Complexity)的事情,少做无意义的事情。怎么才能有效工作呢?

  1. 拓展自己的上下文,看到真正的目标,更好地对准靶子,比如,多了解用户,才不至于做错了方向;站在公司的层面上,才知道哪个任务优先级更高;站在行业的角度,而不局限于只在公司内成为高手,等等。
  2. 去掉不必要的内容,减少浪费,比如,花时间分析需求,不做非必要的功能;花时间做好领域设计,别围着特定技术打转;花时间做好自动化,把精力集中在编码上,等等。

充分利用工具的效能,化主动为被动,化计划外为计划内。比如钉钉提醒大家发日报周报、钉钉的自动回复、微信读书的零散划线笔记再集中汇总到博客上。

迎接新世界,给你讲四个小故事

  1. 我还是挺喜欢一万小时这个法则的,不管这个社会怎么变化,人接受知识并转化为自己的智慧的能力没有本质的提升,仍然还是需要大量的学习、练习、反思,才能最终成为一个靠谱的人。在一个领域积累的时间长了,最终会迎来一个或者多个爆发点的,因为在中国,不仅仅是互联网行业,各行业都极度缺乏高级人才。
  2. 如果一个人有这种创业的心态,那他就自然的站在了一个更高的角度来看问题,相对容易能够看出事情的优先级和各种问题的真正原因,也就更有可能知道怎样推进事情才是更合理的。

技术人如何自我成长?工作上不可能所有的事情都能按自己的期望来,或多或少总会有一些大家理解的“杂活”、“苦力活”,在一个项目或一段合作中,不妨多问问自己希望被别人记住什么?然后赋予这段工作意义。我记得去年女排世界杯的时候,记者采访郎平,她提到每个人发球要有“使命感”,赋予每一次发球意义,大致意思是:不能说自己怕失误就保守,所以每个人都要去冲击对手。

一切兼有章法,只要肯用心、肯下苦功夫,敢于在思想上艰苦奋斗,我相信就一定会有大的收获。

而我们始终要记得工作中我们做很多的事情,最终发现留下来的不是事情本身,而是我们在做事情时候留给别人的印象,别人打给自己的标签

永远不要”屁股决定脑袋”。这里我想表达两层意思,一层是我们需要“进化”,需要不断的发现和感知世界的变化,更快的适应变化,有时候你在哪儿比你做什么更重要;另外一层是格局和眼界,就是不要被自己所处层级、所在的角色立场、视角所局限。PS:对于我来说,就是你开会反驳的时候,要再多琢磨一下,找的这些理由是不是因为你做这个事情 才找的。

技术

程序员修炼之路:你该知道的 7 个必经阶段

  1. 设计重于编码,接口重于实现。制定接口的过程,本身就是设计过程,接口一定要反复推敲,尽量做减法而不是加法,在能满足需求的情况下越简单越好。PS:从小组长的视角来说,你不可能完成所有编码,也不可能所有细节都去review,这就要求你自己先想好一个项目的轮廓,然后去检查小伙伴有没有偏的太远,这个轮廓就是设计与接口。
  2. 不要完全根据使用需求去设计接口,参考 MVVM,ViewModel 就是根据 View 的需要而对 Model 进行的再封装,不能将这些接口直接设计到 Model 中。PS:一个Model尽量只有一个设计目的,ViewModel 可以只根据View 需要设计,而被多个场景用到的 Model 不行。
  3. 空杯心态,有人提意见,先收下它(无论接受与否)。
  4. 设计期间就一定要找他人讨论,我一直比较反对一个人把设计做完了,把文档写完了,然后才找大家开个评审会那种模式,虽然也有效果,但是效果真的达不到极致,大家没有参与到设计中来,通过一场会议的时间理解不一定有那么深,最关键的是,如果设计有些问题的时候,但也不是致命问题,难道还让打回重新设计么?

架构的腐化是必然的软件的后期迭代和进化架构师们往往是不参与的。业务的变化又不会少数人的意志为转移,随着变化,一定会有那些并不适合放进最初设计中的需求出现,这时候架构师远在天边。工程师们排期又紧,那就只能先临时用丑陋的方案把需求实现。在系统里留下技术债。这种“不适合融入既有架构”的需求事件出现在什么时间点,谁也说不清楚。给每个项目都安排长期跟进的架构师,而项目又一直没出现大的变化,又会变成资源浪费。架构师日常的工作如果不是跟进某个项目,这个项目碰到问题的时候,需要再做设计评审,临时抱佛脚找架构师来 review,大多也是走马观花。这还真是有点两难。

开发框架文档体系化的思考 当时看完之后非常有感触:1. 写文档本身就这么多道道。 2. 最令人启发的就是作者从案例中对问题的识别。关键是发现。

社会

先做成一件事,是打开世界的钥匙。

张勇:作为企业一号位,什么是你不可推卸的责任?商业设计是一号位不可推卸的责任。你的团队,你指哪儿,大家打哪儿。但是你自己心里要不断去思考,公司走到现在,要走向未来,我的客户是谁,他有没有发生变化,我原来给他提供什么服务,我今天要给他提供什么服务,未来他还需要什么服务,跟我有什么关系。这就是整个商业模式设计。在商业设计以外,组织设计是企业一号位不可推卸的责任。再怎么思考得完美,抉择得果断,最终这个事情没有办成,就是你抉择的不对,也许是你执行没到位。如果没有好的组织,没有好的组织里的人,很多问题都会走样。所以要执行到位第一件事是解决生产力的问题,第二件事是解决内部生产关系的问题。

从整个商业模式构架来讲,最终考验每个人的是什么?是对我们自己本性的挑战。我们到底愿不愿意去面向未来、面向可能的市场,在非常困难的情况下,做一个不完美的决定。所有决定都是不完美的,因为在你没有发生好的结果之前,你甚至都不知道它是不是一个好的决定,但是没有决定是最大的问题。

技术人如何自我成长?认真生活也是一种态度,更是对人生的一种理解。在过去,我一直觉得自己处在一个奋斗的年纪,从来没有过多的关注生活,我也从来没有相信什么生活和工作的平衡,我对待工作的热情和投入的精力要远大过于我的生活。我觉得人的精力是有限的,必须要把最旺盛的阶段投入到事业和个人能力的提升上来。所以对待“认真生活”从来没有仔细去想过,更多停留在喊喊说说而已,我狭隘的看待了生活与工作之间的关系,Outing 之后我有不一样的思考。我们常常会提到一个问题:如何平衡生活和工作本身?这里边有一个词叫“平衡”,我不知道这个词在大家脑海里的画像是什么?在我脑子里第一出现的是“天平”,要么投入生活,工作上不做过多追求;要么更多思考工作,生活更多服务于工作。这种工作和生活非此即彼的狭义理解其实深刻阻碍了自己进一步的思考。我很长时间都是这么割裂开来看的。事实是工作是生活的一部分,是包含关系,生活是什么?生活是人生,生活包含了事业(工作)、家庭(我们常常理解的生活)、孩子、教育、兴趣爱好等等。《高效能人士的七个习惯》这本书在讲“要事第一”时提到“木桶人生”,这个木桶里可以装大石头、小石子、沙子等等,工作对于我可能是一个大石头,它承载了我很多人生的价值、经济基础等底座,这本书让我觉得生活是可以全面推进的,核心是我们需要识别自己在生活中每一个角色里承担的“重要不紧急”事项,然后做好它,做好这关键的 20%,不断的汲取,以“全面推进”为原则,而不是以某一个片面的侧重点为方向。而且日常生活中的思考和启发其实是可以很好的作用于工作。发现美好,发现痛的地方,发现人性中趋利避害,这是一种智慧,这也是过去一年在认真生活里收获的成长,我还在不断的强化这种理解,不断的在践行这条价值观。

你的战略之所以失败,很可能因为它根本不是战略。真正的战略包括一系列清晰的选择,这些选择明确了公司将来要做什么和不要做什么。很多所谓的战略都只是目标,这种目标不会告诉你你要做什么,而是告诉你你希望的结果是什么。然而,你依然需要战略去实现自己的目标。

那么“战略”到底是什么?日本的一本书里的定义给我印象很深:战场上,所有和看得见的敌人有关的,都叫战术,除此之外的,都叫战略。也就是说,所谓“战略”无非是超越某种感官限制的思考和手段。“看得见的东西都不是核心竞争力”。比如,大厂可以给你分享监控系统技术原理、如何支持多样的报警规则。但真实的业务系统需要监控什么东西、哪些事件无伤大雅、哪些事件要报警、哪些事件不仅要报警还要一直报警、如何让什么都不想管的开发用起来 等。 这些判断和决策(也就是”落地“) 才是系统发挥价值的关键。