工程文化复兴：数字化转型成功的关键

本文要点

• 为具有竞争力，组织中的各个部门都必须在数字化上表现出色。
• 持续更新和转型正成为一种业务常态。
• 软件工程团队必须给出引领变革的创意。
• 自上而下的干预对工程文化造成破坏。
• 为实现持续变革，现在应恢复那些支撑软件成功的核心实践。

Finbarr Joy 指出，团队可以创造出自己的可持续发展环境，从而对交付的内容和方法提供创新的见解。团队管理者必须对持续改进和革新的需求做出预估，否则将会受到“自顶向下”方式驱动的“数字化转型”的干扰，这种干扰会挫败软件工程实践。当前正是团队恢复软件工程实践的时候。

在 QCon 2018 伦敦大会上，Superbet 集团首席技术官 Finbarr Joy 就工程文化做了一次演讲。前期，InfoQ 曾分别报道了“构建伟大工程文化和组织”分会的上午议程情况汇总和下午议程情况汇总。

InfoQ 采访了 Joy。采访内容包括，“自顶向下驱动转换”方式的项目是如何阻碍工程文化的、Superbet 具有怎样的工程文化、软件开发团队应如何嵌入工程文化，以及在支持并改进组织的工程文化过程中管理者应该如何做。

InfoQ：您在演讲中谈及，“自顶向下驱动转换”的项目会阻碍工程问题。您能详细介绍一下吗？

Finbarr Joy：“数字化”的需求正以前所未有的规模和速度席卷各个行业，在许多组织（尤其是一些大型企业）中，存在着难以跟上这一趋势的问题。由此，我们看到了在那些由管理人员（通常是管理顾问和分析师）召入团队的同事中，出现了另一个由一些技术、工具和词汇表构成的“平行宇宙”。虽然管理人员的这些干预措施本身是源自于敏捷等良好软件工程实践，但他们对这些措施的解释和实现是与工程实际相脱节的，因此这些措施毫无意义。尤其需要指出的是，我看到出现了一个由一些“现成可用的”框架和技术所构成的市场。企业购买者希望能从这样的市场中获取“快速修复”企业“IT 困境”的解决方案。不幸的是，这个蓬勃发展的第三方咨询市场仍需要进一步培育。

由此，导致人们主要关注的是如何开展大规模的采纳过程。在此过程中，各位同事被一批批地被纳入到“经认证”类中。人们看重的是如何走完“仪式”化的流程，而非如何去改进客户和软件产出。

正如我们从这次召开的 QCon 大会中所能看到的，许多组织当前正处于数字化转型的第二次甚至是第三次浪潮中，并且烧光了“变更预算”（感谢 Kevin Goldsmith 给出了如此贴切的比喻！）。团队不再考虑如何通过敏捷等方式进行持续改进。在过去的数年中，我曾遇到几个团队，敏捷对于它们而言已成为一种诅咒，因为他们依据的只是一些在任务和仪式上毫无意义的经验，并且在敏捷的“风味”或时尚发生改变后，仅在数个月后就陷入到另一套同样随意的任务和仪式中。很少（如果有的话）在商业过程或文化上发生任何真正改变。

另一种常见的干预是构建一种“创新实验室”，以此作为组织中“数字化响应”的孵化器。这种干预的合理性在于，“我们不能指望核心业务会在一夜之间发生变化”。另一方面，对于维持或改善季度业绩的实体，我们要维持其现状。因为在股东们的眼里，主张采用核心业务或产品的做法是完全没有风险的。此类做法虽然在组织的安全“沙坑”内隔离了一些“有趣”的发展，但却会让核心业务停滞不前。同时，此类做法也会阻碍通过创新培养蓬勃发展的工程文化，并将此作为所有人的核心责任。

总而言之，尽管许多转型中的企业不断宣扬着以“自主团队”、创新和软件为核心业务的必要性，但对于真正的“自顶向下”的变革而言，缺少的是发起者，以及切实采取行动者（多家分析给出的转化失败率浮动于 50% 到 90％之间）。这样做的结果是导致团队失去动力，并使工程文化失败。

InfoQ： Superbet 具有怎样的工程文化？

Joy： 在加速企业增长和建立可扩展性的同时，我们尽可能地维持了自然形成的“企业家精神”。在短短的八年多时间中，Superbet 已经确立了在中东欧零售投注市场中的领先地位。与此同时，在过去的一年中，我们重点投资建立了一个“.com”团队，面向全球范围在线推出企业的投注业务。在此历程中，我们完成了多次并购。所以说，Superbet 是一个多民族和多习俗的“大熔炉”，而创业才能居于其中的核心地位。举个例子，我们的斯洛伐克支付系统团队与我们的英国定价 / 交易产品团队是完全独立运作的，但在实现企业业务中，都采用了以实现为驱动的现有方式推动市场演进，即以内部的测试和学习能力作为核心实践。

在推进团队发展的过程中，我们注重从一开始就为工程文化确立正确的“条件”。举个例子，为了达成某个业务成果（“需要在日期 X 之前在某区域中启动”），由团队来决定如何实现这一目标。团队还负责招聘，这有利于团队选定新的成员，而不是由外部人力资源按“招聘”流程“塞进来”。最后，团队对追求创新负有重大责任，因此我们能看到围绕开源、机器学习和事件溯源架构等出现了一些突破性的举措。

InfoQ：软件开发团队应如何加入工程文化？

Joy：我认为现在是团队恢复软件工程实践的时候。尤其是，我认为对于构建一个健康工程文化得以蓬勃发展的环境，大多数团队都低估了自身所具有的裁决水平。

例如，当面临一个有挑战性的最后期限时，我们通常是否能看到一支志愿牺牲测试工作的团队，或者在没有特地权衡的情况下创建技能和技术债务的团队？下一次在给出一个新的需求时，不要主动投身其中（除非特地做了权衡），但应指出降低风险的最佳方法是重新审视业务范围。并非所有请求的事情都是完全有用的，因为这种情况非常罕见。开展更富有成效的对话，以此作为实现增量交付的连接纽带（“并非交付全部，让我们先交付一部分，然后看看所交付的是否会在完成其余全部工作之前，为我们提供一个有用的开端”）。

通过建立这样的模式，团队可以创造一个可持续发展的环境，支撑了生成用于交付形式和内容的创造性思维。

同样，我认为团队低估了自身的“自组织”范围。例如，无论该组织是否正式支持团队重组，成员都可以站出来，推动同事们围绕共同的利益组成一种“实践社区”。最终，可以在招聘新成员时，团队可以积极定义那些发挥作用的特征。相对于“工厂化”的人力资源流程，团队在此过程中将具有更多的掌控权。使用这种模式，团队通常会在基准测试中采用更丰富的特征。例如，一位意向召入的团队成员是如何处理特定的工程问题的，或者他们是如何向同事们提供支持的，如何填补他们以前闻所未闻的空白（而这样的意向成员，并不能直接通过企业的“技能列表”或“经验级别”过滤器筛选出来）。

所有这些做法，将会维持更好的工程环境，支持文化的发展，同时也会产生明显的变化，并给出持续改善的信号。因此，团队更不会倾向于任何自顶而下的变革，这些变革的驱动力来自于对正确情况的无知。

InfoQ：在支持并改进组织的工程文化中，管理者应如何做？

Joy： 需要说明的是，上面我所介绍的很多内容，是许多团队在发现身于不受支持的环境中时所幻想的美好世界。这是就是管理者必须介入之处。我们所有人都有所体会，这个世界已发生了明显的改变，软件能力作为商业成功引擎的途径已经确定，管理者的责任在于，和业务同行一起接受教育，确保理解其中的技术、实践和原则，并将其植根于组织当前必须支持的良好工程实践中。

虽然’数字’这一新术语会迷惑那些对此心驰神往的高管，令其兴奋得头晕目眩，进而判断力被“打断或受到干扰”（disrupt or be disrupted）。但应该看到，一些在软件交付方面具有实力的优秀团队早已认识到这个问题。例如，在贝尔实验室的 Unix 分时系统文档（自 1978 年就开始提供）中给出了如下的原则：

1. 让每个程序做好一件事情。新的工作需要全新的构建，而不是通过增加新的“特征”而使旧程序复杂化。
2. 期望每个程序的输出成为另一个程序的输入，尽管该程序当时可能依然未知。不要将无关的信息与输出混淆在一起。应避免使用严格的列状或二进制输入格式。 不要坚持使用交互式输入。
3. 应尽早尝试软件（甚至是操作系统）的设计和构建，最好在几周内完成。不要犹豫，抛弃其中笨拙的部分，并重新构建它们。
4. 为降低编程任务，应优先考虑使用工具，而不是求助于不熟悉的帮助。即使有时你必须绕路去构建工具，并且部分工具会在使用完成后就弃用。

参考文献：维基百科给出的 Unix 哲学.

如果我们将上述各条目中的“程序”替换为“服务”，就能给出最当前的关于微服务、云、敏捷和 Devops 的建议。可以说“天下无新事”！（译者注：原文为“nothing new under the sun”，语出自圣经）。

尽管前期的错误干预措施来自“居庙堂之高”的高层，但团队管理者不应该让数字化成为一种歇斯底里的“白噪音”，阻碍他们正确地为团队建立最佳环境、为客户提供愉悦的体验，以及培养表示着工程蓬勃发展的文化：

• 建立一种能够整合团队背后核心挑战的“使命”或目的，并为更多的自主工作提供“指引的光明”。
• 切实采取一些维持团队有效互动行为的行动，包括：相互尊重、主动沟通和建设性的挑战。
• 提供创新的“空间”。如果不是出于创新的考虑，那么我们为什么要编写软件（在 SaaS 世界中，尤其是那些没有标准业务流程可以直接拿来使用的领域）。
• 清除所有妨碍团队按需发布软件的外部团队和环境障碍（无需外部依赖性，更多“真实”的资源优先级，确保团队内部有完整的生命周期覆盖率）。
• 确保团队从定期反馈中受益，防止出现“死亡游行”的苦差事。在业务上取得一致，增量推动解决方案实现以证据为驱动的演化。
• 推动将维护“重构”时间作为每次发布的标准部分。这使团队能够保持技术债务和变化的可管理性，避免了终有一天会与“大泥球”搏斗（也推动更好的优先考虑）。

随着来自云、机器学习、“混合”现实、语音激活和加密货币理念的组合技术创新成为现实，当前是前所未有的构建软件的好时机。重新确立团队的核心实践，抓住机会，跨越未来。

受访者简介

Finbarr Joy 任 Superbet 的集团 CTO。Superbet 是一家新进入网络游戏行业的企业。Joy 曾在英国电信，William Hill 和 Lebara 等全球运营商中任职，推动技术转型。在 2000 年至 2010 年期间，他还联合创立并经营了一家服务于英国国内的电子商务软件开发公司。Joy 的早期经历还包括曾在将互联网带入世界的 Netscape 团队工作，他在其中建立了一种数字创新的持久模式。

查看英文原文： Engineering Culture Revived: The Key to Digital Transformation