产品学习之路｜需求的获取
即使是面对面的谈话，也是需要精心准备的。
需求是一切的基石，在我们确定产品方向与核心后，需求就是一切的根源
一、想需求，是伪命题
需求不是想出来的，“想”需求，本身就是错误的。作为一个新人，我犯过的错自己都数不清楚。
最开始，项目经理给了一个大概要求：给公司做一套OA系统。当时我觉得这个要求很泛，也没有任何实际的方向。于是去体验了排行前几名的OA系统，并借鉴他们的功能模块和框架开始进行设计，这里犯了一个极大的错误：没有任何实质性需求就急于画图。
企业级应用不同于互联网APP产品，虽然很多需求是相通的，但这并不意味着不需要去获取需求。坐在座位上“想”需求分析是没有帮助的，我们无法确定“想"出来的需求是否符合用户的实际需要，是否真的能解决用户的问题。
走出去，和用户交流是必须的过程，不论我们有一个多好的商业点子，读了多少心理学的书籍，和用户进行交流都是必须的。需求调研的方法有很多，而对我的情况来说，面对面的用户访谈是最合适的。
二、了解行业
市面上大部分的OA系统功能类似，很多行业都可以共用同一套系统，公司的业务主要在建筑行业，而市面上建筑行业的OA系统非常的少。作为一个对建筑行业一无所知的新人，第一步，要了解行业，从网上找资料，必要时可以找业内人事协助。
三、确定访谈对象
了解了行业，就可以进行用户访谈，进一步了解公司的业务。
先要确定访谈对象，找到合适的访谈对象可以节省调研时间。如果我约见公司各部门如预算员、会计、程序员等岗位人员，能获得的信息量会比较小，最合适的是各部门的经理或者经理助理，因为他们需要统筹管理整个部门的所有事务。
四、访谈内容提前准备
在不了解每个部门的情况时，可以先到行政部了解每个部门的大概业务范围，然后针对各部门的业务范围分析出谈话的内容。访谈内容的准备是为了确定整个访谈内容都被控制在限定的范围内，且包含重点需要了解的业务。
五、精确的提问
精确的提问可以帮助我们快速的进入主题，且获得有效的答案，问题切忌”空大泛“，例如：我们想了解一下您部门的工作范围。这属于一个比较泛的问题，部门的工作是很分散的，很多时候部门经理也无法全面的描述出所有的内容。但是如果问题是：我们想了解一下在招标这个阶段，咱们财务部需要就成本做分析么？是总体概要分析还是包含详细分析呢？这就是一个比较明确的问题了.
一般来说，根据3W1H方式提问，问题中包含When，where，who，how，就是一个比较精确的问题。
六、适当的引导
在访谈过程中，用户的思维可能是跳跃的，也可能是保守的。适当的引导有助于帮助用户打开思维或把话题拉回现实。如果用户谈起一个问题时开始滔滔不绝越扯越远，我们应该适当的把话题拉回主题。如果用户思维固定在一个点上无法发散，我们应该引导用户向其他方向思考。
使用场景来进行引导是最有效的！
七、用自己的话再说一遍
复述自己所理解的访谈内容很重要，因为信息的输出与接收是不对称的。把自己理解的向用户复述并确认是一个非常重要的过程，能一定程度消除错误的理解，并发现更多的问题。
八、不要被牵着鼻子走
用户访谈中遇到的用户形形色色不同类型，如果遇到比较强势的用户，千万不能被牵着鼻子走。即使用户跟你拍桌子瞪眼说你必须给我弄一个XX功能，你也要冷静思考。如果顶不住压力答应了，会变得很被动。
九、敢于质疑
从用户那里了解到的需求不一样就是真实的，由于每个人看事情角度不同，对事情的分析也不一样，要仔细思考用户描述的内容，提出质疑点。
我们还会接收到来自与领导的各种要求，不要附和领导的思路，再多想想，对有问题的要求要敢于质疑，提出自己的看法。
十、做产品，脸皮要厚！
需求是一个反复确认的过程，我们从各业务部门获得了业务流程后，还需要跟他们进行反复确认反复梳理，这个过程可能会受白眼被嫌弃，但是我们的脸皮必须厚，如果因为可能遭受白眼就不继续，需求调研就很难进行下去。
在整个访谈过程中，我们获得的是业务流程和原始需求，接下来，我们可以进入需求分析阶段。
PS:以上是个人在工作中需求访谈的总结，还有很多遗漏之处，求指点！
本文由 @⑨月 原创发布
关键字：产品经理
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
