【365成长联盟】BAT优秀的互联网人每天都在学什么？如何坚持学习与提升？戳此查看大咖成长之路
本文长度为3300字，建议阅读7分钟
产品的构思初期，我们会罗列尽可能多需求，也会收集到很多需求。但有些需求是伪需求，有些需求也不具备实现价值，那我们如何做好判断并管理好这些需求呢？
作者 / 木木
来源 / 公众号 大白学堂（ID:dabaixuetang）
本文主要分为两部分，一部分是与用户需求相关的内容，见下图所示：
需求往往来源于痛点，当我们发现了一个痛点后，通过用户研究的方法，发现了痛点背后庞大的市场；市场很大，而我们能力有限，这时候我们就要找到自己能解决的哪一部分，并了解这部分用户的需求，这个过程就是定义用户需求的过程，在这个过程中我们要弄清楚这里的用户角色，使用场景，用户的问题，这三个方面综合起来也就是我们常说的用户需求，在这里要注意，痛点，市场需求和用户需求并不是同一个东西。
另一部分是与产品需求相关的内容，见下图：
当我们弄清楚了用户需求后，就需要提供一个产品解决方案来解决用户的需求，在提供解决方案的时候，我们不能只考虑用户需求，还需要考虑战略的需求，老板的需求，产品运营的需求，业务人员的需求，竞争的需求，作为产品经理自己本身的价值观需求等，基于这些需求，我们来构建产品，在这个产品方案里面会有很多产品的功能，这个功能就是我们常说的产品需求。
当我们确认了产品需求后，产品就从需求阶段进入到了实施阶段，接下来就是这篇文章的主题，怎么管理产品的需求，我们分三部分来讲：
交付需求
制定需求实施计划
控制需求变更
产品经理本身不能对产品方案进行实施，需要协调研发，测试，设计等工作人员来共同完成产品需求，这个时候我们就需要将自己梳理的产品需求，传达给我们需要协调的这些人，这个过程就是交付需求的过程，一般分下面两个步骤：
第一步：提交需求
提交需求就是把产品需求完整清晰的告知给需要协作的小伙伴，让他们清楚的了解产品的需求， 一般通过以下三个交付物来告知：
【1】产品流程图
产品流程图是说明产品操作和相应过程的文档，一般有两类：
一类是业务流程图，基于业务逻辑来设计，一般包含主要流程和功能模块，用来说明产品的架构；
另一类是功能流程图，一般基于用户任务来设计，包含人物角色，操作过程的关键节点，状态，判断，结果等，可以参考下面两个简单的小例子（只是为了说明问题，不代表真实流程）：
【2】产品原型
上面的流程图主要偏重于对产品后端和逻辑的描述，而产品原型的作用正好与流程图互补，偏重于对产品界面信息架构，跳转逻辑和交互功能的展示说明，通过产品原型，可以将抽象的产品具体化，让产品更容易被理解，产品原型一般由线框图构成，在业界大部分人使用axure来制作，有的公司有交互设计师，原型制作工作由交互设计师来承担，大部分互联网公司是没有交互设计师的，所以产品原型一般由产品经理来完成，一般长下面这样:
【3】产品需求文档
产品需求文档，英文Product Requirement Document，简称prd, 主要以文字形式来阐述产品的详细需求，与流程图，产品原型配合使用来说明产品需求，核心内容是对要实现的每个产品功能及里面用户角色、前置条件、后置条件、界面、流程，数据统计等内容的描述，主要面向研发人员，使用word来撰写和阅读。
以上这三种交付物是产品经理协作过程中比较常见的交付物，尤其是在大公司中这些是必备的。但这不是强制的标准，很多中小公司都没有产品文档这个部分，有的直接用产品原型标注文字说明来做文档，有的是用excell来写文档，所以具体的交付物根据自己所处公司的实际要求来看，这些交付物的目的是为了辅助沟通，不管什么样的交付物，只要能达到简单，快速，高效沟通的目的就可以。
第二步. 评审需求
在提交了产品需求后，需要组织研发，运营，设计，测试等人员对产品需求评审，在评审过程中，对产品的目标，背景，问题，思路，解决方案等进行介绍，评审的目的一个是为了让产品更完善，更具有可行性，另一个目的，也是让所有参与实施的人员对产品需求认可，目标达成一致，只有被所有参与人员认可并评审通过的产品需求才能被开发，评审是产品工作中非常重要的环节，如果这部分工作做不好，开发过程中的摩擦和修改需求的概率非常大。
需求评审通过后，就可以开始实施了，在实施前需要和具体的执行人一起来确定执行计划，一般包含下面几种情况
1.和研发确定开发计划，主要包含：
谁来做？
什么时候开始做？
什么时候完成？
什么时候测试？
什么时候测试版上线？
什么时候正式版上线？
2.和设计人员确定UI设计计划，主要包含：
谁来设计？
什么时候开始设计？
什么时候出主风格？
什么时候完成设计？
3.和运营人员确定运营计划，主要包含：
谁来运营？
什么时候开始试运营？
运营计划和资源准备？
在这里面特别要注意下面三点：
第一：明确干系人，每一项需求的实现工作都要具体到某个人，不能似是而非，否则最后出了问题都找不到人；
第二：明确工作中的关键时间节点，比如研发什么时候开始，什么时候测试，什么时候结束等问题；
第三：在计划中要考虑风险因素，和执行成员事先商量好规避的办法，比如在计划安排上考虑到后面需求变更，人员变更，技术实现困难等因素，在排期上时间安排的宽松一点，这样有意外情况发生也有时间来调整。
在需求评审完成后，产品会进行封版，需求池也会冻结，不论什么需求，都不会加在这个版本里面了，原则上是不能再改变需求了，但是有时候因为一些客观因素，需求变更又是不可避免的，比如市场环境的变化，之前考虑不周，功能被遗忘，技术实现比预估的困难等因素，所以管理产品需求变更也是产品需求管理一项重要的工作，下面来说说怎么管理需求变更；
1. 分析需求
需求变更常见的类型有三种，新增，删除和更改，当产生了新的需求的时候，首先我们使用之前讲的需求分析的方法，从痛点－用户需求－产品需求－到评审这样一个流程来对需求进行分析，确认需求的价值，看看这个需求是真需求还是伪需求，只有靠谱的需求才有变更的必要和讨论的意义，在这里要防止拍脑袋变更需求，拍脑袋一两次是可以的，经常随意改变需求，自己的信誉会下降，而且能力也会被同事质疑。
2. 分析变更的可行性
变更需求通常意味着要调整资源、重新分配任务，并修改前期的工作成果，有时要付出较大的代价，如果动不动就变更需求，项目也许永远不能按时完成，要不要变更需求，我们可以从以下三个方面来评估：
第一.考虑变更需求对用户使用的影响：
产品最终是要推向市场面向用户的，要不要改，首先得考虑对用户使用的影响，如果一个需求属于无差异型需求，有没有对用户使用都没有影响，那这样的需求就没必要存在，更没必要变更，如果一个需求属于基础型需求，比如社交网站没有用户上传头像功能，这对社交网站来说是功能的缺陷，没有头像，用户体验不到社交的氛围，这样的需求就得考虑变更。
第二.考虑需求变更带来的成本因素：
需求变更意味着在计划外要做很多工作，额外的工作就需要额外的投入，如果本来2个月可以完成的开发的产品，需求变更后，变成了3个月，就多了一个月的人力，物力，财力的投入，不论是大公司还是小公司，每个项目都有预算，如果因为需求变更导致预算超支，即使产品开发完成也得不偿失，所以在评估需求是否要变更的时候，要考虑变更带来的成本大小。
第三.考虑市场的机会成本：
大多数需求变更都会影响产品的上线时间，产品上线时间直接决定了后面投入市场运营，推广的时间，如果错过了某个有利的时间窗口期，产品是完善了，但是同样丧失了市场推广的有利机会，这样也是不可取的，所以在考虑变更需求的时候，也要考虑市场因素，不能单纯的看功能。
3. 变更需求
变更的需求被评估，确定要进行需求变更后，就可以执行需求变更了，这时候需要做两方面的工作：
第一部分是自己独立完成的工作，需要进行需求变更后的产品流程，功能，原型，文档制作和变更工作。
第二部分是协调其它参与人，及时把需求变动告知相关人员，让其对工作做出对应的调整。
做完以上两个工作，需求变更才算真正完成。
你在管理产品需求时都遇到过哪些问题呢？欢迎在下方留言区一起探讨~
联系客服
