需求分析的十三要素五步法

本文由作者 杨堃 发布于社区

需求挖掘和分析是产品设计中挑战最大的工作之一，如何洞察需求的本质，识别出真实的意图，并通过优雅的产品设计，解决需求背后的痛点，是所有产品经理都应该持续提升的核心能力。

需求分析的偏差和错误，不仅会浪费宝贵的研发资源，在错误的功能上投入精力和代价，更加会给业务带来损伤和伤害，甚至导致错失市场时机。
本章，我们将聊一聊B端产品的需求分析工作，包括如何基于场景洞察需求本质，如何利用UML进行复杂需求的抽象设计。

举例：一次并不成功的的需求分析
关于需求分析失败的经历，果冻有着切身的刻骨体会。在刚毕业没多久时，果冻负责一款企业自研，给电销团队销售人员使用的销售型CRM产品设计，主管会将一些比较简单的需求和设计任务交给果冻。
有一次，电销部门销售运营部的小姐姐豌豆找打了果冻，提了一个需求。
豌豆：“果冻果冻，又来麻烦你了，给你提个新需求！”
果冻：“好呀好呀，一起聊聊！”
豌豆（对着系统边说边比划）：“咱们现在的CRM系统，不是会有消息提醒么，里边会有很多提示，比如说如果线索还有1天就要掉库，就会在消息中心弹一条消息，比如说你看现在这个，就是有三条未读消息，其中第一条就是掉库提醒。”

目前消息中心的样子
果冻（不好意思的挠了挠头）：“呃，这个，是，小姐姐，我想请教下，掉库是啥意思啊？”
豌豆：“哦对了，你刚接手这块工作，还不太了解业务。在我们销售管理业务中，如果给销售分配的销售线索，销售7天没跟进，或者14天没成单，这条线索就要强制被收回到公共资源池中，由其他销售捞取跟进，这个就叫掉库。”
果冻：“明白啦，小姐姐就是厉害，一说就透！咱们这次需求是什么呢？”
豌豆：“是这样的，目前线索的掉库提醒是提前一天，销售同学看到后很容易就忘了，大家找我反馈说希望提醒能够更及时一些，比如说掉库前一小时再提醒一次；我想一小时哪儿够啊，还得忘，前1小时和前10分钟，得提醒两次，这样大家就不会忘记处理了。”
果冻听完后心中有一些疑惑，提醒了就能及时处理么，而且掉库前10分钟提醒，就能保证销售同学马上放下手头工作，去跟进这个线索么？不过虽然有诸多疑问，但是果冻对业务并不了解，刚刚已经请教过问题觉得怪不好意思，不好再追问太多，于是。。。
果冻：“好的，这个需求听起来很合理，估计也不难，我让研发大哥评估下，尽快排期去做！”
豌豆：“太好了，那麻烦你了，果冻同学就是好，工作最高效了！”
两周后，这个功能上线了！豌豆很开心，还给果冻和研发同学买了奶茶表示感谢。
不过，上线一周后，豌豆又来找到了果冻。
豌豆：“果冻同学，还得麻烦你。上次提的需求上线后，我问了下销售同学，他们提了个意见，我觉得很合理，就是在消息文案中，能说清楚还有多久掉库，之前是没写的，但是大家都知道是提前1天推消息，可是现在掉库前要推三次消息，大家就不知道到底还需要多久掉库了。”
果冻：“嗯嗯，有道理！”（内心在懊恼的拍大腿，这么简单的问题我咋没想到！）
豌豆：“还有个问题，这个提醒功能，销售同学非常喜欢，但是大家还反馈说提醒的内容太多了，如果能分个组，比如说能把掉库提醒的消息，在点击‘查看更多’后进入的消息盒子页面中，都能分类展示，那这样大家就能一目了然，知道今天有哪些新分线索，掉库线索啦，安排自己的工作计划就更方便啦！”
果冻听起来感觉怪怪的，为啥要通过消息中心来管理自己的工作计划呢，不过他也想不出其他更好的主意，也找不到反驳的理由，于是就按照下边这样做了设计，过了些日子就又安排上线了！

掉库提醒消息增加了时间说明

消息盒子（展示全部消息的页面）中增加了消息分类
本以为消息中心的优化到此就结束了，没想到过了两天豌豆又找来了。
豌豆：“果冻果冻，又得麻烦你！上次做的功能非常棒，销售同学很喜欢！我最近又想到了个好点子，现在的消息只是提示了掉库预警，但是销售是不是有处理跟进，其实销售是记不住的，如果我们能在消息提醒后边加一个按钮，让销售同学来标记这条消息是不是做了处理，这样咱们的消息盒子功能就更强大啦！”
“你说的是不是这样？”果冻拿着工具很快改了一版原型给小姐姐演示。

消息盒子中增加了消息待办标记
豌豆：“对对对，就是这个意思，专业人员果然有效率！”（豌豆对果冻比了个大拇指）
果冻（思考片刻）：“我想到个好主意，我们将处理、未处理的消息再做一次分类，这样如果消息特别多，销售同学就能一下子找到所有没处理过得掉库提醒消息了！，就像这样：”

消息盒子中增加了根据待办的分类
豌豆（兴奋地搓搓手）：“太棒了，产品经理果然厉害！”
虽然前两次研发同学已经对这个项目有抱怨，因为据研发同学讲，看了后台数据，通过“查看更多”按钮进入到消息盒子的页面访问量基本为0，说明消息盒子根本没人用，在里边加功能没意义。但是，果冻这次依然硬着头皮找了研发，拍胸部保证了需求的合理性，并说之前没人用是因为宣传不到位，最终艰难的说服研发排期实现。
过了两周，功能很快上线了！
这次果冻留心也查了后台数据，发现消息盒子根本没有人访问！果冻心很慌，难道做了这么久优化的功能，完全没人用？为此他专门去找了豌豆。
果冻：“豌豆小姐姐，咱们做的优化，从后台看，好像没人用啊，要不我们一起去找销售同学做做宣传！”
豌豆（懊恼的）：“哎，不用去了，我已经做过好几轮宣传了，也和很多销售同学聊过，他们说这个功能想法是挺好的，不过不是特别实用，销售同学希望在展现即将掉库线索的同时提供更多线索信息。所以，我正想找你提个新需求，能不能把新分线索、掉库线索这些不同类型的线索，都在线索列表页加一个新的筛选条件给筛出来啊，这样大家就不用通过消息盒子来管理自己每天的待办工作了，毕竟消息盒子只负责通知嘛！”
果冻听完后，当初吐血倒地……

通过十三要素五步法进行需求分析

相信阅读完上一节的案例，大家都会会心一笑。
耗费了这么多时间和资源，做出来的功能却没能帮助到业务人员，甚至没有人愿意使用，恐怕这是最让产品经理伤心的事情了。
问题出在哪里呢？
我们应该责怪豌豆，谴责她提需求不靠谱不负责么？
还是应该责怪果冻，谴责他不去挖掘需求背后的真实性和痛点，只是做了一个原型工人么？
还是认为他们两人都有责任？
我认为，在任何产品设计工作中，产品经理要对需求的分析、判断、方案的设计负全责！产品经理的工作职责之一，就是帮助用户、引导用户分析他们的真实诉求，找到背后真正的问题点，而不是用户提了什么就做什么。我们不能苛求让用户来提出合理、严谨的需求，这不是用户的责任和义务，而应该通过自己的专业能力，来完成这项工作。
在上边的案例中，有几个明显的问题：

• 果冻不熟悉业务，没法和需求方在同一个频道上对话交流

• 豌豆只是需求的二传手，并不是需求的真正来源，而且夹杂了很多自己的想法

• 果冻没有认真地去分析需求、理解需求

• 果冻在产品设计常识和原则上需要继续积累（例如个人待办管理是不应该在消息中心实现的，这是个基本产品设计常识）

当然，果冻毕竟是一个当时才毕业没多久的新人，需要学习和历练。那么，有没有什么方法，能帮助果冻尽量做到全面的需求分析呢？其实，在需求分析中，是存在一些套路和技巧的，如果尝试通过这些方法进行需求分析，至少保证你在一些关键点上没有遗漏。
接下来，我将介绍需求分析的十三要素五步法，这是我结合工作经验以及一些理论，总结的一套方法论，帮助大家做好需求分析工作。
十三要素五步法，即在需求分析过程中，通过五个核心步骤，涉及十三个关键要素，帮助设计人员尽量全面的梳理需求，挖掘需求背后的本质问题，找到所有可能的解决思路，从而做出正确的产品设计方案；这五个步骤分别是分析相关角色、了解基本场景、挖掘真实动机、发散更多场景、设计产品方案，具体见下表。

我将以果冻遇到的CRM消息中心线索掉库提醒的需求为例，给大家讲解并演示十三要素五步法的实际应用。

步骤一：分析相关角色

当我们接手需求后，第一件要做的事情，是先识别需求背后的各个角色；这和我们在从无到有构建产品的调研前期，需要先识别关键利益方，道理是一样的。理不清楚人，就理不清楚事，也就无法设计合适的产品方案。

要素1：提出人

给产品经理提出需求的人，是需求的提出人。
在公司中，任何人都可能是需求的提出人，比如客户、销售、售前顾问、实施人员、客户成功、业务运营、老板等等。需要注意的是，需求的提出人，并不一定是产品功能的使用人！而需求背后要解决的痛点，也并不一定是需求提出人的痛点！

要素2：使用人

最终使用产品功能的人，是需求的使用人（或者叫做产品功能的使用人）。
需求的使用人，不一定是需求的提出人。反而我们在工作中收到的很多需求，都是需求提出人，代表需求使用人提出的需求；例如，在甲方公司，业务运营团队总是代表业务一线提出需求；在乙方公司，销售或者客户成功经理（CSM，Customer Success Manager，SaaS公司特有的岗位，负责对付费客户进行持续跟踪服务）总是代表客户提出需求。
对于产品经理来讲，如果想准确且深入的分析需求背后的场景和痛点，必须对预期产品的使用人进行调研，了解他们真正面临的问题，而不要把精力都花在和需求提出人的沟通上。大多数时候，产品经理要解决的是产品的使用人遇到的问题和痛点，但有些时候，解决的也可能是需求提出人的痛点。在本节结束会有一个案例演示这种情况。
诚然，很多时候，需求提出人可能和产品用户的接触更加频繁密切，对用户的整体诉求有更直接的了解，产品经理应该悉心听取需求提出人的建议，但是产品经理必须和产品的使用人取得直接联系，要面向终端用户进行访谈和沟通，需求提出人所描述的需求，毕竟是经过自己消化理解后二次转化的内容，是二手的素材，产品经理只能作为参考，但不能作为决策的依据！
在某些甲方公司，存在一些很不好的现象，某些业务部门或人员，总是拦在业务一线和产品经理之间，不允许产品经理直接接触一线用户，希望产品经理只是一个原型工具，希望自己能“把握大权”。这样做，对公司利益来讲是不利的：研发资源本身就是公司的高价值稀缺资源，好钢应该刀刃上，做出来的功能应该能够真正解决问题。既然公司设计了产品经理这个岗位，就不应该只是作为工具人而存在，而应该能够深入一线，融合技术，赋能业务。

要素3：受影响人

最终受到产品功能影响的人，是需求的受影响人（或者叫做产品功能的受影响人）。
需求的受影响人，不一定是产品的使用人。产品经理在需求分析时，一定要留意对受影响人的分析，有必要时也要进行调研和访谈，从而更全面的理解问题，并做出决策。
在果冻面对的CRM需求案例中，需求的提出人，就是销售运营部的豌豆，她代表自己部门的销售人员提出了需求，这也是她的本职工作，然而在过程中她同时加入了自己的理解和判断（通过增加提前1小时和5分钟的掉库提醒消息，来提示销售同学跟进即将掉库的线索）。
需求的使用人，是销售一线人员，因为实现的功能最终是给他们使用的，并不是给销售运营部使用的。
在这个案例中，需求的受影响人同样是销售一线人员，并不涉及其他角色。
我们可以再举一个例子，来展示提出人、使用人、受影响人不一样的情况。假设销售部门的老板提出了一个线索分配的需求，希望新的销售线索由系统根据配置规则分配给不同销售，而不再由人手工分配；针对这个需求，提出人是销售部门的老板，使用人是销售运营（配置功能是给销售运营人员使用的），受影响人则是销售一线（配置的规则会影响到销售一线人员获取新分线索的方式）。注意，在这个案例中，产品经理要解决的是需求提出人的痛点（销售部门的老板，针对新分线索人工分配不合理导致线索资源被浪费的痛点）。
大家可以看出，在B端的业务场景下，仅仅是需求背后的相关方，就需要先花一些功夫作分析。

步骤二：了解基本场景

当我们理清了需求的相关角色后，下一步要着手分析需求背后的基本场景。基本场景的分析，要围绕着存在痛点的那一方来进行，如果多方都有痛点，则要分析多个场景。

要素4：基本场景

在互联网公司做产品设计，不论是C端还是B端，在探讨产品的功能设计时，大家最喜欢提出的挑战就是，你这个设计背后的场景是什么？具体情况是怎样的？一切脱离了场景的功能设计，都是脱离了实际的空中楼阁，是难以落地并发挥真正价值的。
一旦我们把枯燥的功能设计，融入了具体的场景，就会发现事情变得鲜活、生动、有趣。
如何了解需求背后的基本场景呢？方法非常简单，我们小学时就学过了，按照写叙事作文的方法，来进行场景分析，即：
基本场景 = 人物 + 时间 + 地点 + 起因 + 经过 + 结果
我们将需求尽量按照按照这六个要点进行场景还原，就会发现一句话需求马上鲜活了起来。
现在，果冻试着将原始需求，通过这六个要点进行拆解还原。首先回忆下原始需求是这句话：
“目前线索的掉库提醒是提前一天，销售同学看到后很容易就忘了，大家反馈说希望提醒能够更及时一些，比如说掉库前一小时再提醒一次”

果冻找到了最早给豌豆提需求的销售，并且又联系了几个愿意和产研团队多交流的新销售和老销售，聊了聊针对这个需求背后的场景，整理了下，写下了这段文字：
场景还原：销售同学栗子（人物），来公司半年了，每天勤勤恳恳辛辛苦苦，手里有不少老线索，每天也会分到很多新线索。在每个工作日的早上、下午和晚上（时间），坐在格子间的工位（地点），开着CRM系统，都要忙碌的联系不同的客户，可以说，不是在打电话，就是在拨号的路上。然而，今天下午，栗子同学又暴躁的生气了，又有一个优质线索，因为不小心忘了跟进掉库了（起因）！“这个系统一点都不好用！”栗子抱怨着，系统中这条线索的掉库提醒只在昨天发了一条消息，一闪而过，一点意义都没有，根本记不住，也不方便统一查看管理（经过），就是因为这个系统不好用，导致我经常丢掉一些线索，损失掉很多优质客户，业绩不达标，还影响心情士气！（结果），不仅我如此，所有伙伴都有同样的经历和感受！
当果冻还原了这个需求背后的场景后，发现销售同学遇到的问题一下变得生动了，而且在场景中更多体现了问题和现象，并不用描述解决方案，这让果冻对问题的把握一下子有信心了！

要素5：发生频率

需求背后事情或问题发生的频率，是我们需要一开始就了解清楚的重要问题，有必要作为一个要素列出来，引起大家重视。
在大多数情况下，一般我们会有一个一般认识，对于非常低频的需求和操作，可以将优先级调低，因为有些功能，可能做出来一年只会用到一次，如此还不如提供线下支持投入产出比高。例如某些配置功能，可能开发需要10人天，但是一年只用两次，如果让研发手工在后台帮忙设置，只需要10分钟，在资源紧张的情况下，这个需求还不如就让研发手工支持了。
但是，有些特殊情况，即便需求的频率很低，也要考虑支持，例如财务的月结工作，每个月只进行一次，对于企业来讲是非常重要的业务动作，如果有相关的处理逻辑调整，应该提前开发，做好充分测试，保证月结工作顺利进行，而不能让研发同学在月结当天手工处理，影响月结工作，问题就非常严重了。

步骤三：挖掘真实动机

掌握了需求的基本情况后，下一步，我们要尝试尽可能的挖掘需求背后的真实动机。
绝大多数情况下，用户提出的需求，都是自以为正确的解决方案。这是人之常情，即便作为产品经理，我们静下心来自我反思，很多时候我们给别人提需求时，是不是也会习惯性的把自己以为正确的解决思路一起提给对方？而且希望对方能按照自己的想法和意图去执行？
畅销书作者Simon Sinek，在TED演讲中提出了黄金思维圈（Golden Circle）理论：如果将思维模式分为三层，即Why、How、What，通常情况，我们思考问题时，往往喜欢从外层开始，在表层上探索，很少深入到核心的Why层面；如果我们在思考时能够从最里边的Why层出发，展开到How，再到What，更容易洞悉问题的本质并做出正确决策。

黄金思维圈

在产品设计需求分析工作中，用户提交的需求往往是在What层面的思考，我们应该帮助用户，从思考的外层逐步深入到内层，找到核心诉求后，再往外延伸展开，寻找更多的解法，如下图。

需求分析和产品设计的思维方向

要素6：核心诉求

在寻找需求背后的核心诉求时，我们可以采用丰田公司大野耐一提出的5W法，连问五个为什么，层层递进，通过打破砂锅问到底的方法，穷究问题的本质。当然，5Why只是一个参考，实践中并不一定必须问五次为什么。
果冻尝试用5Why法对需求进行分析。
原始需求是销售同学希望在线索掉库前1小时也能推送一次提醒。
为什么要提前再多推送一次？
因为目前提前一天的消息提醒销售同学认为时间隔得太久很容易忘记。
为什么要提前到一小时？
因为这也只是一个拍脑袋的决定，其实估计提前一小时推送也会忘记。
为什么提前到一小时也会忘记？
因为目前系统只是推送通知，推送完就不见了，不是刻意记忆，根本想不起来，也很难找到。
为什么推送完就不见了？不能持续的提示或不消失么？
因为目前采用的是消息通知的组件来进行通知，如果希望将即将掉库的线索提醒变成一个持续存在的待跟进任务，需要采用其他产品设计方案更佳。
为什么不能通过其他产品方案进行处理呢？
当然可以，销售遇到的问题并不是推送消息的时机问题，而是有没有更好的方法，时刻提醒他们有一条很重要的待办工作存在。
设计一个一直存在的明显提示的待办任务，销售同学就肯定能够及时跟进么？
不一定，他们可能还是没时间处理。
为什么没时间处理？
因为销售同学目前线索分配不合理，有些销售会收到大量的新分线索，根本处理不完。
为什么会给某些人分配大量的新分线索？
因为目前系统采用的是销售组长人工分配的策略，销售组长分配时纯粹凭感觉，并不知道目前谁工作量饱和，谁比较清闲，从而分配的更合理。
为什么组长分配线索要凭感觉？
因为目前既没有数据报表给他们参考，也没有系统自动分配策略算法给他们提建议，他们也不知道怎么分配合理。
为什么一直没有在系统上实现这种功能，帮助他们决策？或者代替他们决策？
这实际上是个敏感话题，某种程度上讲，组长能够手工分配线索，代表着一定的“特权”，销售管理层认为每个销售小组都有自己的管理模式，把分配策略留给一线管理者，感觉更高效。
为什么管理层会有这种感性上的认知？而不是理性上的基于数据的分析？
问的对，这是存在了很久的，大家一直知道但却没有深入分析的问题，我们应该借此机会深入分析下目前的人工分配策略到底是否合理，是否应该从本质上解决新分线索的分配模式，让每个销售的工作量都变的公平、合理。
你看，通过对需求不停的问为什么，其实我们可以发现很多问题点和改进的机会点。当然，问题挖掘的深度和方向，需要产品经理自己做好把握和判断。比如说，果冻在分析完后，发现问题的原因之一是线索分配规则不合理，不能简单粗暴的直接跑去质疑销售负责人。我们分析的目的，应该是洞悉本质，在合理的范围内找到更多更优的解法。
同时，我们也要意识到，对需求做深层次的洞察，不是没完没了问为什么就足够的，一方面，需要有灵活的思路和探究到底的勇气以及决心，另一方面，更需要对业务有着深刻地理解和认识；尤其是后者，对于B端产品设计来讲，如果你对业务理解不够深刻，是很难洞察需求本质的。

要素7：强烈程度

需求的强烈程度，代表了用户对痛点的忍耐程度。如果需求强度大，说明用户痛点显著，需求真实性高；如果需求强度低，说明用户痛点不显著，甚至可能是一个伪需求。
判断需求的强弱程度，或者说判断需求的真实性，推荐两个方法。
—方法一：采用正反两问的方法。
我们总是习惯询问用户，如果我做了某某功能，你是否喜欢，或是否会用。请相信我，多数情况下，用户都会回答“我喜欢”，“我会用”，但上线后用户却不会像之前承诺的那样热心使用新功能。除了正向询问，你应该还要采取逆向询问，即：如果我不做某某功能，你的感受是“我很喜欢”？“理应如此”？“无所谓”？“勉强接受”？“我很不喜欢”？这也是C端产品设计、用户研究分析时经常采用的KANO模型背后的设计思路（关于KANO模型，我们在第12章B端产品的迭代管理中还会进一步探讨）。
—方法二：询问目前痛点的解决方法。
判断需求强度的另一个办法，是询问用户目前是如何解决痛点的。如果用户说需求很紧急，但当你问他，目前问题是如何解决的，而他回复你说目前问题并没有着手解决，那么你一定要留心，这个需求，对用户可能并不像他所说的那么紧急。如果真的是很着急的痛点问题，请你放心，即便你没有实现相关功能，用户也一定会自己想办法解决。
同样的方法也适用于产品初期市场分析时，当你定义了目标客群，在分析客户的痛点或遇到的问题时，如果客户当前并没有采取措施解决这些痛点，那么很可能他也不会为了解决这些痛点付费购买你的产品。

要素8：实际价值

需求的实际价值，是需求优先级管理中重要的排序依据。在需求分析前期，我们也需要明确需求价值，如果价值有限，或者不符合公司当前阶段产品规划的重点，甚至可以不用投入太多精力，而直接将原始需求的优先级降低。
B端产品需求整体可分为两大类，一类是解决客户、用户痛点的业务需求，一类是针对产品或技术本身持续优化的技术需求。
业务需求的价值
我们在第一章提到过，B端产品对企业来讲承担着提升收入、降低成本、提高效率、保证品质、控制风险的重任。每一条业务需求都服务于业务，背后的价值也在以上五点以内。还有一类需求是为了改善用户体验，我们暂且将这类需求也归于业务需求范围，因此，除了以上五点，还可以再加一点，即改善体验（软件产品的交互体验，而非企业对于终端消费者的服务体验）。
技术需求的价值
软件产品在构建过程中，自身也存在很多非业务相关的优化点，比如说，我们要将列表页进行支持自定义设置的改造，从而解决为不同客户三天两头硬编码修改列表页的烦人工作，这类需求是为了降低研发成本，或提升产品化能力而存在；再比如说，为了解决企业客户重复的问题，我们需要将产品背后的应用架构，进行主数据改造，这类需求，是为了改善架构合理性而存在；这些都是技术需求背后可能的价值。（关于主数据架构改造的话题，我们将在第四篇“进阶篇”进一步探讨。）
我们应该尽量保证每条需求只对应一个价值点，如果一个原始需求对应了多个价值点，产品经理可以考虑（并非绝对）该将其打散、拆解成多个需求，分别对待分析。这样做的目的，是让工作的颗粒度更加合理，并且可以和产品规划相呼应，也可以需求对应的功能设计更加聚焦。

步骤四：发散更多场景

用户提交的原始需求，往往是针对背后的痛点自以为正确的解决方案。当我们已经洞察了需求背后的核心诉求后，应该跳出需求本身的范围，从更多的角度、场景切入，思考如何解决问题。

要素9：横向替代场景

横向替代场景，是指围绕核心诉求，找到所有可能的解决思路或者场景，这些场景彼此之间在某种程度上是可替代关系。
原始需求所描述的场景，只是所有可选方案中的一种，而且不一定是最优解。通过5W法分析问题本质时，我们对问题有着不同层面的理解，可以选择对其中某一层面或某几个层面，展开分析所有可能的解法。
果冻分析需求后，发现背后的核心问题是销售同学新线索分配不合理，导致来不及跟进线索，造成掉库现象频繁发生。虽然需求希望的是加强即将掉库线索的提醒频率，但这并不是唯一的解决思路。果冻思考后，针对提高销售人员线索跟进效率问题，梳理出了以下解决问题的思路和场景。
1、让线索分配流转更加合理公平高效
a)优化新线索的分配规则
i.实现系统自动化分配策略
ii.保持人工分配，但给分配人员更多的数据支撑作为参考
iii.采取机器自动化+人工分配混合的模式
b)优化线索掉库流转规则
i.完善线索掉库时间的规则（目前规则可能一刀切且过于严格）
2、让销售人员对每日工作计划的安排和执行更加合理且高效
c)让销售人员及时掌握当前任务待办情况
d)系统帮助销售人员根据优先级和价值安排每日工作计划
果冻的分析相对全面的覆盖了可能的问题解决方向，而且果冻再次深刻地认识到，需求分析的难点在于对业务理解的深度。豌豆提交的需求，只是上边提到的方案c）中的一个小功能点而已，除了c），我们还有a）、b）、d），都是可以选择的优化方向，而且他们彼此独立，在某种程度上是互相可替代的选择。果冻通过追本溯源，找到了问题的本质，再通过横向扩展，采用结构化思维，穷举了解决的思路，一切从业务场景出发！下一步，就可以选择一个确定的解决方向和场景，继续深入的分析！

要素10：纵向互补场景

纵向互补场景，是对选定的解决方案及场景，进一步思考在需求点的上下游和整体的用户操作动线上，是否存在考虑不够全面的机会点和优化空间，找到围绕需求点的互补场景，让方案更佳全面、透彻。
用户提交的需求，往往只是一个点，但是背后的场景，实际上是一条线，或者一个面。如果我们在设计时只是实现了一个点，那么接下来总会有接二连三的补充需求出现。作为产品经理，需要提前将这些可能的优化点、相关的补充场景都思考周全，进行统一的规划和设计，避免局部和片面性的思考。
分析纵向互补场景，可以将场景中用户行为或动作的事前、事后环节，或者在系统上完整的操作动线全部梳理出来，找到其中可优化的遗漏点。想做到这一点，最有效的方法，就是深入到业务一线，要么轮岗体验业务的实际场景，要么通过观察用户操作并访谈了解用户的行为。
在C端产品设计中，用户故事地图（User Story Mapping）是一个非常经典的用户体验分析工具，可以帮助产品经理和体验专家分析用户为了达成某个目的，在使用产品中的关键步骤和动线，并依据此，从场景的角度出发去拆解设计软件的功能点。
在B端产品设计中，我们可以借鉴用户故事地图，来分析某类用户角色，在某些场景下的完整环节，以及相关的需求点或功能点。
结合目前领导对产品的规划，当前阶段CRM建设的重点在于赋能销售，帮助销售人员提升工作效率，因此暂不考虑线索分配策略这些涉及到业务规则调整的功能设计，果冻将注意力集中在如何帮助销售人员及时掌握当前待办任务这个方向上，从原始需求“提高掉库消息提醒频率”切入，思考更加全面的设计方案。
通过在销售部门实际轮岗工作三天，以及大量的访谈工作，果冻尝试使用用户故事地图这个工具，将自己了解到的电话销售核心场景（部分）的故事地图绘制出来，虚线部分是目前销售人员通过线下手工完成，系统还不支持。

销售人员的用户故事地图
用户故事地图的绘制并不复杂，难点在于场景的梳理拆解。为了达到某个业务目标或目的，用户的操作动线首先在第一个层面进行拆解，得到了不同的一级场景，即Activity，将一级场景可以进一步拆解出二级场景，即Back Bone，这就像一个叙述故事的骨架，也叫作Walking Skeleton；在二级场景下，我们可以进一步更加细致的列示出所有相关的功能点，即用户任务UserTask。
用户故事地图中最小颗粒度的用户任务，也就是敏捷开发中的用户故事User Story，用户故事是一种从用户场景切入去描述最小功能点的软件设计方法论，每一条用户故事按照如下结构来描述：
作为（谁），我想要（什么），以便（为什么）；Aswho，I want what，so that why。
在传统的软件设计工作中，尤其是针对复杂的业务型软件产品，我们往往从业务流程和功能结构切入去进行软件设计，但很少考虑用户体验和场景。而敏捷软件设计中，更重视从单一用户和场景的视角切入去进行软件设计。两者设计思路和出发点完全不同，产生的效果也不一样！
B端产品有一个很常见的体验问题，就是功能都有，单独用起来也没问题，但在实际业务场景下，把这些功能连起来，就非常难用，体验差。这正是因为很多设计人员习惯于从功能结构的角度思考设计问题，而很少从场景的角度思考体验问题。
作为B端产品经理，一定要认识到，现代软件设计，既要求有抽象设计和结构化思维，又要有场景设计和用户体验思维，这两者缺一不可，是每一名B端产品经理都应该重视并掌握的能力。
用户故事地图，以及User Story的产品设计方式，对B端产品经理来讲，值得学习借鉴。当然，User Story在B端产品设计上也存在缺陷和不足，这个话题在本章最后一节还会深入探讨。在梳理纵向互补场景时，用户故事地图是一个可选的工具，并非必须，梳理纵向互补场景的要点是将某个解决思路下所有的操作链条以及相关场景的功能点都能思考全面，避免需求上线后重复返工修补。
基于自己的轮岗调研，并结合用户故事地图的呈现，果冻发现，在销售的日常线索跟进作业场景中，首先每天会拿一个小本子把待办任务整理好，并标记优先级；在收到消息通知后，销售还会把新分线索、即将掉库线索记录下来，更新到小本子中；每天工作结束前会回顾当天的跟进情况，并计划第二天的工作安排。
可见，系统已经无法很好地支持销售人员的当日工作管理，销售人员反而通过记事本自己管理工作。针对线索掉库提醒的功能优化，单纯的提高通知频率是不够的，还需要从销售的完整工作场景入手，在各个环节都进行优化。
经过思考，在“帮助销售人员及时掌握任务代办情况”这个思路下，除了提升消息通知频率，我们还考虑增加当日待办清单任务聚合的能力，增强销售同学对当天工作的管理，让销售同学和小本本说拜拜！

步骤五：设计产品方案

产品经理通过对原始需求进行充分分析后，确定了整体的解决思路，接下来，要设计具体的产品方案，来帮助用户解决痛点，实现业务诉求。

要素11：已有方案

有些需求，其实并不一定要开发新的产品功能来解决问题，现有功能可能也许就可以一定程度的直接或间接满足诉求，产品经理首先要对此进行判断，不要盲目的、匆忙的着手功能设计。如果需求优先级并不高，客户又很着急，那么通过一些已有功能，部分、间接的解决问题，也不失为一个尽量帮助到客户的好选择。
尤其是对于甲方自研自用系统的情况，研发资源有限，如果可以用一些变通的方式解决问题，并不一定必须开发功能，而且在甲方工作的软件设计人员必须严肃的意识到，解决业务问题才是核心目标，软件产品只是为了解决业务问题采用的手段之一，有些时候通过软件产品解决问题投入产出比反而较低。
我们可以举一个小例子，来解释下如何通过已有方案间接地满足用户诉求。相信大家在使用微信中都会有一些烦恼，有一些群总是不停地弹消息，占据聊天记录前排位置，对自己没有任何意义，但因为某些原因自己无法退群，因此只能忍受（大家可以想象生活中是不是有这种群），假如你是微信的产品经理，用户提交了一个对群“置底”的功能，这样就能既不退群，又不会受到打扰。假设这个功能暂无法开发，有没有其他妙招能够帮助用户间接地解决这个问题呢？当然有啊，你可以让用户挑十几个经常聊天的对象都“置顶”，这样那些让人烦恼的群被静音后就不会再看到他们啦！

要素12：功能需求

产品经理在分析原始需求后进行软件产品设计，编写PRD（Product Requirement Document，产品需求文档），也即功能需求文档，提交给研发人员，进入下一步开发工作。
在B端产品设计中，很多时候仅仅绘制线框图编写逻辑说明是远远不够的，还需要进行需求建模等工作，将软件功能进行高度抽象化的设计，具备灵活性和扩展性，支持不同客户和业务场景，这是一个相当复杂且具有挑战的过程。
除了增加掉库线索的提醒频率，果冻还设计了一个全新的待办事项面板，将销售每日工作几个关键场景的待办事项聚合在一起展示出来，如下图。用户可以通过点击数字超链接，进入到线索列表页，呈现出符合条件的线索记录。
“今日新分线索”展现的是当日新分的所有线索；
“今日需联系线索”是指之前设置了待办提醒的当天待跟进线索；当线索被跟进并添加了拜访小结后数据就会被清除；
“即将掉库的线索”是指1天内即将掉库的线索；当针对线索做了某些相应的动作后，数据就会被清除；如果新增了一条即将掉库线索，则消息中心进行首次提醒，且“即将掉库的线索”数字加1。
有了下边这个小面板，以及点击数字后进入到统一的线索列表页，实际上已经实现了先前豌豆需求中对消息盒子的各种改造需求。在典型的B端产品设计中，消息中心只负责主动式消息提醒，待办管理应该通过其他的组件设计实现。

全新设计的待办事项面板

要素13：非功能需求

在需求分析工程中，非功能需求（NFR，non-functional requirement）是指软件产品为了满足业务需要必须具有且除了功能需求之外的特性。在软件质量评估国际标准 ISO/IEC 25010:2011对非功能需求做了非常详尽的定义。
简而言之，类似于访问时间、并发量、安全性这类非功能诉求，但是在软件设计和使用中非常重要的要素，都是非功能需求涵盖的范围。对于产品经理来讲，需要留意这类需求，在某些场景中，如果有需要，应该明确的指出软件产品的非功能性诉求，例如某些同步查询功能，要求最长响应时间不应超过30秒，并发量要至少支持30个并行查询。

【资源推荐】

关于非功能需求详细的说明，有兴趣可查阅ISO官网https://www.iso.org/standard/35733.html。

小结

至此，我们已经完整探讨了需求挖掘分析的十三要素五步法，通过这五个步骤和十三个要素进行充分的需求分析，相信会帮助您洞察、探索需求的全貌。
作为产品经理，一定要分析需求背后深层次的原因，而不是马上上手进行功能设计。只有理清了背后的问题，才能做出合理的方案决策，确定优先级，并与产品规划结合起来考虑。
当然，这套方法分析起来也略显复杂，更重要的是，我希望大家能够通过学习这套方法，培养自己场景化的思维意识，以及全面、缜密的思考逻辑。当你经过方法论多次的训练后，思维模式和思考习惯会形成肌肉记忆，一旦形成了肌肉记忆，在以后的工作中，即便你不会刻意的采用这套方法，依然会潜移默化的把握需求分析的关键要点。
同时，我也想再次强调，B端产品成功需求分析的前提永远都是理解业务为第一要务，如果自身业务知识底子不够厚实，学习再多的需求分析技巧也是枉然。