需求描述方法论:条件—结果—目标

0 评论 1851 浏览 13 收藏 9 分钟

本文作者从自身工作实践出发,梳理总结了关于需求描述的非常使用的经验方法,与大家分享。

唠嗑时光

各位乡亲父老们,欢迎来到村里!我还是先来自我介绍下,免得各位老乡对我有些陌生(此处需要些掌声!)。

背景:在大四实习选择了产品汪道路的我,有幸在世界500强某公司实习,这让我在毕业后工作上更有底气了(邪恶笑)。刚开始实习时,就想着从我的工作点滴中总结出一些产品干货,与各位乡亲父老们学习、讨论…….(想着有一天能在村里的广播站,作为村里的产品传播员,分享干货)。没想到现在已经毕业两年了,才开始输出我第一篇干货,才作为村里的产品传播员。

好了,我们还是先进入到正题吧,(不然我这个村里产品传播员的位置不保了!)各位乡亲父老们,请准备好笔和纸,今天的入门级干货课程马上开始。今天分享的干货,对于刚入门产品的村员们来说,个人觉得非常实用。这也是我在实习的时候,自己总结出来的一些需求描述方法论

工作场景

上级汪:待会和客户开需求会议后,你把需求描述下,记录至需求池中。

下级汪信心满满地说:好的,没问题。(不就是把客户的需求记录下而已,这也太简单了! 偷笑)

会议结束,下级汪很快就把客户的需求记录至需求池中,胸有成竹提交至上级汪。

上级汪看了看,这需求怎么描述地一团糟呢,看起来真费劲!!

在初步入产品工作时,你很有可能需要维护项目的需求池,记录来自客户、公司各个部门的需求,那我们怎么去做好需求描述呢?那我们直接进入到真题演练环节吧,让各位老乡们实战感受下。

真题演练

项目背景:此系统用于门店旅行社,用户下载APP登录后,需绑定旅行社员工(旅游专家)。绑定后,旅行社员工可为用户提供专业的旅游服务,如旅游选品推荐、旅游订单确认等。

下级汪描述的需求

1. 需求描述:

用户绑定旅游专家后,若旅行社员工不在旅行社或休息日时,则无法处理相关业务。

2. 解决方案如下:

(1)当旅行社员工收到订单需求后无法处理时,自行联系同事帮忙处理;

(2)当旅行社员工收到订单需求不在旅行社时,可通过手机登录营业端进行处理。

3. 需求评审结果:

软件开发角度上暂不修改,通过其他方式按照解决方案(1)(2)暂时解决此问题。

上级汪描述的需求

1. 需求描述:

当用户绑定了旅游专家,且营业端只能在(旅行社的)PC上运行,如果该旅游专家不在旅行社或PC出故障时,当用户发起相关业务时,该旅游专家无法处理用户的业务请求,也无法委托其他同事代办。旅行社要求希望此情况下该旅游专家要能够处理用户的业务请求。

2. 解决方案如下:

(1)系统增加旅游专家委托代办功能;

(2)系统增加营业端的手机版;

3. 需求评审结果:软件暂不修改

(1)委托代办:该旅行社员工把自己的账号密码临时通知同事代为处理,事后变更密码即可。

(2)营业端的手机版:后续适当时机会安排开发;目前该旅行社员工可以用手机浏览器直接登录营业端,界面虽然没有针对手机优化,但可以使用。

点评:通过上级汪和下级汪之间的需求描述对比,在不了解项目的整体情况下,看到上级汪的需求描述时,我们也能很清楚的知道在描述一个怎么样的需求,而下级汪描述的需求,需要对整个项目整体很了解,我们才可以看得懂。在实际情况下,需求会议上会有对项目了解程度不同的人员参会,所以按照上级汪的描述方式,好处显而易见。

方法提取

那么上级汪是如何把需求描述地如此清晰呢,使得对项目了解程度不同的人员都能理解?其实在描述需求的时候是有一套方法论,那接下来,我讲对上级汪的需求进行拆分,各位乡亲父老们,睁大眼睛看看!

1. 需求描述:

条件:

(1)当用户绑定了旅游专家,且营业端只能在(旅行社的)PC上运行;

(2)如果该旅游专家不在旅行社或PC出故障时,当用户发起相关业务时;

结果:

(1)旅游专家无法处理用户的业务请求,

(2)旅游专家也无法委托其他同事代办。

目标:

旅行社要求希望此情况下该旅游专家要能够处理用户的业务请求。

2. 解决方案:

(1)系统增加旅游专家委托代办功能;

(2)系统增加营业端的手机版;

3. 需求评审结果:软件暂不修改:

(1)委托代办:该旅行社员工把自己的账号密码临时通知同事代为处理,事后变更密码即可。

(2)营业端的手机版:后续适当时机会安排开发;目前该旅行社员工可以用手机浏览器直接登录营业端,界面虽然没有针对手机优化,但可以使用。

我把上级汪的需求描述拆分后,各位乡亲父老们应该能很清晰地看出其中的套路了吧。

在描述需求的过程中,我们使用以下的套路,会让你的需求描述看起来:

  1. 条件:描述下事情发生在怎么样的前提条件下,也可称为事情发生的前置条件;
  2. 结果:时间发生后,产生的结果是什么;也可称为事情发生的后置条件;
  3. 目标:在产生的结果下,需要解决怎么样的问题;

所以我们再描述需求时,我们脑海中应该有这么一条弦:条件—结果—目标,这样描述出来的需求更胜一筹!在需求描述完成之后,通过需求会议讨论出解决方案及解决方案的评审结果。

大家可以拿起手头上的需求,赶紧试试,看看是否显灵!

希望这点小小干货对各位乡亲父老们有小小的帮助,欢迎共同探讨。之后将会持续发布干货文章,欢迎关注!村里产品传播员要下线了!

 

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

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!