产品经理必备：高效需求管理技能全面解析！

处理需求是每一位产品经理都需要面对的基础工作，如何安排好各个需求的排期？怎样合理安排工作？本文作者将结合自身工作经验和相关理论，为你讲解需求管理是什么，以及如何进行有效的需求管理，希望对你有帮助。

作为一名B2B产品经理，我的岗位主要职责之一就是需求管理。在我每天的工作中，我面临的主要挑战在于需要同时支持内部多个业务线，并为外部客户提供高度个性化的定制服务。这意味着，我的需求管理工作需要应对各种复杂场景，如内外部需求的平衡、多个业务线的协调以及多个开发团队的协作。

在本文中，我将结合自身工作经验和相关理论，为你讲解需求管理是什么，以及如何进行有效的需求管理。无论您是一名产品经理，还是对需求管理感兴趣的读者，我相信这篇文章会对您的工作和学习有所帮助。

一、需求管理是什么

首先，需要明确一个观点：需求管理并不仅仅是简单地管理需求优先级。真正的需求管理是涉及需求的整个生命周期，其中包含需求产生、需求分析、需求优先级、需求开发与测试、需求验证、需求结项以上六个方面。因此，只有同时关注以上六个方面，才能算得上真正全面的需求管理，也只有这样才能确保需求管理的有效性。

接下来，我们从上述六个方面出发，为您逐层进行分析和阐述需求管理的实现途径。请您仔细阅读每个方面的内容，以全面提高您对需求管理方案的认识和理解。

二、需求产生

2.1 需求来源

B2B产品经理的需求来源渠道众多，主要渠道有：业务部门、外部客户、研发、产品、运营、运维、老板等等。

上述渠道产生需求大致原因如下：

• 业务部门：制定业务目标时，当发现产品功能无法支持业务目标实现，则会产生需求。
• 外部客户：新的业务合作或已合作业务进行优化时，则会产生需求。
• 研发部门：技术升级或技术架构调整，当需要产品经理配合时，则会产生需求。
• 产品部门：产品经理自驱进行产品功能建设或重构时，则会产生需求。
• 运营、运维部门：日常运营和运维时发现用户使用问题或可优化功能时，则会产生需求。
• 老板：参加某些论坛或高层交流等情况时，则会产生需求。

2.2 需求产生过程

接下来，以需求产生最多的渠道且最典型的“业务部门“为例，深入剖析需求产生的的底层逻辑。

首先，业务目标是需求的起点。业务为了自身发展，制定业务目标。业务为了完成目标，就会制定相应的业务策略，即行动路径，以达成目标。但这期间可能会发现，现有系统能力不支持业务的策略，不能支持达成目标，就会产生业务痛点。

业务痛点是代表在完成业务目标时，在行动过程中遇到了问题或障碍。但是在业务中，不同的人对痛点的认知和理解是存在差别的，高层管理者更清楚自己的业务痛点以及对目标的影响程度，而基层员工对痛点的理解更多停留在操作层面和自我层面。因此，业务痛点和业务目标关联性越强，越容易得到重视，也最容易产生业务需要。而对业务目标影响不大的痛点、业务可以忍受的痛点、甚至业务自己都不知道的业务痛点，反而极少产生业务需要。

业务需要是源于业务痛点的一种感觉缺失的状态，业务为了满足自己的需要，就会寻找解决方案。如果发现这个业务需要可通过内部流程优化、人工处理等方式暂时解决，那么就不会产生业务需求，只有当业务内部无法解决时，需要依靠外部（产品经理）解决时，才会产生业务需求。

综上，这个由“业务目标→业务策略→业务痛点→业务需要→业务需求”的转化过程，是产生需求的底层逻辑。

产生业务需求（MRD）需三个条件：

• 系统现状不满足业务策略或计划。
• 业务认为痛点必须当下解决。
• 自己无法解决，只能寻找产品解决。

由此及彼，其它渠道也遵循上述需求产生的底层逻辑，读者可以把上述图片中“业务”替换为“其它渠道目标”进行理解。如：外部客户因某个业务增长目标，产生新的需求；研发因为某个降本增效的研发目标，产生新的需求；运营部门因为某个体验运营目标，产生新的需求等等。

三、需求分析

产品经理承接来自各渠道的需求，并且投入大量精力实现业务需求。但是，却经常出现需求中途废止、上线后不符合业务诉求、未取得预期结果等问题。虽然造成以上问题的原因很复杂，但其中一个最关键的因素就是产品经理错误地分析了业务需求。

需求分析是什么？需求分析是：通过分析需求产生过程，识别真正的需求并排除虚假的需求。其中，分析需求产生过程，就是分析“目标→策略→痛点→需要→需求”的过程。那么，如何进行有效的需求分析呢？接下来，我介绍两种需求分析方法，都是产品经理日常工作中常用的方法。

方法一：使用5why分析法分析需求产生过程

首先，我们从高维度进行需求分析，即对需求产生过程进行分析。从需求产生过程来看，一个业务需求的形成，到最终传达至产品经理，是需要经过漫长的流程和多重决策，信息在传递过程中必然会失真。我们可以通过5why方法，分析过程是否存在问题，以保证需求的真实可靠。

因此，产品经理在分析需求产生过程时，可以尝试问以下问题：

• 业务目标是否合理？目标是否过高或者过低？是否可量化？
• 实现业务目标的策略，是正确路径么？
• 业务痛点真实么？是高层的痛点，还是基层员工的痛点？现状无法满足么，还是他们不会操作？真的影响业务策略么？
• 业务需要是对业务痛点的真实反馈么？必须现在解决么？
• 业务需求的方案是唯一解决方案么，合理么？业务内部不能自行解决么？
• 上线后能否助力目标达成？能为目标贡献多少？投入产出比合理么？

以上罗列的问题仅抛砖引玉，建议产品经理在实践中尝试从不同角度、不同环节进行分析，锻炼需求分析的能力。

方法二：使用“场景、角色or系统、流程”分析方法

接下来，我们从细维度进行需求分析，即对需求内容进行分析。首先，使用“场景、角色、流程”方法，进行业务流程梳理，从而设计出正确、合理、可执行的业务流程。其次，使用“场景、系统、流程”方法，并结合产品架构能力，将业务流程设计成正确、合理、高效的系统流程。通过以上两个方法，可以产出业务流程图和系统流程图，是产品经理设计方案的关键内容。

案例：

业务背景：我司属于物流平台公司，面向物流市场中大客户及中小客户销售物流服务产品，为客户提供物流配送及仓储行业解决方案。因此，需要与客户签约，并进行合同单据管理，以作为合同物流凭证。

首先，通过“场景、角色、流程”梳理业务流程。从中发现大客户与中小客户合同签约流程不同，大客户流程更复杂、更长，而中小客户流程相对简化和标准。如下图：

最后，通过“场景、系统、流程”设计系统流程。（此处作者有意简述，实际业务场景、系统角色会更加复杂。且针对业务流程与系统流程如何制作，此处不再进行详述，读者可以参考BRD、PRD写作规范进行学习。产品架构能力可参考作者之前文章：https://www.woshipm.com/pd/5794522.html

四、需求优先级管理

从需求优先级的表象看，是在对需求进行排序和取舍，但其背后的实质是：协同业务、研发、测试等部门达成目标一致， 且高效、合理的利用资源，从而 保证目标达成。

产品经理作为需求优先级管理主要负责人，在协同各方目标达成一致以及进行资源分配时，面临的难点主要有以下几个方面：

其一，多部门间的目标取舍、排序问题。需求会同时来自多个渠道，会存在多个目标，如业务、产品、研发、运营等目标，对不同部门间的目标取舍、排序是很困难的。

其二，多业务线间的目标取舍、排序问题。面对不同业务线时，当不同业务线的发展阶段不同、业务规模大小不同时，对不同业务间的目标取舍、排序是很困难的。（该问题虽被第一点包含，但此处仍被提及，是因为相比多部门间的目标取舍，它更难）

其三，多目标并行时资源分配问题。需求虽有先后顺序，但实际工作中都是多需求并行。所以，如何分配资源并保障多目标都完成是很困难的。

其四，临时且紧急需求的处理问题。临时且紧急需求会对现有排序造成巨大冲击，导致需要重新排序、重新分配资源。因此，既要处理已排好需求，又要满足紧急需求是很困难的。

通过以上难点不难看出，需求优先级管理考验的就是：当产品经理面对跨业务线、跨部门 等复杂场景时的 协同沟通能力。

接下来，重点介绍两个需求优先级管理方法：定量分析法和定性分析法。首先，要先声明一点，需求优先级管理工作是十分复杂的，上述两个方法仅能起到辅助作用。若想做好需求优先级管理工作，仍需先具备优秀的协同沟通能力，再结合方法的使用才可做好。

4.1 定量分析法

优先级的评估如果仅凭个人感性判断的话，会很难让多位相关方对优先级达成一致。为了尽量避免个人喜好或偏见带来的影响，我们需要引入更科学的方法，通过综合评分打分评价法（或加权求和法）来对需求优先级进行量化。具体步骤如下：

第一步：确定标准。选取和制定优先级衡量标准时，要与其它部门充分沟通，确保衡量标准得到多方认可。

案例：以某工作单位为例，优先级衡量标准有“目标类型、需求来源、重要&紧急程度、收益类型”4个，其中，每个标准下子类目有：

目标类型：公司战略目标、业务战略目标、产品目标、迭代优化目标等。

需求来源：业务部门、外部客户、研发部门、体验部门等。

重要&紧急程度：重要紧急、重要不紧急、不重要紧急、不重要不紧急。

收益类型：业务规模增长类、效率提升类、体验提升类、创新类等。

第二步：确定打分标准。制定各标准及标准子类目分值，也要与其它部门充分沟通，并得到多方认可。

案例：仍以上述单位为例，共计4项标准，总分数为80，每个标准均为20分。其中：

• 目标类型（公司战略目标-20分、业务战略目标-15分、产品目标-10分、迭代优化目标-5分）
• 需求来源（业务部门-20分、外部客户-20分、研发部门-10分、体验部门-5分）
• 重要&紧急程度（重要紧急-20分、重要不紧急-15分、不重要紧急-10分、不重要不紧急-5分）
• 收益类型（业务规模增长类-20分、创新类-15分、效率提升类-10分、体验提升类-5分）

针对打分标准，有以下几点补充说明：

• 需求优先级管理中，“综合打分评价法”相比“加权求和法”应用的更多，因为不同标准间相关性较差，标准间不同权重与实际情况不符。如：目标类型与需求来源之间，无法制定谁的权重更高。
• 综合打分评价法的分值问题。采取各标准分值相同策略，理由同上。如：若目标类型为30分，需求来源10分，这样划分是不合理的。
• 加权求和法使用问题。常见应用于各标准之间可区分重要程度的场景下，读者可以依据实际情况采用。如：A30%+B20%+C20%+D30%=100%。

第三步：打分。针对不同需求进行打分，确定最终得分。

案例：以上述单位为例，最终打分结果如下：

针对打分，有以下几点补充说明：

• 打分的前提是：只有详细了解需求的目标、收益等信息后，才能做出客观、正确的判断。
• 打分的结果要定期回顾与评估。因为外部环境时刻都在发生变化。如：不紧急需求变成紧急需求、业务部门目标变成公司战略目标等，分值在变化。

4.2 定性分析法

需求优先级管理仅依靠定量分析法，是不能解决全部问题的。因为，定量分析法不能覆盖全部场景。所以，为使得需求优先级管理更加全面、合理、灵活，还需要使用定性分析方法。

定性分析法属于感性的判断，笔者认为定性分析法更多的是来自经验的积累，凭借“经验”进行需求优先级管理。我总结了以下经验，分享给读者：

• 开发周期短的需求，可以搭车其它相关项目或见缝插针进行开发。
• 产研需求可选择搭车业务需求，通过一个需求，达成多目标。
• 产品方案设计时，要考虑产品长期规划目标。说服业务接受更长周期但更合理的产品方案，既满足业务目标，又能达成产品长期规划目标。
• 重点关注“重要不紧急”需求，避免变成“重要紧急”需求。
• 周期较长的需求，若上线时间紧张，可采用分批次、分阶段实现。
• 老板或客户的紧急需求。首先，不要盲目执行和推进。其次，尝试与老板、客户沟通了解背景及原因等。最终可能发现是伪需求或非紧急需求。
• 资源紧张无法按期望上线时，可以尝试运营、业务线下方案临时兜底。
• 建议优先处理外部客户需求，再处理内部需求。一方面以客户为中心，避免客户投诉或流失，另一方面，内部需求属于内部矛盾，可以关起门来解决。
• 线上BUG不要进入需求池管理，而应及时解决。

五、需求开发与测试

需求进入开发测试阶段后，大部分产品经理认为无需进行需求管理工作，只需等待上线即可。其实不然，若在该阶段出现延期、开发测试质量等问题，仍会影响需求的交付。因此，在该阶段，需求管理工作仍必不可少！

接下来，分别从“需求开发”与“需求测试”详述产品经理应做哪些需求管理工作，以保证需求顺利交付。

5.1 需求开发

在需求开发阶段，产品经理要重点关注以下两点：其一，关注开发是否按计划进行，有无风险。其二，关注开发质量，保证高质量交付。

首先，关于第一点。产品经理应熟练掌握项目管理相关技能，并对需求进行常态化项目管理。例如组织产、研、测日站会、项目周会、需求进度沟通会等。通过定期与研发盘点开发进展及问题，从而提前识别风险，并及时采取措施，避免延期。

其次，关于第二点。虽然产品经理不参加开发工作，无法直接为代码质量负责，但可以通过建设合理的开发流程，以实现高质量的交付。建议：①增加“技术方案概要设计、技术方案详细设计”评审环节，且产品经理参与评审，把控技术方案符合产品诉求。②增加“代码评审”环节，架构师参与评审，把控代码质量。（Ps:如果读者公司没有以上流程，产品经理可以发起流程变革，但确实无法增加，那么只能自求多福了。）

5.2 需求测试

在需求测试阶段，产品经理要重点关注以下两点：其一，关注测试是否按计划进行，有无风险。其二，关注测试质量，保证高质量交付。

首先，关于第一点。参考上文需求开发第一点。读者可同时管控开发、测试进展及问题。

其次，关于第二点。建议：

• 增加“测试用例评审”环节，且产品经理参与评审，把控测试场景覆盖全部功能场景。
• 要求测试人员记录并反馈测试问题，并追查问题产生原因，以提升产品、研发、测试质量。
• 测试完成后，产品经理要进行线上验收。

六、需求验证

这个环节是最容易被产品经理忽略的环节。大多数产品经理认为，需求上线后就完成了自己的工作，对需求目标是否达成不太关心，并将这视为业务部门的职责。然而，这种想法往往会导致我们错失成功的机会。所以，作为产品经理，我们必须“以始为终”，始终牢记需求的初衷，在需求验证环节中确保需求目标得到充分的实现。只有这样，我们才能最终摘取成功的果实，也才能让需求管理的旅程更加完美圆满！

接下来，讲解在需求验证阶段，产品经理应该采取哪些需求管理工作。

首先，产品经理应该重点关注和参与“三个计划”的制定与执行。“三个计划”即：灰度计划、推广计划、运营计划。虽然它们从职责上是属于业务方（需求提出方）工作，但它们却是影响需求能否取得业务结果的关键因素。

产品经理应采取如下管理动作：

• 其一，灰度计划。与业务协同制定灰度目标、场景、时间等，确保灰度期间快速验证产品方案的可用性及可行性。
• 其二，推广计划。与业务协同制定推广目标、范围、时间等，确保产品方案可复制，达成业务预期目标。
• 其三，运营计划。与业务协同制定稳定、长期、高效的日常运营流程，确保产品方案持续产生稳定的业务结果。（读者尤其要注意，以上三个计划，虽有先后顺序，但尽量一起制定，避免脱节。）

其次，在制定和执行三个计划时，同时要建立业务数据指标体系。数据指标体系应包含可衡量项目过程和结果表现的指标。指标体系应是客观的、可量化的，以便更好地监测和评估项目进展以及业务成果。建议参考亚马逊：Input、Output、观测指标方法。

最后，迭代产品方案或调整计划。通过对数据指标体系的监控及分析，找出产品方案、灰度&推广&运营计划中存在的问题，分析原因并制定解决方案，及时调整计划或迭代产品方案。

七、需求结项

需求结项是需求管理旅程的最后一个环节。一般情况下，只有单独立项或较大项目才会有这个环节，其它需求在需求验证通过后就已结束。需求结项阶段的核心工作是进行需求结项文档编写，并组织结项会议，完成项目的结项。

作为产品经理，需要完成结项文档的编写及结项会议的召开。接下来，分别从“结项文档”和“结项会议”讲解产品经理如何进行需求管理。

首先，结项文档内容主要包含四个方面内容：回顾目标、评估结果、分析原因、总结规律。其中，回顾目标：主要是编写当初的目标是什么。评估结果：评估现有结果，判断是超额完成目标、符合预期目标，还是未完成目标。分析原因：分析实际结果与当初目标差异原因。总结做的好或不好的原因是什么。总结规律：通过对问题的原因分析，从中总结经验和规律，为以后工作起到指导作用。

其次，结项会议要组织相关业务、产品、研发、测试等人员参加，针对结项文档进行阅读和讨论，共同学习经验和规律，促进团队成长。

最后，关于需求结项工作，有几点需要着重关注。首先，结项文档的撰写应该客观、实事求是，不扭曲事实。其次，在讨论问题时应强调事情本身，而不是关注个人责任。第三，结项会议旨在总结经验、教训和规律，而不是追究责任或抱怨。最后，我们需要总结好的经验和规律，同时也需要总结不良经验，即我们在过程中遇到的问题和诸多挑战，进而汲取教训，防止重蹈覆辙。

八、总结

需求管理是产品经理日常工作中非常重要的一环。本文详细地讲述了如何从需求产生、需求分析、需求优先级、需求开发与测试、需求验证、需求结项六个方面实现有效的需求管理。但要更好地完成需求管理工作，读者必须不断练习和多次应用，积累经验并不断优化。愿读者通过此文的指南和建议有所进步，也欢迎各位读者留言交流经验！

九、案例分享：排期那点“破事”

这个故事是这样的，我有个业务项目，需协同其它研发团队开发。但是评审完成后，该研发团队反馈暂时没有资源开发，等待资源释放后再定。给出的理由主要有两条：

第一、相比其它业务线项目，项目收益太低，以后再做。（潜台词：项目太小，成绩不显著，不想做，要做就做大的）

第二、如果想做，那各业务线之间先协调下项目优先级。（潜台词：资源就这么多，我能怎么办？业务线自己PK去吧，谁赢了做谁的）

作为业务体量较小的产品经理，你是不是也遇到过上述场景？是不是很卑微、无助且可怜？接下来，让我告诉你，我是如何处理并解决这个问题。

针对第一个理由“相比其它业务线项目，项目收益太低，以后再做”。

首先，你要了解各业务线发展情况，以及自身业务线处在什么阶段，要做到知彼知己。结合自身业务实际，我是这样处理回复的。

第一，不同业务线的市场规模是有大小之分的，这是天生属性，进行横向收益对比是不公平的。虽然我们业务线市场规模小，但都是关键头部客户，也是公司整体重要市场之一。因此规模不是衡量收益的唯一准绳，而应看项目对业务本身发展的重要程度。

——潜台词：对不起，你的排期逻辑我不认可。如果按照你的逻辑排期，那么市场规模小的业务线项目收益永远最低，岂不永远无法排到？

第二，我们业务线产品建设阶段已经从“初期大规模建设”发展为“功能迭代优化建设”。去年已经完成大规模基础建设，现阶段就是针对上阶段进行补充和优化。该阶段项目的特点就是项目小、收益低。这是产品生命周期发展的必经阶段，预计未来会长期处于该阶段，大家需要有清晰的认知和共识。

——潜台词：要认清不同阶段，工作是不同的。这个阶段工作就是这个特点，难道这个阶段的项目都不做了么？

针对第二个理由“如果想做，那各业务线之间先协调下项目优先级”。

这个理由也是研发常使用的，往往产品经理此时也会让业务内部进行横向沟通，其实是不对的。我是这样处理回复的。

第一，各业务线仅为自身发展负责，不为其它业务线发展负责，也仅知道哪个项目对自己最重要。

——潜台词：哪个业务会舍弃自身发展，而成全其它业务线发展，不管自己的绩效了？通俗点，都是屁股决定脑袋，两个业务都觉得自己最重要，怎么办？

第二，需求管理的职责应在平台型研发部，而不在各业务。各业务线需求应单独管理，且应预估各业务线需求量，提前准备和分配研发资源。避免各业务线资源冲突，否则就会出现被业务投诉资源安排不合理、贻误业务发展等问题。

——潜台词：认清自身职责，不要甩锅，甩锅的结果就是被反噬，不如提前做好需求管理工作。

以上，就是我处理该问题的方式，你也可以结合自身情况调整策略，抓紧试下吧！当然，虽然场景是发生在产品与研发之间，你可以进行总结归纳，灵活应用到不同公司不同岗位上。

​Read More