做为产品经理，口中说得最高频率的词就是“需求”，这也是产品人所必须掌握的能力。在这个人人都说需求，谈痛点的互联网时代，作为产品经理的你，是否真的掌握了需求分析的方法和能力？

我曾写过一篇文章，题为《经验总结：产品需求文档的编写四步法》，此文是我多年产品工作经历所总结出的一套快速有效的需求文档编写方法。相比我写的其它话题文章，这篇文章发布后浏览量，收藏量都非常高，可此可见产品人对需求，对技巧，对实例分享都非常有兴趣。为此，本文就再次围绕需求这个话题作出进一步分享。

在写需求文档之前，我们必须先进行需求分析，从用户需求到产品需求，再到产品功能，最后形成产品需求文档转入产品开发。

对于如何进行需求分析，知乎上各路大神们都写出了高深莫测指导理论，令人膜拜。但这种高度理论化的内容，让人看完之后，仍然有一种无从下手的感觉。因此，我准备用更直白的实例方式来分享一下我的需求分析经验。

一、尽可能地让自己成为用户

不管你在做任何产品，如果想要做好它，都需要将自己代入相应的用户角色，从真实的使用者角度去思考问题。

我曾在一家车联网公司负责智能车机产品，当时我还没有拿到驾照，所以并没有驾驶经验。虽然我对车联网非常感兴趣，但作为非车主，我对此并没有产品感，在做需求分析时，很难做出合理的判断和设计。

为了让自己成为车主，有产品感，我提前去买了辆车（半年后才拿到驾照），虽然没法上路，但至少有辆车让自己体验，甚至在小区的车库里转两圈也是没问题的。

在后来的一次产品需求评审会上，有位同样没有开过车的项目经理提出了一个问题，车机系统界面上为什么没有关机功能，一直开着多耗电？这个问题在熟悉汽车的人眼里会觉得可笑——因为车机是直接连通汽车电源的，而汽车只要点火后，发动机工作就可以为蓄电池充电，并不存耗完电的问题；而且汽车的部分控制操作是通过车机界面进行的，如果真关机了，就没办法操作了。所以车机并不需要关机功能，最多也只是关闭屏幕。

这个问题，在我没碰到车之前，我也一样没法回答这个问题。

还有一些基本常识问题，如开车过程中去操作车机是很危险的，所以车机界面上的触控区域都做得很大很显眼，就是为了能实现半盲操作，尽量提高行车安全性。又如，我们车机的各个界面都会显示时间，而且特意设计得比较显眼。

那么就有人会问，为什么搞那么多时间，汽车本身没有时钟显示吗？

还真没有。

在当时，中低端汽车上大部分都没有时间显示功能，而高端车已经标配了较强大的车机，并不是我们车机产品的目标载体。因此，显示时间这个功能是非常基本和必要的。

如果我自己并不是车主，并不开车，那这些最基本的认知就不会有，也很难体会到作为驾驶者的需求。

当然，车联网产品有一定的特殊性，因为车主和非车主群体有一道鸿沟，非车主很难通过脑补的方式代入车主角色。但的，对于其它产品，如果你能成为真实的用户，相信你对产品需求的把控会更加到位。

这是做好需求分析工作，做好产品的基础。

二、倾听用户需要，理解用户需求

很多需求都是直接从用户中来的，用户有时会告诉你他需要什么，这个时候，我们会认真听取用户的意见。

但是我们并不能只是简单的接收用户反馈的信息，而是要去理解用户内心的真实需求。

在某个项目中，我们在后台管理中设计了一个订单管理的功能模块，用户（其实是B端客户，但为了统一，仍称为用户）正式使用后跟我们提出说，希望能增强查询功能，比如订单多状态下的组合查询（目前只有单状态条件查询），这样就可以方便地查询到他所需要的数据。

咋一听，会感觉这需求很明确，也很简单，无非就是把查询功能增强一下，so easy!

但真的是这样吗？

这个时候，我们需要进一步了解用户的动机。就是：为什么要这么做，目的是什么？

经过进一步沟通，才弄明白了他的目的是：想通过这种操作方法导出所需要的各项数据，然后拿到这些数据进行计算，最终用于对账，核对账目是否齐平。

由此可见，通过增强的查询功能查询出各项数据，只是一个中间环节，最终的目的是为了拿到这些数据进行对账。因此，对账才是用户的最终需求。所以，如果我们的平台能自动地计算出各项数据，直接告之用户对账结果，是不是更好？

显然是的。

但考虑到目前业务模式变化快，还不稳定，用于对账的数据也可能经常会有变化，所以对账规则还无法固定，并不适合进行系统化。

因此，最终我给出的方案是：新增一个功能模块，系统按相应的规则自动查询出当前所需要的各项对账数据，并以列表的形式展现出来。这样，用户只需要把这几项数据拿出来，复制到对账所用的Excel表中，再将其它需要的数据填充进来，就可以便捷地进行对账工作。

此用户听到我提出的方案后，表示出非常惊喜的样子，说道“真的可以这样？那真是太方便了！”。

通过这样的深入分析，给出更接近用户内心需要的方案，结果就能大大超出用户的预期，这不就是所谓的用户体验吗？

大部分用户在面对问题时，都会通过自己预想的方案去寻求满足，这是人的本能——但这只是用户的需要，通常不会是“用户需求”。这就是所谓的伪需求，传说中的“一匹更快的马”。

这个分析过程，可以总结为what-why-how的求解过程，也就是：是什么？为什么？怎么做？

经过这样的分析后，真正的用户需求就能浮出水面。

三、听听用户的解决方案

当我们一边在做需求分析，一边在考虑产品方案时，有些时候会陷入困境。

按着自己的思路去思考时，很可能会把事情变得复杂难解。

而在这个时候，我们需要做的，并不是继续努力思考去攻克难题，而是应该停下来，找我们的用户聊聊。

某项目，我需要在产品中增加一个汽配商补贴运费的功能。

简单描述一下背景：我们是做汽配物流业务的，也就是帮汽配商配送货品到汽修门店，我们会收取配送费；配送费通常由汽修门店支付，但有时汽配商为了让利，会选择补贴部分配送费。但我们配送时是按趟收取配送费，也就是说：同一趟车，配送到某汽修门店时可能会有多家汽配商的货物，也就可能存在多家汽配商同时补贴运费的情况。

这个时候问题就出来了：假如3家汽配商都补贴配送费10元，共30元，而配送费是25元，这时，就会出现汽修门店即使支付0元配送费也还多出5元的问题。

这种情况下，为了账目清晰，可能需要将这笔多出的钱变为一项收入记录到系统中。

但这笔钱在业务流转中又没有相应的款项与之对应，怎么处理这笔钱却成了麻烦事。多方思考终究觉得这个处理起来比较麻烦，没能想到更简单的方案。

这个时候，我决定找用户聊聊。

我问道，在没有系统来解决的情况下，你们现在是如何来处理这种情况的？

经过详细沟通后知道，原来他们的解决办法如此简单——直接将配送费调整为与补贴配送费之和一致，这样就不存在会多出一笔收入的问题，就只是一笔普通的配送费；这样账目也是齐平的，只不过配送费是由汽配商来支付的而矣。

于是，最后的解决方案就是：当汽配商补贴的配送费高于原定的配送费时，则系统自动调整配送费，汽修门店免付配送费。

所以，当我们面对一些不知怎么处理的需求时，不用急于思考如何解决，可以问问用户目前是如何处理此类问题的。

很多时候，我们自以为能用产品技术的方式更专业，更便捷地解决用户的问题；但其实更多时候我们会把问题复杂化。面对全新的需求，我应该多和用户沟通，要相信劳动人民的智慧，很可能会给你带来意外惊喜。

四、了解需求发生的频度

面对需求，在思考如何解决之前，我们还需要问多一个问题：这个需求发生的频度到底有多高？

特别是当要满足这个需求而要对系统进行改造花费高昂的成本时，我们在考虑产品方案时要所有选择。

还是上面那个案例：如果用户所采用的处理方法无法借鉴到系统时，也就是没有更简单的处理方法时，我们就会再次陷入思路困境。

而这时，我们更应该问问：这样的情况发生的次数多吗？

得到的答案是：很少。

对于这种不好处理，而发生频度又低的需求，我们应该坚决考虑低成本应对方案。如果实在没有更好的系统解决方案，那么， 你们最终还可以考虑人肉方案——当这种情况发生时，就自动转接到人工进行处理，即人工干预。因为人脑更灵活，可以应对复杂多变的情况。

就像我们的客户电话一样，一般高频而标准的需求，可以直接通过语音菜单引导进行选择操作，这种系统语音与电话按键的交互就相当于系统程序来处理需求。而如果系统语音给出的选项都不匹配时，最终你还可以通过选择人工客服来寻求解决。

但在很多时候，我们无法直接从用户口中了解到需求频度的情况，这个时候我们还可以从我们系统数据中分析。也就是利用我们系统中的业务数据、用户埋点数据、访问日志等等各种数据，从中提取并进行综合分析，最终找到这个答案。

有了这个事实数据，如果数据表明频度确实低，那我们则应该毫不犹豫考虑低成本方案。

五、模拟用户操作，补全缺失流程

到这一步，我们基本已经完成了需求的分析工作，正式进入了产品设计和需求编写的阶段。

在这个阶段，只要我们在前期的需求分析工作做得比较完善，这个过程基本上不需要花费太多时间。

但唯一是需要注意的问题是：避免出现业务流程缺失。

还是实例说明：

我们项目中有一个需求点叫汽配商货款确认，意思是我们代收的货款，需要汽配商在系统中核对确认后，我们才会进行货款的转账工作。这个需求我安排了另一名产品经理A同事来负责，跟他描述完大体的需求要点和流程后，他便开始工作了。

没过多久，A同事便完成了此功能的需求文档，他发了过来让我确认。我大概看了一下，用户（汽配商）端的设计没有什么大问题，但是在系统后台管理中却存在一个不小的问题：后台管理中，他只做了货款确认记录的查询；当然，还有导出数据功能。因为我当时跟他说过，确认的货款记录，我们前期需要在导出数据后用人工的方式进行转账操作（因为银行转账接口还未接入）。

我们来分析一下，按着这个功能的操作流程来模拟一下过程：

汽配商在系统中对着未确认的货款进行逐一核对，然后将无误的数据进行确认操作；我们的出纳人员每天定时通过后台查询出已确认但未转账的货款记录，然后导出，然后根据导出的数据一个个进行转账……

细心的同学可能已经发现问题了：如果这样操作，那么，同一个汽配商下的货款有多笔；如果按着这份数据进行操作，则需要对同一汽配商进行多次转账——如果是这样，那么我想不光我们的出纳会疯，汽配商也会疯。

当然，出纳可以将导出的数据再合并一下，但毕竟每天这样操作太过于麻烦，我们需要进一步完善我们的设计。我们可以增加一个功能模块，直接呈现每天需要转帐的汇总数据，自动合并同一汽配商的货款总额，这样出纳人员可以直接拿这份数据进行转账操作。转账完毕后再回来将这些记录设定为“已转账”，然后系统自动将汇总记录对应的货款记录进行一次性状态变更。

通过这样一个过程，就可以将我们的需求进一步完善，最终完成系统流程闭环。

当然，如果我们在前期分析时能够提早考虑到，则不需要在产品设计阶段进行复盘补漏。

六、不忘初心，方得始终

有些时候，我们把产品做到最后，才发现前面始终有一道鸿沟无法跨越。而这个时候，我们可能才会静下心来思考。也许复盘之后才会发现，我们一开始就错了。

我在做车联网项目时，曾负责过一个音乐产品，也就是车机上的音乐APP。我们在做产品需求的时候，商务同事也同步在外部寻找音乐资源，因为我们产品的定位是在线音乐，所以需要海量版权音乐库的支持。

但是音乐资源的问题却一直没有能搞定，主要问题是合作方开出的价格都太高，让我们无法接受。洽谈过好几家都差不多，因为音乐资源集中度较高，并没有太多的选择。等到我们的音乐产品都快要开发完成了，也没能最后确定音乐资源——这样就会导致这个音乐产品根本无法上线。看着商务同事无能为力的样子，我们也很无奈。

在这种情况下，我们不得不思考，能否在产品层面突破这个问题？

音乐产品是为了解决车主开车时听音乐的需求，我们希望能给车主提供便捷的音乐服务，享受驾驶的乐趣。就像以前就专门有MP3这样的随身听产品，满足人们随时随地的音乐需求；但后面因为有了智能手机，于是被取代了。现在，只要喜欢听音乐的人，自己的手机里都会有音乐APP，也会存储一定的音乐，想听就听。

想到这里，忽然发现一个问题：我们通过智能手机来获取音乐已经足够便捷，对于车主，真的需要一个新的“在线音乐”吗？我们做车载音乐，是为了解决车主的便捷音乐需求，但并非一定要“在线”音乐。

音乐资源的来源可以有别的选择，比如可以利用SD卡将电脑上的音乐进行拷贝，还可以利用手机蓝牙发送过去——对了，是否可以将手机上的音乐传送到车机中进行播放呢？比如我们同时开发一个手机APP，用于与车机进行连接，实现音乐文件的传输，或者说是同步。

这样就解决音乐源的问题，而且也比SD卡方式更为便捷。

这种低成本的方案同样可以解决音乐资源问题，只是稍微麻烦一点点。

从需求角度讲，用户需要的只是听音乐，而并不是什么在线音乐。在线与否并不是问题的关键，只要能听、方便地听，这就够了。

对于用户需求，我想更重要的是想明白车载环境与普通环境下对于听音乐这个需求的差异上。比如，我们在长途驾驶时会容易犯困，这时就特别需要一些激情的音乐来提神。而在普通环境下，这种需求却很弱。对于这点，我们可以从车主在不同精神状态下对不同类别音乐的需求角度去深入探索，相信通过这样的挖掘一定可以做出符合用户需求的产品。

不忘初心，方得始终。只有始终记着用户的根本需求，才能做出恰当的产品来满足用户内心的渴望。

以上便是我自己对需求分析的经验和理解。这里没有多少高度化的理论，但如果大家在做需求分析工作时，能用这样的方式去思考，相信定能做出满足用户需求的好产品。

本文由 @星思维 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash ，基于 CC0 协议