数字化转型中，我们应该关注传统工程存在生产率问题

本文最初发表于 Medium 博客，经原作者 Arnaud Doko 授权，InfoQ 中文站翻译并分享。

摘要：我们正在非软件工程中解决一个巨大的问题，这个问题在现有的知识管理解决方案中存在系统性的缺陷。对局外人来说，这个问题看起来并不明显；但对局内人来说，却很令人沮丧。工程师（我们的用户）用脚投票，为已有的解决方案使用代价高昂的变通方法，显示了这个被忽视的用例对他们有多重要。

如果你从事科技行业，你很可能听说过我们这个时代所谓的“大停滞”（Great Stagnation）。20 世纪 70 年代发生了一些事情，如今，突然之间，比特世界主宰了所有的科技进步，而原子世界却被远远甩在了后面。Peter Thiel、Tyler Cowen 等人有一句名言：

“我们想要飞行汽车，结果却得到了 140 个字符。”

但是他们说的有道理吗？举个例子：Instagram 在早期的时候，估值约为 10 亿美元（2012 年被 Facebook 收购），而那时只雇佣了 6 名软件工程师。与劳斯莱斯（Rolls Royce）这样的原子世界中更为传统的工程公司进行对比：2018 年，它雇佣了约 17000 名不同学科的工程师（大部分是非软件领域的！），但其市值只有约 270 亿美元。

它仅仅是一个例子，也许只是一个粗略的价值比较，但是软件与非软件之间的脱节确实存在，而且显而易见。这个问题值得一问：为什么软件工程师创造的价值要比他们的非软件工程师同行创造的价值高出两个数量级？

Thiel 的观点非常清楚：除了计算机科学之外，任何工程学科（机械、化学或核工程说）都是灾难性的职业选择。计算机科学就像黑暗中的手电筒，发出孤单的、狭窄的“进步之锥”，而非软件工程则盲目地在后面蹒跚前行。但是，事情本不应该发展至此。

软件工程与非软件工程之间巨大的生产力差距是如何产生的？我们认为主要有两个原因：

1. 加强监管

非软件工程的监管力度明显更大。与开发送餐应用相比，管理飞机设计的标准更多。这是件好事。但是，非软件工程团队却要承担这些额外的合规开销。与此同时，全球加强监管的趋势仍在继续。

2. 软件是完全不同的行业

一个关键的区别就是软件工程和非软件工程的构建成本。如果产品是比特而不是原子形式，则开发复杂系统的成本相对较低。

为了弥补这一差距，非软件工程师已经开发了复杂的计算机辅助工程（Computer-Aided Engineering，CAE）工具，以便将更多的工作引入比特领域。迄今为止，这种方法已经取得了巨大的成功，但是它也引起了数据方面的问题。如今，由非软件工程师生成和处理的数据存在于分散的、有时是物理的、并且常常是非结构化的位置和格式中。

我们要解决这两个问题，从第二个问题开始，然后扩展到第一个问题。

这个问题听起来并不新鲜，现在肯定已经解决了吧？

是也不是。现在有许多工具可以用来管理非软件工程数据并减少合规性的努力。知名的公司包括西门子、PTC、Autodesk 等。它们本质上是数据库解决方案，解决了数据库形状的问题。这一系列工具通常被称为产品数据管理（Product Data Management，PDM），或者更广泛的产品生命周期管理（Product Lifecycle Management，PLM）。

那么，PDM/PLM 系统有什么问题？

问得好。外面的人是不会知道的。但如果你在一家使用 PDM/PLM 的工程公司工作，你会发现有些东西很奇怪。你将发现，在项目的早期阶段，工程团队倾向于避免使用 PDM/PLM。

为什么呢？项目的这一早期阶段研究得很透彻，它有一个名字：就是模糊前端（Fuzzy Front End，FFE。译注：指模糊的项目前期，产品开发前期）。这个阶段在项目中是最模糊的，因为需求是最不明确的，而且工程师所开发的解决方案也会经常改变。而这往往是一种边缘化的混乱。

下面举几个例子来说明工程师在 FFE 中所做的事情：

完全避免 PDM/PLM，并将文件存储在云端（如 GDrive 或者 Dropbox），同时通过文件命名约定手动维护版本控制。使用手机拍摄团队白板会议照片，并通过邮件或 Slack 发送到项目团队。然而，几天后，哪张照片拍摄的是最新达成一致的设计修改，却令人费解。搜索收件箱中最近的客户需求列表（PDF 文件或 PPT 文件）同事可能已经收到了——最好赶紧打电话跟她问清楚！

PDM/PLM 系统有一个用途：它们提供了项目的可视性，不同连接部分的可追溯性，以及谁为具体工程决策签字的问责制。该系统旨在使公司能够通过 ISO、监管机构和客户的审核。

上述均要求在 PDM/PLM 中输入的数据一旦锁定，就很难更改，且速度很慢。在 FFE 中，这与工程师的工作性质是背道而驰的。工程团队有意避免使用 FFE 中的 PDM/PLM，以揭示他们的偏好。他们用脚投票，告诉我们还有一个用例还没有解决。没有一个已有的解决方案为 FFE 的用例提供服务。

模糊前端的生活：PDM/PLM 的任职者未能在工程项目的早期阶段为工程团队提供服务，这一阶段最灵活、最有成效。

那么，最后的结果反而是什么呢？

在缺乏适当的技术的情况下，出现了两种非技术的应对策略：

投入更多的人力时间去解决问题：很多工程公司聘用项目经理团队来解决 FFE 混乱的问题。在 PDM/PLM 系统中，这些项目经理手工确保数据的完整性，执行团队的数据管理纪律。这种解决问题的方法花费不菲。对小型企业而言，这是它们无法承受的奢侈品。依赖于组织过程：在某些情况下，项目的利害关系方会张开双臂，接受事实，即他们在 FFE 过程中将具有最低限度的可视性、可追溯性和问责制。对于拥有数千名员工的大公司来说尤其如此。取而代之的是，项目利害关系方将等待他们瀑布过程中自然的项目里程碑来做出决策。

通常，这个里程碑是第一次设计评审。这个会议有一个最后期限，所有的项目数据都必须更新，并为评审做好准备。实际上，工程团队已经在 PDM/PLM 以外的地方工作了几个星期或者几个月，然后争分夺秒地上传所有的数据，直到设计评审截止日期之前。在 FFE 期间出错，将对整个项目的其他部分造成巨大的下游影响。有许多证据表明，FFE 的决策在很大程度上决定了项目的成本、质量和进度。

作者简介：

Arnaud Doko，供职于 Thea 公司，研发、项目管理和客户管理。面向汽车、医疗机构和咨询。

原文链接：

https://medium.com/usethea/traditional-engineering-has-a-productivity-problem-and-nobody-is-talking-about-it-876db1fb8e1b