跳到正文
讨论欧洲为什么在与中国、美国的竞争中落后，人们经常提到高福利、工作习惯、文化差异和官僚主义。但在我看来，这些解释还没有触及一个更基础的问题：欧洲整个系统组织创新的方式，已经跟不上技术发展的时代节奏。
这个问题可以用两个工程概念来理解：Waterfall，也就是瀑布式开发；DevOps，也就是把开发、部署、运行和反馈连接起来的持续迭代。
工业成功留下的组织逻辑
欧洲过去的工业成功，与精密规划、标准化、明确分工和严格的流程控制密切相关。制造复杂机械、组织大规模生产，需要提前确定要求，设计好各个环节，再按照顺序执行。用今天的软件工程语言来描述，这是一种 Waterfall 式的组织逻辑：先规划，再设计，再生产，再交付，每个阶段满足条件以后，才能进入下一个阶段。
这套逻辑曾经非常有效。正因为它取得了巨大成功，它逐渐超出了生产流程本身，进入公司治理、国家治理和人们的思维习惯。整个系统倾向于相信，只要事前规划足够完善、规范足够清晰、审批足够严格，执行就能够得到可靠结果。
现实怎样参与产品形成
然而，今天许多技术领域面对的是高度不确定的环境。产品究竟有没有价值，用户会怎样使用，部署后会出现什么问题，哪些功能应该保留，哪些方向需要放弃，都需要通过实际运行才能逐渐知道。再完善的计划，也无法提前获得所有这些信息。
DevOps 所体现的，正是另一种生产模式：提出产品，进行部署，观察运行，取得反馈，修改产品，然后再次部署。开发与使用连接成一个不断循环的过程，现实持续参与产品的形成。
准入与反馈的先后顺序
我认为，中美与欧洲在科技开发上的本质区别，就体现在这里。
中美的科技开发更倾向于先把产品做出来，通过市场和部署推动迭代。产品进入使用以后，开发团队不断发现问题、调整方向，技术与市场一起演化。
欧洲则把大量规范、流程和审批要求放在市场准入之前。产品必须先符合这些要求，才能进入市场；如果无法通过监管或满足规范，实际部署就可能根本无法发生。
在欧洲生活，或者在欧洲工业界工作的人，对这种流程优先的运作方式往往有非常直观的感受。一个项目的推进，始终伴随着对程序、标准和权限的确认。开发团队能够多快完成工作，只是其中一部分；整个系统允许它多快进入现实使用，才决定了完整的迭代速度。
这一区别的后果会不断累积。部署推迟了，市场反馈也随之推迟。团队无法及时知道自己的假设哪里有问题，无法迅速修正方向，也无法开始下一轮有效试验。等待审批所消耗的，是交付时间，也是整个组织的学习时间。
在高度不确定的环境中，许多关键知识是在行动之后产生的。如果一个制度要求组织在行动之前就完成充分论证，它就容易让人花大量时间证明尚未被现实检验的假设。
Scrum 为什么跑不起来
这也是为什么，欧洲的强监管和流程体系会打断 Scrum 所需要的迭代循环。
一个团队可以每两周开会、安排任务、完成一个 sprint，但如果产品仍然无法部署，预算变更仍然需要漫长审批，技术调整仍然必须重新经过一系列审核，那么整个系统的速度并没有随之改变。团队内部完成了一轮开发，却没有完成一轮“部署—反馈—修正”。
局部的敏捷，被外部的瀑布式体系限制住了。
从工业优势到制度惯性
因此，我说欧洲缺少 DevOps 思想，指的是这套思想没有充分成为整个系统的运行原则。即使欧洲有人提出过它，也有企业采用它，都不能说明公司治理、监管机制和国家治理已经围绕持续迭代重新组织起来。思想的存在，与思想能否在现实制度中发挥作用，是两个不同层次的问题。
当预算、责任、绩效和准入都围绕事前流程安排时，组织自然会把大量注意力放在如何通过审批上。久而久之，完成规定程序成为最明确的目标，快速验证产品价值却很难获得同样的制度支持。
欧洲过去的工业优势，被精确地转化为今天的转型阻力。曾经带来成功的规划、标准和控制方式被固定下来，继续被用于需要持续试验、持续部署和持续修正的领域。环境变了，整个系统对工作的基本理解却没有同步改变。
这也意味着，增加研发投入、招聘更多工程师，未必能够解决问题。如果部署和反馈的入口仍然被同一套机制限制，新增资源依然会遇到同一个瓶颈。
欧洲应该正视这种工程与制度之间的关系。人事安排、利益协调和政策口号，无法替代对系统运行方式的理解。真正需要改变的，是治理如何容纳不确定性，如何让现实反馈及时进入决策，以及如何允许产品在使用中不断完善。
在我看来，这就是欧洲竞争力问题最根本的机制：一个在 Waterfall 时代取得成功的整体系统，正在用原有的组织方式参与 DevOps 时代的竞争。
如果欧洲无法改变这种运行逻辑，它失去的将是一轮又一轮学习和修正的机会。竞争者不断通过部署获得新知识，欧洲仍在为进入下一阶段完成程序。随着时间推移，这种迭代能力的差距，就会变成产品、产业和竞争力的差距。
（很遗憾的是，这恐怕正在变为现实）
