编辑导读：为什么女生讨厌男朋友对自己说“多喝热水”，因为女生的需求是要男生的关怀，而不是具体的解决措施！开发产品也是一样，对需求分析不对，就对影响产品的研发工作。那么，如何对需求进行梳理和分析呢？本文将从五个方面展开分析，希望对你有帮助。

为什么要讲梳理与需求分析？

这里的需求梳理与分析指的不是一个工作项，而是研发流程的一个阶段，也是研发流程的前期阶段；

那么需求分析这阶段具体是要做些什么呢？

我们简单概况一下就是：将用户非形式的需求表述转化为完整的需求定义。 这里关键词是“表述转化”，用白话讲就是把用户的市场类语言，翻译成开发能听得懂的技术类语言。

所以这次为什么要给大家讲《需求分析》呢？

因为需求分析不只是需求分析师和产品经理的必备技能，对于项目经理/研发经理/解决方案经理等多角色的工作其实都有涉及；

哪怕你这些角色都不是，需求分析在生活中也是用得上的，就例如女生跟你说她肚子痛了，她背后的需求是什么呢？学了需求分析也许你就不用被人说直男了。

给大家讲《需求分析》的第二个原因是，需求分析对于产品成功来说很重要，甚至是最重要的一个阶段都不为过。

雷军说过一句很经典的话：选择比努力更重要。

用户需求不等于产品机会。 如果前面的需求做错了，也许后面的开发的同事再怎么努力，也许结果都是枉然的。

好吧我们现在进入正题，接下来给大家介绍的第一部分是：

01 需求来源 | 需求从哪里来

以我目前服务的项目 为例，目前最主要的需求来源渠道主要来自客户自提的需求。

所以这次的需求分析的方法也主要围绕着“项目（客户）的需求”和“用户反馈的需求”。

（如果大家觉得有需要，其他类型的需求分析分析过程会在往后的内容中分享，可以用点赞或留言的方式告诉我你们想要我讲更多）

02 需求确定 ｜ 如何准确的理解与描述需求

为什么我们需要做需求分析呢？

因为很多少时候人们需求的表达形式并不直白，人们更习惯表达问题。

这到底有没有什么标准的公式可言呢？

其实也是有的，下面就给大家分享一个常用的公式。

为什么要关注角色？因为角色是解决方式和优先级的判断依据：假如这个角色不是女朋友，而是一个普通的同事，那么我们的解决方式大概就是假惺惺的说一句：are u OK？lam so sorry to hear that了。

而我们最常犯的失误，我们经常容易忽略场景。以这个例子说：在例假的时候肚子痛，我们的解决方案可以是喝红糖水，但是不是来例假的时候就不那么适用了。忽略场景出来的结果有可能就是：我们在给滴滴司机设计PC客户端接客程序一样。

那为什么关注他的当前的解决途径呢？因为只有知道对比他过往的解决途径才能体现我们的解决方案给他产生了多少价值。

TA期待的解决方式我们最常犯的错误就是喜欢照搬，关于这个我后面会单独讲。

当然还有更专业一定的表达方式：

需求记录下来了，接下来当然要做更深层次的分析咯，这里我打算给大家提供一些分析的小技巧。

03 需求分析 | 一些分析的小技巧

需求分析的基本内容：其实也是对需求进一步挖掘的过程。

我们大概会做一些的几件事情。其中我觉得业务流程的梳理画流程图是最不能省的一项工作。

假如连这个都没有，就不能叫需求分析了。

还有这一项工作其实需求分析师跟产品经理有重合的地方，有的需求分析师其实是从业务转岗而来，所以不一定具备这样的能力，所以我建议这一些工作需求分析师和产品经理是谁有能力谁做，甚至共同完成。

我觉得需求分析的关键是关键用户的分析，而关键用户的分析的关键则是决策路径的分析。

以B、G端产品为例 关键用户主要分为3种；

由于决策者与执行者的视角不同，必然会导致用户体验的割裂。所以需求分析的过程，有的时候就是一个权衡利弊的过程。

就以这张图为例： 育儿产品是该讨好父母，还是孩子？

所以当决策者与执行者的体验站在对立面的时候， 不是优先解决高频使用的体验问题，而是优先解决距离决策最近的体验问题。

当然也有更好的解决方案：

实现赋能是协调决策者与执行者的共同获得好体验的最好方式。

前面分析了这么多为了解决做不做和做什么的问题，而需求评估则是为了解决什么时候做的问题。

所以简单的需求分析之后就要对需求进行分类管理。

那么接下来就是解决怎么做的问题，

04 输出创意/解决方案 | 一些设计的小技巧

输出解决方案之前，可以先看看竞争对方做得怎样。

具体竞品分析怎么做，在这里也不展开了，后面有机会再跟大家分享。

接下来解答一下前面遗留的一个问题。

问为什么不要太关注用户期待的解决方式：

因为用户提的解决方案可能不是最适合我们的解决方案，

应该关注用户真正想要的目的，以选择适合我们的解决方案。

我们经常会说到做项目和做产品，那么在项目里和产品里的需求产品经理该如何区别对待呢？

项目类解决方案考虑的是：如何用最低的成本，实现用户期望，如果成本高于项目预算则可能不做。

产品类解决方案考虑的是：有多少人愿意为这个功能付费，用户多成本高也做，用户少成本低也不一定做。

假如客户为国企等政府机关：

这个行业有明显的官僚体制的经济学想象。面对这个行业的设计策略，不能照搬民企的一套效益为王的方法。官僚体系中的人的追求：津贴、权力与声望；决策者往往不是企业的所有的者，他们比起提升实际收益，可能会更关注彰显政绩这样的决策方案。因而这个群体，不是价格敏感型，而是服务敏感型。

信息化有三个阶段，产品设计应该循序渐进。

有很多缺乏B端产品设计经验的人，在做业务信息化的时候还没完成数字化上来就喊着做大数据，最终会导致产品的落地性极差。

在业务信息化的过程，很多人做着都会发现，数字化阶段其实是最难推动的，因为这一个阶段并不一定能减轻执行人员的工作量，相反可能还会增加工作量。所以从结果数据化开始，也许阻力会小一些。

接下来要分享的，也是一个比较常见的问题。

如果涉及到改变流程怎么办？

流程变更就可能涉及到别人的利益，为了避免利益冲突带来的阻挠，应该先设计纸质流程试运行，确定流程可行后再把流程数字化。

（如果只考虑合同交付，不考虑用户成果的项目可忽略）

设计最小可用产品（MVP）：

MVP也是比较大的概念，这里也不打算展开讲，后面有机会再跟大家分享。

研发类项目建议设计MVP（最小可运行版本）

报价主要分两种方法：

按价值报价就要计算它的价值流了，这里就不展开讲，就简单举个例子。

一个优秀的需求分析，它是要明确知道用户价值的。

05 解决方案/项目筛选

外部评审：

尽量在开发之前与需求方进行充分的原型评审，能在原型阶段发生的需求变更就不要拖到开发阶段；

（这一阶段用户可能会频繁变更需求，所以建议使用低保真原型）

内部评审：

通过评分最终得到需求进入开发阶段的优先级：

评分维度举例：

• 战略一致性和重要性（战略契合性和重要性、对业务的影响）
• 产品和竞争优势（独特的客户利益、经济价值、客户反馈）
• 市场吸引力（市场规模和发展、利润、竞争地位）
• 核心能力影响力（技术、生产、市场与分销/销售）
• 技术可行性（技术差距、技术上的复杂性、是否使用内部技术、技术可行性是否被证实）
• 财务收益（机会，投资回收期、净现值、内部收益率，评估的确定性，风险性和难度）