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

3周带你玩转Excel!在行第一行家手把手带学+作业实战+答疑辅导,升职加薪快人一步,了解一下>>

实例化需求不仅解决了需求分析和撰写的问题,也给出了需求沟通和澄清的方法。本文介绍了一些关于实例化需求的学习和工作体会。

之前听了一场何勉老师的线上分享课程,他是敏捷和精益开发方面的专家。听完之后,我最为好奇和想要去实践的是实例化需求。

于是,这之后,基于线上培训关于实例化需求的阐述,做了一个更为深入的了解。

以下是一篇学习笔记和心得,希望能够帮助大家解决一些困惑,也为了自己后续工作的实践。

一、需求中的“之乎者也”

产品经理在日常的工作中,大约80%的时间都在跟需求打交道。

  1. 2C领域,我们需要了解,分析,拆解,跟进用户需求;
  2. 2B领域,我们需要了解,分析,拆解,跟进业务、客户需求。
    需求与产品有一种天然的“唇齿相依”的关系。

为什么这么说呢?

在我看来,需求是产品的前置驱动,而产品是需求价值的具象体现。在实际的工作中,产品开发源于,基于需求,也就是需求是产品开发的输入。

如果输入源头缺乏保障,就会变成GIGO(Garbage in,garbage out):输入是垃圾,输出也是垃圾。

需求的分析,澄清和沟通是产品顺利落地的保障。于是为了保证源头的准确,可靠,在我们日常的工作中,通常需求文档中会堆砌大量的规则、约束条件,这些通常需要很拗口,复杂的文字去书写。

实践表明:用文字去书写规则是件“狗带”的事情,用语言去讲规则更是件“狗带、狗带”的事情。

比如一个关于下拉选项的规则:显示第一个有有效状态的活跃选项的对应的有效内容。

这个规则无论给用户、客户去看,还是给开发和测试同事澄清,都会觉得特别别扭。前者难以理解,后者难以澄清。

其实不难发现,有时候一些规则就是一些特定情况下的实例,你会发现写了大半篇幅去说明清楚的几个规则,举几个例子就很轻而易举的搞定了。

所以,面对需求中的这些“之乎者也”,语言变得那么的苍白无力。

二、实例化需求

为了解决上述需求实施过程中的一些问题,实例化需求应用而生。

到底什么是实例化需求呢?看下图:

上图中可以看出实例化需求的三个特征:

  1. 用例子来澄清需求;
  2. 这些例子成为测试用例;
  3. 开发完毕,用这些例子来验证需求。

不难发现实例化需求,从始至终都在强调例子。

做产品需要好用易用,沟通需求也需要通俗易懂。

这是我从这次培训中受益最大的地方,也是最切实可操作的方法。

为什么要基于实例去沟通需求?一切都源于一种叫做“知识的诅咒”的东西。

人们在沟通的时候不自主的认为别人拥有和自己一样的背景知识,从而带来了沟通的障碍和误解

产品人员对业务比较了解,但是对开发知识就比较缺乏;开发人员对开发技能比较专业,但是对业务知识可能并不深入。

这就是知识的诅咒,而例子则可以打破这个魔咒。

实例化的需求,从基本的需求分析开始,到最后的需求交付,整个过程可以基于已有的资源,比如已经上线的系统,然后用可视化的方法进行需求澄清。

在我看来这种方法尤其适用于对于业务规则较多,且复杂的场景下进行需求文档的编写和需求澄清。

三、实例化需求的实施

那知道了实例化需求的典型应用场景之后,我们再看一下一个需求中一般包含哪些内容?

先看下面的需求金字塔:

(图片来之何勉老师分享)

需求金字塔则讲述了一个完整需求应该包含哪些内容?

需求金字塔包含了三个层次,这三个层次既是需求分析的层次,也是需求编写和表述的层次。

需求的目标:需求从沟通目标开始。所谓需求的目标,你可以称述为这个需求解决谁的问题,什么问题,当前的现状,不解决会带来哪些后果。

操作和操作步骤:为了实现上面的目标,系统需要支持用户哪些操作?这些操作的先后顺序是什么样的?

业务规则:基于用户的操作步骤,在什么情况下,用户做什么操作,会产生什么样的结果。这些规则可能是对应一个操作步骤,也可能是对应多个操作步骤之后的综合的结果。

基于上述需求的三大部分,我们可以分别对其进行落地操作。

(图片来之何勉老师分享)

如上图所示,三个步骤:

1. 澄清价值。

澄清当前需求的背景和现在;澄清当前需求想要实现的目标和解决的问题。

其实,这块我们在平时的工作中特别容易忽略的部分,以为澄清需求只需要把功能点,逻辑,交互和规则讲清楚就行。这就是为什么在需求澄清会上产品经理经常会受到莫名其妙的挑战,开发和测试同事对需求目标的理解不一致有很大的原因。

2. 识别操作以及操作步骤。

列出相关的操作;画出各个操作的用户使用工作流。

这个时候我们需要注意以下几个问题:

(1)比如流程是否合理和高效?任务走查是一个非常好的验证方法,这块后续再议。

(2)是否覆盖所有场景,异常场景有无考虑,是否全面?

(3)流程是否可以更简单?

示意图,流程图在这里是一个很好的表现方式,直观且易于工程师理解。

3. 定义业务规则。

规则其实就是输入触发输出的一个结合。通俗的说就是在什么情况下,做什么操作,产生什么样的结果。

业务规则是需求文档中必不可少的内容,因为它关系到逻辑的严谨性,进而影响系统的稳定性,最终直接关系到产品的用户体验和企业的利益。这个步骤需要考虑的是规则是否完整?是否考虑的各种情况,比如异常、出错情况等。

对于规则的编写时最考验一个人逻辑是否严谨的时刻,也是最能体现汉语博大精深的地方。但是如何能够更直观,形象的表达出来就是实例化需求的用武之地了。

我工作中的实践经验就是:

在传达信息的效果上:视觉>听觉>感觉。

所以,在尝试编写复杂,拗口的规则时候,多用图例的方式,少用语言。

四、结语

以上大概就是关于实例化需求的一些简单学习新的和工作体会。实例化需求在我看来既解决了关于需求分析和撰写的问题,又给出了需求沟通和澄清的方法。

 

作者:夏唬人。公众号:夏唬人,某厂推荐策略产品经理。

本文由 @夏唬人 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 大多数,都看不懂是什么,读完脑子里面还是没有概念,可能缺少例子吧

    回复
  2. 作者学过艺术概论

    回复
    1. 哈哈,没有没有。。。经验而已

      回复