本文目录
产品经理本身不能对产品方案进行实施，需要协调研发、测试、设计等工作人员来共同完成产品需求，这个时候我们就需要将自己梳理的产品需求，传达给我们需要协调的这些人，这个过程就是交付需求的过程，一般分下面两个步骤：
在提交了产品需求后，需要组织开发、运营、设计、测试等相关人员对产品需求进行评审，在评审过程中，对产品的目标、背景、问题、思路、解决方案等进行介绍、评审的目的一个是为了让产品更完善，具有可行性；另一个目的，也是让所有参与人员认可并评审通过的产品需求才能被开发，评审是产品工作中非常重要的环节，如果这部分工作做不好，开发过程中的摩擦和改需求的可能性非常大。
需求评审通过后，就可以开始实施了，在实施前需要和具体的执行人一起来确定开发计划，一般包含以下几种情况：
1、和开发确定开发计划，主要包含：
2、和设计人员确定UI设计计划，主要包含：
3、和运营人员确定运营计划，主要包含：
1、明确干系人，每一项需求的实现工作都需要具体到某个人。不能似是而非，否则最后出了问题都找不到人；
2、明确工作中的关键时间节点。比如开发什么时候开始，什么时候测试，什么时候上线等问题；
3、在计划中要考虑风险因素，和执行成员事先商量好规避风险的办法。比如在计划安排上考虑后面需求变更、人员变更、技术实现困难等因素，在排期上时间安排的宽松一点，这样有意外情况发生时也有时间来调整。另外在执行过程中，可以和团队小伙伴商量使用每天10分钟站立会的方式对执行过程的工作内容进行把控，让每个人讲下前一天的工作进展和今天的工作安排，有没有延期或者有没有什么自己解决不了的问题，然后再讲一下今天的工作计划，有没有什么困难需要帮助，通过对每一天工作内容和进度的把控来保证产品需求能被按照计划来实现，这个方法在很多互联网公司使用。
在需求评审完成后，产品会进行封板，需求池也会冻结。不论什么需求，都不会加到这个版本里面了，原则上是不能再改变需求了，但是有时候因为一些客观因素，需求变更又是不可避免的。比如市场环境的变化，之前考虑不周，功能被遗忘，技术实现比预估的困难等因素，所以管理产品需求变更也是产品需求管理的一项重要工作。
需求变更常见的类型有三种：新增，删除和更改，当产生了新的需求的时候，首先我们使用之前讲的需求分析的方法，从痛点→用户→需求→产品需求→评审，这样一个流程来对需求进行分析，确认需求的价值，看看这个需求是真实需求还是伪需求，只有靠谱的需求才有变更的必要和讨论的意义，这里要防止拍脑袋变更需求，拍脑袋一两次是可以的，经常随意改变需求，自己的信誉会下降，而且能力也会被同事质疑。
要不要变更需求，可以从以下三个方面来评估
变更的需求被评估，确定要进行需求变更后，就可以执行需求变更了，这时候需要做两方面的工作：
第一部分是自己独立完成的工作，需要对变更后需求的产品流程、功能、原型、文档等进行相应调整；
第二部分是协调其他参与人，及时把需求变动告知相关人员，让其对工作作出相应的调整。
做完以上两个工作，需求变更才算真正完成。
1、需求管理源于业务需要，始于需求挖掘，继而需求分析，需求定义，需求验证。周而复始。
2、一，业务需要说明需求产生的原因，可能是高层制定的目标，中层对工作流程的调整，基层碰到无法解决的问题，用户需要，外部环境变化，竞争对手策略变化或者政府政策调整等。
3、需求人员在明确业务需要时，首先明确干系人，其次获取干系人要求/需求。可以采用的方法包括：行业基准（竞品），业务规则分析（产品分析），头脑风暴，焦点小组，功能分解，根源分析等。
4、二，需求挖掘阶段的目标是找出干系人的真实需求。单方面的口头描述或者规范章程都可能与实际需求相差甚远，因此需要需求人员收集各方面需要，交叉验证，合理推导，发掘出用户的实际需求。
5、工作步骤：确认干系人，收集实际情况，整合多方面信息，确认实际需要。方法包括：访谈，观察，问卷，焦点小组，头脑风暴，可用性测试，竞品分析，数据分析，文档分析，咨询专家等。
6、三，需求分析阶段则是对已经收集的真实需求进行规整，包括两部分内容，组织整理需求和对需求排优先级。
7、组织整理需求采用相同粒度描述需求，并描述需求间关系。主要方法包括：功能分解，业务规则分析，数据模型，流程模型，范围模型，用户经历，场景和用例，组织模型。
8、需求优先级划分通过定义需求的优先级，为计划安排提供有价值的参考。可以参考的定义维度包括：时间，预算，业务价值，业务和技术风险，实施难度，成功可能性，规范和政策，与其他需求的关系，与干系人的协议，紧急程度等。可采用3/4级优先级定义，或者MoSCoW模型定义，其中M=必须 S=应该 C=能够W=将要。
9、四，需求定义主要工作为根据前期整理的相关文档整理需求说明。输出包括：业务需要，需求陈述，组织整理后的需求以及需求优先级。需求说明主要包括：业务需要，业务需求和系统需求。·
10、五，需求验证包括需求检验和需求确认，即需求过程中的检查和需求完成的测试。
11、需求跟踪矩阵是个好东西，可以在需求分析阶段产出。
1.确定需求变更控制过程。制定一个选择，分析和决策需求变更的过程，所有的需求变更都应遵循这个过程。
2.进行需求变更影响分析。评估每项需求变更，以确定它对项目计划安排和其他需求的影响，明确与变更相关的任务，并评估完成这些任务所需要的工作量。这些分析将有助于需求变更控制部门做出更好的决策。
3.建立需求基准版本和需求控制版本文档。确定需求基准，这是项目各方对需求达成共识时的一个快照，之后的需求变更遵循变更控制过程即可。每个版本的需求规格说明都是独立说明，以避免将底稿和基准或新旧版本相混淆。
4.维护需求变更的历史记录，将需求变更情况写成文档，记录变更日期，原因，负责人，版本号等内容，及时通知到项目开发所涉及的人员，为了尽量减少困难，冲突，误传，应指定专人来负责更新需求。
5.跟踪每项需求的状态。可以把每一项需求的状态属性（如建议的，已通过的，已实施的或已验证的等）保存在数据库中，这样可以在任何时候得到每个状态类的需求数量。
6.衡量需求稳定性。可以定期把需求变更（添加，修改，删除）数量和原始需求数量进行比较，过多的需求变更是一个报警信号，如果需求蟀达到50%，则意味着项目的基本需求并未真正弄清楚，这个项目应该取消。
1、大多产品经理都是从管理需求的工作做起，负责产品的定义，并检验研发出的产品是否符合最初的产品定义。这要求产品经理培养自己一定的需求管理能力。一般来说，产品需求管理包含以下工作内容：
2、1）需求收集，包括被动和主动的需求收集，其中主动的需求收集要求掌握需求收集的途径和方法，产品创意需要统一纳入到需求收集的范围；
3、2）需求分析，通过需求分析的层级模型，透彻地分析需求背后的用户问题和痛点，用户的需求场景，必要时还需要通过一些简单的原型确保准确地理解用户需求；
4、3）需求分发，不是所有需求都要纳入到下一个产品版本，成熟的需求管理团队能够发现高价值的中长期需求，在需求分发环节将其纳入到产品规划；
5、4）需求实现，该阶段的责任主体是产品开发团队，产品经理需要确保产品开发的各个阶段没有偏离自己的产品概念；
6、5）需求验证，包括产品经理对产品的验证，还包括产品经理主导的用户验证。
7、总的来说，产品需求管理能力培养的目标是发现价值需求，形成能够获得市场成功的产品概念，以指引产品研发团队顺利研发出让用户满意的产品。
