“接需求”是产品经理（下文简称“PM”）工作中必不可少的一环，文章中笔者会结合自己的亲身经历，讲述做好需求分析的几个关键点，希望能给刚入行和打算入行的朋友们一点儿启发。需求分析在产品生命周期中占有重要的地位，决定着产品做出后被用户接纳的程度。通过对接触过的PM进行观察，我发现大部分人进行需求分析时做的事情大同小异。故总结出几个关键点，形成一个可以应对大多数需求的操作方法。 说明：由于笔者一直从事ToB产品的工作，故本文所述的方法只针对此类产品，不保证对ToC产品适用。
一、需求从哪里来的
需求是某些用户在特定场景下为了得到某种服务或功能而提出的诉求或建议，它是产品的组成部分，也是产品最终要达到的目的。它可以是老板的一句话，可以是用户使用过程中的一声抱怨，也可以是对一堆数据分析后得出的结论。 根据笔者的观察，需求的来源有以下几种：1. 老板
对于老板提出的需求，一定要重视，并非因为需求方是老板，而是因为它同时包含着机会和陷阱，而且很难拒绝。 （1）机会- 通过老板的需求，了解老板的思路，借此一窥公司战略发展方向；
- 将自己对产品的理解和老板的对照，找出其中的区别并思考原因；
- 和老板交流下自己的产品思路，发现自己和老板的差距；
- 把老板交代的事做好了，得到老板的赏识（这个大家都懂）。
- 并非所有的老板都了解产品开发流程，了解业务发展，会出现瞎指挥的情况；
- 某些需求会打乱团队的产品规划及开发节奏，PM处理不好将会里外不是人。
2. 用户（内部同事）
笔者面对的用户是公司内部的同事，大部分是使用系统的部门同事，小部分是其他的PM。 从部门同事的需求中看出，他们在意的是系统能否满足他们的某项要求，通常会在提出需求的同时给出他们的解决方案。但是并不意味着就是真实需求，一个很著名的案例是想要快马但是福特提供了汽车（不知道的朋友请自行查询）。因此，PM在沟通中需要引导他们表述出自己的真实需求。 负责其他系统（业务线）的PM也会提出需求，来满足一些需要跨系统实现的功能。这种情况的沟通会比较顺畅，因为彼此对系统、开发流程、技术边界都比较了解。3. 自我驱动
这类需求通常会基于以下三种原因产生：- 通过数据分析得出的。
- PM在使用系统时发现的问题（通常用户无感知）。例如：笔者做风控系统时发现的问题，需要对推送的进件增加控制开关。作用是在风控模型调整或新功能上线后，控制推送进件的数量，待验证无问题后再打开，允许大量进件。
- 根据产品感提出的。产品感是指基于PM对产品的理解，对市场的分析，提出了一些对于产品未来发展有益的需求。
二、对需求提出方式做规定是有必要的
每个需求的提出者，通常会站在自己的角度提需求，或基于交互，或基于效率，或基于KPI等。这对PM把握需求的重要程度，了解需求内容的准确性增加了难度。例如：笔者曾经对接过和我不在一个城市工作的业务部门。对接过程中，出现了同一个部门多人同时提需求且优先级不明确，需求上线后使用者（非需求提出者）反馈需求实用性不高，或者需求上线后很多等待使用的人不知道等问题。笔者通常会分三步进行操作：
1. 确定接口人并明确其职责
接口人：和需求方部门Leader沟通，让他指定一名接口人，所有人的需求都在接口人处汇总，再提给PM。 职责：- 收集部门同事的需求；
- 过滤掉不合理和不必要的需求；
- 给出需求的优先级；
- 将需求提交给PM；
- 跟进需求进度；
2. 确定需求提出方式
邮件提出，确保周知所有相关人，并能留存记录。3. 部门Leader进行审批
必须由部门Leader审批，确保他了解并认可需求内容和优先级。三、需求收集方式
一句话概括，就是多提问、多沟通，了解业务和实际使用场景。1. 5W1H分析法
很多需求提出者不了解系统，他们只关心当前问题是否能够解决，PM必须详细了解需求的来龙去脉，以便能提出解决方案。在此推荐5W1H分析法，用来收集需求内容。
（1）What（描述）
需求是什么？
（2）Why（原因）
为什么会有这样的需求？之前的替代方案是什么？
（3）Who（使用者）
需求的使用者是谁，或者说是哪个部门？
（4）Where（场景）
需求的使用场景是什么？
（5）When（时机）
需求什么时候会被用到？被用到的频率是怎样的？
（6）How（检验）
如何确认需求已经被满足？
上述问题要求需求方描述清楚，可通过邮件，也可通过面谈。需求的收集方法可按照自己的习惯选择，重点在于对需求信息的收集。
2. 和需求方的沟通频次
负责ToB产品的PM必须了解业务，笔者曾经负责过财务系统的设计，由于不了解需求方对于结算、对账、提现等操作使用场景的要求（需求方也不了解），导致设计出现问题，需要进行二次开发。 要想深入了解业务，就需要和需求方保持沟通。笔者认为，在接到需求后，至少应该有三次沟通。- 第一次是在接到需求后。要遵循5W1H分析法，围绕其中的问题进行沟通，收集需求详细信息。
- 第二次是在收集信息并对需求进行分析后。PM会结合自己对系统的了解，挖掘出一些细节问题，其中有一些需要和需求方确认。这期间可能会有多次沟通。
- 第三次是在PRD完成后。要将文档内容讲给需求方听，在评审前最后一次确认自己是否准确理解需求。至于需求背景这类问题，必须在评审会前了解清楚，以便在会上讲给所有人。
四、需求的分析与整理
1. 需求分析的步骤
判断需求的真伪–>分析需求的业务价值–>评估需求的可行性–>给出需求的优先级。 笔者将以自己的经历为例，说明如何进行这四步操作： （1）判断需求的真伪 该需求的5W1H分别为：- What：需求方是财务部门，需求内容是在财务系统中新增列表，用来展示某项费用的明细，且该列表可以下载。
- Why：之前的替代方案是从系统中另一个列表下载，由于并不是专门展示此类数据（数据量较大），所以需要人为进行筛选和计算。筛选计算时间不长，笔者亲测约为15分钟。
- Who：使用者是财务部门的一名同事（只有一人），系统的其他使用者不会用到该列表。
- Where：使用场景是每月与合作方对账时，需要下载该列表，然后在excel中对某几项金额进行计算。
- When：每个月月初使用，统计上一个月各资金类型的交易量，使用频率一个月一次。
- How：列表中能够按时提供准确、完整的数据，即满足需求。
- 重要性：指需求是否符合公司战略发展、是否是产品线上的战略项目、是否和公司的收益挂钩、是否满足产品的基础服务等等。总之，在时间上不具有紧迫性，但是会对未来的发展产生重大影响。
- 紧急性：指需求是否必须立即解决，如不解决会持续产生或将要产生不良影响。这类需求不一定很重要，但是在时间上有紧迫性。
KANO模型：
- 必备因素：在业务流程中必须具备的功能，用以保证流程能正常进行。功能缺失时，使用者会发现流程不能走通。故这类需求需要优先考虑。例如：风控系统中跑反欺诈模型时，如果调用失败后没有重启流程这个功能，就会存在调用失败的进件卡在反欺诈模型环节，造成流程中断。
- 期望因素：这类需求通常能节省使用者的时间，提升效率。存在的目的是为了让系统操作起来更流畅。优先级一般没有必备因素高。例如：财务系统每月做报表时，如果系统能够将需要从多处查找并计算的数据，统一到一处并展示计算后的结果，那样能提高使用效率。
- 魅力因素：通常是一些使用者没有想到的功能，能大幅提升使用者效率、优化体验和解决使用者线下难以解决的问题的需求。这类需求在ToB产品中不常见，通常是必备因素和期望因素占据主导地位。
2. 需求整理
需求的收集与整理需要用到需求池。需求池没有固定的模板，建立的目的是为了帮助PM进行需求的评估和管理，模板内容依照个人习惯建立即可。 需求池中的需求由PM录入，记录不需要像收集需求及分析时那样细致，重点在于对需求的状态、优先级、排期进行记录。 以下是我的需求池模板：
以上是基于笔者对需求分析的想法，可能存在一定的局限性，仅供参考，欢迎大家多交流学习！
作者：打酱油的熊，公众号（打酱油的白熊）
爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容；是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台；
想了解更多移动互联网干货知识，请关注微信公众号运营小咖秀（ID: yunyingshow）
【转载说明】 若上述素材出现侵权，请及时联系我们删除及进行处理：8088013@qq.com
