实例化需求不仅解决了需求分析和撰写的问题，也给出了需求沟通和澄清的方法。本文介绍了一些关于实例化需求的学习和工作体会。之前听了一场何勉老师的线上分享课程，他是敏捷和精益开发方面的专家。听完之后，我最为好奇和想要去实践的是实例化需求。 于是，这之后，基于线上培训关于实例化需求的阐述，做了一个更为深入的了解。 以下是一篇学习笔记和心得，希望能够帮助大家解决一些困惑，也为了自己后续工作的实践。
一、需求中的“之乎者也”
产品经理在日常的工作中，大约80%的时间都在跟需求打交道。- 2C领域，我们需要了解，分析，拆解，跟进用户需求；
- 2B领域，我们需要了解，分析，拆解，跟进业务、客户需求。 需求与产品有一种天然的“唇齿相依”的关系。
二、实例化需求
为了解决上述需求实施过程中的一些问题，实例化需求应用而生。 到底什么是实例化需求呢？看下图：
上图中可以看出实例化需求的三个特征：
- 用例子来澄清需求；
- 这些例子成为测试用例；
- 开发完毕，用这些例子来验证需求。
人们在沟通的时候不自主的认为别人拥有和自己一样的背景知识，从而带来了沟通的障碍和误解产品人员对业务比较了解，但是对开发知识就比较缺乏；开发人员对开发技能比较专业，但是对业务知识可能并不深入。 这就是知识的诅咒，而例子则可以打破这个魔咒。 实例化的需求，从基本的需求分析开始，到最后的需求交付，整个过程可以基于已有的资源，比如已经上线的系统，然后用可视化的方法进行需求澄清。 在我看来这种方法尤其适用于对于业务规则较多，且复杂的场景下进行需求文档的编写和需求澄清。
三、实例化需求的实施
那知道了实例化需求的典型应用场景之后，我们再看一下一个需求中一般包含哪些内容？ 先看下面的需求金字塔：
（图片来之何勉老师分享）
需求金字塔则讲述了一个完整需求应该包含哪些内容？ 需求金字塔包含了三个层次，这三个层次既是需求分析的层次，也是需求编写和表述的层次。 需求的目标：需求从沟通目标开始。所谓需求的目标，你可以称述为这个需求解决谁的问题，什么问题，当前的现状，不解决会带来哪些后果。 操作和操作步骤：为了实现上面的目标，系统需要支持用户哪些操作？这些操作的先后顺序是什么样的？ 业务规则：基于用户的操作步骤，在什么情况下，用户做什么操作，会产生什么样的结果。这些规则可能是对应一个操作步骤，也可能是对应多个操作步骤之后的综合的结果。 基于上述需求的三大部分，我们可以分别对其进行落地操作。
（图片来之何勉老师分享）
如上图所示，三个步骤： 1. 澄清价值。 澄清当前需求的背景和现在；澄清当前需求想要实现的目标和解决的问题。 其实，这块我们在平时的工作中特别容易忽略的部分，以为澄清需求只需要把功能点，逻辑，交互和规则讲清楚就行。这就是为什么在需求澄清会上产品经理经常会受到莫名其妙的挑战，开发和测试同事对需求目标的理解不一致有很大的原因。 2. 识别操作以及操作步骤。 列出相关的操作；画出各个操作的用户使用工作流。 这个时候我们需要注意以下几个问题： （1）比如流程是否合理和高效？任务走查是一个非常好的验证方法，这块后续再议。 （2）是否覆盖所有场景，异常场景有无考虑，是否全面？ （3）流程是否可以更简单？ 示意图，流程图在这里是一个很好的表现方式，直观且易于工程师理解。 3. 定义业务规则。 规则其实就是输入触发输出的一个结合。通俗的说就是在什么情况下，做什么操作，产生什么样的结果。 业务规则是需求文档中必不可少的内容，因为它关系到逻辑的严谨性，进而影响系统的稳定性，最终直接关系到产品的用户体验和企业的利益。这个步骤需要考虑的是规则是否完整？是否考虑的各种情况，比如异常、出错情况等。 对于规则的编写时最考验一个人逻辑是否严谨的时刻，也是最能体现汉语博大精深的地方。但是如何能够更直观，形象的表达出来就是实例化需求的用武之地了。 我工作中的实践经验就是： 在传达信息的效果上：视觉>听觉>感觉。 所以，在尝试编写复杂，拗口的规则时候，多用图例的方式，少用语言。四、结语
以上大概就是关于实例化需求的一些简单学习新的和工作体会。实例化需求在我看来既解决了关于需求分析和撰写的问题，又给出了需求沟通和澄清的方法。 作者：夏唬人。公众号：夏唬人，某厂推荐策略产品经理。爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容；是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台；
想了解更多移动互联网干货知识，请关注微信公众号运营小咖秀（ID: yunyingshow）
【转载说明】 若上述素材出现侵权，请及时联系我们删除及进行处理：8088013@qq.com
