产品经理是产出解决方案的岗位，但不同的人对需求、解决方案有不同的理解。这篇文章，我们看看作者对于需求分析的认识和自己的经验，是否有可参考的地方。

一、需求分析高效之道

需求分析思维模型（底层逻辑）

观点：基于问题相关的人和事情、市面上的产品调研以及实践经验总结去分析需求比较完善，而想要需求分析高效需要大量的刻意练习。

在接触到比较多产品经理之后，我发现产品经理的思维模型有比较大的区别，有的人是仅基于问题相关的人和事情去分析需求；有的人会基于问题相关的人和事情以及市面上的产品调研去分析需求；还有的人会基于问题相关的人和事情、市面上的产品调研以及实践经验总结去分析需求。最后一种方法是我最认同的，也是我认为的高效的需求分析的思维模型。

仅基于人和事情去分析需求，这个是比较入门的产品经理会这样去做，这个方法要求这个产品经理有正常人的逻辑思维能力即可。这样去做，你的系统没有什么架构可言，大多东西可能都是固定的，例如：公司说我要一个用户画像的功能，结果可能是用户标签都是固定的，某个业务线需要新增一个标签那么我就再新增一个。这样的产品方案是很初级的。

基于问题相关的人和事情以及市面上的产品调研去分析需求，这样做的好处是了解市面上的产品是怎么做的，站在巨人的肩膀上找解决方案，一个产品经理如果这个点都做不到，很可能会浪费开发资源，走很多的弯路，例如：很多书籍或者文章都有分享AI建设道路，但是还是有公司会花2~3年的时间去走完这篇文章里提到的弯路，如果产品经理在初期做了充足的调研就会知道很多弯路是可以避免的，可以减少非常多开发资源的浪费。

基于问题相关的人和事情、市面上的产品调研以及实践经验总结去分析需求，这样的思维模型是比较完善的，能够做出比较成熟的产品方案，使得业务流程跑顺，也节省了开发资源。

一个比较成熟的底层思维模型并不是需求分析高效的原因所在，可能它需要花费同样多的时间去做需求分析。做什么都最好有个前提，大多数观点并不是完全通用的，除了一些数学或者物理里面的定律等。

打个比方，假设你是一台电脑，虽然有了一个成熟的模型——这个是一个程序，想要高效，你应该是不断地提升运行这个模型的效率，当你给这个模型喂了足够多的样本（实践），你就会非常快地识别出这个需求的本质是什么。也就是说你做了足够多的需求、调研了足够的的产品、做了足够多的总结，你的需求洞察力会有很好的增强，可以让你高效地进行需求分析。

需求分析方法（表层逻辑）

观点：邀请相关的业务方一起参会表明需求与讨论产品方案会提升需求分析的效率。

曾经有几次：业务详细描述了他的需求之后，会让我给他输出一个可行方案。例如：业务说：“我们平时是这样对账的……想让你给我出一个方案。”这就有点像我是提供管理方案的人，我给业务提供管理方案，然后由业务判断是否合适，如果不合适我再去思考新的方案。有的时候方案准确命中业务的需求那是比较好的结果，但是有的时候如果方案整体不是特别符合业务的方向，业务会让我修改，修改一次还好，但是如果修改几次，那么产品经理的效率会非常低，可能有很长的一段时间都是在做这么个需求。

到这里，可能会有一个疑问：产品经理不就是提供方案的吗，这不是很合理吗？

确实很合理，我反思出来我当时最大的问题点是：我没有要求提需求的同事拉所有相关的同事一起来商量出一个可行的方案，反而是我自己基于得到的一些可以说不够细节的信息在构思这个方案，这个时候是比较棘手的。

当时我不是特别在乎每个步骤是谁来处理的，因为之前我也试过这样操作是可行的。结果就是给了一个方案之后业务不满意，但是追问怎么不满意，等到他回答了之后算是给了我一个大方向，然后基于这个大方向输出方案之后，与相关的业务去评审的时候，就会出现很多新的需求，又需要基于这些新的需求点去完善方案。

总的来说，一整个流程下来会花费不少时间，效率会比较低。

我其实很多次也只是了解整体流程就可以做出让业务代表满意的方案的情况，但是实际上线之后，每一个相关的人都会给我提需求，很多时候还是我不解决他们的问题，他们就不会使用系统的情况。

基于这些情况之后，我总结下来，一定要找到所有相关的人来协商出一个让各方都满意的流程。当我把这些人都聚集起来之后按照一定的流程去让大家说出自己的需求，然后在这个会议上我应该有一个方案的大方向，有了这个大方向之后，我后面出方案的效率会有非常大的提升。

当然，这个动作并不只是为了提高我的效率，更是一个有效的方案的很好的助力。当然有的时候你无法不基于没法接触到很多业务相关人就开始做方案的情况，因为我们有进度的要求，在接到需求之后了解大概的情况之后就开始做方案，然后给到各个业务相关人确认是否可行也是一个方法，但是不是产品经理比较高效的方法。

所以总的来说，引导业务们协商出一个合适的流程是非常必要的，这是产品方案的大方向，有了这个方向之后，产品方案可以很快地输出。

最后给这种情况写一个前提：并不适用于所有情况，大多数的关于流程固化到系统上的需求都是适合的，需要自己加以判断。像有一些业务方不会有这么多时间去思考这些东西，就是需要你提供方案给他，例如：总裁、总监等等，或者是当我作为管理人员（假设我是主管）需要提供部门的管理方案的时候。

二、方案输出高效之道：假设检验法

观点：遇事不决，大胆假设，细致验证，果断选出你认为最好的方案。

在我们的大方向出来之后，接下来是方案的输出，这其中会涉及到各个细节。

关于细节，我们常常会出现一个问题，当到达同一个目的地时，可能有2个方案都可行，然后我们会不确定是A还是B比较好，此时不知道你是怎么处理的？

我在刚做产品经理的时候，通常都是在脑子里去比较这2个方案的优劣，然后决定出一个方案，那时候还不是思考得很深，比较表面的，有的时候会比较纠结，因而浪费了时间。

基于这么一种情况，我认为其实不用纠结，你完全可以将所有的方案都罗列出来，然后对比他们的优劣，然后决定一个你认为的最好的方案，当然这个方案可能不会是所有人看来都是最好的。

在评审会的时候，技术也会给我提出方案，一般来说他们提的方案我很多时候都是思考过的，对比过的，因而我能说出来为什么不采用技术建议的方案。

在对比的过程中，我会有以下几个维度：交互是否便捷、开发成本、是否符合普通人的认知。

1. 交互是否便捷：也就是能不能让业务少操作一步，这对于我来说是重要的，我认为一个好的产品应该减少操作人的时间浪费，即使开发的时长会增加一点。
2. 开发成本：衡量方案的开发成本，当然这个是由我来判断，大多数情况下我不会感到疑惑无法判断，如果无法判断我会请教技术同事。在大多数情况下，开发成本并没有什么很大的变化，不影响你大胆地假设。
3. 是否符合大多数人的认知：我不希望每个人在使用这个功能的时候都会感到疑问，这是什么，那又是什么。系统应该尽量地跟现实世界对应起来，让用户用起来是熟悉的亲切的。