需求管理的工作包括：1. 需求收集；2.需求分析；3.功能设计；4.变更需求；5.开发上线。其中，需求收集可以拆分成两个部分：一是从哪收集需求，二是如何管理收集来的需求。
一、需求管理的工作
名列前茅阶段：需求收集
需求收集可以拆分成两个部分：一是从哪收集需求？二是如何管理收集来的需求？
如何收集需求？
需求的来源一般是从以下几个渠道来的：
渠道一：公司内部
(1）公司老板
作为产品经理，如果是在创业公司，那么老板提的需求也可能占据需求总量的一小部分；部分老板，可能不能很好的遵守需求的流程，但需求优先级又很高，如果遇到这种情况，一要先和上级沟通，让上级知悉此事并请求建议，二要弄清楚老板提这个需求的目的，挖掘老板更多的决策信息，让需求更顺利、更准确的推进下去。
(2）运营人员
运营人员是公司中最直接接触用户的一批人，接触频率高，很多时候，运营人员能提供很多用户的反馈，需求。
另一方面，运营也是需求的产生者，运营活动会产生一系列的相关需求，比如因节假日、周年庆活动等而提出来的需求，因为运营一般是背有KPI的，所以运营也会提出关于数据统计相关的需求，借此来帮助他们总结运营的成果。
(3）技术人员
技术人员能够站在技术角度提出一些你从来没想过的问题，思考问题的角度不同，有时候也能提出一些独到的见解。愿意提需求的技术说明他真的在思考产品，反而可以促进产品经理进一步思考产品的迭代方向。
渠道二：用户反馈
(1）内部渠道
比如用户的投诉、电话录音、客服的相关咨询、产品自带的用户反馈入口等。
(2）公开渠道
比如App Store、微博、应用市场（豌豆荚、应用宝等）、知乎、贴吧等论坛、qq用户群、反馈邮箱等。
渠道三：用户调研
(1）用户访谈
用户访谈的三个关键，一是确定【访谈目的】、二是确定【访谈目标用户】，三是确定【访谈问题】；这三个关键确定下来后，还需要制定一份详细的访谈计划，来支撑产品经理顺利完成整个访谈流程。
(2）可用性测试
可用性测试是指一群具有代表性的用户在一定场景下对产品进行典型操作，观察员对用户操作过程、操作习惯进行观察、记录，发现用户在使用产品时的需求、偏好、痛点、路径、习惯等，了解产品存在的问题，达到改善产品的目的。
(3）问卷调查
问卷调查是通过调查问卷，了解用户需求的一种方式；问卷调查必须先弄明白调查主题、问卷目标用户、以及想要从用户那边获取什么信息，确定好这3个点，就可以进一步设计问卷的具体问题和提问形式了。
(4）数据分析
数据分析是通过对相关数据的收集、分析、提取有用信息并形成结论，对产品需求、功能以及趋势进行判断的一种方式。
渠道四：竞品分析
(1）竞品分析是需求挖掘的方法之一；竞品分析的概念就是研究同类产品，从中找出竞品的优劣势，从而发现产品的突破口，将产品做到【人无我有，人有我优，人优我精】。
渠道五：头脑风暴
(1）头脑风暴是一种氛围比较轻松的讨论形式，产品、运营、UI、技术都可以参与。风暴会议可以围绕一个核心问题，自由发挥发表观点，不评论对错，不过要做好会议控制，避免漫无边际的讨论。
如何管理收集来的需求？答案是：建立需求池
有些朋友可能会问：为什么要建立需求池啊？需求池又是啥意思呢？
不着急，我们接下来就给大家讲下需求池的概念和作用。
需求池是什么？真实面目长啥样呢？
需求池的概念：需求池是需求的集中地，集合了最初原始的需求信息，以便日后进行需求过滤、需求调研。需求池的需求通常包括功能改进类需求、体验提升类需求、BUG修复类需求、新增功能类需求等需求池以“宽进严出”的理念进行管理，目的就是不遗漏任何有价值的需求点；它的真实面目是这样的（请看下图）：
第二阶段：需求分析
需求分析可以拆分成四个部分：了解需求背景、明确需求目标、过滤不当需求、确定大致方案。
了解需求背景
这一环节主要完成的就是对业务场景、问题场景、用户群体、当前相关产品功能的摸底和确认，旨在复原原业务场景、明确用户要解决什么问题，以及找到用户需求与现有功能体系的联系。
（1）该需求发生的业务场景是什么，这些业务活动是为了实现什么目的。
（2）在业务场景中用户遇到了什么困难，当前是如何解决的，期望通过该需求怎么怎么解决这些困难。
（3）该需求还与哪些系统或模块相关，它们的运行逻辑是什么样的。
（4）该需求可能还有哪些用户会用到，会对他们有哪些影响，他们的期望会有哪些。
（5）业务模式是否已经成熟稳定，预计未来何时可能会发生调整。
明确需求目标
通过需求背景的调研，对需求的目标有了一定的预知，那么接下来就要明确需求的目标，即明确该需求究竟要干什么？并将需求目标具体化到可测量的维度上，可使用5W2H规则：
需要的功能是什么（What）
为什么要有这个功能（Why)
功能的用户是谁（Who)
用户在什么时候使用（When)
在哪个模块使用（Where)
怎么使用（How）
使用频次如何（How Much
过滤不当需求
科学地过滤需求既有利于产品体系的良性发展，也体现了整个团队的工作价值。最简单的过滤需求的方式，主要是判断需求是否有价值，是否合理，以及优先级排序。
（1）确定需求是否有价值：做了该需求能解决多少劳动力、增加多大收益、挽回多大损失；不做该需求有多大损失，是否影响业务。
在考虑需求价值时候，可以从四个维度考虑：
· 广度：该需求的受众面有多大？
· 频率：该需求的使用频率是以日/周/月为周期？
· 强度：该需求对用户有多强烈需要？
· 时机：该需求是否符合产品的规划？当下的环境？
（2）确定需求的合理性：需求的合理性包括需求的定位是否合理、需求的实现是否合理2个方面；
需求定位：比如需求在本系统中是否恰当、权限开放出来是否合适、是否泄漏了公司的机密。
需求实现：比如技术的投入产出比是否合适使用第三方的应用成本是否更低，当前公司人员是否足以支撑该需求的实现。
（3）通过优先级辅助过滤需求：使用KANO模型，排出需求优先级，优先级低的需求可以考虑暂时过滤掉。
确定大致方案
在调研需求时，虽然还没有开始进行方案设计，但是基本的方案轮廓已经在产品经理的头脑中形成，因此产品经理可以和开发人员交互意见，大概描述出方案的轮廓，咨询其可行性。同时和需求方沟通方案的可接受性。当然在最终的方案输出之后，要正式与需求方确认具体的细节。
第三阶段：功能设计
根据第二阶段和需求方确认大致的方案（也就是所有的产品功能点），输出相关的产品流程图、产品架构图、原型图、PRD需求文档，用于交付研发人员，并进入开发阶段。
第四阶段：需求变更
名列前茅：为什么会出现变更？
因为很多时候，需求方无法说出自己所有的需求，或者负责该需求的产品经理没有挖掘出需求方的所有需求，所以当时需求方确定的方案，也很有可能出现请求变更的情况，遇到这种情况，作为产品经理，也应该从容的去处理这个需求的变更流程。
第二：如何处理需求变更？
变更管理的核心在于评估需求变更的价值，那么决定做不做以及是否在当前版本做，我们可以从这几个方面来考虑：
假设我们处在产品转型的新旧交叉时期（简单说就是一方面要维护原有功能，另一方面更需探索设计新的功能），因此这个时期的需求变更可以划分成四个维度：原有核心功能，原有周边功能，新功能核心功能，新功能周边功能；
那么这个时期的需求变更重要程度应该为：新功能核心功能变更>原有核心功能变更>版本上线时间>新功能周边功能变更>原有周边功能变更。
执行变更的步骤：
· 需求方提出变更（通常以发起流程的形式，提交至需求跟进人及产品领导人）
· 需求跟进人通知开发，开发同学评估变更工作量，双方共同决定是否在当前版本实现变更，如果意见不能一致，需要提交可以负责的干系人审批决定；
· 审批通过的需求进入研发；变更审批驳回的需求进入需求池，在池子里重排优先级。
第五阶段：开发上线
产品设计工作完成后，将进入研发测试阶段直至产品上线，接下来就是要从各渠道收集用户反馈或进行数据分析，为下一个版本迭代寻找目标。
二、根据需求优先级做版本规划
做版本规划的目的是让所有需求都有一个结果。是放到这个版本，还是下一个版本。还是下下个版本。一般我会按季度来规划版本。如果一个季度还排不上的话，就会告知跟需求相关的人员（一般是需求的提出者、受影响的同事），这个需求短时间内不做。同样，如果未来计划版本的需求有变动，也要及时告知跟需求相关的人员。
注意事项：在做版本规划的时候，因为未来还会有很多临时需求，所以不要在一个版本里排期太满。尤其是那些P3，P4的需求。同时，在回复需求提出者的时候，不要给一个明确的时间，应该是一个模糊的日期。比如，下个月或者下下个月。
以上就是关于需求管理有哪些工作的内容希望对大家有帮助。
