跳到主要内容

2020年的总结

·4945 字·10 分钟·

你看到的这篇文章,是今年的第一篇,同时也是今年的最后一篇。按照惯例,每年我都会写一篇总结。今年的总结会比往年的要长,就当我唠个长磕吧,把今年要写但没机会写出来的东西总结一下。

关于写作、分享和演讲 #

虽然今年没有写博客或者公众号,但今年确是我写作量最大的一年,将近 20 万字。是我往年平均数的两倍。顺利的话,2021年7月会和大家见面。至于是什么主题和内容,这里先卖个关子。

写作是一个很好的整理自己知识体系的过程。我在写作的时候,经常能发现某些知识掌握的不够扎实。于是研究过,讨论,实践。再把结果如实的写出来。写完之后,自己就对自己的知识体系有了更深的信心。

由于写作,耽误了和朋友家人相处的时间。在此还要谢谢夫人的支持和抱怨。

今年谢绝了一些公开的分享邀请。今年的主要的实践积累在于“规模化敏捷”(SAFe)和“领域驱动设计”(DDD)两个课题上。一部分已经写到了今年的项目中,另一部分计划更新到明年的公众号上。

明年的分享可能会采用微信视频号或者录播的方式。

其实最重要的,就是持续、稳定的输出和总结。这些都会是未来职业道路上积累的财富。今年做的不够好,明年继续。

关于阅读 #

今年读了很多不同方面的书,疫情期有了大段的时间和家人相处和读书。剩下就是利用午休、地铁、和乘飞机时间。

疫情期间读完了《禅与摩托车维修艺术》,这本书我曾经拿起三次,没超过10页又放下了。豆瓣的“特别版”读起来还是比较轻松。最重要的是理解作者自身的分裂和世界观的分裂而后统一的过程。这本书有三种读法,都会有不同的体验。

  1. 普通读法,就是从头按照夹叙夹议的方式读一遍。
  2. 游记读法,跳过哲学的部分。按照故事的方式读。
  3. 哲学读法,跳过游记的部分。按照论文的方式读。

此外,今年把买了三年的《三体》全部读完,确实一部比一部精彩。听说《三体》要拍电影和连续剧。我个人觉得从情节来说,第一部会比较好拍。选取一个人类的角度,对外星世界采用谈话和想象。构造出足够恐怖和威慑的感觉就可以。当然,辛苦画分镜头的画师了。而第二部第三部的细节描写较多。影视化会比较困难,每十年可以重新拍一次。很多经典的小说都重拍了很多次了。每一个导演和演员对剧本和故事都有不同的诠释。所以,我并不担心拍坏。新版总会比老版强,能够驾驭住故事本身和读者期望的导演,也需要几年甚至十几年的努力才做得到。

文学类的书还读了《岛上书店》和《在森崎书店的日子》,两本都是围绕一个书店展开的故事,同样也都是外文引进的翻译作品。从文学角度来讲,《岛上书店》的文字更加克制,情节安排更加引人入胜。同样,这两本书都分别改编成了电影,有机会的话可以比较着看一下。

去年在鼓浪屿上的书店买了《100个基本》和《新100个基本后》,就很喜欢松浦弥太郎这种简单且有智慧的表达(当然翻译的也很好)。所以今年也买了很多松浦弥太郎的书,大部分是在 Kindle 上看完的。包括:

  • 《只要我能跑,没什么不能解决》
  • 《不得不爱的两件事》
  • 《今天也要用心过生活》
  • 《崭新的理所当然》
  • 《工作的100个基本》

技术方面,今年的主题是敏捷和DDD,都和工作相关。敏捷推荐BoB 大叔的《敏捷整洁之道》(我极其讨厌这个翻译)和《学习敏捷》。DDD 仍然推荐《实现领域驱动设计》,和《领域驱动设计》相比,文字更加顺畅。

社科类的书,今年读完了《未来简史》,《今日简史》读了一半。“人类简史三部曲”的恢弘叙事确实能够让人提升自己对世界的认识,开阔格局。我觉得,《未来简史》甚至影响了中国的政策制定。因为在《习近平谈治国理政 第三卷》里,你可以感觉到“人类命运共同体”这个宏大叙事和《未来简史》中所描述的理想是一致的。

对,我买了《习近平谈治国理政》,这仍然是我实践《原则》一书中所提到的原则:拥抱现实,应对现实。中国的现实是党的长期执政并引导社会各层面的全面发展。理解世界和所生活环境的社会大背景,就会得到长期而稳定的指导。能够在工作和投资中获得启示。

关于工作 #

当你阅读本文的时候,我应该正在办理离职手续。今年的最后一天,同样也是我在埃森哲工作的最后一天。

来埃森哲专注于技术咨询的两年,是一个认知和格局升级的过程。在埃森哲的两年中,接触到了更高级别的客户和更具备挑战的问题。在这个过程中,我收获了很多的咨询和实践经验。特别是今年,参与了两个客户的数字化转型。能够把我之前积累到的知识和技能统统用上,算是一件幸事。

然而,在埃森哲的咨询工作并不会给我一个固定类型的项目和时间用作积累。经常是哪里需要就前往哪里。这种不断更换项目内容和类型的工作方式有好也有坏。好的一面是能不断训练我让我对新环境的适应力会不断变强,但不好的一面就是容易变得浅薄,无论是知识积累还是客户关系。这对长期做咨询来说是不利的,毕竟客户需要的是你的专业服务,而专业是需要时间积累的。

很多时候人都会陷入对未来的迷茫中,如果想知道未来要往哪里去,最好还是要看你过去从哪里来

我总结了一下我过去几年的工作经历,找到了以下五个关键词:

  1. 咨询
  2. 敏捷和DevOps
  3. 架构
  4. 云计算
  5. 数字化转型

咨询 #

总的来说,我还是很热爱咨询工作的。一方面可以拓宽眼界,另一方面,可以帮助他人解决问题。在咨询中对学习到的知识有更深刻的理解和更广泛的应用。和同事、客户的合作就形成了一种彼此滋养的关系。

中国的咨询行业缺乏体系化的职业培养和训练体系,这是由市场客观条件决定的。于是,我在自己做咨询和培养新晋咨询师的过程中总结了一系列原则和方法。一方面帮助自己在咨询项目中成功,另一方面用于帮助很多新晋咨询师。有些方式方法的反复实践印证了一些有效性,当然,咨询项目中还是会因为各种因素不同程度的“悲剧重演”。然而,这些原则和方法可以帮助我走出困境。明年也会将这些心得通过公众号分享出来。

敏捷和DevOps #

敏捷是一条持续精进且没有尽头的旅程,它是一种有效的生活方式和工作方式。今年我在一个客户上实施了 SAFe,也第一次让我完整了理解了规模化敏捷所要面对和解决的问题。想到之前和一群反对SAFe的人批评一起人云亦云,就觉得惭愧。现在理解到自己也曾经是没有实践过 SAFe的“嘴炮派”。

在体验了 SAFe 后,我报名参加了 SAFe 的认证咨询师(SPC)培训,并且通过了认证。同时我还通过了 SAFe 敏捷软件工程,SAFe 架构师和 SAFe DevOps 的认证以及培训师资格。学习的越深入,越发现 SAFe 这套体系的厉害之处。SAFe 解决了很多我在经历企业IT治理和数字化转型中所遇到的问题。

今年给不同的两家客户做了敏捷和 DevOps 转型相关的工作。我发现随着 DevOps 运动的持续深入,企业通过 DevOps 所需要的是一套完整的 IT 治理和研发管理体系。而“DevOps”虽然是当今数字化企业的必备,但新面临的各种问题却超出了 DevOps 的范围。

但是,我不赞成把 DevOps 泛化和扩大化。否则做 DevOps 就变成了无所不能的“假药”。

你可以简单理解 IT 行业就是“卖春药”和“卖假药”相互交替的过程。前者给你一个无限憧憬和期望,后者则是实践落地的一地鸡毛。“敏捷”,“DevOps”,“微服务”,“云原生”和数字化转型都被不同的IT巨头们当作春药和假药来卖。

这是“软技术”跟不上“硬技术”发展过程中的必然。但从制度经济学角度来看,这并不是什么新鲜事。制度转换的过程中有两个交易费用——寻找制度的费用和转变制度的费用,这两者只能在边际上区分开。我要补充的一点是,这两个费用可能是同时发生的。

在企业数字化的过程中一定会有自己的产品,也会需要构建自己的研发能力。这些能力采购不来,只能尽早开始积累。因为于管理的通用 IT 产品已经无法满足企业构建核心竞争力。因此,产品经理会是未来数字化企业的核心竞争力。所以,对于缺乏产品思维而只会一味“提升研发效能”的组织来说,是一个降维打击。

你可能会觉得“产品规划”属于“提升研发效能”的领域,我也认可这种想法。这里面涉及到一个“效能的边界”问题。但事实上我所碰到的客户(能代表大部分企业),因为组织结构和权限的关系。并没有把“产品规划”纳入“研发效能”的范畴。所以,这里还是尊重客户对“效能”边界的定义。

对于以上这些问题,SAFe 5.0 已经有了比较体系和完善的解决方案。接下来我仍然会继续这方面的实践。DevOps 会成为研发“新常态”。

云计算 #

我在 ThoughtWorks 工作的最后一年,开发了一套亚马逊云计算(AWS)的架构实战课程。它总结了我在AWS上为客户实施云计算架构的一系列最佳实践所必要的组件。帮助零基础的学员快速的掌握云计算的必备技能。

可惜的是,加入埃森哲之后,没有机会继续做云计算技术相关的工作了。这本身是我的比较优势,却很难得到发挥。不过,今年年底为某个云计算企业规划云计算业务未来的蓝图让我对云计算在中国的落地有了新的认识。

云计算是企业数字化转型中的必然基础设施。它的好处是“单一软硬件解决方案供应商”,节约了企业管理多个软硬件供应商以及相互适配的成本。但这同样也是它的坏处,形成供应商锁定。随着开源和开放标准的出现,企业将会储备自己的基于云计算的研发能力。这也是企业核心竞争力的一部分。

单个领域的技术和产品的演进是非常快的,但整合解决方案的演进就不会这么快。这涉及到组织结构的演进速率问题。因此,虽然软件技术和硬件技术从传统的服务器发展到了云计算。但企业本身的组织架构和应用架构却并不会跟着演进。只有新的企业用新的商业模型和组织模型对行业进行了颠覆。才会促进行业的演进加速。

架构 #

我在埃森哲这两年的工作的大部分时间都围绕着“架构”这个主题:帮助客户的产品设计应用架构,进行微服务架构的演进,并编写简化架构设计工作的制度和方法论。今年我在项目中把 SAFe 和领域驱动设计中的“事件风暴”结合。实践出一套规模化微服务产品的制度。明年应该会在这个方向上继续实践,并且整理出成熟的方法。

架构是数字化转型中不得不面对的问题。企业的数字化转型走过了“无纸化”,“信息化”本质上是技术降低企业资源管理运营成本,使得企业在进一步规模化中大幅降低边际成本。但这些应用系统并未延伸到客户那里。只有和互联网结合,把外部的客户侧和内部管理侧系统对接。才称之为数字化转型。

这并不仅仅是技术的变革。

今年很多企业都在开展各种“一站式”的项目,这本身就是数字化转型的需要。一站式不光要拉通企业内部的 IT 系统,更需要有效的组织企业内的各部门。因此,“一站式”从用户的角度看只是“前台”,你还需要“中台”。

数字化的转型中,不得不提到的概念就是“中台”。企业级的 IT 系统都是需求驱动而非产品规划驱动的。当数字化转型让企业从“需求驱动”转变为“产品驱动”的时候就要先从客户侧开始。而客户侧所对应的就是“前台”。

前台需要有一个能够统一整合企业内部各领域的烟囱系统的统一提供数据和服务的,避免重复建设和浪费。这时候就需要有一个组织来负责这个事情。这个组织,就是“中台”。所以,中台不是技术概念,而是一个组织概念。

上一个试图解决这个问题的概念是“SOA”,可是 ESB 带来的中心化协作问题又让“SOA 春药”变成了“SOA 假药”。敏捷,DevOps,微服务和云原生都选择不去面对“康威定律”。让技术的归技术,业务的归业务。直到“中台”的出现才扯下了这个遮羞布,去面对真正的问题。这包括数据责任的归属企业级通用数据标准的制定。“限界上下文”的解决了前者。API 治理(OpenAPI)解决了后者。

这不是又回到了集中式管理吗?没错!只不过这一次业务部门的加入解决了IT部门话语权较低的问题。而且,现在的技术门槛更低,供应商更多了。这俩就是“微服务”实施中最难的两点。但“业务中台”需要在企业内部重新划分资源蛋糕,所遇到的阻力不是技术人员能搞定的。这也就是那么多做中台的企业只有“数据中台”能活下来的原因。

数字化转型 #

聊了那么多,都在围绕“数字化转型”。这是我从前面几个关键字中总结出的线索。我未来职业生涯的核心还是利用我的技术优势(敏捷和DevOps,架构以及云计算技术)在这个领域上积累和沉淀。

我个人觉得 2020 年是数字化转型的元年。60年一甲子,“庚子年”总会遇到世界级的大灾难。一场疫情让“互联网上的国家”战胜了“车轮上的国家”,也让数字化转型变得更加急迫。

至于下一份工作在哪里,马上就会公布。让我用这短暂的休息时间来补偿一下我的家人。

关于 2021 #

今年想和你唠的嗑,全都写在这一篇短短的总结当中了。

2021,新的开始,期待与你相见。