如何用一句话来描述你的需求，以便用最小的沟通成本，获取团队对需求最深刻的了解。

之前一篇文章有提到过，产品经理如何合理获取需求，并合理安排任务，以实现最小成本的投入获取最优产出。

那么这篇文章就是对其的一篇扩充——如何用一句话来描述你的需求，以便用最小的沟通成本，获取团队对需求最深刻的了解。

说到这里，可能会有朋友不相信，因为一句话，如何把一个需求说清楚呢？难道不是说的越详细，才会越清楚吗？说的没错，这也是为什么每一次需求评审会都要开大半个小时的原因了。因为有一半时间在说一些多余的话。

那问题来了，如何说不多余的话，这也是这篇文章的主题。原理很简单，

即谁在什么地方遇到了什么问题，（解决方案），用一个洋气的表达方式就是，Who，Where，Question，（How）

（Ps：括号内的内容是针对开发团队使用的，对外不需要）。

举个栗子：

在开需求确认会的时候，除了一上来的几句开场白，接下来的第一句话只需要说：

市场部leader，希望在工作台，能够将客户名单分给市场专员。

想必各位看官已经知道我们接下来要做核心需求是什么了。

剩下肯定是还有一些不明确的地方，但那并不是核心，只不过是为了把一个抽象需求细化的辅助描述，即便不说，团队成员也已经知道自己本次会议的目标是什么，本次工作任务的目的是什么。能够在会议之初就明确目标不说，还因此大大缩短了会议时间，提高了效率，这就是一句话需求的魅力所在。

上面已经提到了，Who，Where，Question。那还剩一个How，应该怎么办。这时，身为产品的你，就要拿出你的看家本事了，如何用同样的方式，用几句话把需求表达清楚。

在这里我有一个不成熟的建议，可供大家参考。个人认为，可使用一个模板，把需求拆分成几句话，例如：

1. 需求描述：市场部leader，希望在工作台，能够将客户名单分给市场专员；
2. 涉及角色：市场部leader、市场专员；
3. 载体：内部系统的工作台（务必附图）；
4. 核心功能：批量分配，显示市场专员手头名单数量；
5. 分配对象：客户名单；
6. 分配规则：即分配规则，“相对公平”分配；
7. “相对公平”的定义：即所有人手头名单尽量平均。

以上。

看到这，也许大家已经知道这个需求的核心关键点在哪了，甚至已经可以大致估算时间了。当然，估算时间的事情还是交给开发负责人来比较合适，毕竟人家对工期直接负责。

当然，上面描述的需求并不清晰，因为分配规则本身不合理，但这毕竟只是一个栗子，不做深究。

话说回来，如果在需求确认会之前，就做好这个表单，在开会的时候，给大家往那一展示，若还有问题，基本上也就是一些细节问题了，就不一一举栗了。

如果有朋友感兴趣，可以尝试着把手头的需求精简成一句话，建议从简单的需求开始，逐渐简化复杂的需求。

我再举个略微复杂的栗子（就不做详细分析了，毕竟篇幅有限）。

如：财务，希望能在客户消费情况中，开发票。

简单分析如下：

1. 需求描述：财务，希望能在客户消费情况中，开发票；
2. 涉及角色：财务、客户；
3. 载体：内部系统的客户管理–消费详情（务必附图）；
4. 核心功能：开发票；
5. 开票对象：客户订单；
6. 开票类型：单笔订单（非全额）开票、多笔订单合并（非全额）开票、多客户合并开票（团票）。

开票规则：

1. 单笔（合并）开票金额≤对应（多笔）订单剩余可开票金额;
2. 单笔订单开票和多笔订单合并开票不互斥;
3. 开过团票的订单，不再允许开个人发票；反之亦然。
4. 以上。

其实到了这里，相比大家也多少清楚了本需求的核心目标，但是这其中还有很多隐藏需求，也许大家也发现了。

1. 开票的前提，必须确保订单金额及可开票无误；
2. 开票还涉及到打印发票，需要对接开票打印机or税控盘；
3. 申请开票，必须要有发票抬头等信息，需要提供客户填写的端口；
4. 发票也许需要寄送，那么还需要接入快递模块，如果每日开票数量足够大（几十上百），甚至需要接入快递单打印机，以及相应的快递信息录入端口，可以和申请开票做在一起。

以上还只是我简单描述了一下显性需求和隐性需求，也许还有很多待挖掘的部分我没提到。但是无论如何，我们的一句话需求还是很成功的，因为大家都清楚了本次需求确认会的核心目标，至于那所谓的隐性需求，只不过是为了满足大需求而做的铺垫，也能够按照普通需求一样，通过一句话来描述需求，并逐一拆分、细化，逐一完成。

最后，个人建议，将一句话描述需求养成习惯。真的受益匪浅。

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

题图来自 Pexels，基于 CC0 协议