市场需求分析怎么做，做好需求分析需要注意这

“接需求”是产品经理（下文简称“PM”）工作中必不可少的一环，文章中笔者会结合自己的亲身经历，讲述做好需求分析的几个关键点，希望能给刚入行和打算入行的朋友们一点儿启发。

需求分析在产品生命周期中占有重要的地位，决定着产品做出后被用户接纳的程度。通过对接触过的PM进行观察，我发现大部分人进行需求分析时做的事情大同小异。故所以出几个关键点，形成一个可以应对大多数需求的操作方法。

说明：由于笔者一直从事ToB产品的工作，故本文所述的方法只针对此类产品，不保证对ToC产品适用。

一、需求从哪里来的

需求是某些用户在特定场景下为了得到某种服务或功能而提出的诉求或建议，它是产品的组成部分，也是产品最终要达到的目的。它可以是老板的一句话，可以是用户使用过程中的一声抱怨，也可以是对一堆数据分析后得出的结论。

根据笔者的观察，需求的来源有以下几种：

1. 老板

对于老板提出的需求，一定要重视，并非因为需求方是老板，而是因为它同时包含着机会和陷阱，而且很难拒绝。

（1）机会

（2）陷阱

2. 用户（内部同事）

笔者面对的用户是公司内部的同事，大部分是使用系统的部门同事，小部分是其他的PM。

从部门同事的需求中看出，他们在意的是系统能否满足他们的某项要求，通常会在提出需求的同时给出他们的解决方案。但是并不意味着就是真实需求，一个很著名的案例是想要快马但是福特提供了汽车（不知道的朋友请自行查询）。因此，PM在沟通中需要引导他们表述出自己的真实需求。

负责其他系统（业务线）的PM也会提出需求，来满足一些需要跨系统实现的功能。这种情况的沟通会比较顺畅，因为彼此对系统、开发流程、技术边界都比较了解。

3. 自我驱动

这类需求通常会基于以下三种原因产生：

二、对需求提出方式做规定是有必要的

每个需求的提出者，通常会站在自己的角度提需求，或基于交互，或基于效率，或基于KPI等。这对PM把握需求的重要程度，了解需求内容的准确性增加了难度。

例如：笔者曾经对接过和我不在一个城市工作的业务部门。对接过程中，出现了同一个部门多人同时提需求且优先级不明确，需求上线后使用者（非需求提出者）反馈需求实用性不高，或者需求上线后很多等待使用的人不知道等问题。

笔者通常会分三步进行操作：

1. 确定接口人并明确其职责

接口人：和需求方部门Leader沟通，让他指定一名接口人，所有人的需求都在接口人处汇总，再提给PM。

职责：

2. 确定需求提出方式

邮件提出，确保周知所有相关人，并能留存记录。

3. 部门Leader进行审批

必须由部门Leader审批，确保他了解并认可需求内容和优先级。

三、需求收集方式

一句话概括，就是多提问、多沟通，了解业务和实际使用场景。

1. 5W1H分析法

很多需求提出者不了解系统，他们只关心当前问题是否能够解决，PM必须详细了解需求的来龙去脉，以便能提出解决方案。在此推荐5W1H分析法，用来收集需求内容。

（1）What（描述）

需求是什么？

（2）Why（原因）

为什么会有这样的需求？之前的替代方案是什么？

（3）Who（使用者）

需求的使用者是谁，或者说是哪个部门？

（4）Where（场景）

需求的使用场景是什么？

（5）When（时机）

需求什么时候会被用到？被用到的频率是怎样的？

（6）How（检验）

如何确认需求已经被满足？

上述问题要求需求方描述清楚，可通过邮件，也可通过面谈。需求的收集方法可按照自己的习惯选择，重点在于对需求信息的收集。

2. 和需求方的沟通频次

负责ToB产品的PM必须了解业务，笔者曾经负责过财务系统的设计，由于不了解需求方对于结算、对账、提现等操作使用场景的要求（需求方也不了解），导致设计出现问题，需要进行二次开发。

要想深入了解业务，就需要和需求方保持沟通。笔者认为，在接到需求后，至少应该有三次沟通。

四、需求的分析与整理

1. 需求分析的步骤

判断需求的真伪–>分析需求的业务价值–>评估需求的可行性–>给出需求的优先级。

笔者将以自己的经历为例，说明如何进行这四步操作：

（1）判断需求的真伪

该需求的5W1H分别为：

根据笔者的判断，该需求目前有替代方法且不难操作，需求使用频率低（一月一次），使用人数少（一人）。故该需求的业务价值不高，是伪需求。

笔者向需求方阐明了需求的不合理处，并建议在已有列表处，增加下载入口，可下载每月需要对账的金额总和，这样既节省了下载后再计算的工作量，同时也降低了数据量，减少下载时对资源的占用。

因为需求方坚持按照最初提的方案进行，同时不能给出合理的解释，故最终砍掉该需求。

（2）分析需求的业务价值

这一条可以和判断需求真伪互补，通常业务价值很低的需求，即便做出来也很少会被用到。

依照上述事例，虽然是投入人力、耗费时间都很少的需求，但其业务价值只是为了每个月节约一个人15分钟时间，得不偿失。

另外，PM还需要对系统的发展方向、包含的功能、服务的人群有明确定位。对于后台系统来说，在增加功能、列表时必须要有规划和节制，否则系统很快就会功能冗余、查找困难、使用不便。

（3）评估需求的可行性

这一步的目的在于判断需求的开发难度，进而给出大致的实现方案，需要PM和开发共同完成。

上述事例中的需求页面功能简单，所需数据在数据中有记录，接口也有提供，故从可行性来说没有问题。

PM需要对自己负责的系统、对接的技术人员的能力、代码开发中的技术边界有一定了解，才能更好的做出可行性评估。因此建议PM多学习技术，以免提出“根据手机壳颜色变换APP主题色”这类的需求。

（4）给出需求的优先级

笔者一般会运用四象限法则和KANO模型来判断优先级。这两个方法在确定优先级中是比较常用的，在此过多介绍，感兴趣的朋友可以自行查询（优秀的PM需要具备查询能力和自学能力）。

四象限法则：

如下图所示，重要紧急的需求需要立即放下手中的事情，集中精力去解决，例如：笔者接到的风控系统需求，要在合规备案检查前上线，以满足合规备案的需要。重要不紧急的，要在了解并分析完需求后，制定出方案，然后按部就班的执行。紧急不重要的，能不做就不做，做的话也尽量采用省时省力的方法解决。不紧急也不重要的，这类多为伪需求，参照上述财务部门的事例，果断拒绝掉。

KANO模型：

无差异因素和反向因素：这两类需求我认为是伪需求，是耗费时间、精力后却不能提升使用者体验、效率的，遇到后应予以拒绝。

2. 需求整理

需求的收集与整理需要用到需求池。需求池没有固定的模板，建立的目的是为了帮助PM进行需求的评估和管理，模板内容依照个人习惯建立即可。

需求池中的需求由PM录入，记录不需要像收集需求及分析时那样细致，重点在于对需求的状态、优先级、排期进行记录。

以下是我的需求池模板：

以上是基于笔者对需求分析的想法，可能存在一定的局限性，仅供参考，欢迎大家多交流学习！