“阿波罗“登月这样的工程是如何做项目管理的？
程序员厌恶项目经理，这大概是最常见的现象了。在程序员看来，安心干活是本份，自然不希望有人打扰，而项目经理给人的印象是不停催进度，不停问东问西。可是在项目经理看来，程序员只会埋头干活，不会抬头看路，而且出了问题往往习惯自己解决，不到最后一刻绝不暴露，搞得大家都很被动。
然而总的来看，许多项目的管理也确实很糟糕，三天两头延期不说，最终的交付质量也不如人意。
所以有人说，高科技行业的项目管理就是很难做的，全都是创意劳动，怎么可能有严密的项目计划？真的是这样吗？我们不妨看看上世纪60年代，NASA（美国航空航天局）登月的“阿波罗”计划中，项目管理是怎么做的。
要知道，登月是前无古人（到目前还没有“来者”）的事业，上世纪60年代的计算机水平乃至整体科技水平，今天看来都相当原始。就在这种条件下，NASA确实兑现了肯尼迪“十年内登月”的誓言，而且11次“阿波罗”载人航天任务全部安全返回——大部分宇航员出发时都相信，自己只有2/3的几率生还。能取得这样的成就，科技当然很重要，项目管理也相当重要。
更麻烦的是，“阿波罗”是一系列的任务，从1968年开始，肯尼迪航天中心采用流水线作业，任何时候至少都有三项任务在同时开展：
一枚“阿波罗”/“土星5”航天器在发射工位进行最后的组装和测试
一枚或两枚“土星5”火箭在垂直总装厂房进行组装和测试
一枚“土星5”火箭的各子级在低顶区进行检测
至少一次任务的指令舱/服务舱、登月舱在载人航天器操作厂房进行组装和测试
另一次任务的指令舱/服务舱、登月舱在载人航天器操作厂房或垂直总装厂房检测
换句话说，哪怕最近要发射的是“阿波罗9”，但“阿波罗10”和“阿波罗11”也在紧张的准备之中，所有工作必须相互协调，不能出任何差错。
在当时，计算机还是刚出世不久的玩意儿，更多用于“计算”，用计算机和软件来管理项目根本还是没影的事情。当时NASA是怎么管理这一切的呢？
答案是：靠PERT图。
学过计算机专业课程的同学们大概还记得PERT图，这是美国海军在20世纪50年代为了管理“北极星”潜艇和导弹系统的开发任务而发明的工具。它将复杂任务分解为不同的活动，用网络结构清晰描述每项任务需要的人力、时间、资源的量和依赖关系。通过PERT图分析，可以一眼看到复杂任务中的关键路径，看到每项任务的前驱-后继条件，看到任何一项任务的提前或延后对其它任务的影响。
如果你不记得PERT图也不要紧，下面这个简单的例子用PERT图分析了做饭的过程。
假设要解决的问题是做饭，我们首先穷举所有的步骤，比如淘米、洗菜、炒菜、煮饭、切菜等等。然后，把每一步的时间估计出来。接下来整理出各步骤之间的依赖关系，比如煮饭要在淘米之后，切菜要在炒菜之前，洗菜之前要先浸泡而且是用淘米水浸泡最好……
下图可以清楚看到各步骤之间的依赖关系（哪一步必须依赖哪一步），以及各步骤的耗时时间。经过现成算法，可以提炼出关键路径（用红色标注）。
可以看到，能吃上饭的最短时间就是2+30=32分钟，最关键的两步是淘米和煮饭。关键路径上的任何延迟，都会导致整体目标的延迟，所以必须严格保障。非关键路径上的步骤也不能无限拖延，同样可以通过算法计算出其富裕度，包括最早开始时间、最晚开始时间，最早结束时间、最晚结束时间。实际执行的时候不必反复过问，只要所有步骤都在预计的时间内，整体进度就可以保证。
实际的PERT图类似这样，红色标注关键路径。来源：Bourton Group
在肯尼迪航天中心的4号发射控制室，墙上贴着面积超过100平米的PERT图。其中A级活动表是总纲，主要是由NASA总部和肯尼迪航天中心的高级官员设定的里程碑；B级含超过7400个事件，追踪为了达成里程碑所需要的各重要事件，主要由肯尼迪航天中心的各级官员使用；C级则对B级做了进一步分解，包含超过4万个事件，标明了顺序和预计完成时间（以便后续工作开展），它主要由NASA一线人员和各供应商自行维护。
任何时候，B级和C级都必须对齐A级中的里程碑。所有活动按照WBS（工作分解结构）编号，通过编号可以方便地发现各事件之间的联系，这样就保证了B级中的一个事件最多可以关联C级中的15个事件。
因为当时还没有计算机，一共有几十名分析人员来协调和跟踪所有的活动。
A级PERT图，提供整个项目的总揽。来源：NASA
4号发射控制室的巨型PERT图。来源：NASA
阶梯会议室共有90个座位，另外还可以容纳50人站立。前方的金属墙面有21m x 5m大小，用磁性标贴标示了整套火箭工作流程。如果要调整计划，就召集大家开会，重新安排这些标贴。会议室前方中间有一个跟踪状态栏，相当于程序中的“指针”，用来保证大家都知道当前的状态和将要完成的任务。
在整个任务管理中，最关键的问题是对关键路径的管理。只要能时刻盯住关键路径，整体的任务目标就在把握之中。下图是1966年1月20日的发射场活动关键路径图，图上部的信息来自具体工作，汇总之后得到最重要的答案：
LC-39发射平台什么时候可以投入使用？
上图对应若干延误事件，信息总结如下表
可以以第一行为例来说明项目的管理协调：第一行内容是“将LUT 1移动到VAB”，其中LUT代表发射脐带塔，是移动发射平台的一部分，VAB代表垂直总装厂房。
在1965年8月，移动发射车才开始建造了六个月，比预期延后了一年。所以在LC-39发射平台最初交付时无法进行飞船测试。但是最初交付时只会使用500-F训练箭，本来不需要搭配飞船，因此延迟不会有影响。不过如果持续延迟，就会影响“土星5”火箭的第一次发射。
在8月5日的会议上，马歇尔航天中心的代表承认，电气设备的交付将要延迟1周。虽然当时LC-24发射平台有更高的优先权，但是LC-39的装备交付时间也必须提前。工程总部指出，如果不提供更多的资金给垂直总装厂房，其高顶区在10月1日就不能就绪，会影响500-F训练箭的使用，而使用日期是已经确定的重要节点。所以，管理层一致同意加速。
另外还有一条好消息，Bagnulo的工程代表宣布找到了解决移动发射平台摆臂的“迂回方案”。伯明翰的Hayes International公司将按已延误时间节点向亨茨维尔的马歇尔航天中心交付第一套摆臂。LC-39初次交付时，摆臂将被运送到肯尼迪航天中心用于500-F训练箭。如果到时没有足够的时间进行测试，肯尼迪航天中心就不从马歇尔航天中心获得摆臂，直接从Hayes获得第二套摆臂。等肯尼迪航天中心完成500-F训练箭项目之后，再从马歇尔航天中心获得已经测试过的第一套摆臂。
这样调整之后，就可以保证移动发射平台能赶上第一个里程碑——1966年1月28日，关键流程1和PERT分析结果的日期相符，可以认为最终目标不受影响。
除了PERT图，NASA还需要一套关键的系统：零配件记录系统。NASA在亨茨维尔维护着零配件列表，数据来自三处航天中心的工程部门，信息包括：名称、数量、预计就绪日期（预计送达肯尼迪航天中心的日期），必须就绪日期（肯尼迪航天中心必须用到的日期）。零配件记录系统扮演着肯尼迪航天中心与零配件供应商之间的终结角色。航天中心设备工程和构建部门的代表负责汇报核心构建里程碑的当前状态，各供应商负责将当前状态与自己的组织对齐，并汇报所有问题。如果出现情况，调度员必须在一周内在PERT图的网络中标注出来，并准备好一份C级事件的前期报告。
在肯尼迪航天中心，最上层的，发射总指挥（Director of Launch Operation，DLO）的任务计划表是固定的，也造就公布给NASA和新闻界，除非有重大事件，否则不会调整计划表。对于前无古人的挑战来说，这有点不可思议，但他们也确实做到了这一点。“阿波罗15”的指令长Dave Scott曾说：
在发射前几个月，他们就会说，“我们将在7月26日上午9点36分发射”。到那个时间点一切都会准备就绪？这真是难以置信。甚至到今天，你都不一定能这样做，也做不到。
当时能做到这一点，靠的就是卡纳维拉尔角强有力的项目管理和异常庞大细致的流程图，所有工作全部纳入其中，所有工作都必须按时完成。外面的人都不知道，这一切究竟是如何发生的。
要保证登月任务准时顺利完成，光有计划和系统还不够，还需要强有力的执行。肯尼迪航天中心采用72小时/11天计划表来监视任务的执行进度。该表格的72小时部分显示了未来3天内，每个小时要完成的工作任务；11天的部分预测了接下来两个工作周的关键事件，这些时间表均按一天三班来划分。
飞船、火箭、地面支持机构每次任务中都必须制定各自的72小时/11天计划表（The 72-HOUR/11-DAY Schedules）。每天下午1:00，在4号发射控制室召开会议，飞船、火箭、地面支持机构的负责人汇报重要节点的状态变化，并确定下一个阶段的关键活动和需求。所有信息最后输入汇总到综合计划表里，形成整个发射场的72小时/11天计划表。
可能有人注意到了，虽然任务紧张，但是对应“两周”的竟然是11天，而不是满满当当的14天。根据我看到的材料，在项目紧张的时候，大家确实是每天12小时，每周7天工作的，但这不是常态——比如“阿波罗11”发射之前的半年。NASA在“阿波罗1”的资料里提供了一份数据可供参考：
（把飞船转移到肯尼迪航天中心的火工品装配大楼）改进工作条件之后，NASA判断每天两班8小时轮换，一周工作六天，就可以保证整个分析和解体的任务进度。唯一的例外是在拆除隔热盾时，实行了每天三班8小时的轮换，这项任务在1967年3月28日完成。
美苏合作的“阿波罗-联盟”计划的72小时/11天计划表。来源：NASA
如果你留意看上面的图，会发现另一个有趣的点，这就是右下角的“史努比”卡通图案。这可不是普通的涂鸦，在卡纳维拉尔角，北美-罗克韦尔公司的调度员Al Tinnirello把“用史努比作为团队代言人”的想法变成了现实，后来陆续又有多人加入，把当前的工作画成了史努比漫画，并加上有趣的对话。
在紧张、高压的工作环境下，史努比的出现确实受到了大家的欢迎。它的人气极高，甚至高级管理人员每天都会去看计划图，甚至会抗议自己的形象画得不对。但是能够出现在史努比卡通图案里，常常被视为一种荣誉。它不仅反映了工作的繁琐，也体现了员工的无奈、困难和同情。“史努比”的漫画逐渐成为一种亚文化现象，成了管理层和员工之间重要的非正式沟通工具。
在阿波罗航天计划中，史努比漫画无处不在。如今eBay上还有当年的漫画海报出售。来源：NASA
要缓解工作压力，除了史努比漫画，许多巧妙的比喻说法也相当有用。对于项目管理中的变动，肯尼迪航天中心流传着三种说法：插队、沙包、打伞。
项目管理中的潜规则是，所有环节汇报的工时预估都是保守的，而且具体执行人员都很不喜欢被插队。好在载人登月是史无前例的工程，各项目发生变动也是难免的事情，于是总会留出一些余量，这就让插队成为可能。但总的来看，插队终归是不正常现象，对工程质量和员工情绪都会有影响，所以必须严控。
“沙包”指的是把任务的延期藏起来，具体执行人可以躲在沙包背后，不到最后一刻不做汇报。在具体执行人看来，稍微延期一点并不重要，只要后期能赶上就行。相反，及时汇报延期往往只会招来一顿责骂。这种“沙包”可不是“把头往沙堆里一扎就万事大吉”的鸵鸟战术那么简单，如果运气好，你会遇上“打伞”的人，那你就得救了。
所谓“打伞”，指的是虽然你延期了，但还有更倒霉的家伙延期了，而且率先被暴露出来，而你的工作恰好依赖他，于是你如释重负，可以心安理得地延期。没有人希望成为打伞的人，但大家都希望有其他人能为自己打伞。
无论事业多么激动人心，项目延期都是无可避免的事情，“报喜不报忧”，把延期消息藏起来，也是人之常情。但是如果迟迟没有遇到“打伞”的人，沙袋最后藏不住往往就会酿成大祸，甚至导致发射中止。肯尼迪航天中心的项目管理团队花了非常多的精力，终于把“沙袋”控制在了合理的范围之内。
同样不容忽视的是大量的文书工作。虽然各零配件在出厂时都号称经过了测试，但到发射现场之后，仍然需要再次核验。这方面最突出的例子是，有一个子系统号称经过了供应商的确认，但运到发射现场之后才发现，有个接插件的两端都是母插头，这显然是有问题的。但是，“阿波罗”计划要解决的问题不止于此，发射规范甚至详细到了要求每一个螺丝的拧紧力度，并且必须有详细记录在案。
“阿波罗”计划中的挑战不止于此。在之前的“水星”和“双子星”的任务期间，NASA的员工如果在现场发现问题，可以直接动手修正，然后告知供应商。但到了“阿波罗”计划期间，因为系统过于复杂，涉及因素过多，NASA要求员工不能直接动手处理，必须以书面形式告知供应商，由供应商修复，并且全程都必须留下记录。可以想见的是，一开始大家都很不适应这种“哪怕问题近在咫尺也必须克制动手，书面描述”的做法。
最终，这些“繁琐”的规定对保证整个项目的质量至关重要。肯尼迪航天中心有一句笑话：当文件的高度和火箭一样的时候，发射就没有问题了。这虽然是玩笑，但也毫不夸张。
当然，以上说的都只是手段，最终目的是为了培养所有2.4万名参与人员的紧迫感，并将其始终保持在高水平。为了做到这一点，密切的沟通是非常关键的。
“阿波罗”计划的特征之一是，各级员工为了工作或解决问题，有权与任何需要的人沟通，无论他的职级如何。只要管理人员能随时掌握真正的问题，就不需要兴师动众，找到合适的人来处理。更重要的是，这培养了员工的主人翁意识——不只是负责人知道要做什么，哪怕是最基层的员工，也清楚在整个项目中自己在做什么，做的工作有什么价值，要做什么才能推动实现下一个目标。如果下面要进行的是一整套测试，那么谁也不敢隐瞒任何问题，哪怕他发现的不是自己的问题。
能做到这点，另一个因素也不可忽略：在发射前的“漫长”准备工作中，宇航员与地面工作人员的交流很充分，配合很密切。一名“阿波罗”项目的宇航员公开承认：
火箭发射之后，不管遇到什么故障，只要还有一线希望，宇航员都不愿意放弃，因为航天任务太让我们兴奋和期盼了。
许多参与过“阿波罗”项目的人回忆，正因为了解到宇航员的这种热情，他们才会有高度的责任心：“我们必须一丝不苟，才能保证这些与我们朝夕相处的家伙们能安全返回”。
“阿波罗”计划的宇航员同样深刻意识到，即便在建造的是“自己的”飞船，自己也不能简单坐享其成。举世瞩目的“阿波罗13”旅程中，飞船进入太空之后一个液氧贮存箱爆炸了，指令长Jim Lovell后来承认，他早就判断这个液氧贮存箱有问题，在发射之前他完全有权力要求更换的，然而他没有这么做。在后来的任务中，从飞船开始建造一直到任务完成，宇航员都要全程密切参与，这样既建立了信任，也提供了更多的视角，降低了事故概率。
最后来谈谈我的感想——我必须承认，看完“阿波罗”计划的项目管理，我很惭愧。
我以前也学过PERT图，也知道关键路径，但是真正做起项目来往往着急埋头骨干，把这些统统都扔到九霄云外去了，充其量是对重点项目做做关键路径分析。而且我还很会自我安慰：高科技行业，创意劳动，就是不能抠这些死板的东西，否则都变成流水线工人了。所以虽然美其名曰“高科技”项目，不屑与传统制造业为伍，号称“迅速迭代”，但仔细看看项目管理的文档，其实还是几十年前的瀑布模型，只有“设计-开发-测试-上线”几个孤零零的大节点。
然而同时，我们又不得不无奈面对另一个事实：项目延期是家常便饭，只能粗估时间节点，意外情况总是层出不穷。许多时候是事到临头才发现，之前没有仔细分析过协作配合，结果时常有人在无所事事，有人在干等。
然而，“阿波罗”计划的项目管理实践刷新了我的认识，这么复杂的项目，仍然可以靠“原始”的工具管理，而且能进行强有力的管理。回想起来，我们在日常的工作中，是否被“高科技”的耀眼光环遮蔽了双眼呢？是否对待变更、延误过于随意，太不把它当回事呢？我觉得是有的，无非是程度轻重而已。许多人都有类似的经验：尽管是充满不确定的新研发项目，项目抓得紧一点，虽然抱怨多一点，确实也更重视一些，幺蛾子也少一些。
不过也不全是惭愧，“阿波罗”项目中的一个细节也证实了我坚持的习惯——在“阿波罗”计划中，每天的例行会议都会在白板面前展开，讨论结束之后，有专门的人负责将白板的结论拍照、整理，然后印好发出来，后期才装备了专门的设备，可以直接将白板上的图形文字转制印刷出来。
我开过很多技术会议，最头痛的一个点就是画图。许多设计图画得美轮美奂，但是要么问题多多，要么根本没有达成共识，悲剧的是现场改起来无比麻烦。在我看来，白板、随手画图是最好的讨论工具，不需要你的图画得横平竖直、惟妙惟肖，只要能准确反映对问题的认知就可以。要做到这点，起码有几点需要注意：
同样的概念应当用同样的图例，比如都是Java程序，不能一会儿用圆圈一会儿用方框；
同样的图例不应当表示不同的概念，比如一模一样的方框，不能这里代表浏览器，那里代表消息队列；
逻辑概念和物理概念不应当混淆，存储层是逻辑概念，Java实例是物理概念，不能相提并论；
设计应当遵循格式塔心理学基本原理——距离反映对象的关系，关系紧密的对象离得近，关系远的对象分得足够开；
数据的流向应当足够清晰，一目了然，清楚看到整条链路；
整体系统、分子系统的边界应当清楚，能画出边界线最好；
我以前写过《文不如表，表不如图》，说的就是这个道理。如果能做到上面这些点，起码许多讨论可以大大缩短，甚至根本不需要讨论。然而遗憾的是，一方面，大而无当、华而不实的图表仍然层出不穷，另一方面，能随手画出清楚图表的开发人员仍然少而又少。
另外，无论问题和组织多么复杂，沟通始终保证成功的重要手段。人性是不变的，我们可以看到，即便在“阿波罗”计划里，瞒报延迟、寄希望有其他人“打伞”也是无法杜绝的事情，如果最后没有人“打伞”，可能影响就会非常大。虽然许多时候大家都在提倡“及时沟通”，但结果往往不是“各自找婆婆”的倒U型沟通，就是追求嗓门大、效果夸张的嘶吼型沟通，只会让问题更复杂。
而简单、直接、就事论事的沟通，往往解决问题的效果最好。可惜这件事情说起来简单，做起来不简单。它不但牵涉不少复杂的心理因素，也涉及职业素养、心态、心胸。更麻烦的是，还可能掺杂了其它的因素——“xx有什么资格跟我说话”，“xx跟这根本没关系，凭什么来插一嘴”，都是常见的心态。恰恰是这种心态，把关注点从“事”转移到了“人”。
某种程度上说，史努比的漫画恰恰以一种不那么正经的方式，赋予了普通员工说话的权利。这种方式很有效，但也不那么容易实行。不信你看看四周，哪家公司的领导能坦然接受自己被员工用漫画画出来提意见？
同时，宇航员与肯尼迪航天中心工作人员的密切配合也是不可忽略的因素——“我必须一丝不苟，才能保证这些家伙们安全返回”的念头，变成了高度的责任心。而许多悲剧之所以发生，原因就在于大家不能拧成一股绳——“出了事跟我没关系”、“xx坏了关我什么事”。单纯的问责往往只会让情况更糟，只有真正以平等、尊重的态度对待所有参与人员，要追问责任，更要共享愿景和喜悦，才能让大家产生“命运共同体”的感觉，这种责任感是任何外力强制都很难替代的。
最后，即便“阿波罗”/“土星”项目有这么强有力的项目管理，仍然无法杜绝一些匪夷所思的问题——这方面最著名的就是“阿波罗13”的二氧化碳过滤器的故事。
众所周知，“阿波罗13”发射升空之后，液氧贮存罐意外爆炸，所幸没有影响宇航员的生存。面对这种情况，NASA不得不临时放弃原定的登月计划，以顺利返回地球为最重要目标。经过紧张计算，地面指挥中心发现可以借用登月舱的资源保证宇航员生存，所以原本设计供两名宇航员使用两天的登月舱需要容纳三名宇航员生存四天，这会存在风险。
果然，登月舱的二氧化碳氢氧化锂过滤罐不堪重负，好在天无绝人之路，指令舱有备用的过滤罐。这时候才发现，因为登月舱和指令舱的过滤罐一个接口为方形，一个接口为圆形，并不兼容，只能临时想办法，在“每一克重量都极宝贵”的飞船上想出办法来解决这个问题……
看过电影《阿波罗13》的人应该都记得这个画面。 来源：NASA
虽然NASA最终解决了这个问题，但事后调查发现，之所以会出现这种情况，是因为负责为登月舱和指令舱提供过滤罐的供应商是不同的，之前没有人知道这回事，更没有人想过要统一规格……
今天我们看这个故事觉得非常荒谬，匪夷所思。但是看看日常的软件开发，同样的故事不是在一再上演吗？大一点的项目里，同样是处理json数据，你用gson我用fastjson，这类现象真的没有人遇到过吗？
资料来源
nasa.org
《“阿波罗”登月发射倒计时》，国防工业出版社2017年10月
往期推荐：
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。