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

　　总有一些小需求，根本写不出PRD姜太公公
　　你是否遇到过写不出PRD的小需求呢？也就是我们经常说的“一句话需求”。
　　加个按钮，改个颜色，加个跳转，删除个逻辑blabala～这种情况下，你说写PRD吧？写10个字儿写完了。不写PRD吧？和开发童鞋直接沟通，开发完成后发现和预期相差八百里。那么，你是怎么处理“一句话需求”的呢？你在处理过程中和开发沟通的愉快吗？
　　举一个实际例子：
　　产品：在这个页面增加一个回到顶部的按钮。这个需求的场景是用户在列表页一直滑滑滑，突然想回到页面顶部，这个按钮可以帮助用户快捷回到顶部
　　技术：好的
　　
　　一天之后
　　产品：这个回到顶部按钮为啥出现在首屏？我还没有滑呢为啥它就出现了？这时候不需要回到顶部啊？
　　技术：你说过吗？
　　所以你看，“一句话需求”真是说时一时爽，上线之后都是填不完的坑。
　　那么问题来了，为啥给开发讲“一句话需求”开发总是做的跑遍了？明明是一个很简单的需求啊！
　　其实，“一句话需求”没有错，错的是你踩了“场景”和“实现效果”两个大坑。要高效的沟通“一句话需求”，可以尝试的遵守如下两个原则：
　　原则一：“一句话需求”不要谈场景，要讲“当前状态”！
　　原则二：“一句话需求”不要谈实现效果，要讲“用例”！
　　原则一：“一句话需求”不要谈场景，要讲“当前状态”！
　　什么是场景？简单来说，就是什么人在什么时间什么地点做了什么事情产生什么结果（whowhenwherewhathow）
　　产品经理必须会谈场景。就像一个情场老手必须时刻把“我爱你”挂在嘴边一样。有了它，你几乎战无不败。直到某一天你遇到一个开发，你手捧粘着露水的玫瑰，深情满满的说“我爱你”，开发扣着脚说“啥？”，想想也是够扫兴的了。
　　那正确的姿势是什么？描述当前状态。
　　如下图，故事原作者是老李说，图片截取自UI中国
　　回到上文加回到顶部按钮的例子，产品说的“这个需求的场景是用户在列表页一直滑滑滑”就是这个需求的场景
　　这样的描述，开发会有如下疑惑：
　　列表页：哪个列表页？搜索结果页，促销列表页？是只加单个列表还是全局添加？
　　列表页状态：在初使状态是否添加回到顶部按钮？在空状态时是否添加回到顶部按钮
　　正确的描述应该是：
　　在“搜索结果页”，用户处于浏览态（没有任何可点击浮层覆盖在“搜索结果页”上），并且当前曝光商品处于屏幕的非首屏，此时需出现一个回到顶部按钮。备注：只要满足上面的条件，无论上滑手势或者下滑手势都可吊起回到顶部按钮展现
　　正确的描述“当前状态”，应该尽可能用结构化的语言。结构化的目的是为了让“一句话需求”的表达更加接近于开发思维，从而减少和开发的信息理解不对称。下面是几种常见的“当前状态”的描述，可以进行参照：
　　当前的物理状态是什么？断网状态，网络不好状态，网络通畅状态
　　当前的用户状态是什么？浏览状态，确认状态，输入状态，等待状态，初始状态
　　当前的页面状态是什么？无结果状态，处于第几屏，是否为叠加层
　　原则二：“一句话需求”不要谈实现效果，要讲“用例”！
　　“一句话需求”讲实现效果可以吗？可以是可以，但是问题是，实现效果是一种感性的描述，而开发是理性的动物。这就是我们的代沟。当你说出实现效果时，你的逻辑是：首先脑海中有画面，然后话语描述实现效果
　　可是开发通过你的一句话可以准确的倒推回和你脑袋里面的画面吗？
　　回到上文加回到顶部按钮的例子，产品说的“用户突然想回到页面顶部，这个按钮可以帮助用户快捷回到顶部”是这个需求的实现效果
　　那怎样的描述可以更加精准的帮助开发理解呢？讲用例。用例是用户完成目标的方法和步骤。告诉开发用户的任务，前置条件，用户做了怎样一个操作。
　　正确的描述应该是：
　　前置条件：用户点击手势或者长按后的松开手势
　　预期结果：页面回到顶部，回到顶部按钮消失
　　总结
　　为啥把“一句话需求”单独拎出来，一方面是有的需求小的根本无法写出PRD，另一方面本着敏捷开发的原理，处理好“一句话需求”可以帮助我们团队提升效率。那么PRD怎么写呢？下回分解吧。
　　PS：你被哪些“一句话需求”坑过吗？欢迎大家留言踊跃留言