全面的聊一聊需求定义、收集分析和管理

一、需求定义

1. 基本定义

需求是指由需要而产生的要求，更底层的来源是人的欲望。比如因生存的需要，而产生温饱需求；因精神共鸣的需要，而产生社交需求；因想拥有愉悦的情绪，而产生听音乐的需求；因想舒适出行，而有打专车而非坐地铁的需求等等。

需求无处不在，贯穿于我们的工作、生活每一个具体的场景当中。其实仔细想想，我们日常的每一个决策、动作，都是基于需求在背后的推动，只不过对于那些可以快速决策和反应的行为，有时我们自己都感知不到，而那些需要耗费脑力、精力和时间的行为，我们才会有清晰的感知。这就涉及到人类大脑的“系统1”和“系统2”，本篇文章不做详解，感兴趣的话可以翻阅丹尼尔·卡尼曼的著作《思考·快与慢》。

2. 需求的合理性

从用户，即需求产生者的角度出发，需求永远是合理的。在没有外力的胁迫下，每个用户提出的需求都是基于自身主观效用最大化而产生估的。

即使作为一名产品经理，基于一些理性的成本和收益分析，认为用户提出的需求是不合理的，也不能改变用户站在其自身角度出发，所认为的该需求是合理的认知。

反过来思考，产品经理认为用户的需求“不合理”，也是产品经理把自己与其背后的企业放在一起，从未来的成本、收益出发才有的判断，这本身也带有主观偏向性。因为产品经理有自己的需求：为企业发展带来效益、为产品规划更好的未来的需求。

我们常说产品经理需要有同理心，其实说的是产品经理需要学会与用户“共情”，让自己站在用户所提出需求的具体场景去思考用户所表达需求背后的真实原因，而且要去感受用表达诉求时的情绪反馈。我现在在做B端产品，银行客户是我们产品的目标客户群之一，有时跟同事聊到产品的稳定性就经常会提到一个场景：试想一名柜台工作人员正在帮助客户办理取钱业务，但是用我们的产品时却总在关键时刻卡顿影响业务的正常办理，而客户又急需用钱。若你是这位柜台工作人员，你会如何评价你所使用的产品呢？当你接收产品厂商的调研时，你会给与什么样的反馈呢？

虽然每个人的成长经历、生活环境、认知水平都会有所不同，产品经理难以对每个用户反馈的具体需求都做到感同身受，但是对于那些自己认为不合理的需求，其实更应该花时间去了解和挖掘用户提出该需求的更深层次原因，这种方式也很有可能会给产品的发展方向带来意外收获。

3. 需求的差异性

用户其实并非就是自然人，更确切的说，应该是需求的集合，只不过当前所讨论的产品大多数都是为自然人而设计的，因此习惯性的将用户理解为自然人。但其实我们也有很多产品是为其他生物设计的，比如为猫狗专门设计的饮食器等。

自然人本身具有异质性的特点。

因此，针对同一类需求，不同的用户之间也会存在差异。同样都是通过饮食来满足温饱的需求，但有的人偏向于辛辣口味，而有的人偏向于酸甜口味。

放在互联网产品中亦如此，比如音乐类的产品是满足用户的听歌诉求，但不同的用户对于听歌的音效喜好是不同的，有的喜欢 live 场景，有的喜欢音乐会场景，还有的喜欢宽广环绕等。

对于产品发展来说，基于需求满足的用户量覆盖来考虑，要优先洞察用户的共性需求，这类共性需求是保证更多的用户使用产品的基础，可以为产品带来可用性价值。当产品逐步趋于成熟，用户量足以支撑为满足个性化需求所投入的成本时，再做共性功能的拓展或其他个性化需求的补全。

用户作为自然人而存在，需求产生的背景是多种多样的，因此用户提出的需求并非是都可以实现的，完全满足所有用户的所有需求的产品也是不存在的。

4. 需求的周期性

如果以时间为维度，一年可分为四季、12 个月、365天，一天可分为 24 小时。用户在不同的时间所需要满足的需求是不相同的，就像对于衣服购买的需求，也会有旺淡季一样。对于各类产品而言，本质上也是在提供服务，这种服务只是区别了传统交付形式，但目的仍是满足用户的诉求。

简单举例，以天为单位时，用户对于消磨碎片化时间的需求大概率会集中在 8:00-9:00、18:00-19:00 之间，其他时间可能忙于工作、陪伴家人、运动健身等。此时，如果去观测产品的数据统计情况，日活跃度的时段分布也是有明显特征的。将时间周期放大到月、季度、年，也是一样的道理。再例如一款户外产品，在周末的平均活跃度高于工作日，在春秋季的活跃度高于夏冬季。

掌握这些时间规律，可以帮助产品经理更好地了解用户使用产品时的各种状态条件，包括用户的内在心理状态和外在物理环境，进而能更好地设计产品，以满足用户需求。

5. 需求的不可实现性

用户需求千千万，但真正可以被满足的需求是极少数的。很多需求注定是无法被实现的，认识到这一点很重要，虽然听起来似乎有点残酷。因为需求是用户欲望的一种表达方式，而欲望是无穷的。

对于产品经理而言，即使有着要满足用户所有需求的雄心壮志，也要认识到客观现实对于用户需求满足的限制性。

满足所有用户的所有需求并不是产品唯一的成功方式或检验标准，选择满足大多数用户在更常见场景下的基本需求，且提供良好的产品体验，为用户带去主观效用的最大化，才是需要重点考虑的。一步步地去了解你的用户，带领你的前进，适当舍弃那些在当前条件下不可实现或低价值的需求。有些需求也许当前不具备可实现性，但随着条件的改变（如新技术的出现、国家政策调整等），会让那些过往不可能实现的需求成为可能。

认识到需求不可实现性的客观现实并不是让我们妥协，而是为了让自己具备更理性的决策思维。

以上都是关于需求的一些基本特点介绍，了解需求的特点并接受其实并不是一件容易的事情，因为这些特点看起来像是在给产品经理的工作制造麻烦：有些特点让产品工作无规律可循，有些特点感觉又让产品落地受到限制。

但是这也是产品经理工作的乐趣之一，于众多内在和外在因素之下，不停摸索需求满足的最优解，为用户、为企业、为团队、为自己带来正反馈的平衡决策，是产品经理的价值体现所在。

二、需求收集

了解了需求的特点之后，再来聊一聊需求的来源，需求的来源有很多，比如用户反馈的需求、运营部门的需求、研发部门的需求、领导的需求、竞品分析梳理的需求、也有产品经理自身认知所产生的需求等等，重点聊一聊用户反馈、上层领导和自我认知所产生的需求。

1. 用户反馈

产品因为用户愿意为其需求得到满足，而付出对应的成本（金钱、时间、精力等）而存在，所以某种程度上可以说用户就是产品的“衣食父母”。无论是各种互联网产品，还是电影、脱口秀、音乐、饮食等传统服务，在交易模型上都是类似的，因此产品或服务的价值也就体现在满足用户的需求上。

用户在使用产品的过程中，都会带有自己的心智体验感受，这种感受会转化为情绪体验，如满意、一般、不满意等。在不同的情绪体验上，用户会有不同的反馈。以使用APP 为例，满意时，用户可能会提高产品使用时长、购买增值服务等；觉得一般时，用户可能会反馈一些期望增加的功能；不满时，用户可能会立刻卸载 APP，甚至还会去应用商店上给一个低评分。

对于用户反馈要增加的功能，只是其需求得到满足的一种外在表现形式，因此产品经理需要谨慎评审，更多的挖掘用户期望增加的功能背后所隐藏的底层需求，一个高质量的用户反馈是产品经理难得一遇的“宝藏”。

2. 上层领导

每个企业或团队中都有不同的岗位和角色分工。在对行业认知洞察以及产品方向规划上，上层领导往往可以给出相对更准确的决策结论，至少是全局条件下综合考虑更合适的，这是由领导层在行业信息掌握程度和认知程度决定的。

只不过上层领导所提供的需求往往是比较宽泛的一种想法、理念或目标，还需要产品经理将这些想法具象化，进而推动落地。

例如针对当前产品现状和目标，梳理出产品的发展路线图，根据讨论确认的路线图再进行产品的概念设计、详细设计等，直到最终可以转化为研发、测试、设计等同事进行工作的产出物。需要注意的是，产品经理在进行产品具体规划的同时，还要考虑产品的运营、市场推广、售后等所有涉及产品上线交付的全链条工作。

这是对产品经理全局视野的要求和培养，坊间流传“产品经理是CEO的学前班”，也是不无道理的。

3. 自我认知

基于自我认知而挖掘或规划需求是最难的一点，因为需要产品经理长期投入对于产品和行业的学习成本，且多做项目和总结复盘积累，还需要个人对产品的热爱，投入激情，最终形成行业的产品认知体系，包括但不限于对行业的认知、对产品专业能力的认知、对成本收益评估的认知、对用户需求的认知等等。

从职场发展来说，自我认知的高低也是产品经理的核心竞争力之一。

当自我认知成体系形成后，便可以引导产品的发展规划，也可以帮助用户去发现他们自己都未发现的需求，进而让产品赢在起点上。当然，除了上述需求来源，前面提到还有来自公司运营、市场、研发等部门的内在需求，也有来自对齐外在竞品的需求等。至于何种需求才是具有生命力的，那就需要每个产品经理基于公司和产品现状和未来规划做综合考虑，需求本身的业务价值、投入的成本、收益反馈周期等，也都是需要考虑的因素。

需求是用户与产品的连接点，对于需求的挖掘、分析、规划都可能直接影响到企业在市场竞争中的地位。

在了解了需求的基本特点和收集之后，接下来最重要的事情就是需求价值分析，进而通过需求优先级和研发资源情况来进行产品迭代规划。

4. 场景化分析

“无场景，不需求”，需求都是在具体场景下产生的，因为用户生活在具体的场景当中。产品经理接收到需求反馈时，首先要做的就是明确需求所发生的场景。如果用一句话来需求，就是：什么人在什么场景下需要用到什么服务来满足自己的什么诉求。

对于需求的场景化分析，最好的方法就是到用户中去，例如对于外卖骑手来说，他们对于派单语音播报的音量大小习惯，是坐在办公室中处于安静思考状态下的产品经理容易忽略的。

只有深入了解用户工作或生活的环境、消费习惯、收入来源、社交关系等信息，才能更加精准地结合具体场景来分析需求价值，进而规划产品方向。

5. 用户故事地图

用户故事地图是用户在具体场景下为寻求需求的满足，所发生的一系列行为动作的路径。当我们想将收集到的新产品需求全部实现时，需要在史诗（通常是与特定结果密切相关的原始想法）层面进行多种实现，史诗是一个大的故事，在敏捷开发中称之为“史诗故事”。对于史诗故事来说，实现的成本和交付时间都更长，对于团队以及利益相关者来说并非是最佳的。此时，可以拆分成许多小故事，拆分故事的颗粒度，最终成为一个又一个具体场景下的用户故事。

不过需要注意的是，用户故事的衡量标准并非是将功能简单拆分，合理的用户故事应该具有封闭性、针对性、独立性这三个特点。封闭性是指该用户故事有独立的交付价值；针对性是指该用户故事只针对特定的用户群，确保服务的目标用户对象清晰，多用户群的需求往往存在差异性；独立性是指该用户故事不与其他故事相互依赖，否则无法进行交付。

用户故事地图的重要作用就是让用户在具体场景下的需求变得更加清晰，也是最终产品交付时，用户对于使用产品来解决具体场景下的需求更加清晰。

6. 最小可行产品

将用户需求都纳入到不同的用户故事里，将大故事拆分成有价值的小故事进行独立交付，也就是我们常说的 MVP 产品（最小可行性产品）。

其实MVP 产品不一定是通过软件代码开发出来的运行在各种设备上的软件产品，可将视野扩展到其他行业当中，比如：在酒店行业，MVP产品可能是一套迎接客人的快捷服务流程；在餐饮行业，MVP产品可能是一套核心上菜流程等等。

MVP的目标是在早期阶段验证产品的核心假设，并获得用户反馈和市场验证，以便进一步改进和迭代产品。既验证需求的真实性，也验证产品方案的满足程度。

在激烈的市场竞争中，抢占时间就是抢占市场，考虑到投入成本和交付周期，企业为了后续决策的正确性，往往会选择先通过推出一个 MVP 产品投入市场，然后观测用户使用数据和反馈，用以校准下一次的产品决策。

无论是领导下发的战略性需求，还是用户反馈的场景化需求，抑或是运营部提出的产品营销活动类需求，都有其特有的价值，但是企业所拥有的资源是客观稀缺的，无法满足所有角色提出的所有需求。

产品经理的价值体现之一，就是在综合所有因素之后，制定产品的迭代次序，在投入产出比上创造价值。

7. 需求分类

对于所面临的众多事项，人们通常会采用重要紧急四象限来进行划分，以此来制定事项处理顺序，更好地分配精力，确保综合结果能达到自己预期。面对众多纷繁复杂的需求，也可以采用同样的方法进行归类。经典的需求归类模型是 KANO 模型，将需求划分为：必备型需求、期望型需求、魅力型需求、无差异型需求、反向型需求，体现的是产品功能与用户需求匹配度的一种关系。

简单地理解，必备型需求就是提供满足用户刚需的产品功能，如果没有此功能，用户则会放弃该产品，这是产品初期最需要关注且投入资源去完成的工作。

期望型需求则是用户有所期待的需求，当产品提供了满足该类需求的功能，用户对于产品的好感度会直线上升。但是产品即使没有满足该类型需求，在其他产品不具备同等功能之前，用户一般也不会离开该产品。长期来说，这是提升产品持续竞争力的重要一环。

魅力型需求指的是用户自身也没考虑到，但是产品经理基于自己的认知等因素，挖掘出了用户更本质的一些需求，并予以了满足，让用户有一种“喜出望外”之感。用户也会因此成为产品的忠实粉丝，并向其他非产品用户推荐产品。无差异型需求指的是从用户侧来说，无论是否提供满足该类型的需求，都不会影响用户对于产品的使用和评价。开发此类需求，对于企业来说，是属于资源浪费型投入。

反向型需求指的是违背用户初始意愿，开发与用户在各场景下的需求相反的功能，此行为最为不可取。

8. 需求等级

为了更好地将需求优先级予以体现，还需要一些量化方法对需求进行标记， 常见的如P级制、 百分制、MSCW、高中低等。

P 级制是将需求优先级从高到低为P0、P1、P2、P3、P4 级 别； 百 分 制 是 按 照 100、80、60、40、20 等进行划分；MSCW 分别代表 must（必须做）、should（应该做）、could（可以做）、won’t（不会做）；高中低等则是最直观地将需求分为高优先级需求、中优先级需求、低优先级需求。对于产品管理来说，采用何种方式进行划分标记不是最重要的，而是同一个项目团队里，对于所选取的等级划分方法是明确且达成一致的。所有的工具方法本身都没有意义，只有使用者对其的使用创造价值，才为其赋予了意义。学会优先级的划分不仅适用于工作，同样也适用于生活。每个人的资源、精力、时间都是有限的，要学会“把好钢用在刀刃上”。

三、需求管理

收集需求、拆分需求都是前置工作，产品经理还需要一些管理工具或者说方法来让收集到的需求为后续的工作服务。

1. 需求池

产品经理将所有收集整理的需求进行汇总归类、划分优先级之后，需要进行统一的维护管理，这就是总需求池。总需求池主要是为了避免需求遗漏，可以从全局上综合评估所有需求的相对优先级，进而做出更正确的产品迭代内容决策。

同时，每个产品都有自己的生命周期，需求是可持续性的，因此对于每次规划的产品迭代也需要单独维护一个迭代需求池来管理。主要是作为此次产品迭代的需求范围而存在，与技术、测试等团队达成最终产品验收的一致认知。

关于需求池的形式，可以用市面上的需求或项目管理工具来维护，也可以通过线上表格等工具来管理，重点是方便信息更新时可即时同步到团队成员。

2. 产品方案

产品经理接收到需求之后，往往并不需要立刻开始做产品原型的设计。

所有的需求都是为了满足用户的需求而存在的，而用户需求的满足不一定是通过功能的开发，也许通过一些服务流的程改进也可以满足。

用户也可能会针对自己的需求，把自己放在产品经理的角度，提一些“建设性”的产品功能设计方案。就像之前张小龙说每天都有一亿用户在教他如何做产品一样，这些用户虽然有自己的具体的使用场景，但是缺少一种全局观。同样的，这些产品方案也许具有其参考性，但其参考的价值也是倒推到用户为何有此需求，期望自己的何种欲望得到满足。

而产品经理要做的是将用户需求与产品现状相结合，寻找其最合适的衔接点。

例如考虑用户需求被满足的功能设计时，还需要考虑该设计方案对于产品已有架构的调整程度，这就涉及到成本问题；可能还需要考虑功能上线后，如何做推广运营，这就涉及到功能的盈利问题等。

综合而全面的考虑用户需求，进而提出合理的产品方案才是产品经理需要做的事情。

3. 产品需求文档

一般来说，对于当前的互联网产品来说，以界面型需求居多，例如通过触摸屏点击来实现交互，那就是涉及到界面的。

当然也有些不涉及到界面的，例如当前很多产品中的推荐算法、排序规则等，不过这些算法规则之后，也是通过界面展示给到用户的。

对于界面型需求来说，产品经理往往需要输出产品原型，也就是常说的产品需求文档（PRD）。

对于开发、测试等同事来说，最忌会的就是来自产品经理的“一句话需求”。

一份优秀的产品需求文档，应该是可以直接知道开发、测试的工作，而不需要他们来反复找产品经理做内容确认的。

4. 低保真

对于产品经理而言，用来与开发、测试、设计等人员进行需求评审的产品方案采用低保真原型（即线框图）文档即可，其优势就是对于产品经理而言，可以快速将思考的产品方案具象化，进而与参与评审的同事快速对齐认知。

虽然低保真原型文档不要求像高保真一样的“养眼”，但是也需要注意最终呈现出来的效果，对于阅读者（开发、测试、设计等）而言，降低他们的理解成本。

5. 产品需求文档

首先，对于界面型（即用户做操作之后，与原先页面有差异之处的页面）的需求都需要通过原型来表达。

因为由于每个人认知不同，如果不直观地将所有界面绘制出来，便会出现“一千个读者有一千个哈姆雷特”的情况，每个人所设想的都不同，到最终产品方案执行阶段，便举步维艰。

其次，专业的人做专业的事。

在设计低保真原型时，主题色采用黑白灰即可，目的就是不影响与产品经理配合的设计师进行产品高保真设计。

使用黑白灰进行低保真原型设计时，也要注意色彩尽量统一，若采用各式各样的灰或者黑，最终的低保真原型呈现出来的效果也会不佳，建议每种颜色最多定义两种，用于不同的页面元素上即可。

再者，在产品方案设计时，还需要考虑页面多状态的情况，例如对于电商产品的订单功能，需要考虑有订单和无订单的状态；再比如对于增值服务，需要考虑用于购买了增值服务和未购买增值服务的情况等。由此产生的各种数据流转情况，也要同步予以说明。

同时，还有一些“隐藏性”的需求，也是需要在产品方案中进行说明的。

例如存量数据的处理、排序规则的定义等，这些都是无法通过原型页面直观表达出来的内容，但是对于产品的最终上线效果，具有举足轻重的意义。

另外，这部分需求与技术可行性相关，产品经理可适当寻求技术同学帮助，一起商讨方案，确保最终产品方案可落地执行。

最后，也是非常重要的需求标注内容。

需求标注是对设计的产品原型的解释说明，就相当于是开发、测试等同事在实际工作执行中时的“产品经理代言人”，承载着将产品原型对应的需求规则进行清晰明确的重任。

还有一些内容，如全局说明、背景介绍、交互释义、展示规则等内容，也是需要与低保真原型文档组合在一起，最终形成一份产品需求文档，也就是常说的PRD。

6. 修订记录

由于认知偏差的客观存在，产品经理最终用于需求评审的产品方案往往都不是最终稿，而需要进行修订。

为了让产品项目组与产品需求文档相关的所有人员可以知晓每次修订的内容，需要建立一个修订记录模块，专门用于记录产品经理对于此次产品方案的调整内容。

如此，便可以在项目组内保持信息的即时性。

团队在认知一致的基础下进行协作，对于工作效率、质量产出，以及团队的工作效力、契合度都是具有重大意义的。

产品经理基于需求，与研发等同事做了初步讨论，设计出产品方案之后，还需要组织项目组相关人员进行产品需求评审，进而推进下一步的产品研发工作。

需求评审的目标是对需求内容达成一致认知，从提升需求评审通过的角度来说，可以将需求评审分为三个阶段进行，分别是：迭代价值、业务流程、产品需求，是一个从宏观到微观的过程。

7. 迭代价值

从工作流程上来说，研发、测试、设计等角色都是依托于上游的产品经理需求来推进工作的。某种意义上，产品经理的需求迭代规划决定了他们的工作内容和强度。因此，若希望整个项目团队中的成员可以有效的进行产品的开发迭代，首先要做的就是与团队成员明确迭代价值，从宏观愿景上达成一致认知。

常见的迭代价值如公司战略规划要求、用户反馈的高频需求、B端客户反馈的高价值商业需求、数据分析得出的产品优化点、新技术要素催生的商业模式探索等。

将迭代价值与团队成员做了明确，且得到认可之后，整个需求评审便已成功了一半。因为战略已定，而剩余的战术则是容易完成的事情。

8. 业务流程

版本迭代价值达成一致认知后，下一步便是对具体的目标下的业务场景和流程进行讲解。

业务讲解的目的是为了让相关人员了解后续所讲解需求的背景，而研发、测试等人员都是具备较强的逻辑性思维的，因此在做业务讲解时，可以提前准备好业务流程介绍的内容，如业务流程图。

在讲解的过程中，将具体的业务场景结合多角色的流程流转进行说明，便可以将需求核心功能逻辑讲解清楚。

甚至对于一些有经验的开发人员来说，后续的页面样式、功能特点都在这个阶段都已经在心里有了个初步的雏形了。

当然，如果有人员提出针对某些复杂的业务流程做具体说明，也可以准备对应的任务流程图来辅助说明，让整个流程讲解更加清晰。

业务流程与团队人员达成一致认知后，最后的产品需求就是一个辅助说明的作用了。

9. 产品需求

最后的产品需求主要是针对所设计的产品原型、需求规则等进行说明，也就是最终的具象化的需求。

这一阶段的讲解是为了将前面的迭代价值、业务流程做一个在产品表现层的说明，促进最终产品需求的落地。

对于产品开发迭代来说，最终发布验收的还是产品功能、交互、元素展示是否与产品需求文档一致。产品需求文档也是作为产品、研发、测试、设计等角色都唯一共同认可的标准。

由于个体认知偏差的客观存在，需求评审有时并不是一轮评审就可以敲定的，往往都会有一些遗留待确认内容。产品经理需要在评审会上进行记录，会后将内容确认之后，再行同步相关人员。如有必要，还要继续发起二次评审，确保将歧义内容都在迭代开始之前进行明确。

做好需求管理，用产品价值为公司的发展奠定坚实基础。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！