货运崇拜

Source: Dev.to

Introduction

Hey friends!

你有没有注意到，人们有时会复制一种好做法的形式，却并没有真正理解其背后的原因？我们给这种现象起了个名字：cargo culting（仪式崇拜）。

这个名字来源于二战太平洋战区：在该地区，美军和日军在被占领的岛屿上修建了跑道。飞机满载补给降落。战争结束后飞机离开了，但一些当地岛民仍想要更多货物。他们观察到占领军在建跑道，便做出了因果的逻辑跳跃，开始用竹子铺跑道、雕刻木制收音机，甚至点燃火堆模仿降落灯塔。他们给朋友们配上竹制“步枪”，进行整齐的列队演练。他们做了所有看起来像能带来货物的事，却再也没有飞机回来。

When Technologists Create Cargo Cults

在我的职业生涯中，我遇到过许多 cargo cult 的例子：

• 管理层宣布要“更敏捷”，但正如 Jez Humble 著名的说法，“唯一改变的就是我们站着开会”。
• 团队通过创建一个“DevOps 团队”来采用 DevOps 实践，而不是让开发参与运维、运维参与开发。
• 宣布需要测试自动化、静态分析或其他某种开发实践，团队照做了，但没有人相信这些测试或扫描能够在发布（或阻断）流水线时起作用。

并非所有例子都与软件开发生命周期有关：

• 最近公司纷纷宣布返岗（Return‑to‑Office）政策，常常以“因为其他大公司都在这么做”为理由。
• “扁平化组织”并裁撤大量中层管理职位的趋势。

我并不是要抨击这些想法（好吧，也许我对 RTO 有点小小的怨言）。问题在于它们的实施缺乏理由或数据，只有“$SOME_OTHER_COMPANY 正在做，我们也必须跟着做”。

cargo cult 的真正危险不是竹子跑道，而是错误的进步感。你感觉自己很忙，外表看起来很官方、很专业（甚至可能显得很有见识），但实际上并没有任何进展。组织的绩效没有可衡量的提升，愤世嫉俗的情绪蔓延，工程团队翻白眼，领导失去可信度，甚至好点子也会被归入失败的仪式之中。

How to Escape the Cargo Cult

我们是不是应该永远不再参考其他组织？荒唐！我们可以借鉴别人的做法，但必须理解其背后原理。以下是几条可以帮助你摆脱仪式崇拜的快速建议：

• 连续两次问“为什么”。 当领导层推出新倡议时，回击并询问它要解决的具体问题。如果他们说不出答案，你可能正要建一条竹子跑道。第一次的“为什么”可能得到公司口号；第二次的“为什么”会让你突破表层回答。
• 进行小规模实验。 与其在全公司推行完整框架，不如在低风险的角落先试验其中一块。先学习，再扩展。正如朋友所说，这就像地毯清洁剂上的警示：“先在不显眼的区域测试”。
• 衡量结果，而非仪式。 必须衡量正确的指标！不要统计你开了多少站会；要统计决策或发布速度提升了多少。不要只算关闭了多少工单；要衡量因变更导致的、影响客户的故障频率。
• 根据情境进行调整。 在拥有 10,000 名工程师的亚马逊有效的做法，未必适用于五人小团队。某些实践可以直接迁移，但你需要深思熟虑；改变越具破坏性，你就越需要提供充分的依据证明它是必要的。

Wrapping Up

模仿他人本身并没有错。这是我们几乎所有事物的起点。孩子们在懂得语法之前先通过重复声音学习语言。初级开发者在掌握架构模式之前先复制 Stack Overflow 的代码片段。但在某个阶段，成长意味着要问为什么。

如果你手里只有一把竹子步枪和一个木制收音机，你并不是在建跑道——你只是在玩“士兵”。