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