需求的管理一般分三部分：
一、交付需求
产品经理本身不能对产品方案进行实施，需要协调研发、测试、设计等工作人员来共同完成产品需求，这个时候我们就需要将自己梳理的产品需求，传达给我们需要协调的这些人，这个过程就是交付需求的过程，一般分下面两个步骤：
1、提交需求
提交需求一般包含以下内容：
结构图（信息结构图，功能结构图）
流程图（业务流程图、功能流程图）
产品原型（低保真、高保真）
产品需求文档（PRD）
2、评审需求
在提交了产品需求后，需要组织开发、运营、设计、测试等相关人员对产品需求进行评审，在评审过程中，对产品的目标、背景、问题、思路、解决方案等进行介绍、评审的目的一个是为了让产品更完善，具有可行性；另一个目的，也是让所有参与人员认可并评审通过的产品需求才能被开发，评审是产品工作中非常重要的环节，如果这部分工作做不好，开发过程中的摩擦和改需求的可能性非常大。
二、制定需求实施计划
需求评审通过后，就可以开始实施了，在实施前需要和具体的执行人一起来确定开发计划，一般包含以下几种情况：
1、和开发确定开发计划，主要包含：
谁来做？
什么时候开始做？
什么时候开发完成？
什么时候提交提测试？
什么时候测试版上线？
什么时候正式版上线？
2、和设计人员确定UI设计计划，主要包含：
谁来设计？
什么时候开始设计？
什么时候出主风格？
什么时候完成设计？
3、和运营人员确定运营计划，主要包含：
谁来运营？
什么时候开始运营？
运营计划和资源准备？
这里面要特别注意下面几点：
1、明确干系人，每一项需求的实现工作都需要具体到某个人。不能似是而非，否则最后出了问题都找不到人；
2、明确工作中的关键时间节点。比如开发什么时候开始，什么时候测试，什么时候上线等问题；
3、在计划中要考虑风险因素，和执行成员事先商量好规避风险的办法。比如在计划安排上考虑后面需求变更、人员变更、技术实现困难等因素，在排期上时间安排的宽松一点，这样有意外情况发生时也有时间来调整。另外在执行过程中，可以和团队小伙伴商量使用每天10分钟站立会的方式对执行过程的工作内容进行把控，让每个人讲下前一天的工作进展和今天的工作安排，有没有延期或者有没有什么自己解决不了的问题，然后再讲一下今天的工作计划，有没有什么困难需要帮助，通过对每一天工作内容和进度的把控来保证产品需求能被按照计划来实现，这个方法在很多互联网公司使用。
三、管理变更需求
在需求评审完成后，产品会进行封板，需求池也会冻结。不论什么需求，都不会加到这个版本里面了，原则上是不能再改变需求了，但是有时候因为一些客观因素，需求变更又是不可避免的。比如市场环境的变化，之前考虑不周，功能被遗忘，技术实现比预估的困难等因素，所以管理产品需求变更也是产品需求管理的一项重要工作。
1、分析需求
需求变更常见的类型有三种：新增，删除和更改，当产生了新的需求的时候，首先我们使用之前讲的需求分析的方法，从痛点→用户→需求→产品需求→评审，这样一个流程来对需求进行分析，确认需求的价值，看看这个需求是真实需求还是伪需求，只有靠谱的需求才有变更的必要和讨论的意义，这里要防止拍脑袋变更需求，拍脑袋一两次是可以的，经常随意改变需求，自己的信誉会下降，而且能力也会被同事质疑。
2、分析变更的可行性
要不要变更需求，可以从以下三个方面来评估
考虑变更需求对用户使用的影响
考虑需求变更带来的成本因素
考虑市场的机会成本
3、变更需求
变更的需求被评估，确定要进行需求变更后，就可以执行需求变更了，这时候需要做两方面的工作：
第一部分是自己独立完成的工作，需要对变更后需求的产品流程、功能、原型、文档等进行相应调整；
第二部分是协调其他参与人，及时把需求变动告知相关人员，让其对工作作出相应的调整。
做完以上两个工作，需求变更才算真正完成。
内容摘自《人人都是产品经理》
