【水伯】《消费者洞察指引》作者，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闭环，这个三角是实例化需求的核心概念。
