时间: 2021-07-30 11:04:35 人气: 6 评论: 0
编辑导读：需要和需求虽然只是一字之差，但是状态是完全不同的。通常情况下，用户只**告诉我们他需要什么，而需求则是要将用户所说和用户所做相匹配，再去明确真正的需求。本文作者结合案例，对用户需要和用户需求这两个概念展开了分析说明，与大家分享。
业务方总**从四面八方提出各种各样的需求，多问一个为什么，或许能得到真实需求。
上个月一个例子：
业务方：能否在现在邀请中心的页面增加一个入口，可以保留上一个月的页面。
我：为什么要保留上一个月的页面？
业务方：不然用户等到8月份之后，怎么领取7月份的奖励呢？
我：7月份的奖励**在什么情况下，需要等到8月份才能领取呢？
业务方：就比如用户邀请好友报名正式课，但是我们的规则是限定要消课满一定数量才能获得奖励，所以就**出现这种情况。
我：那就应该是有一个领取历史奖励的入口，查看哪些奖励是还没有领取过什么、领取过什么，对吧？
业务方：对的。
从上面那个例子可以发现，需要和需求是两种不同的状态。通常情况下，用户只**告诉我们他需要什么，而需求则是要将用户所说和用户所做相匹配，再去明确真正的需求是什么。
需要集中体现为用户对于产品的不满。不满的原因有很多，通常是业务方觉得系统功能不能满足他们的使用场景、不方便不高效；家长觉得APP功能相较其他产品不够便捷，对比之下发现的不满。需要大部分都是自我感知，所以总是**听到“我觉得”、“我感觉”、“我认为”等开头语。
和需要不同，产品需求是针对一个具体的产品的具体行为下产生了可衡量的需要。需要是需求的前提，但是需求要将用户行为来衡量，现有的资源和需求达到效果之间是否匹配。
之前做过一个关于批量绑定的功能。当时听到业务方说“一个一个绑定太麻烦了，为什么不出一个批量绑定的操作呢”，只是想到业务方需要这个，ta的感知就是觉得“诶重复操作好多，一个一个操作好浪费时间”，所以就策划了这个功能。
但是等到功能真正上线后，并没有人去使用批量绑定。原因在于在绑定前，业务方都**仔细核对绑定信息，确保绑定正确，因此都**使用到单个绑定中的“查询功能”，所以也就没人去使用批量绑定功能了。
因此从这个功能后，凡是业务方提出的反馈，我**多问一个为什么：为什么现在的不行，、这个是用来做什么的，你一般**怎么用它，对现在工作有什么影响…
通过不断追问用户行为，获得真实需求。
在开始成为产品经理前，接触过**金圈法则。这个法则帮助我从用户那里获取到需求。从外到内依次是what、how、why。
用上个月的一个“采购数据”例子说明 使用**金圈法则来练习获得需求的过程：
采购方希望将订单管理页面的班主任和CC信息删除。原因是他们觉得这4列数据（包括2列团队数据）都不怎么使用了，所以基本上可以去掉。
用户说要把数据去掉，通常都**询问为什么要这么做。这时候是了解用户使用场景的“好时候”。
采购方说他们通常用这个页面导出订单安排发货等事宜，所以只需要具备学员信息、收货人信息等关键信息即可（他们认为班主任信息是多余的）。当用户描述的行为和之前的功能相违背时，或许要更深入去求证。
继续询问后发现，班主任信息是在少部分家长因发货时遇到地址错误或收货信息不匹配等情况才需要去找对应班主任，联系家长确认才**使用到这些信息。但是现在采购不负责这一块了，加上之前采购都**导出Excel表交给对应负责人沟通，因此采购方觉得这项可以去掉。
沟通下来之后发现，采购方感知到“去掉这4列信息”的原因在于自己不对接这块了+使用频率变少了。但其实班主任信息是必要但不是主要。
因此真正的需求占页面篇幅需减少并置后，才能够让采购一打开页面就能在列表最主要位置看到想要的信息。
画好原型输出方案后，可以询问需求方对方案的意见，这样可以更好确认方案是不是符合需求方的使用场景。
在明确了业务方的真实需求后，同样也是需要告诉开发的。对于目前接触到C端产品来说，特别是做用户增长，开发和测试不仅仅是研发技术人员，更是需要他们去了解产品为什么做，怎么来的这个需求。
所以在写需求文档的第一步，要明确告知开发需求的背景、用户场景、需求分析、竞品调研。
业务方每天都**将自己对产品的使用体验、家长反馈告诉我们，在接收到反馈的同时，需要从中提取需求、规整需求，多一步思考、多问用户行为。
本文由 @莫琳 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
