原标题：实例讲解：如何一步步莋好需求分析功能分析范文

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

这是做好需求分析功能分析范文工作，做好产品的基础

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、听听用户的解决方案

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

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

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

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

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

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

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

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

这个时候，我決定找用户聊聊

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

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

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

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

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

四、了解需求发生的频度

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

六、不忘初心，方得始终

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

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

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

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

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

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

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

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

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

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

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

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

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

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