转载声明：文章来源https://blog.csdn.net/AdBright/article/details/127694571

作为一名产品经理，从各个角落接到or自己挖掘到产品需求时，还需要对需求的可行性进行分析。

产品需求的定义

需求是产品存在的基础，贯穿产品的整个生命周期。而对需求完整生命周期的把控又叫需求管理。

需求管理方法论的概念包含需求调研和挖掘、需求分析、需求管理（输出需求文档），也可以用一句话来说明，就是收集客户想要什么，最终确定实际做什么。

“产品经理怎么进行需求可行性判断”这个问题，简单来说，属于需求分析的范畴，即如何分析“这个需求要不要做”，那么我们先抛开代码实现层面的可行性（即先不考虑开发是否能实现），我们来聊聊到底该如何判断这个需求要不要做。

首先，我们知道，需求的分类一般有以下几种：

业务需求：就是业务流程中产生的需求，业务流程是行业体系的一部分。

用户需求：用户在系统/APP使用过程中产生的需求。

管理需求：在B端行业为实现业务而进行决策、计划、控制等的过程产生的需求；或者在移动端，要进行数据统计、分析等相关需求。

如果将产品简单比作一个鲜活的生命，业务需求就是这个生命构成的中枢和骨骼；管理需求是血液，供产品能正常流转；用户需求就是肌肉组织。

业务需求一般情况下是产品的核心点，而用户需求与管理需求则是围绕核心需求衍生出的差异化需求。产品经理接收的需求的来源是多方面的，由于需求提出者的局限性，往往会产生一些伪需求，这就需要产品经理去适时的分析、把关和审核。

产品需求的分析

那么如何进行需求分析呢？

1）摆正需求方位置

需求的来源会有各种不同的渠道，有内部同事、领导、产品经理自己产生的需求；也有外部市场、用户、竞品分析、行业规范等产生的需求。我们需要先把他们产生的需求分类，摆正位置，才能对症下药。不管是哪个渠道来的需求，在上文有说到，可分为三类：业务需求、管理需求、用户需求。

2）判断真实的需求

方法一：逻辑演绎

当产品经理不清楚客户的业务但又感到有疑问时，可以用逻辑推演来判断，通过逻辑推演可判断客户的需求是不是合理的、正确的。

例如：为什么需要做这个功能？缺少这个功能会如何？这个功能与其上游的工作流的关系、与下游的工作流的关系？这个功能是否已有同化的功能可替代？思考新需求对现有业务逻辑的影响，会不会影响现有业务功能，当然也同样要考虑到一些潜在的影响，这同样是对需求评估的一个重要标准。

方法二：多维度观察

产品经理与客户在专业知识方面是不对等的，客户并不知道他提的需求将来在系统中会带来什么后果，产品经理也未必听懂了客户的真实需求，因此，对客户提的“表面需求”或“野生需求”，要经过侧面的判断才能确定为“真实需求”。

为了解决这个问题，可以参考使用 5W1H 分析法帮助做好判断工作：

在需求调研中使用5W1H方法，首先要理解的是What、How，而作为判断的重要依据的是Why，其他Where、When、Who是附属信息，经验不足的产品经理一般只会从正面进行调研，即询问“做什么”、“怎么做”，但是最为重要的“为什么做（Why）”却往往不问，这样就会失去多维度观察需求的机会，也同时失去了识别需求“虚实”的机会。

方法三：价值判断

对于复杂的、规模较大的需求，用简单的、操作层面的能够做评估的依据，难以确定是否是真实的需求，可以用“目的、价值和功能”三要素来分析和判断。

目标，即客户的需求目标是什么？价值，即确认该目标达成后，客户可以获得什么价值？功能，即做什么功能可支持该价值的实现？

如果针对某个需求的判断符合下述条件，那么它就可能不是真实的需求——

确定不了这个需求的目标是什么。

虽然知道目标，但是看不出目标达成后会给客户带来什么价值（回报）。

提出的功能需求实现后，并不能给客户带来预期的价值等。

其实我们知道，大部分需求都是可以实现的，而筛选和判断需求只是产品经理比较基础的操作，更重要的是和需求方“博弈”的过程。

产品经理在接收到一个需求的时候，除了要知道这个需求能不能做，还要能知道这个需求背后的“真实需求”，并“引导”需求方接纳自己的“方案”。

举个通俗的例子：一个人说他想要喝可乐，那么我们要知道，他到底是口渴，还是就是爱喝饮料。如果只是口渴，我能不能建议他喝一杯更解渴的冰矿泉水，这样既省钱（降低系统/APP的复杂度，节约开发成本）、又能更好的解决他的痛点。

如果这个人就是爱喝饮料，那我是不是要考虑一下买一台自动贩卖机，并调研一下他除了可乐以外，还喜欢喝什么。有了自动贩卖机，就避免了过两天，他又来说他想要喝雪碧、想要喝柠檬茶的情况了（需求延展，避免同类问题反复迭代）。

每个产品经理都有自己的经验和价值观，对需求的判断也有有所不同，但在对需求的分析上，都要做到多想、多问、多维度、多角度，并有自己的判断。