Airport 95: Automated Baggage System?

Paper Link

https://dl.acm.org/doi/pdf/10.1145/227531.227544

一篇1996年的老文章。作为课程学习阅读。

这篇文章《Airport 95: Automated Baggage System?》由 A. John Swartz 撰写，主要分析了丹佛国际机场（DIA）自动行李处理系统的失败案例。文章以该项目为研究对象，探讨了大型软件/系统工程中常见的管理问题，并呼吁软件工程界系统性地记录和分析失败项目，以便从中学习。

你说得对，之前我像个在念技术报告的书呆子。让我重新讲这个故事——像一个老工程师坐在吧台边，边喝啤酒边跟你聊的那种。下次你再用“快速原型”去签一个大合同时，或者在项目中途轻率地答应客户“这个改动很小”的时候，想想丹佛地下那4000辆永远跑不起来的小车吧。

一个关于野心、傲慢和4,000辆小车的故事

一、梦开始的地方

1991年的丹佛，市政府在市机场里想干件大事。不是建个新机场，虽然这也是个大事，毕竟美国上一座新的大型机场还是1975年的达拉斯。真正让人兴奋的是：他们要让行李自己长腿跑起来。

想象一下，你从联合航空的柜台托运一个行李箱，它要自己翻山越岭，穿过一英里多的地下隧道，准确找到你飞机的登机口。而且这一切要在35分钟内完成。联合航空说，我们要让飞机快速掉头，不然赚不到钱。传统的牵引车拉着一串推车？太慢了。普通的传送带？距离太远。丹佛需要科幻片里的东西。

所以他们找到了BAE自动化系统公司。BAE搬来一个原型——一小段轨道，几辆小车，当着联合航空高层的面，让小车嗖嗖地跑起来，稳稳当当地把行李送到目的地。

“好极了！”联合航空说，“就它了。” 丹佛市也点头了，给了BAE 1.93亿美元的合同。虽然另一家Harnischfeger联合体的报价只要1.6亿，而且他们用的技术已经在东京、新加坡的机场跑了好几年。但BAE的原型演示太迷人了。在场的所有人都心照不宣地相信同一件事：系统已经差不多搞定了，只需要“稍微调调软件”。

这句话，成了整个故事里最著名的遗言。

二、第一次警报

其实早在那年前，就有人小声说过“不”。那是一家叫Breier Neidle Patrone的咨询公司。他们写了一份报告，白纸黑字地写着：

“关于单行李小车系统，考虑到它目前还只是个原型，我们强烈认为它无法在项目的时间表内实现。”

翻译成人话就是：这东西还嫩得很，你们别做梦了。但没人听。因为联合航空的大客户在催，因为机场要在1995年开业，因为“我们已经在原型上看到它跑起来了”。

你有没有见过这样的场景？一个项目里，所有人都很聪明，所有人都很努力，但所有人都在假装问题不存在。因为说实话太贵了：会推迟工期，会让领导不高兴，会让股价波动。他们把咨询报告塞进抽屉，继续往下干。

三、噩梦的开始

1992年春天，工程已经破土动工。突然，航空公司和市政府的人跑过来说：“呃，我们改主意了。系统要重新设计一下。”

不是微调，是“重大修改”。

这时候轨道已经在铺了，电机已经在装了，软件已经在写了。改设计？可以。但风险呢？没人做新的风险分析。接着是“地盘之争”。你见过建筑工地上不同包工头互骂吗？1992年10月，BAE的主管打电话告状：“另一家公司的人不让我们进现场。”这种扯皮一直持续到1993年。想象一下，你在修一座大桥，结果负责钢缆的人和负责桥面的人互相锁对方的门。

项目还怎么干？

四、那两次要命的测试

1994年4月，第一次集成测试。

他们铺了1000英尺轨道——差不多三个足球场那么长，放了200辆小车——别急，整个系统是17英里轨道、4000辆小车，这次测试只是全系统的1%到5%。计划是每天跑10小时，连跑两天。

结果呢？

第一天，小车撞在一起。不是轻轻碰，是保险杠互相卡住，锁死了。行李从车上掉出来，卡在轨道和传送带之间。传送带上的光电眼看不见那堆行李——设计的时候没人想到行李会堆那么高——于是传送带继续往里塞，行李越堆越多，像堵车一样。

第二天，更妙了：系统不知道哪些小车是空的哪些是满的。因为前一次死机的时候，它丢了记忆。重启之后，它以为所有小车都是空的，于是拼命往已经塞满的小车里装行李。行李掉得到处都是，小车一辆接一辆卡住。

测试人员站在旁边，看着屏幕上的红灯一个个亮起来，就像心电监护仪拉成了一条直线。不到半天，测试就叫停了。BAE的人说：“这些问题都能解决。”然后拉了一个清单，上面列着72项必须完成的硬件、软件和测试任务。清单很长。

距离机场原定的开业时间已经不多了。

五、咨询公司最后的诊断

1994年9月，德国Logplan公司来给BAE的系统做“体检”。他们跟BAE要一些关键数据——控制系统的设计、操作策略。BAE支支吾吾，没给全。Logplan最后交了一份12页的报告，措辞很客气，但结论像一记闷棍：

这个系统有可能在五个月内修好，但也可能……两到三年。

人话：我们也不知道。

六、机场开业了，但行李没有飞起来

1995年2月28日，丹佛国际机场在一片喧嚣中开业。政要剪彩，媒体闪光灯噼里啪啦。

但自动行李系统……只在一个航站楼跑了一个迷你版。而且那个迷你版的成功率是90%。

听起来还不错？可这意味着每10个行李里就有1个去了错误的地方。你站在行李转盘前等你的滑雪板，它可能去了巴黎——不对，它去了另一座航站楼的某个角落，跟陌生人挤在一起。

机场方面后来解释说，那10%的行李“并没有真的丢，只是需要人工去找”。人工去找。在一个号称“全自动”的行李系统里。那套花了几亿美元、铺了17英里轨道、装了5000个电机、雇了150台电脑的系统，最终被大幅降级使用。设计容量4000辆小车，实际能稳定跑的远少于这个数。

七、这个故事到底告诉我们什么？

作者John Swartz说，他写这篇报告不是为了羞辱丹佛或者BAE。恰恰相反，他认为每一次失败都是整个软件工程界的失败。1994年夏天，丹佛机场曾经绝望到上新闻求助：“有没有人能让我们的系统跑起来？”如果当时软件工程真的成熟了，就应该有人站出来给出答案。但没有。所以问题不是“谁搞砸了”，而是“为什么我们总是在同一个坑里摔倒”？

他列了几条最直接的教训：

1. 原型跑得再好，也不等于大规模能跑。 在1000英尺的轨道上演示成功，跟在17英里上稳定运行，中间隔着无数个“没想到”——空车管理、同步时序、故障恢复，每个都足以杀死项目。

2. 项目中途改设计，必须重新算风险。 1992年那次“重大修改”之后，没有人坐下来问：“这会让工期延长多久？会让bug增加多少？”大家只是埋头往前赶，假装一切还在计划内。

3. 多个承包商打架的时候，业主必须当裁判。 丹佛市政府看着BAE和其他公司互相锁门，基本上没管。结果就是内耗吞掉了几个月的时间。

但更深一层的教训，也是最让他痛心的：

我们这个行业，不记录失败。

他说，每一个项目管理方法论都写着“项目结束后要做经验教训总结”。但现实中，大家要么说“没这个预算项”，要么公司文化就是“家丑不可外扬”。就算写了报告，也是报喜不报忧，把项目包装成光辉案例。于是，新项目的人根本不知道前人踩过哪些雷。他们怀着同样的自信，用同样的错误设计，撞上同样的墙壁。

最后他在文章里写了一段很扎心的话：

“如果软件工程界不建立一个项目失败原因的知识库，那么项目将继续因为同样的原因失败——而且没有人会知道这些原因是什么！”

八、一个老工程师的请求

Swartz把这份报告叫做“尸检”。

他说：“不好看，但如果我们现在认真做一次，将来就不用反复做。” 他呼吁所有的软件从业者：把你搞砸的项目写下来。用同样的格式写。这样我们可以横向比较，可以积累数据，可以真正地、科学地学习。今天的我们回头看这篇文章——它写于1995年。将近三十年过去了。

你觉得我们真的学会了吗？