这里是IT修真院产品分享课，今天要分享的是
【需求的重要性】
一、需求中的“之乎者也”
产品经理在日常的工作中，大约80%的时间都在跟需求打交道。
2C领域，我们需要了解，分析，拆解，跟进用户需求；
2B领域，我们需要了解，分析，拆解，跟进业务、客户需求。
需求与产品有一种天然的“唇齿相依”的关系。
为什么这么说呢？
在我看来，需求是产品的前置驱动，而产品是需求价值的具象体现。在实际的工作中，产品开发源于，基于需求，也就是需求是产品开发的输入。
如果输入源头缺乏保障，就会变成GIGO（Garbage in，garbage out）：输入是垃圾，输出也是垃圾。
需求的分析，澄清和沟通是产品顺利落地的保障。于是为了保证源头的准确，可靠，在我们日常的工作中，通常需求文档中会堆砌大量的规则、约束条件，这些通常需要很拗口，复杂的文字去书写。
实践表明：用文字去书写规则是件“狗带”的事情，用语言去讲规则更是件“狗带、狗带”的事情。
比如一个关于下拉选项的规则：显示第一个有有效状态的活跃选项的对应的有效内容。
这个规则无论给用户、客户去看，还是给开发和测试同事澄清，都会觉得特别别扭。前者难以理解，后者难以澄清。
其实不难发现，有时候一些规则就是一些特定情况下的实例，你会发现写了大半篇幅去说明清楚的几个规则，举几个例子就很轻而易举的搞定了。
所以，面对需求中的这些“之乎者也”，语言变得那么的苍白无力。
二、实例化需求
为了解决上述需求实施过程中的一些问题，实例化需求应用而生。
到底什么是实例化需求呢？看下图：
1、用例子来澄清需求；
2、这些例子成为测试用例；
3、开发完毕，用这些例子来验证需求。
不难发现实例化需求，从始至终都在强调例子。
做产品需要好用易用，沟通需求也需要通俗易懂。
这是我从这次培训中受益最大的地方，也是最切实可操作的方法。
为什么要基于实例去沟通需求？一切都源于一种叫做“知识的诅咒”的东西。
人们在沟通的时候不自主的认为别人拥有和自己一样的背景知识，从而带来了沟通的障碍和误解
产品人员对业务比较了解，但是对开发知识就比较缺乏；开发人员对开发技能比较专业，但是对业务知识可能并不深入。
这就是知识的诅咒，而例子则可以打破这个魔咒。
实例化的需求，从基本的需求分析开始，到最后的需求交付，整个过程可以基于已有的资源，比如已经上线的系统，然后用可视化的方法进行需求澄清。
在我看来这种方法尤其适用于对于业务规则较多，且复杂的场景下进行需求文档的编写和需求澄清。
三、实例化需求的实施
那知道了实例化需求的典型应用场景之后，我们再看一下一个需求中一般包含哪些内容？
先看下面的需求金字塔：
需求金字塔包含了三个层次，这三个层次既是需求分析的层次，也是需求编写和表述的层次。
需求的目标：需求从沟通目标开始。所谓需求的目标，你可以称述为这个需求解决谁的问题，什么问题，当前的现状，不解决会带来哪些后果。
操作和操作步骤：为了实现上面的目标，系统需要支持用户哪些操作？这些操作的先后顺序是什么样的？
业务规则：基于用户的操作步骤，在什么情况下，用户做什么操作，会产生什么样的结果。这些规则可能是对应一个操作步骤，也可能是对应多个操作步骤之后的综合的结果。
基于上述需求的三大部分，我们可以分别对其进行落地操作。
澄清当前需求的背景和现在；澄清当前需求想要实现的目标和解决的问题。
其实，这块我们在平时的工作中特别容易忽略的部分，以为澄清需求只需要把功能点，逻辑，交互和规则讲清楚就行。这就是为什么在需求澄清会上产品经理经常会受到莫名其妙的挑战，开发和测试同事对需求目标的理解不一致有很大的原因。
- 识别操作以及操作步骤。
列出相关的操作；画出各个操作的用户使用工作流。
这个时候我们需要注意以下几个问题：
（1）比如流程是否合理和高效？任务走查是一个非常好的验证方法，这块后续再议。
（2）是否覆盖所有场景，异常场景有无考虑，是否全面？
（3）流程是否可以更简单？
示意图，流程图在这里是一个很好的表现方式，直观且易于工程师理解。
- 定义业务规则。
规则其实就是输入触发输出的一个结合。通俗的说就是在什么情况下，做什么操作，产生什么样的结果。
业务规则是需求文档中必不可少的内容，因为它关系到逻辑的严谨性，进而影响系统的稳定性，最终直接关系到产品的用户体验和企业的利益。这个步骤需要考虑的是规则是否完整？是否考虑的各种情况，比如异常、出错情况等。
对于规则的编写时最考验一个人逻辑是否严谨的时刻，也是最能体现汉语博大精深的地方。但是如何能够更直观，形象的表达出来就是实例化需求的用武之地了。
我工作中的实践经验就是：
在传达信息的效果上：视觉>听觉>感觉。
所以，在尝试编写复杂，拗口的规则时候，多用图例的方式，少用语言。
【更多内容，欢迎加入交流群565763832与大家一起讨论交流】
【这里是技能树·IT修真院：，初学者转行到互联网的聚集地】