需求分析—产品经理的基本功.pdfVIP

需求分析——产品经理的基本功

需求分析是产品经理的一项基本功，不论是新人还是老司机都要

经过这一环节。

然而需求分析却不是那么简单，我们时不时容易被伪需求坑，容

易被不赚钱的需求拖累。那么我们到底应该怎样去做好需求分析呢？

需求分析的定义

需求分析是软件计划阶段的重要活动，也是软件生存周期中的一

个重要环节，该阶段是分析系统在功能上需要“实现什么”，而不是

考虑如何去“实现”。需求分析的目标是把用户对待开发软件提出的

“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与

规范的文档，确定软件需要实现哪些功能，完成哪些工作。此外，软

件的一些非功能性需求(如软件性能、可靠性、响应时间、可扩展性

等)，软件设计的约束条件，运行时与其他软件的关系等也是软件需

求分析的目标

需求分析的内容是针对待开发软件提供完整、清晰、具体的要求，

确定软件必须实现哪些任务。具体分为功能性需求、非功能性需求与

设计约束三个方面。

1．功能性需求

功能性需求即软件必须完成哪些事，必须实现哪些功能，以及为

了向其用户提供有用的功能所需执行的动作。功能性需求是软件需求

的主体。开发人员需要亲自与用户进行交流，核实用户需求，从软件

帮助用户完成事务的角度上充分描述外部行为，形成软件需求规格说

明书。

2．非功能性需求

作为对功能性需求的补充，软件需求分析的内容中还应该包括一

些非功能需求。主要包括软件使用时对性能方面的要求、运行环境要

求。软件设计必须遵循的相关标准、规范、用户界面设计的具体细节、

未来可能的扩充方案等。

3．设计约束

一般也称做设计限制条件，通常是对一些设计或实现方案的约束

说明。例如，要求待开发软件必须使用Oracle数据库系统完成数据

管理功能，运行时必须基于Linux环境等。

判断需求的真实性

我们会碰到形形色色的需求，有的需求是真实的，有的会是伪需

求。我们首先要对需求的真伪进行筛选。伪需求通常是用户表面上的

需求，而非用户的真正痛点。伪需求的问题是，目标用户发现没有任

何环节或者流程上会用到这个功能，即使能够用上也会发现付出的成

本太大了。

再细想一下，你可能会发现伪需求通常是“用户提出解决方案”。

而用户通常只是会比较含糊地表达表面的需求，他们可能没有时间也

没有能力（也没有必要）去提出真正的解决方案。产品经理如果只是

满足于这样的形式，那就会掉进伪需求的坑。

去识别需求的真伪，就需要我们深入到用户的使用场景中，而不

是止步于获得表面需求。举一个例子：用户会说我饿了。细化到不同

场景这个表面需求背后的真实需求是不一样的。如果用户是在极度疲

劳或时间紧张的情况下，要的是快点吃完去睡觉或者去赶路，那背后

的真实需求可能就是“越快越好吃上东西赶紧去休息”。如果用户是

个正在和男友逛街的妹子，可能一句“我饿了”背后的真实需求是“我

想要在一个有格调的地方吃饭”。

简单总结，伪需求只是表面的需求点，真实的需求需要产品经理

结合用户的真实场景去具象化。

需求是不是刚需

我们筛选出了真实的需求，还不能马上开动。我们还必须分析这

个需求是不是刚需，不是刚需的真实需求做出来也是苟延残喘。

如何去判断需求是不是刚需？

一句话概括：需求量是否足够大，是否有持续性，不能是一锤子

买卖。

具体来说可以从3点来判断：

1、估计目标用户基数、消费能力，意愿预算，行业公开对比。

产品经理要去看目标用户基数是个怎样的水准，用户是否会有持

续为这个需求消费的场景，心理承受价位是多少，目前市场是否有同

类的竞品，他们的用户情况是怎样，整个行业现状如何。

2、可以提升多少效率，节省多少成本

这一点是说我们解决需求的方案能给目标用户提升多少效率，减

少多少成本。这一点是很重要的，用户不傻，他们不会为一个费时费

力的功能区买单。俞军提出一个公式，我认为非常适合解释这一点：

产品价值=（新体验/新效率-旧体验/旧效率）-换用新体验的成本

如果这个需求解决了，但是用户的更换成本太大，使用体验还不

如原有的。那么这个需求就很可能不是刚需。因为他没有实际上解决

用户的效率问题。创新的本质之一就是“效率”。

比如有人设想做个APP为四五线城市的用户去提供本地生活