产品经理在日常工作的过程中，经常会面对突如其来的需求，如果不能在短时间内记录需求、处理需求，会对后期的产品开发排期产生一定的影响。因此，本文讨论在面对新的需求场景下，产品经理应该如何有效地处理突发需求。

一、问题的来源

在日常的工作中，各种突发需求经常来源于客户、老板、其他部门，这些人提出的需求经常与原有计划产生冲突，使本来就拥挤的需求队列更雪上加霜。

二、问题原因

对于经验不够的产品新人通常会直接答应下去，以证明自己的工作能力优秀，能够完成多种需求，但这种想法对于成熟的产品经理来说，是片面的、缺乏思考的。

当时的需求源为领导或客户，自己因对方职级/身份重要性，在紧张的情况下，直接不经思考许诺了对方，由此对正常排期造成一定的影响。

下面我举例说明一下具体的伪需求：

• 这个需求很新颖，但不能助力业务增长。
• 这个需求听起来对业务增长很可观，但没有经过验证。
• 这个需求很容易完成，但是不值得做。
• 这个需求可是领导提的，但这不是真实需求。

三、问题的影响

没有经过深度思考后答应需求方，会带来以下后果：

• 重新调整需求开发的优先级。 比如：按照排期，前端开发工程师正在开发【权限配置页面】，但你已经答应别人修改【审批流程页面UI】为最高优先级，现在你只能让前端优先修改【审批流程页面UI】，这就可能导致了前端开发工程师逾期完成【权限配置页面】，如果【权限配置页面】需要前后端联调，可能还会影响后端的开发进程，带来连锁进度影响。
• 重新调整开发资源配置。 比如：现在有两个前端工程师和两个后端工程师正在联调【表单功能模块】，当你答应别人的紧急需求以后，需要一个前端和一个后端去处理你的新需求，因此，拖延了【表单功能模块】的上线日期，导致排在【表单功能模块】后的【审批功能模块】的开发人力资源缺失。
• 重新安排相关日程。 对于以开发为中心点，辐射其他工作的影响，可根据团队任务轻重来评估。当今的互联网公司，已经摒弃了软件时代瀑布式开发流程，采用了敏捷开发模式，敏捷开发模式的优点是可以根据实际需求，带领团队快速做需求变更。当你的团队被临时任务压满，其灵动性会大幅降低，导致面对意外的能力大幅降低。

四、解决问题

4.1 面对不断涌起的突发需求

一个有减肥需求的人士去健身房，如果没有提前规划好健身方案、没有系统地学习健身姿势，那么最后的结果很可能是没有减肥，反而因为不正确的姿势伤了身体。

所有的需求终将转化为功能或者服务，而服务和功能是助力业务为公司创造价值的源泉，如果将不经过深度思考的需求投入开发或者修改，将会浪费人力成本，甚至会影响公司收益。

4.2 留给自己思考空间

在突然接到用户的需求时，不要立刻给出答案，一定要留给自己空间去评估需求的真伪、需求的紧急程度、需求的实现难度等一系列因素。那么在突发需求场景中，如何为自己创造思考的空间呢？

需要用到这个方法：

肯定需求方/感谢需求方的支持+翻译/确认需求方的具体需求+请需求方给时间思考如何帮其更有效地解决问题。

其在场景中应用的示例如下：

• 肯定需求方/感谢需求方的支持： 感谢您提出的建议、您这个建议确实对产品价值提升起到了一定的帮助、您讲的这个方向挺新颖的、这个确实是个可以深入的点。
• 翻译/确认需求方的具体需求： 您的意思是想优化一下页面、您觉得系统的流畅度还能得到改善、您对于系统操作顺序可能有点异议。
• 请需求方给时间思考如何帮需求方更有效地解决问题：请您给我点时间看下还能不能有更多的改进空间、麻烦您稍等下我现在去找开发确认下情况。

接下来我举两个实际场景中发生的例子：

客户： 我觉得你们的产品近来一段时间页面都没有什么大的变化，请你们立刻改一下页面UI，下午有个领导要来视察，你现在告诉我下大概什么时间可以改好。
产品经理： 您提的这个需求很重要，我也很重视，对于领导检查确实得认真准备一下，您刚提的要求能不能给我10分钟思考的时间，我主要想一下怎么配合您的建议改善下系统的现状，以便能更好地支撑领导检查。

客户： 这个【权限功能】你们不是刚开始吗，要不先别做了，我觉得没什么实际用处，咱们系统又不涉及权限分发这一块的内容。
产品经理： 您一直以来对产品的要求都比较务实，对开发团队的工作量也很照顾，【权限功能】目前已经开展了一定的研发进度，您能不能给我一点时间，我先去评估下现在开发的具体进展，我马上给您回复。

4.3 需求处理方法论

接下来要面对的问题是：如何在短时间内高效评估需求的有效性。

产品经理必须要有一套需求处理的方法论，一般称呼为产品路线图/产品流程图/产品象限图等。无论那种方法，其核心都是管理需求的优先级。

笔者在管理需求优先级实际应用的过程中，一般先通过【优先级估算】的方式，快速定位需求优先级的大概位置，排除伪需求。然后通过【需求优先级模型】得到需求在需求池中的排名。

4.3.1 需求优先级估算

优先级估算主要通过两方面去考量：

1. 业务价值考量。
2. 相关资源考量。

业务价值考量： 主要通过衡量需求和公司主线业务的相关性做出预估，在这个粗评估阶段主要考虑使用者对该需求的接触频率、该需求所辐射的使用者数量，此需求对于业务增长产生的效益和实现此需求所花费成本之间的权衡。

举例来讲：对于To C领域，此需求能不能为公司主线产品获取新用户、提高留存率、提升用户转换率、增加私域流量等——以公司主线业务指标去衡量需求的效益。

相关资源考量： 相关资源主要考虑包含人力、物力。人力是指：投入开发、设计所花费的人力成本，和需求落地带来效益的对比。物力是指：满足此需求的过程，是否需要采购其他产品；是否需要花费额外的庞大资源助力需求落地。（例：Openai公司训练chatgpt4一次所耗费的电能约为美国120个家庭一年的耗电量，开发这种量级的系统应把物力消耗考虑其中）

通过两个估算过程，大概能够排除掉一般的伪需求，那么有些需求涉及的方面比较多，对业务的影响比较大，无法通过估算排期，那么接下来需要引入【需求优先级模型】进行处理。

4.3.2 需求优先级模型

需求优先级模型的引入的目的是：通过成熟的方法论，根据不同场景需求，使用不同的判断模型，将突发的需求和正在开发的需求进行对比，通过判断突发需求的优先级，来保证正在开发的需求边际收益最大化。

4.3.2.1 MoSCoW模型（莫斯科模型）

• M – Must（必须）: 对系统成功实施至关重要的需求——这些需求是客户对产品的基本要求，是主力推动业务增长的功能或服务。 例如：微信的最重要的功能是通讯，而不是朋友圈。
• S – Should（应该）: 对系统的成功实施非常重要，但不像Must那样急迫——这种功能通常会满足客户的“爽点”和“痒点”提高用户体验、增强用户粘度。 例如：Iphone6，岂止于大，这种能够满足用户情感诉求的解决方案。
• C – Could（可以）: 这些需求在Must和Should满足之后会被考虑，但它们不是紧急的。 例如：对于一个软件产品，【多语言支持】功能不是项目成功的关键因素，但可以为更广泛的用户群体带来价值。当基本功能和核心特性已经实现并投入使用后，团队可以考虑增加【多语言支持】功能作为下一步的改进。
• W – Won’t（不做）: 这些需求在当前版本中不会被实现，但可以作为后续版本的候选。

优点总结： MoSCoW模型优先级层次分明，节省排期时间，易于相关方理解；在Must栏目中，涵盖了主要的发展目标，可作为OKR工作法中的北极星指标，使整个团队专注于最重要的真实需求，避免了过多的资源浪费。

缺点总结： MoSCoW模型分类不够细化，只有四种优先级；在判断需求的重要性时，决策者主观介入较多，没有各需求档次之间的划分标准，导致需求优先级排列不准确。

4.3.2.2 RICE模型

RICE 是一个缩写，代表着四个指标：Reach（受众规模）、Impact（影响力）、Confidence（信心度）和Effort（工作量）。这些指标以加权的方式用于计算每个项目的优先级分数。

公式：优先级得分 = ( R * I * C ) / E

• Reach（受众规模）：指项目对受众的影响范围，即有多少用户会受益于该项目，通常使用百分比表示。例：假设你是一家【在线教育平台】的产品经理，你正在考虑开发一个新功能，该功能将允许用户通过平台与导师进行一对一的在线辅导。在这种情况下，”Reach” 将评估该功能能够影响的用户数量。如果你的用户总数为100人，你预估影响90人，那么“Reach”值为90%。
• Impact（影响力）：表示该项目对用户或业务的影响程度，通常在指标化程度上进行评估。评分使用1到10之间的数，10分表示影响力最大。例：假设你是一家电子商务公司的产品经理，你正在考虑一个新功能，该功能将改变用户结账流程，使其更加简化和便捷。在这种情况下，”Impact” 将涉及到该功能对用户体验和转化率的影响。如果该功能被实施后，用户结账的流程变得更加快速和直观，会显著提高购买转化率，并且带来更多的销售收入。这样的影响将被认为是高的，因为它直接关系到业务的核心目标，一般打9-10分。
• Confidence（信心度）：指评估该项目所需工作实施的信心度，考虑到资源、技术和市场等方面的风险。信心度也是用1-10的分数来评分。例：假设你是一家新创公司的产品经理，你考虑实施一个新的社交媒体功能，该功能将增加用户之间的互动和分享。在这种情况下，”Confidence” 将涉及到你对该项目成功实施的信心程度。 如果你有充分的数据支持，可以证明类似的功能在其他平台上取得了成功，并且你的团队也具备开发和推出这一功能所需的技术和资源，那么你可能会对该项目的成功有很高的信心，一般打8-10分。 如果这个功能需要依赖尚未成熟的技术，或者缺乏可靠的数据来支持其潜在的成功，你可能会对项目的成功实施有较低的信心，一般打2-5分。
• Effort（工作量）：表示实现该项目所需的时间和资源投入。使用时间（例如，人天）来表示，例如，需要5个人天的工作量。

优点总结： RICE方法从产品开发的各种方面进行评估，考虑周全，不仅考虑到了产品资源，也考虑到了开发能力；同时，这种方法在实际应用中评估过程较为简单，通过将需求数据化评估，使得需求优先级排列更为精准。

缺点总结： 受众人群和信心评价较为主观，由于环境和场景对决策人的影响，可能会和实际情况产生一定的误差；整体评估流程只是评估了关键因素，还有很多影响较大因素，未被纳入评估，如：技术可行性等。

4.3.2.3 马斯洛需求模型

马斯洛的需求层次结构是心理学中的激励理论，包括人类需求的五级模型，通常被描绘成金字塔内的等级。从层次结构的底部向上。需求分别为：

1. 生理（食物和衣服)： 例如：当一个人很饥饿时，那么他极需要食物。假设人需要工作的薪酬来生存，其具体表现形式为：领导以生理需求来激励下属。
2. 安全（工作保障）： 例如：一个工作者居无定所，四处漂泊，没有相关的职业保障，缺乏相应医疗保险、失业险和退休福利等。
3. 社交需要（友谊）： 例：一个人要求与其他人建立感情的联系或关系。
4. 尊重： 例：自尊的需要使人相信自己的力量和价值，使得自己更有能力，更有创造力。缺乏自尊，使人自卑，没有足够信心去处理问题。
5. 自我实现：例：运动员把自己的体能练到极致，让自己成为世界第一，只是单纯为了超越自己。

这种五阶段模式可分为不足需求和增长需求。其优先级对应1（最高）-5（最小）。

优点总结： 马斯洛的理论为人们的需求提供了一个清晰的结构，帮助人们快速定位需求层级，同时可以判断出需求方的主要诉求，以便更好地采用方法论帮其解决问题。

缺点总结： 马斯洛需求理论并未考虑到不同文化下的需求差异，可能不能完全适用于所有人群，其次，该理论是建立在所有人的需求层级结构的相似性，但每个人的需求顺序和重要性都是存在差异的。

五、反馈问题

在确认完需求的合理性以后，需要对需求方做需求评定反馈，在对需求方反馈问题的时候，大致分成两种情况，第一：对方的需求经过评估，不是一个有效的需求。第二：对方的需求是一个有效的需求。

1. 如果对方的需求无效：首先，要感谢需求方对开发流程的帮助与指导，其次，阐明开发流程中与需求的相关性、需求对开发的影响，以及对需求实现以后的判断。最后，给需求方一个结论。例：您提的这个需求很好，有助于对用户体验的改进，是这样的：我们现在开发正在主要做权限结构相关功能落地，这个需要前后端协同开发，而且快到了上线交付日期了。我们会将您提的需求安排在下个阶段，在整体产品升级的时候，我们会重点考虑您提的建议，感谢您的指导。
2. 如果对方的需求合理： 直接向对方表达谢意，同时告知需求方开发排期，大概多久这个变更可以投入上线使用。

以上是笔者根据自身的真实经历总结的一些技巧，希望可以帮助到刚入职的产品朋友。