F-16战隼之父引以为傲的“战斗机黑手党”生存法则：以终为始的“

【水伯】《消费者洞察指引》作者，stygoogle创始人；

移动网络时代唯一壁垒就是认知，周二有约给思想洗澡让认知破壁！

实例化需求

F-16战隼之父引以为傲的“战斗机黑手党”生存法则：以终为始的“实例化需求”

引语：

爸妈不在家

翠花的爸妈走亲戚，晚上就住亲戚家了；

翠花高兴的给男票来福打电话：“爸妈不在家，我不敢一个人睡觉。”

来福：“那我过来陪你吧！”

翠花听后生气的扣了电话，埋怨道：“尼玛！就不能让我去你家吗？”

翠花扣下电话的瞬间，一股对牛弹琴的感觉油然而生。。。！

需求！欲望！何为欲望？心理学上对欲望的解释是由人的本性产生的想达到某种目的的要求。在这个定义里有两个关键词：本性、目的。它指出了欲望的源头，是由人的本性产生的，是一种本能，人人皆有。同时也指出了欲望的产生原因，是为了达到某种目的。段子“爸妈不在家”就是一个典型的需求分析过程，通过需求分析找到了最简单的满足人们欲望的方式。不同的角色肯定会有不同的需求，这个时候，我们需要将自己代入角色，仔细想想如果自己是这个角色，会有什么样的需求。现在一个新的需求管理方法，被称为「以终为始的PDCA循环」的实例化需求，可以解决这些问题。实例化需求不再编写和维护需求文档，而是直接使用高质量的测试用例作为需求文档。通过测试用例可以很清楚的看到产品的需求内容，而且，在需求变更时，必然会产生新的测试用例，而不必费力去维护。在清晰表现需求的基础上，构建出正确的产品。

一、实例化需求，「以终为始的PDCA循环」

怎样的产品才是正确的产品？客户知道吗？也许知道一点；产品分析师知道吗？也许知道更多一点；测试人员的知识挺重要；程序员当然也少不了，但无法完全依赖于他们。看来只有提炼各种角色人员的知识才能得到正确的产品，因此协作是必须的。当然大家都知道要协作，可说起来容易做起来难，怎样的协作方式效率更高？

Gojko Adzic 说要借助实例的力量！他还进一步总结了一套非常清晰的关键过程模式。Gojko Adzic 是《实例化需求》的作者，该书在 Amazon.com 获得了超过了20条的几乎全五星的评价；该书又获得了软件开发图书领域最富盛名的 Jolt 大奖！这一奖项意味着《实例化需求》基本是上从2011年6月到2012年7月这一年中对软件行业影响最为重大的一本书。在第一章 Gojko Adzic 就清晰地说到：“在过去的十年里，软件开发社区致力于使用“正确”的方式构建软件，关注使用技术实践和思想来确保质量。但是，正确地构建软件和构建正确的产品是两码事，我们要二者兼顾才能取得成功。”

实例化需求：通过4W1H(Why，What，Who，When，How）帮助大家掌握这一高效的精益和敏捷需求实践，并落实验收测试驱动开发（ATDD）方法。它帮助团队分析、澄清、拆分和沟通需求，为开发活动提供高质量的输入。同时它也将影响整个开发和交付过程，支持精益和敏捷开发的成功实施，改善团队的交付过程，达成高质量和顺畅的价值交付。

1、Why：实例化需求的目标——以终为始

实例化需求的目标可以概括为四个字——以终为始（Begin with the End in Mind）。「以终为始」是《高效能人士的7个习惯》一书中的第二个习惯，指在开始一件事情之前，先明确其目标，再努力实现之。对应产品开发，它指：开始开发前，充分澄清需求，明确其验收标准，并保证相关人员对需求的一致理解。「以终为始」的反面是「GIGO」：Garbage In， Garbage Out（输入的是垃圾，输出垃圾）。这恰恰是很多精益敏捷实施的现状，极大影响团队交付的质量、节奏和最终业务成果。

敏捷开发团队中普遍以“用户故事”承载需求。用户故事有两个核心作用：

1）它是交付的单元。用户故事应该是足够小的、端到端的可交付单元，基于它可以组织和规划迭代或持续交付；

2）它是沟通的载体。与传统的需求表述方式不同，用户故事中并不包含需求的详细信息，它只是对未来进一步沟通的承诺。

问题如何才能有效沟通？确认什么？怎么确认？这是困扰很多敏捷开发团队的问题。传统的需求分析问题，在精益和敏捷开发中依然存在。实例化需求既要解决传统上需求分析的问题，又要适应迭代和持续交付的模式，更加高效、有效和持续地沟通需求，做到“以终为始”。

2、What：实例化需求的核心概念——用实例说明需求

以终为始是目标，那实例化需求具体包含什么内容呢？实例化需求的英文是Specification by Example，简称 SBE，直译过来就是用实例说明需求。为什么要用实例来说明需求？让我们从需求沟通中的一个最常见误区：知识的诅咒说起。知识的诅咒是指：人们在沟通时会不自觉地假设别人拥有和自己一样的背景知识，造成沟通的困难和误解。在陌生的地方问路，经常体会到「知识的诅咒」。下图，当地人告诉你：「噢，那家旅馆啊，前面左拐就到了」。但事实上，你需要走到第三个路口再左拐，然后穿过一个街区，再从巷口进去才是。并不是当地人不够友善，而是他太熟悉这里了，不自觉地假设别人也有同样的背景知识，这就是典型的“被自己的知识诅咒”，而影响了与他人的沟通。

「知识的诅咒」在需求沟通中时常发生。我们经常会看到这样的场景，需求交付后，才发现场景的遗漏，或规则的错误。对此，开发人员抱怨：「需求说明中并没有说要考虑余额不足啊」，或者说：「从来没人告诉我还有这种类型的交易啊」。而业务人员却说：「这不是很明显吗？」。业务人员口中明显的事，对开发和测试人员可不一定。

为避免需求沟通过程中的「知识诅咒」，“实例化需求”方法从场景出发，以用户的操作实例来澄清需求。相比一般的规格说明，实例更加场景化，能够激发参与和深度讨论；同时，实例是具体的，其典型形式是：「在什么情况下，做什么操作，会得到什么结果」。基于具体的实例，更加便于沟通中的双向确认，保证理解的一致和场景覆盖。

3、下图是对实例化需求的概念说明——PDCA闭环

-用例子来分析和澄清需求。

-这些例子随后会转化为测试用例。

-最后再通过测试验证需求。

如此形成PDCA闭环，这个三角是实例化需求的核心概念。

二、为什么实例化需求被称为「以终为始的PDCA循环」

一个产品成功的基础是客户满意度，而客户满意度的基础是客户需求的分析质量。但是长期以来，许多产品苦于没有找到一套系统化、结构化的需求分析方法，备受需求分析质量不高的困扰。而“需求实例化”是一种系统化、结构化地进行需求分析的指导方法，可以有效地解决需求分析过程面临的困难，质量不高的难题。

但是，一种好方法的推广使用，不是一蹴而就的事情，也需要一个系统化的思路和法则来推动它落地起效。如何在一个产品项目中分阶段、有策略地推进“需求实例化”，以解决产品需求分析质量的痛点，转变需求分析参与人员的观念，为产品的客户满意度提升提供源源不绝的动力。PDCA循环是一个管理学的通用模型，是一种可以灵活运用的持续改善过程。基于PDCA循环的原则，从Plan(计划)、Do(实施)、Check(评估)和Action(改进)这四个维度来开展具体的行动，最终达成“需求实例化”落地生效的预期目标。

1、「以终为始的PDCA循环」保障需求澄清和沟通的质量

实例化需求活动上，业务、开发和测试人员通过实例澄清小批量的需求，澄清过程通常符合金字塔结构，在目标、操作和业务规则这三个层面，逐渐明晰，解决相应的挑战：

-目标层面：目标是什么？不做这个需求会怎么样？

-操作层面：通过哪些操作来实现这些目标？操作步骤合理吗？还可以更简化吗？

-业务规则层面：和操作相关的业务规则都考虑了吗？特殊情况，异常或错误处理包含了吗？是否涵盖了不同的业务、数据和接口类型？

解决以上问题，保障了需求目标的清晰、交互流程的简单合理、业务规则的完整覆盖，并让业务、开发和测试对需求形成一致理解。特别是基于共同领域模型的沟通，静态和动态视图相互印证进一步确保了需求的质量。

2、「以终为始的PDCA循环」的需求拆分是实例化需求的核心产品

作为核心产品，实例化需求还起到了需求拆分的作用。在实施精益敏捷产品开发过程中，需求拆分是许多团队面临的难题。之所以需求拆分困难，是因为它要做到：

-足够小：这样才能保障迭代或持续交付。

-端到端，这样才能保证交付有意义的价值。

-相对独立，这样才便于迭代和交付的灵活安排。

-拆分完还能看到整体的结构。

采用「以终为始的PDCA循环」的实例化需求，以上要求往往能顺便达成，需求会被自动的分解成一个个小的独立的操作，从用户角度的分析也保证了这些拆分后的需求是端到端且可交付的。

3、「以终为始的PDCA循环」通过“需求实例化”我们可以得到的收益

做到「以终为始」，实例化需求落实到位，验收测试驱动开发则水到渠成。正如前面实例化需求的概念三角中所表达的：

-在就绪队列填充前，团队通过实例化需求活动产生实例。

-实现过程中，团队将这些实例自动化，功能实现和自动化测试开发同步完成。

-实现完成后，团队用已经完成的自动化测试来验收这些需求。这个循环就是验收测试驱动开发循环。

三、实例化需求如何将抽象的用户需求转化为实例化的产品体验

要知道用户需求是不可见的，它是一种抽象的概念；而产品体验是真实可见的，它是用户需求的一种实例化表现。如何将抽象化的需求转换为实例化的体验，产品需求便是一个不可或缺的中转站。如何发掘用户动机、确定用户需求？用户想要一个钻头，这是用户的需求；但这不是他的动机，他可能只想在桌子上钻个孔。那么这个钻孔才是用户需要钻头的动机，由此来看，用户动机不会直接展现，但是我们依然可以从他们的行为和反馈进行推断。这需要一个完整的三层递进的操作体系，从“影响地图”到“用户故事地图”再到“实例化需求”，越到后面越反应实操方面的特性。

1、实例化需求的基本流程

现实中经常出现一种情况，产品根据用户需求去改进，往往功能实现了，用户却不爱了。不是功能改进不行，而是有时候用户自己都不清楚自己到底需要什么，毕竟用户专业度有限，而我们要做的，就是根据用户需求去发掘用户动机，然后综合环境、产品、用户去整理自己的产品需求。定系统、找用户、问目的、画场景、设功能，这5步法：

最终得到以实例化形式描述的需求列表，包括对应的验收准则，以及满足这些需求的功能清单。

2、实例化需求和MFQ&PPDCS的结合，可谓自然天成，相辅相成

实例化需求分析的输出侧重需求增量本身（验证需求），而MFQ&PPDCS测试设计则需要在此基础之上，进行全方位的扩展（验证系统）。简单来说，“实例化需求”过程的前半段帮助KYM（Know Your Mission），后半段应用“PPDCS”解决“M”，并提供SF（Single Function）和PF（Product Function：需求波及的产品已有功能），作为“F”和“Q”分析设计的基础。

3、通过“实例化需求”方法的落地实践，经历了一个完整的PDCA循环

1）计划阶段：通过“试点推进，策略实施”，迅速建立了“需求实例化”实施的样板案例，建立了需求分析说明书的模板，为规模推广打下了基础；

2）实施阶段：通过“流程固化，融合MFQ”，把两者方法的结合使用，有效地嵌入到实际交付的流程和规则中，保证了效果的持续发挥；

3）评估阶段：通过“数据分析，灵活使用”，证明了方法推广的实际收益，提升了团队进一步深入开展的信心和动力；

4）改进阶段：通过“纵向拓展，横向提效”的改进方法，将“需求实例化”方法的正面效应，扩展到产品交付的全流程中，为整体的产品价值交付注入了更大的动力。

总之，任何一项优秀实践，只要对产品交付有利，都能够找到合适的方式推广落地，只要在整个过程中坚持采用系统思考的方法，从整体优化的角度寻找解决方法，就可以达成预定目标。

四、F-16战隼之父引以为傲的生存法则：「以终为始的PDCA循环」

上世纪 80 年代末，有人做过一个很有趣的评估：美军现役装备中最好和最差的武器。B-2 隐形轰炸机、F-15“鹰”战斗机和 RAH-66“科曼奇”直升机不幸荣登最差武器榜。而同时有三件空战武器荣登最好武器榜：“响尾蛇”空空导弹、A-10“雷电”攻击机和 F-16“战隼”战斗机。其中对于 F-16 “战隼”战斗机的评价是：三位国防部工作人员隐匿了一笔研究资金，私下研制了这种轻型战斗机。当通用动力公司生产出第一批 F-16 战斗机时，很多飞行员认为它是有史以来最好的战斗机。尽管它只装备了航炮和红外制导空空导弹，但很多飞行员坚信这就足够了。

令人印象深刻是F-16战斗机，它的最初的设计需求是飞行速度要达到2-2.5马赫，首席设计师 Hillaker 询问美国空军为何需要如此快的飞行速度，答复是“飞机必须能从战斗中逃脱”。然而，意外的是，Hillaker 的最终设计并没有达到2马赫，但通过无框气泡式坐舱盖、倾斜的座位、侧装式控制杆等等诸多创新技术，飞行员可以非常敏捷地从战斗中逃脱，并且这样的设计生产成本更低！看似明晰的“2.5马赫”并未有效地传达真正的需求，那只是一种解决方法，Hillaker 通过理解真正的需求而给出了更好的设计，这是成功产品设计的本质！

1、战斗机黑手党生存法则（P）：以终为始的“实例化需求”

怎样的产品才是正确的产品？客户知道吗？也许知道一点；产品分析师知道吗？也许知道更多一点；测试人员的知识挺重要；但无法完全依赖于他们。“战隼之父”Harry Hillaker借助实例的力量！他还进一步总结了一套非常清晰的关键过程模式。F-16 战斗机是第一种完全以“能量空战理论”为基础设计出来的空优战斗机。其实轻型战斗机的设计理念早已有之，但以往都局限在轻快、灵活、价格低廉、以数量取胜的圈子里，而一旦与先进的空战理念、先进的电子设备和系统优势结合到一起，其性能就有了跨越式的进步！上述这些成功很大程度上归功于 Harry Hillaker 的辛勤工作，他和他的伙伴们（就是著名的“战斗机黑手党”）共同引领了这场战斗机设计方法学上的革命。可以说 F-16 战斗机项目最初起源于一个由一群老资格设计师主导的业余小项目——回溯到上世纪 60 年代中期，Hillaker 花费了自己大量业余时间来设计一种自己梦想中的战斗机——轻型、高性能喷气式战斗机，它拥有无与伦比的高机动性，几乎可以围着其他战斗机随意转圈，这个业余小项目后来成为他的梦想，又由梦想成为现实。甚至今天衡量一种战斗机是否优秀的标准就是它是否符合“战斗机黑手党”提出的以终为始的“实例化需求”设计原则！

2、战斗机黑手党的口号（D）---“让一切变得简单”（make it simple）

战斗机黑手党被人误解的一个原因是因为他们被视为一群“反技术主义者”。他们的口号就是“让一切变得简单”（make it simple）。这句口号言简意赅，但也容易让人产生误解。战斗机黑手党是一个群体，包括各式各样的人：空军战斗机飞行员、飞机制造商的设计师、国防部的官员还有分析专家。但其中起到核心作用的还是 John·Boyd，他创立的“能量空战理论”对后世影响深远，最直接的影响就是 F-16 的诞生。在整个设计过程中，他们有针对性的运用新技术来达到自己的设计目的：那就是让飞机尽可能结构简单、体积小巧。如果他们希望飞机飞的更快，就通过减小飞机尺寸和调整配置来降低飞机在飞行中遇到的空气阻力；如果他们希望飞机具有更大的航程，就让飞机变得更紧凑。

3、成就优秀设计方案的关键（C）---挑战公认法则

他们试着发掘导致各种性能指标相互影响的规律。每一次分析的结果通常包括一根性能变化曲线以及更多由此引申出的问题。譬如这些活动能不能改善我们的设计水平？如果给予这些性能指标一定量的改变，那么他们设计出来的战斗机的性能相应会提高多少？当时对这些问题最关心的人莫过于 John Boyd。“战斗机黑手党”当时挑战的都有哪些公认法则？

战斗机的航程与携带燃油量有关；飞机发动机推力越大，其空速越快；技术越先进，复杂性也越高；双引擎战斗机的安全系数高于单引擎；飞机性能越好，体积、成本也跟着往上涨。这些观念最后使得战斗机设计越来越复杂。

4、成就优秀战机设计方案的关键（A）---明确需求

F-16 战斗机的设计思路和以往的设计模式究竟有哪些不同？在他们真正理解需要实现哪些具体功能之前，他们常常不由自主地陷入一种固定的思维模式中去。轻型战斗机的设计思路应该带有新的东西---对传统设计十分强调的战斗机空速和加速度性能的新理解。以往每个人都希望战斗机能够达到 2-2.5 马赫的飞行速度，但却无人思考为什么要这么做？例如因为曾经从事超音速航空运输方面的研究工作，Hillaker有机会接触所有 B-58 轰炸机的超音速飞行记录。结果发现在 B-58 轰炸机的全部飞行时间里，超音速飞行时间总和占全部飞行时间的 5% 都不到！最长的一架也只有 7 个小时！整个 B-58 机队的超音速飞行时间总和也就 200 个小时而已。许多人把最高飞行时速与飞行加速度混为一谈。对于那些提需求的人而言，有了大推力引擎就意味着有了高空速和高飞行加速度，这些看法都站不住脚。

在 F-16 战斗机的设计阶段，他们首先是确定具体功能要求。他们扪心自问，每一个具体性能指标要求的依据是什么？是否来源于一个给定的能力要求？

第一，明确需求，知道自己需要的是一架什么样的飞机，制空还是制海？高端还是低端？

第二，弄清各项性能指标的内在联系，突出主要的性能指标，适当放宽次要的性能要求。

打破陈规不是一件容易的事情，最初就连通用动力的首席试飞员 Phil Oestricher 也不看好 YF-16，但当他围着飞机走了一圈，里里外外看了个遍后，不由得由衷赞叹：What a wonderful airplane!  1974 年 1 月，他在爱德华兹空军基地驾机完成首飞。

5、最大的挑战是什么---沟通

Hillake 当被问及他认为战斗机设计领域当前最紧迫的问题是什么时，他毫不犹豫地回答：并行工程，包括机载航电、武器系统等外在设备。因为它们在设计时没有有效地整合到战斗机这个大系统里，结果导致战斗机设计师在设计好一架飞机后，还需要花大力气把各个子系统整合进去，最后使得战斗机飞行性能受到影响。他认为以后应当把上述系统作为战斗机一部分考虑进去。而当问及对新一代战斗机设计师们最大的挑战是什么？他的回答是：沟通。因为未来的设计越来越依靠团队合作，只有学会表达才能把好的想法分享出来。不要忘了，更应该关心是如何让F-16战斗机能够更容易从战斗中逃脱，而不是花上很大的代价非要让它的飞行速度达到2.5马赫。就像 YF-16 的设计方案之所以被空军选中，一个重要原因就是它简明扼要、条理清晰，从头到尾只有五十多页，看得出是一个人写的，和其他公司动辄上百页的设计方案形成鲜明对比。

彩蛋：迷失的女孩;公众号：SFA-0002

女孩一个人在街上玩，不知不觉迷失了方向，回不了家，便大声哭起來。

警察走过来说：“好孩子，你哭什么，回家去吧！”

小女孩哭着说：“我迷路了，找不到家在那儿，回不去！”

警察走过来说：“那你家在什么地方啊？”

小女孩：“在楼上。”

警察说：“你爸爸叫什么？”

小女孩：“亲爱的！”

警察说：“你妈妈叫什么？”

小女孩：“宝贝！”

警察说：“你家里还有谁？”

小女孩：“还有我。”

警察说：“那你叫什么？”

小女孩：“乖乖。”。

关于举例说明，我们不准备过多赘述，只提及一点：具体的东西永远比抽象的东西更容易激起讨论，更容易发现原本未注意到的重要因素。

-End-