需求调研|那些关于“需求调研”的坑-案例分享（一）_公众|日活|kol|用户|微信|有机会

编辑导语：在职场中，我们总会遇到各种各样的“坑”，但遇到“坑”不可怕，可怕的是你一次又一次地踩进同样的“坑”里。作者借着一些案例，总结了B端产品运营的源头需求分析中的各种“事故”以及应对的方法，希望对你有所帮助。

文章插图
本文开始就一些实际案例展开讨论，这次讲的是是B端产品运营的源头需求分析。笔者的行业是电商，岗位是项目经理，主要分享的是电商大厂内部的流程管理。
一、需求调研路上的一些“事故“景1：对接人众多，及其导致的需求变更刚入职新公司的第一个项目，是要调整供应商的操作流程。供应商使用人多达8000+人。当时入职一个月左右，组织结构还不熟悉，内部业务对接人没有完全确定，要对接8个以上的部门。
调研起来困难重重障碍，各部门流程又可能不统一。此外，因为对接部门太多，排期紧张，为了挤需求给产研，PRD出完后居然没有和业务正式确认过，自己决定了，导致中间发生多次需求变更。
景2：对接人变更频繁导致的需求变更对接的某个业务部门，半年人对接人变动4次。上线的需求换了个对接人，完全不知道之前的背景，上线了之后就说要改，不断地重新和业务复核流程。
景3：对接方式不恰当导致的优先级变动因为对接的系统A和部门1~7比较相关，部门1~7人员又占中心的大头，所以大部分精力在排系统A的需求。当时部门8的需求一直叫的比较低调，也从未经过主管经理级反馈，大部分时候还是需求对接人在沟通。
可是，某一天，部门8总监直接过来怼排期太慢，让我们当月排完所有需求。简直GG。
景4：干系人范围未明确导致的调研不充分某功能功能需求调研、PRD、评审都结束了，准备进入开发，发现部门2和部门8前期没有调研到。导致整个PRD和评审都要从头来过。当时已经快过年了，各系统逐步在封版。
二、问题分析1. 组织结构不清晰、不熟悉在场景1中，每个业务部门的对接人都是不同职能，有的是项目经理、有的是文员、有的是业务人员本身、有的是行政人员。最大的难点是，有些对接人不具备完全把握流程和统筹意见的能力，只是作为消息中介，这种情况下很可能导致需求确认不清晰。
2. 对于公司的业务重点和人员结构变化未快速了解在场景2里，该部门负责人前期并未将对接人作为核心岗位，前期只是找了业务人员兼职业务对接人。甚至还出现了某一段时间里，对接人和部门负责人并不是完全上下级的关系。这种情况的风险，是确认后的业务流程，不符合部门实际需求，不符合部门长远述求。
在场景3里，部门8的业务线是公司当年最核心的关注点之一。在梳理需求时，应当为该业务单独留出主动跟踪需求的时间，而不是单向接受需求。这样至少和业务是良好沟通，而不至于后面因为反馈无力的直接升级。
3. 业务操作理解不深入不透彻需求调研人最大的难点是不懂业务。尤其场景1刚入职的时候，业务部门又众多，此时如果公司又在大力推动项目，对调研人是最艰难的时刻。后期熟悉岗位大致操作后，以为自己理解了业务，不再跟业务保持密切沟通，导致需求理解和业务不符。持续的底层跟踪，对调研人是最难坚持和最难做好的。
4. 业务调研结论拍脑袋决定景4中，因为临近过年，希望需求赶着过年前上线，前期只调研了部门1的2个业务人员，细节还没有确定完，就提交给产品出PRD。PRD和业务细节并行的阶段，发现细节不符合业务需求、遗漏其它部门对接人。我们常常会因为时间限制，急着推动需求确认。