“三步走”解决需求编写和澄清问题

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