### 第三章：成为“盒子顶部”
#### 引言
老实说，我不能为“成为盒子顶部”这个表达方式邀功。我第一次听到这个说法是从我的导师和朋友罗伯特·莱特富特（Robert Lightfoot）那里，他是前马歇尔太空飞行中心（MSFC）主任和NASA副行政官。罗伯特用“成为盒子顶部”这个表达来强调保持对大局的关注。他是如何想到这个表达的呢？显然，罗伯特是拼图游戏的忠实粉丝，他认为这项活动具有治愈、放松和恢复活力的效果。罗伯特描述说，当你第一次打开拼图盒子，把所有拼图块从包装中解放出来时，你面前是一堆杂乱无章的独立拼图块。看着这些纸板碎片，你完全无法想象最终的画面会是什么样子。它们只是一堆零件——杂乱无章、无序、随机。但这就是“盒子顶部”的作用。盒子的顶部印有拼图完成后的图像。换句话说，用工程术语来说，它是所有组件的系统级视角，集成且完整。有了盒子顶部，你就知道系统（在这种情况下是拼图）在组装完成后会是什么样子。将这个类比应用到NASA，罗伯特会说，领导者需要成为他们项目或计划的“盒子顶部”。
#### 系统思维的重要性
在我看来，罗伯特的想法是一个非常有效的类比，我经常使用它（当然，会适当地给予他应有的荣誉）。我一直认为这是一种通俗的方式来描述系统思维的任务，并保持对正在完成的工作的整体视角。通俗，但有效。领导者可以让自己深入细节，但有很多人负责细节。在任何项目中，各个部分都可能独立存在，每个人似乎在任何时候都有最终的重要性，并吸引技术团队的注意力来解决一个棘手的问题。但除了领导者之外，很少有人负责“盒子顶部”，确保所有部分结合在一起，产生所需的系统，确保系统设计正确，并且团队设计的是正确的系统。技术团队的领导者——首席工程师——必须始终能够保持对“盒子顶部”的关注，专注于大局。
#### 如何构建“盒子顶部”
当你看到“盒子顶部”时，你会看到什么？嗯，我看到的是一个完整的愿景。我看到下面的风景和上面的天气，仿佛它们是整体的一部分（它们确实是）。我看到前景和背景，焦点和需要一些时间才能辨别的隐藏宝石。我看到一个从头到尾的故事，可以传达给他人。工程没有什么不同。当我们开发系统时，这些系统包含许多独立的部分，但它们共同讲述了一个更大的故事。所有元素共同发挥作用，服务于与单个部分截然不同的角色。而且，该系统必须在环境中运行，并可能与其他系统集成，这些系统都是故事的一部分。这就是“盒子顶部”，它应该在你的项目中始终存在于你的脑海中。
#### 项目初期的“盒子顶部”
作为首席工程师，我们从哪里得到这个“盒子顶部”并一直参考它呢？嗯，有几个来源可以借鉴。许多项目在开发初期会制定需求、目标和目的（NGOs）。这些简短的陈述集合提供了系统开发所需的高层次战略描述，系统要实现的基本目标，以及一些更离散的目标，这些目标通常与性能相关。NGOs在几页纸中概括了正在开发的系统的整体情况。NGOs通常会扩展为操作概念（ConOps），从中衍生出系统需求（包括最重要的关键驱动需求[KDRs]）。ConOps和KDRs也是辨别“盒子顶部”的良好来源。
#### 客户和利益相关者的期望
不要忽视客户和利益相关者的期望。其中一些可以在NGOs中找到，NGOs是确保客户和提供者在期望方面达成一致的绝佳机制。在下一个定义层次上，客户和利益相关者的期望可以通过有效性度量（MOEs）来捕捉，这些度量用于在设计过程的每个阶段验证系统。MOEs提供了客户期望的一些更主观的质量的洞察，这些质量无法或难以通过硬性需求来捕捉。许多“ilities”用于MOEs中，例如，可能很难生成关于可操作性的“shall”声明，但可操作性仍然是客户的重要特征。最后，性能度量（MOPs）也是“盒子顶部”的良好材料。MOPs通常是重要性能需求的实例化，并用作度量标准，以跟踪系统在设计/开发过程中的交付能力。
#### 团队对领导者的期望
团队希望他们的领导者成为“盒子顶部”。他们希望知道他们的领导者正在保持大局（部分原因可能是为了让成员能够处理细节）。这是一项重要的责任，幸运的是，大多数首席工程师的集体经验使他们能够承担这一责任。
#### 实际案例
在我职业生涯早期，当我还是休斯顿任务控制中心支持航天飞机飞行的飞行控制员时，我看到了一个关于“盒子顶部”的最佳例子。航天飞机的飞行控制团队由主控制室（FCR）中的一组最多17人组成，这些人是“前厅”操作员，是每个学科中最有经验的飞行控制员，还有一组经验不足的支持人员分散在任务控制中心的各种“后厅”中。整个飞行控制团队的领导者是飞行主管，通常是一位前飞行控制员，被提升为一个高度纪律严明的团队，负责部分成为“盒子顶部”。飞行主管承担着任务整体成功的最终责任，仅次于航天器上的指挥官。
在航天飞机任务的标准每日轮班期间，飞行主管可能面临数十项飞行控制员任务。一些任务是常规的，每次任务都会发生，例如监控即将到来的机组时间表活动、向轨道器上传命令、管理其天线和地面通信站、监督电源/热/姿态的日常维护活动、更新机载状态向量或执行燃料电池净化、与机组人员进行语音通信等等。其他任务更具体，对特定任务至关重要，例如交会活动、有效载荷部署、机载研究和舱外活动（EVA）。当然，有些任务是异常的——设备故障及其相关的安全性和重新配置、与轨道碎片的预测交会、通信丢失，以及航天飞机任务中可能出错的无数其他事情。所有这些任务都是飞行主管必须了解并保持认知的，并根据这些信息向飞行控制团队和轨道机组提供方向。这是一项非凡的杂技表演。
#### 首席工程师的责任
作为开发项目的首席工程师，你将负责管理和优先处理许多不断出现的各种重大技术挑战，同时保持大局。像航天飞机任务一样，大多数开发项目都有主要和次要目标、关键驱动需求和其他建立“盒子顶部”的手段。作为工程技术团队的领导者，你需要在所有活动中保持这些目标和需求。这是你无法真正委派的任务——它几乎完全属于你，是工作的一部分。
#### 系统工程的卡通形象
你们可能都看过那些描述系统工程重要性的常用卡通形象。这些卡通可能展示，例如，卫星的四种配置：1）由通信工程师设计，充满了天线森林和大碟子；2）由推进工程师设计，带有小型航天器总线和巨大的火箭发动机；3）由机器人工程师设计，带有类似小型航天器的可怕机械臂和多余的较小附件；最后，4）由系统工程师设计，具有优化解决方案，所有部分都在适当的比例内。是的，这是一种幽默的学科焦点概念，但它确实传达了如果没有人关注“盒子顶部”会发生什么的信息。
#### 首席工程师的职责
作为首席工程师，我们的工作是随身携带“盒子顶部”，并每天参考它。你经常会被要求在设计权衡中发表意见，并在有多个选择的情况下做出技术决策。每个权衡可能概述一系列利弊，每个选择可能包括收益和惩罚。选择哪一个？当然，每个决策都是独特的，必须在所问问题的背景下理解。然而，每个权衡和每个选择都是通往“盒子顶部”所描述的系统级解决方案的路径上的决策。
#### 技术性能度量（TPMs）
如果你不小心，很容易失去大局。例如，跟踪技术性能度量（TPMs）是技术社区中常见的做法，用于帮助我们确保子系统或组件的性能达到预期目标。TPMs用于建立我们寻求的性能目标，并跟踪它们以告诉我们是否达到了目标或偏离了目标。质量是一个常见的TPM，但我们也可以跟踪带宽、delta-V、流量、阻力或几乎任何技术参数。有了TPM，我们可以在设计过程中跟踪组件的分析或测量性能，评估其达到性能目标的能力。我们可以从概念设计开始，继续到初步和关键设计，再到制造、测试和验证。如果性能不符合我们设定的目标，或者达到了目标但余量不足，可以采取补救措施。我们可以改变设计，计划不同的操作，甚至如果达到它的影响变得不可接受或不可行，可以减少所需的性能。TPMs是保持关注以确保我们从设计的系统中获得我们想要的东西的有用机制。
#### 实际案例
但你知道，TPMs有时会独立存在，我们可能会因为树木而失去森林。有时我们如此专注于TPMs，以至于可能失去对“盒子顶部”的关注。我最近从我在NASA航空部门担任首席工程师的职位上看到了这种情况。NASA航空部门目前正在开发的一个重要项目是低音爆飞行演示器，更广为人知的是X-59，这是一架NASA实验演示器“X-plane”。它的任务是研究一种可以减少超音速飞行时产生的音爆噪音（技术上，是压力波）的飞机形状，其外模线（OML）形状旨在减少和向上偏转飞机产生的冲击波。该项目对NASA航空部门来说具有显著的开发成本和复杂性；因此，他们为这项任务指派了一支非常优秀、经验丰富的技术团队。2018年，当该项目完成初步设计评审（PDR）并朝着关键设计评审（CDR）前进时，一个经常讨论的话题是如何最好地监控TPMs，以提供即将出现的问题的充分早期预警。也就是说，在我们NASA常用的标准红绿灯术语中，TPMs应该在什么阈值下被宣布为绿色、黄色或红色？其目的是保持对TPMs状态的更好认识，并在必要时将注意力集中在必要的地方（和时间）。
该项目携带了大约15个TPMs，涉及诸如飞机总干重、加力
