“一句话需求”如何需求评审?两个原则全搞定

零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。了解详情

总有一些小需求,根本写不出PRD——姜太公公

你是否遇到过写不出PRD的小需求呢?也就是我们经常说的“一句话需求”。

加个按钮,改个颜色,加个跳转,删除个逻辑……blabala~ 这种情况下,你说写PRD吧?写10个字儿写完了。不写PRD吧?和开发童鞋直接沟通,开发完成后发现和预期相差八百里。那么,你是怎么处理“一句话需求”的呢?你在处理过程中和开发沟通的愉快吗?

举一个实际例子:

产品:在这个页面增加一个「回到顶部的按钮」。这个需求的场景是用户在列表页一直滑滑滑,突然想回到页面顶部,这个按钮可以帮助用户快捷回到顶部

技术:好的

 

一天之后……

产品:这个「回到顶部按钮」为啥出现在首屏?我还没有滑呢为啥它就出现了?这时候不需要回到顶部啊?
技术:你说过吗?

所以你看,“一句话需求”真是说时一时爽,上线之后都是填不完的坑。

那么问题来了,为啥给开发讲“一句话需求”开发总是做的跑遍了?明明是一个很简单的需求啊!

其实,“一句话需求”没有错,错的是你踩了“场景”和“实现效果”两个大坑。要高效的沟通“一句话需求”,可以尝试的遵守如下两个原则:

原则一:“一句话需求”不要谈场景,要讲“当前状态”!

原则二:“一句话需求”不要谈实现效果,要讲“用例”!

原则一:“一句话需求”不要谈场景,要讲“当前状态”!

什么是场景?简单来说,就是什么人在什么时间什么地点做了什么事情产生什么结果(who+when+where+what+how)

产品经理必须会谈「场景」。就像一个情场老手必须时刻把“我爱你”挂在嘴边一样。有了它,你几乎战无不败。直到某一天你遇到一个开发,你手捧粘着露水的玫瑰,深情满满的说“我爱你”,开发扣着脚说“啥?”,想想也是够扫兴的了。

那正确的姿势是什么?描述当前状态。

如下图,故事原作者是「老李说」,图片截取自UI中国

回到上文加「回到顶部按钮」的例子,产品说的“这个需求的场景是用户在列表页一直滑滑滑”就是这个需求的场景……

这样的描述,开发会有如下疑惑:

  • 列表页:哪个列表页?搜索结果页,促销列表页?是只加单个列表还是全局添加?
  • 列表页状态:在初使状态是否添加「回到顶部按钮」?在空状态时是否添加「回到顶部按钮」

正确的描述应该是:

在“搜索结果页”,用户处于浏览态(没有任何「可点击浮层」覆盖在“搜索结果页”上),并且当前曝光商品处于屏幕的非首屏,此时需出现一个「回到顶部按钮」。备注:只要满足上面的条件,无论上滑手势或者下滑手势都可吊起「回到顶部按钮」展现

正确的描述“当前状态”,应该尽可能用结构化的语言。结构化的目的是为了让“一句话需求”的表达更加接近于开发思维,从而减少和开发的信息理解不对称。下面是几种常见的“当前状态”的描述,可以进行参照:

  • 当前的物理状态是什么?断网状态,网络不好状态,网络通畅状态……
  • 当前的用户状态是什么?浏览状态,确认状态,输入状态,等待状态,初始状态……
  • 当前的页面状态是什么?无结果状态,处于第几屏,是否为叠加层……

原则二:“一句话需求”不要谈实现效果,要讲“用例”!

“一句话需求”讲实现效果可以吗?可以是可以,但是问题是,实现效果是一种感性的描述,而开发是理性的动物。这就是我们的代沟。当你说出实现效果时,你的逻辑是:「首先脑海中有画面,然后话语描述实现效果」

可是开发通过你的一句话可以准确的倒推回和你脑袋里面的画面吗?

回到上文加「回到顶部按钮」的例子,产品说的“用户突然想回到页面顶部,这个按钮可以帮助用户快捷回到顶部”是这个需求的实现效果……

那怎样的描述可以更加精准的帮助开发理解呢?讲用例。用例是用户完成目标的方法和步骤。告诉开发用户的任务,前置条件,用户做了怎样一个操作。

正确的描述应该是:

  • 前置条件:用户点击手势或者长按后的松开手势
  • 预期结果:页面回到顶部,「回到顶部按钮」消失

总结

为啥把“一句话需求”单独拎出来,一方面是有的需求小的根本无法写出PRD,另一方面本着敏捷开发的原理,处理好“一句话需求”可以帮助我们团队提升效率。那么PRD怎么写呢?下回分解吧。

PS: 你被哪些“一句话需求”坑过吗?欢迎大家留言踊跃留言

 

作者:姜太公公  (微信号公众号:grandpa_jiang)  产品老流氓,终身学习者。致力于研究产品方法论,解决小白PM的疑难杂症。

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

祝给予赞赏的伙伴,2017年发大财!
5人打赏

评论( 4

写下你的想法
  1. 该用户懒得认证。

    领导提的几乎每一个需求都是“一句话需求”

    回复
  2. 换位思考,以程序员视角写文档,这是最好的方式

    回复
  3. 适合零散小需求

    回复
  4. 不错,受益匪浅!

    回复

推荐阅读