如何用一句话来描述你的需求，以便用最小的沟通成本，获取团队对需求最深刻的了解。
之前一篇文章有提到过，产品经理如何合理获取需求，并合理安排任务，以实现最小成本的投入获取最优产出。
那么这篇文章就是对其的一篇扩充——如何用一句话来描述你的需求，以便用最小的沟通成本，获取团队对需求最深刻的了解。
说到这里，可能会有朋友不相信，因为一句话，如何把一个需求说清楚呢？难道不是说的越详细，才会越清楚吗？说的没错，这也是为什么每一次需求评审会都要开大半个小时的原因了。因为有一半时间在说一些多余的话。
那问题来了，如何说不多余的话，这也是这篇文章的主题。原理很简单，
即谁在什么地方遇到了什么问题，（解决方案），用一个洋气的表达方式就是，Who，Where，Question，（How）
（Ps：括号内的内容是针对开发团队使用的，对外不需要）。
举个栗子：
在开需求确认会的时候，除了一上来的几句开场白，接下来的第一句话只需要说：
市场部leader，希望在工作台，能够将客户名单分给市场专员。
想必各位看官已经知道我们接下来要做核心需求是什么了。
剩下肯定是还有一些不明确的地方，但那并不是核心，只不过是为了把一个抽象需求细化的辅助描述，即便不说，团队成员也已经知道自己本次会议的目标是什么，本次工作任务的目的是什么。能够在会议之初就明确目标不说，还因此大大缩短了会议时间，提高了效率，这就是一句话需求的魅力所在。
上面已经提到了，Who，Where，Question。那还剩一个How，应该怎么办。这时，身为产品的你，就要拿出你的看家本事了，如何用同样的方式，用几句话把需求表达清楚。
在这里我有一个不成熟的建议，可供大家参考。个人认为，可使用一个模板，把需求拆分成几句话，例如：
需求描述：市场部leader，希望在工作台，能够将客户名单分给市场专员；
涉及角色：市场部leader、市场专员；
载体：内部系统的工作台（务必附图）；
核心功能：批量分配，显示市场专员手头名单数量；
分配对象：客户名单；
分配规则：即分配规则，“相对公平”分配；
“相对公平”的定义：即所有人手头名单尽量平均。
以上。
看到这，也许大家已经知道这个需求的核心关键点在哪了，甚至已经可以大致估算时间了。当然，估算时间的事情还是交给开发负责人来比较合适，毕竟人家对工期直接负责。
当然，上面描述的需求并不清晰，因为分配规则本身不合理，但这毕竟只是一个栗子，不做深究。
话说回来，如果在需求确认会之前，就做好这个表单，在开会的时候，给大家往那一展示，若还有问题，基本上也就是一些细节问题了，就不一一举栗了。
如果有朋友感兴趣，可以尝试着把手头的需求精简成一句话，建议从简单的需求开始，逐渐简化复杂的需求。
我再举个略微复杂的栗子（就不做详细分析了，毕竟篇幅有限）。
如：财务，希望能在客户消费情况中，开发票。
简单分析如下：
需求描述：财务，希望能在客户消费情况中，开发票；
涉及角色：财务、客户；
载体：内部系统的客户管理–消费详情（务必附图）；
核心功能：开发票；
开票对象：客户订单；
开票类型：单笔订单（非全额）开票、多笔订单合并（非全额）开票、多客户合并开票（团票）。
开票规则：
开过团票的订单，不再允许开个人发票；反之亦然。
以上。
其实到了这里，相比大家也多少清楚了本需求的核心目标，但是这其中还有很多隐藏需求，也许大家也发现了。
申请开票，必须要有发票抬头等信息，需要提供客户填写的端口；
发票也许需要寄送，那么还需要接入快递模块，如果每日开票数量足够大（几十上百），甚至需要接入快递单打印机，以及相应的快递信息录入端口，可以和申请开票做在一起。
以上还只是我简单描述了一下显性需求和隐性需求，也许还有很多待挖掘的部分我没提到。但是无论如何，我们的一句话需求还是很成功的，因为大家都清楚了本次需求确认会的核心目标，至于那所谓的隐性需求，只不过是为了满足大需求而做的铺垫，也能够按照普通需求一样，通过一句话来描述需求，并逐一拆分、细化，逐一完成。
最后，个人建议，将一句话描述需求养成习惯。真的受益匪浅。
