以始为终，高效澄清需求| 学习笔记

开发者学堂课程【研发效能提升和敏捷实施36计：以始为终，高效澄清需求】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/615/detail/9384

以始为终，高效澄清需求

目录

一、需求沟通中的挑战和应对：实例化需求

二、以始为终

三、实例化需求的步骤和过程：构建需求金字塔

四、重构开发过程：从十绿化需求到验收测试驱动开发 

前言：

本次课是精益和敏捷需求管理篇。上次课讲了从用户问题出发，设计产品和服务，聚焦业务目标，挖掘产品需求，基于业务场景，组织和规划需求，本次课的主要内容就是以终为始，高效分析和澄清需求，而有了这些需求如何去高质量的理解和澄清分析，并且高质量的传递给开发团队，下一次的课程会再做一个总结。

本次课分三个内容：

需求沟通中的挑战和应对：关键是怎么应对，因此会提出实例化需求这个方法，会进行介绍实例化需求是什么。

实例化需求的步骤和过程：怎么构建需求金字塔来澄清沟通需求。

重构开发过程：从实例化需求到验收测试驱动开发，实例化需求不仅仅是一个需求方法，实际上会重构和协助整个开发流程。

 

一、 需求沟通中的挑战和应对：实例化需求

敏捷宣言里面说：个体互动胜于流程和工具、可工作的软件胜于详尽的文档、客户合作胜于合同谈判、响应变化 胜于遵循计划。在第一句话个体和互动中，如何有效互动的才能达到效果。第二句有更多争议，因为它没有详尽的文档，整个都在描述设计，尤其是如何描述需求。第三句，以前所定下的规格文档，基于这个文档去开发，去签订合同，在今天这个合同是可以具有法律意义的也可以是开发约定的，但是客户合作胜于合同谈判，那么如何去合作，如何去澄清需求呢，就没有所谓的合同可以响应变化甚至转印文档。第四句，而对于响应变化是承认这个说法是正确的，那么如何更高效的响应呢，或者说如何更快的去理解，去实现呢，这就是敏捷开发中关于需求的挑战，它只指一个问题，就是在整个结构中如何去沟通和澄清需求。因为敏捷开发提出了一系列要求，比如轻量级和高效地分析、澄清和沟通需求，但需求的质量不能降低，也需要不同的职能更好的互动，可以与客户更好的合作，更灵活、更快地去做这件事，这就是一系列挑战。问题是如何去做，如果做不好，在敏捷开发中对效率、质量都是有影响的。

1.需求沟通中的错误来源

那么在提出方法之前，这个需求的沟通和澄清中究竟引入那些问题，或者因为什么原因引入这些问题，可以先看下面的例子。

（1）明显的事不明显：

如图一个人问路的例子，警察说前面左拐就到了，但问路的人却没有理解。这里就要引入一句话，叫知识的诅咒。警察被自己的知识所诅咒。警察是不会骗人的，在警察的认知中，对自己掌握的信息中认为你也应该掌握。这就是需求沟通中常见的错误，比如出现了一个 bug，在复盘的时候就会发现这个需求没有说清楚，而产品经理就会认为这个需求不需要再说。这些都是被知识所诅咒。两个人所以为的事是不一样的。所以在需求沟通中需要避免这样的问题。在这里把它称为明显的事不一定那么不明显。

（2）错误拷贝：一个通俗的说法是拷贝走样，比如综艺中经常可以看到一个节目叫拷贝不走样，就是将一句话或者动作一次次的传递下去，信息也就会与原来的信息不同。这里面更正式的说明就是德鲁克信息学的第一原理：每一次信息的传递，信息都会减半，噪音加倍。这是在需求传递中，不管是业务传递给产品，传递给开发，再传递给测试运营，会进行不断的信息衰减，错误引路，而这都是要避免的问题。那么如何应对呢，下面进行实例化需求的讲解。

2.实例化需求——更快和更好的沟通需求

实例化需求可以帮助去更快更好的沟通好需求，不仅是沟通，更是澄清需求。

实例化需求是什么：

什么叫实例化需求，就像上面讲的，可能会被自己的知识所诅咒，或者明显的事实规定不明显，那么实例化需求做的事情就是说如果被自己的知识所诅咒，或者沟通中有问题，那最好用实例来澄清需求。实例就是用户在什么情况下会有哪些操作，会得到什么结果，用具体的例子来澄清需求。当拿到一个需求时，用户会如何去是使用它，它是怎样的操作流程，怎样的输入得到怎样的结果。而这些例子将会成为测试，并称为用例。而测试和需求之间的关系就是验证，用例子澄清需求，并且例子会成为测试的用例，用以验证需求，这就是实例化需求（Specification by Example），英文翻译为用例子做实例化说明。下面进行讲解看似很简单的概念，怎样使用才能发挥作用。

 

二、以终为始

实例化需求真正要做到的事情就是以终为始，以终为始就是在做一件事情之前，就应该要知道它应该是什么样子的。整个团队在开始开发之前就要知道它要做成什么样子。这就引用到了下面两个概念。

1. WHEN-实例化需求发生的时间

对应的本节课讲精益敏捷就会讲两种模式，Kanban 和 Scrum 及一个迭代模式。在Kanban 里面需求输入给开发之前，要经过实例化需求这一动作。也就是说这里做到以终为始的始，而 Scrum 的需求是在 Scrum Sprint 里面，里面分为两部分，第一部分是定一个目标要做什么，第二部分做一个计划。

2.WHO-谁参与实例化需求

这里需要回到刚才的故事：拷贝走样，如果是一级一级的传递信息，则会拷贝走样，在传统的开发里面经常这样做，就是直接抛给对方，但还是希望实例化需求的参与者是业务、开发、测试共同参与。实例化需求的业务、开发和产品在一起，发生在需求输入给开发团队之前，用例子澄清需求，从而避免知识的诅咒，避免拷贝走样。这里知道了实例化需求是做什么的，但关键是怎么把实例化需求做好，所以下面讲解实例化需求的步骤和过程。

 

三、实例化需求的步骤和过程：构建需求金字塔

在讲解金字塔前先了解一个概念MECE，也就是说不管要表达任何一个概率，要讲澄清需求要把需求表达出来，将需求的结构化呈现出来。

1.需求澄清过程要做到“ MECE”

MECCE 是什么意思可以参考《麦肯锡方法》中的前言：

不管问多少麦肯锡校友（麦肯锡的员工和前员工），麦肯锡解决问题的方法中，哪些他们映像最深刻，答案都是 MECCE,MECE,MECE。

 ——《麦肯锡方法》

ME是相互独立，就是一个问题讲三点，不能完全正交，比如讲一个事情：这个事情很重要，这个事情真的很重要。这样就是不行的，没有独立。但是这三点加起来要能完整描述这个问题。所以这里分为分清与分净，这和客户需求的关系就是需求要支持三个操作，要支持配置，支持热备份等，要把这个问题讲清楚，而且完全，所以无论如何是要分清分净的，就是相互独立，完全穷举，后来才有了金字塔原理。

2.需求表达和沟通，应该符合金字塔结构

（1）如果一个问题分三点讲解，已经是分清分净的，但这个问题可能抽象程度太高，所以要分为下一个层次，继续分解，而每个层次都要分清分净，所以在这里面描述一个复杂的问题，需求往往都是复杂的，而表述和沟通过程都应该符合MECE原则，然后进行一层一层的分解下来往往就构建了一个金字塔的结构。

（2）对于有一定复杂性的问题，如果其表达符合“MECE”原则，它就会呈现为金字塔的层次结构。这也是芭芭拉.明拓的《金字塔原理》这本书名称的由来。

（3）金字塔结构的本质是:问题的阐述是分层次渐进明晰的。金字塔结构的每一层次保持同一抽象级别，并且每一层次做到完全穷举，且各个元素之间相互独立。

（4）需求的分析、澄清和表达，也应该呈现为金字塔结构，每一层做到MECE。

3.需求的信息组织结构

（1）在行动开始前，你有哪些目标，首先需要找到你的目标，其次就是为了支持你的目标，你所需要些什么操作流程，比如要支持配置和使用。最后就是每一步操作流程的规则是什么，这样一来就保证了需求，澄清了结构，以及对需求澄清中的完整性。

（2）下面讲解一个例子

如图一个团队在进行实例化需求这个活动，应该处于在需求的评审端，当然开发之前不一定是评审，很多时候直接就开始，直接用实例化需求的方式去澄清它是最快的。这个需求的目标在右上角，操作流程是便利贴的位置，规则是右边的部分。规则中最关键的就是如果用户在什么情况下，做什么操作，会看到什么结果，而这里图中所对应的是每个步骤的规则。以上金字塔对应的目标，操作流程，规则都在这个案例图中清晰表达出。

4.积极的挑战

表达出后在澄清的过程中可以有一个积极的挑战，比如挑战目标是不是合理的，挑战目标做好的方法是不做会怎么样，然后就会知道做这个需求的目的是什么。操作流程层可以挑战场景是否涵盖了目标、用户使用流程是否合理、用户使用流程可否简单。规则层可以挑战是否考虑了与工作相关的主要规则和是否考虑异常情况。积极的挑战是有信息的，不做会有哪些负面影响，从另一个方面去理解积极挑战就是针对目标、操作流程和规则的一个检查清单，检查清单是开发时固定的清单，使得流程更简单。

5.实例化需求演练

原始需求:为业务经理做一个贷款的方案咨询程序，能够告知咨询) 相关的贷款资质和方案

相关政策:

首套房政策:对首次贷款购买商品住房，无论是新房还是二手房，首付款比例为30%及以上，利率为基准利率。

二套房政策:对贷款购买第二套住房的家庭，严格执行首付款比例不低60%、贷款利率不低于基准利率1.1倍的规定。

三套房政策:全面叫停三套房贷，各商业银行暂停发放居民家庭购买第三套及以上住房贷款。

商业银行在贷款前需要向征信管理部门查询贷款人的信用报告，如果一个人有过不良的信用记录 如逾期不归还信用卡欠款等，且贷款不良记录超过银行相关规定(信用评级为D)的话，不管其他条件如何，都无法获得贷款。如果没有查询到信用记录，也不能获得购房人应向银行提供收入证明。对于“共同贷款人”，不仅要求是为“贷款人”的直系亲属(夫妻 子女、父母)，还必须为住房贷 款抵押物的房产所有者之一。主贷人和共同贷款人是夫妻关系除外。即使房产证上只有夫妻一方的名字，另一方也可以作为住房贷款的“共同贷款人”。贷款人每月的还贷额不能超过主贷款人和共同贷款人总月收入的三分之一。 如果贷款人还有其他贷款，应在 总收入中扣除。

“主贷人”的年龄加上住房贷款的年限，男性不能超过65，女性不能超过60，住房贷款的期限最长为30年。此外，贷款年限加上房龄的总和不能超过40年。

这时候要制作一个系统，能够给客户更好的支持。

STEP 1.目标澄清

目标用户:房产信贷客户经理

目标:

（1）可以用它快速确定客户及其房屋的贷款资格，并告知可能的贷款方案。

（2）当政策发生变化时也可以在系统中统一配置更新，避免政策理解不到位，或不能即时更新的问题

现存解决方案:

人工咨询，政策发生变化则发通告，告知个分支机构

如果不做会怎么样?

信息通知经常不及时;会因业务经理不了解最新政策，而告知错误信息产生矛盾

STEP2.澄清操作和流程

资格审查：能不能贷；方案计算：贷多少；规则配置：谁可以配；用户管理：就是操作。

STEP3.澄清规则

如果征信记录好于D（包含D）则可以贷款

如果征信记录小于D则不可以贷款

规则1：如果是一套或二套房，则可以贷款

规则2：如果是三套房或以上，则不可以贷款

6.从SBE到测试自动化

上文所提到的规则都会变成自动化测试的用例，表格会成为自动化测试的数据表格。本节课不会过大介绍自动化测试，可参考左下角连接，自动化测试的五条原则，自行拓展。SBE就是实例化需求的缩写。

 

四、重构开发过程：从实例化需求到验收测试驱动开发

以上已经讲了实例化的过程是开发，测试和业务，业务包含产品，也讲解了怎么去做实例化需求，通过三个层面，为目标，需求的操作，规则，规则实际就是最终的例子，也称为验收标准，而如何产生好的验收标准需要有操作目标的步骤，那么实例化需求为什么这么重要呢，下面进行讲解实例化需求不仅仅是一个需求的实践。

1.实例化需求+有效和即时地自动验收测试=验收测试驱动开发

如图是一个看板，顶部分别是待开发，开发中，验收，可发布，已发布。

如图实例化需求发生在开发之前，在开发之前用例子澄清需求，接下来在开发过程中同步地转化为测试用例，测试的时候可以用这些测试用例来验证需求。在这样的开发过程有时也被称为 ATDD，就是验收测试驱动开发。TDD 是开发者的行为，它是比较困难的，但是它也非常有效，如果 TDD 前不加前缀的化，TDD 往往指的是单元测试开发，是开发者行为，与测试无关。验收测试驱动开发的门槛较低，撬动作用很大。改变开发模式和流程。

上图虽然表达形式不一样，但都有流程、有规则，开发测试和业务在开始需求之前做的事，其实在开始之前有了明确的验收标准，那么开发看到的就会是需求，参与度就完全不同。

2.实际应用中带来的其他收益

（1）  故事的拆分不再是问题

（2）  故事的粒度变得一致（都是一个独立的操作）

（3）  过滤掉了无用的需求

（4）  简化了需求，同时改善了用户体验

（5）  开发、测试之间的相互支持

（6）  团队对共同目标的意识更强；测试人员的作用明显加强

（7）  开发移交(给测试)的质量显著提高（开发有条件做测试）

（8）  自动化测试完成时间提前

（9）  降低自动化测试的实施难度

3.takeaways

（1）以终为始:在开始开发前，定义验收标准，明确需求应该构建成什么样

（2）共同参与:开发、测试、业务共同参与，即时、小批量地澄清需求，符合精益和敏捷的原则。

（3）构建需求金字塔:基于目标、操作流程、和规则构建需求澄清的金字塔

（4）从实例化需求到验收测试驱动开发: 这是一个非常自然的过程，实例化需求和验收测试驱动开发是一对经常混用的术语，除了二者外还有行为驱动开发，简称BDD。以实例化需求为基础，改变协作的模式和开发过程，实现验收测试驱动开发(Acceptence Test Driven Development)