《数字化转型》笔记（2）—— 领导者必备的技术思维

这一篇是一个总体，是后面几篇的索引，是“总分”模式的“总”。

提高技术水平

在传统行业里，IT被视为成本中心，说白了IT部门就是个只烧钱不盈利的部门。传统行业认为，软件系统找谁来做都是一样的，因此企业会找最便宜的软件供应商。这种想法是非常错误的。

软件系统是企业的战略资产，需要持续演进与业务适配，不是一次性的投资。要想使业务脱颖而出，就需要持续交付有差异化竞争优势的功能。

软件质量

软件质量是代码设计与实现的度量，对最终用户是不可见的。混乱的代码会减慢每个人的速度，在添加新功能或者优化时变得非常耗时、昂贵且不可持续，最终没有办法在业务部门可容忍的时间内交付有价值的功能。

与现实世界的商品不同，现实的高质量商品往往很昂贵。而软件恰恰相反，高质量意味着未来更便宜。

技术债

只具备良好的前期设计是不够的，设计总会随时间的流逝而腐化。

新的需求可能扰乱原始的设计意图；低水平的工程师会引入混乱的解决方案；面临交付压力时，技术实现上被迫走捷径。这些事情每天都在发生，我们称之为技术债。

承担债务必须支付利息，这个利息是：开发新功能或者维护系统时，需要付出额外的努力。等到技术债太多的时候，在原有系统上扩展功能的成本将变得非常昂贵。

工程师水平

传统行业寄希望于高级工程师来设计，初级工程师来编码。在这种模式下，当软件需要持续演进时，系统将很快崩溃。因为战略性数字资产中不存在简单的编码任务。

即使拥有高水平的工程师团队，技术债依然会增加。如果开发团队尽早、频繁地持续检查和修改这些技术债，就能将技术债保持在较低的水平，减缓软件腐化的过程。

业务与技术领导力

管理技术债最困难的部分，是在业务领导者和技术领导者之间达成平衡，不要只关注交付的功能和需求的数量，要在软件质量上做适当的投资。由于这常常与交付业务需求发生冲突，因此是一个有挑战的平衡。当开发人员发现代码难以维护，交付速度受到影响的时候，领导者就应该支持团队投入时间来偿还技术债了。

赋能人才

DevOps与持续交付需要更多的多面手，平台思维和现代架构要求洞察最新的技术趋势，这些都归结于人。你拥有完成这些任务所需要的素质和数量的人才吗？这是灵魂之问——你只有几个医生，也想学别人开综合性三甲医院？获得和留住数字化人才已经成为数字化转型过程中最重要的任务之一。

传统管理智慧要求技术尽可能多地外包，特别是低成本的服务供应商。这造成了大量的技术债，还失去了对技术知识的积累。那么应该去哪里招聘数字化人才呢？首先要关注的是企业内部，而不是外部。重点关注两个方面：

• 建立学习型文化，使员工不断进步
• 营造赋能员工的环境，使员工更快成长

构建学习型文化

数字化时代，技术进步的速度越来越快，把所有人推向了终身学习的模式。这听起来令人生畏，但也意味着从任何时候开始学习都不会太晚。

传统的运营心态是规避风险。在数字化时代，大多数的试验都会以失败收场，关键是要从失败中学习，而不是试图避免失败。

大多数企业为员工制订了培训计划，但这个回报不是立竿见影的。培训预算不应该被削减，否则将会传递出错误的信号——学习是可选的，可以随时停止。这里说的培训，是成体系的培训，包含理论和实践，可能需要脱产学习数周的时间，而不是那种只有两三天的、蜻蜓点水般的宣讲。

构建赋能型文化

自主权、掌控力和使命感是最能激励现代知识型员工的三个关键因素。人们选择工作地点和工作内容的深刻原因，是能够控制自己的行为和目标。

构建培养和赋能的环境，有助于释放现有员工尚未开发的潜能，还有助于从外部招聘和留住人才。以培训与发展数字化人才而闻名的企业，更容易吸引有抱负的人才，让他们不大可能为了更高的薪水而离开当前的企业。招聘人才的建议是，更多地关注学习意愿、学习意志力和学习能力，这比现有的经验水平更重要。

最后，还要找到合适的数字化合作伙伴。技术领域已经足够广泛和复杂，任何一家企业都很难在所有领域拥有深厚的专业知识，专业人员的数量也是有限的。这种情况导致需要多种策略来获取数字化能力，一部分来自内部培养，一部分来自资源共享，一部分来自外包。虽然没有固定套路的解决方案，但是以降低成本为原则的传统外包方案已经过时了。数字化合作伙伴必须能与自身的数字化团队紧密合作，形成整体团队的氛围，不能只是简单的甲方和乙方的关系。

持续交付与DevOps

敏捷方法可能是数字化转型的主要障碍，即使IT部门认为它正在进行敏捷软件交付，实际上也需要进行技术、文化和组织结构的变革，来实现真正的敏捷交付，从而快速向客户交付最大价值。

持续交付

持续交付是指将软件交付过程从缓慢的节奏、较长的发布周期变为快速、增量与迭代的交付方式。团队确保开发的每个功能在任何时候都能发布到生产环境，部署时间变为由业务决策。

为了达到这个目标，产品团队需要以下技术和实践：

• 组建包括业务人员在内的小型跨职能团队（组织结构有职能型、项目型、矩阵型三种）
• 将需求分解为更细粒度的、有价值的、可发布的单元
• 在一次迭代中，完成一个小需求
• 编写自动化测试脚本
• 使用自动化技术，从开发到生产环境启用“一键部署”
• 将基础设施“作为代码”来管理，实现可伸缩性和灾难恢复（这点看不明白）

DevOps

DevOps是一种文化运动，是让开发部门和运维部门更紧密地协同工作，让运维专家成为开发团队的一部分，使运维专家能够向软件开发过程提供早期反馈。

一个建议的方法，是让同一个人来做开发和运维的工作，让开发和运维的技能在同一个角色中融合。这个难度非常大。

数字化平台

从长远来看，数字技术平台是现代企业需要采纳的一个关键步骤，从而能够以更快的速度、更高的质量和更低的成本向客户提供新的价值。

• 模块化架构：软件由细粒度服务构建而成，这些服务可以在不同功能中重用，由稳定的团队独立构建、部署和运行，通过API公开服务。
• 自助访问数据：让团队能够“自助”地访问其需要的数据来创造价值，不会为了访问关键数据而陷入组织的繁文缛节中。
• 交付基础设施：团队经常为了申请服务器、数据库、网络和防火墙之类的基础设施而等待。如果团队能够自助创建开发环境，就能减少试验的开销。

将数字化能力、数据和基础设施打包到服务中，所有团队都能方便地访问这些服务，这就形成了市场或者平台的概念。

产品胜过项目

“产品”是IT行业的一个重要流行语。将面向客户的“事物”作为产品是一个有用的想法，但不面向客户的部分通常很落后。

产品的主要特点：

• 产品解决某个问题或满足某个需求
• 产品与其他竞品有独特的差异性
• 产品是为明确的客户群体设计的

“产品思维”与传统的“项目思维”有强烈的对比。在项目思维中，任何举措都被分解成一系列具有明确范围、预算和日期的项目，项目要在规定的时间内完成。而产品如果能创造价值并解决客户需求，那可以存在很长一段时间。比如微信，按照项目思维，它上线之后，项目就结束了，但作为一个提供即时通讯的产品，它可能会存在几十年。除此之外，产品与项目还有其他不同：

• 项目将相关技能的人聚集在一起，项目完成后，团队被打散并重新分配到其他地方。产品的团队是稳定的，其成员为产品长期工作。
• 项目根据估算投入来投资，不能超出预算范围。产品根据所需的团队规模来投资，并且是长期投资。
• 项目的主要目的是“按时间、按预算”完成项目。产品的主要目的是为客户创造价值。

IT部门的未来

一项对年收入10亿美元以上企业的调查显示，64%的受访者对自身IT组织支持数字化转型的能力缺乏信心。该调查还表明，IT工作量和IT员工增长最快的，是在IT部门之外。业务部门正在投资自己的IT能力，不想依赖于IT部门，这是对IT部门的挑战。“业务人员需要开始使用技术语言”，现在是取得进展的时候了。

围绕业务能力或者客户成效来建立团队

在数字化时代，随着客户期望的提高，越来越多的系统需要协同工作，向客户提供所需的服务和体验。这既是技术上的挑战，也是组织结构上的挑战。新的团队应该按照业务运营方式来建立，而不是按照业务和IT职能来划分。

双速IT不可持续

所谓双速，是指易变的应用层系统采用敏捷交付的方式，而核心遗留系统为了安全、稳定采用慢速的交付方式。这导致数字化产品的快速开发-发布周期与后端系统僵硬而缓慢的传统长发布周期产生冲突，组织以最慢部分的速度前进。

关键点

本篇要点

• 所有领导者需要最低限度的技术认知，了解数字化转型的影响
• 理解关键技术的概念，更好地应对增长的客户需求、变化的速度
• 所有领导者需要支持团队采用更严格的技术规则

锦囊

• 给企业 领导者们设置关键技术概念的基线，将其加入成功变革的愿景中
• 通过能力提升和招聘来发展内部技术人才