每天5分钟，你也可以成为优秀的产品经理。你好，我是郭杉。欢迎来到 《郭杉 产品经理50讲》第31讲
相信经过前面四讲的学习，相信大家对需求分析有了一定的了解。
今天是我们《产品经理50讲》第5期的答疑讲座，我总结了大家近期关于产品需求管理这个话题提问最多的四个问题，给大家进行统一的解答。
这四个问题分别是
1.我们为什么需要对需求进行管理？
2.项目进行过程中，需求突然发生变化怎么办？
3.需求优先级排序为什么需要那么多的维度的评估？
4.需求评审会有哪些注意要点？
第一个问题是关于：我们为什么需要对需求进行管理？
我的回答是：在产品经理的日常工作中，每天都要面对来自四面八方的大量需求。即便身处BAT（百度、腾讯、阿里）这样的头部互联网公司，由于受限于研发团队自身资源和精力分配的问题，项目可用资源不足的问题也依然是常态。
换句话说，谁也没没有办法做到“有求必应”，一下把所有的需求全都实现了。
所以，我们必须要对需求的优先级进行评估，找到性价比高的需求优先设计开发。
也就是说，我们只有做好需求管理，对需求的重要性进行辨别，合理安排需求的优先级，才不会把产品方向给“带偏”了。
否则，我们不但浪费公司大量的研发资源,而且极容易错过产品研发的最佳时机，丢掉产品市场和用户。
因此，我们必须做好需求管理，合理利用公司资源，优先选择性价比高的需求进行研发。这样，我们就能在每一次对产品的迭代改进之中，不断完善产品功能，提升产品的竞争力。
第二个问题是关于：项目进行过程中，需求突然发生变化怎么办？
我的回答是：这个问题很常见。我们需要使用“需求变更5步法”来控制需求的变更。
第一步：根据团队的实际工作流程，制定出对应的需求变更流程与规范。确定好需求变更的“标准流程”和“特殊流程”（针对特殊情况的需求变更流程）。
第二步：当需求发生变更时，需要组织相关人员，对变更的需求进行分析、评估与评审。明确变更的范围、变更的影响以及变更完成的时间节点。（是在当前迭代周期内完成变更，还是将变更移至后续迭代版本中完成）。
第三步：确定好变更后的团队各成员职责，做好需求变更后续跟进工作。
第四步：创建好需求变更控制文档，将需求变更的时间、变更的版本、变更提出人、变更的原因、变更前后的需求描述，逐一记录在需求变更文档上，便于后续对变更进行回溯与查找，避免因为没有需求变更记录导致的产品管理混乱。
第五步：当变更发生后，我们还需要向团队成员发送一封需求变更邮件。并在邮件正文中附上需求变更文档的详细内容，注明变更涉及到的相关人员，便于后续团队成员之间的沟通与协作。
第三个问题是关于：需求优先级排序为什么需要那么多的维度？
我的回答是：这个多维的需求优先级排序方法是我在工作中不断总结积累出来的。期初，我也只用重要紧急度一种排序方法，但后来我发现，这种方式仅仅只是从一个方面来评估了需求的优先级，无法对需求优先级进行全面的评估。
于是，在多年的工作中我不断完善自己的需求优先级评估模型，逐步迭代完善这个方法，你们讲座里听到的就是已经非常全面、系统的优先级评估法了。
其实，在认知学中有个著名的“多元认知理论”。讲的是我们要想深入的认知某一事务，需要从不同的角度多元化的去展开，认知的角度越多，认知的也就越充分。回头想想，我的方法的迭代过程也是逐步认知一个事务的过程。
第四个问题是关于：需求评审会都有哪些注意事项？
我的回答是：要想开好需求评审会，我们需要掌握如下四大注意事项：
注意事项1：不要把自己的想法强行灌输给其他参会人员
首先，我们需要明确一点，召开需求评审会的目的不是为了把我们自己的想法强行灌输给其他参会人员，而是通过对需求的“评审”与“讨论”，最终形成大家都认可的产品方案。
在我经历过的需求评审会中，总会发现有些产品经理抱着“强行灌输想法”和“一定要说服参会人员”的态度进行需求评审。在会上，绞尽脑汁的试图把自己的“想法”强行灌输给其他参会人。结果会议各方为了说服对方，自然会找出以往项目中一些比较极端的案例来支撑自己的观点。结果整个需求评审会偏离了主题，可想结果有多么的糟糕。
注意事项2：对于观点的差异，不要过于纠结，浪费时间
进行需求评审会时，我们需要本着“求同存异”态度对问题进行讨论。也就是说在大方向相同的前提下，允许在小细节上存在不同的观点。也就是产品经理要本着“开放”的心态去参加需求评审会。
另外，需求评审会本身也是帮助产品经理完善方案的一个过程，多听听别人的观点，对自己产品方案的完善会有更多的好处。只要不涉及大方向问题，对于方案存疑或不认可的部分，我们也不需要过于纠结，如果会上讨论了10分钟仍然没有结论，我们就需要先记下这个问题，先进行后面内容的评审，会议的最后再掉头回来讨论之前的争议问题或把问题放在会后单独进行讨论。千万不要在细节问题上过分浪费时间，把评审会开成了拉锯战。
注意事项3：先给所有与会者明确本次需求评审的背景及目标
产品经理在需求评审会上，需要先给所有与会者讲解这个版本的背景和目标。也就是告诉大家这个版本“要做什么”、“为什么做”、“有什么价值”这样三个问题。目的是为了让大家统一思想，帮大家统一“调频”到“同一个频道”中去。接下来的需求评审会，大家才会更专注于需求本身，会议也会更加顺畅。
我见过很多产品经理在召开需求评审会时，一上来就直奔主题，什么背景介绍都不做，就开始讲具体的功能是怎么设计的、交互流程又是什么样的。你要知道，大家对你需求的背景和目标都没有了解呢，怎么会“进到”需求的细节中呢？又怎么能发现你方案中的细节问题呢？这种需求评审又何谈对方案达成最后的一致呢？
注意事项4：现场不管发生什么情况，不可怯场红脸、不可出言不逊、不可情绪失控
在“需求评审会”的现场，由于参会双方的意见不一致，难免会遇到争论和各种意外情况。作为产品经理，不管在评审会上发生了什么事情，都要时刻谨记以大局为重，在需求评审会上各方达成对方案的共识，才是需求评审会的核心目的。不管自己的什么观点，都要冷静客观的表达出来，千万不要因为没控制好自己的情绪，在表述观点时加上了自己的主观色彩，说出的话里带有一股浓重的“火药味”，导致双方更进一步的争吵，这样就事情变得更加复杂，也达不到需求评审会召开之初的目的了。
怎么样，关于产品经理入门的问题你是不是都搞懂了呢？
好了，以上就是本讲的全部内容了。
如果觉得这一讲的内容不错，记得给我点个赞。
下一讲，我们一起聊聊“如何画好产品业务流程图”这个话题。记得准时观看哦！
好的，本讲的内容到这里就全部结束了。我是产品专家郭杉，我们下一讲见。
