十年老产品经理教你管理需求池

                                                需求是一切产品设计开发的前提，做好需求管理才能更好的把控产品品质，实现产品价值。

所有的产品都是解决用户问题的工具，解决问题也是产品存在的唯一价值。
问题是客观存在的，产品经理就是根据企业的战略目标，找到目标用户，分析挖掘他们遇到的问题，提出解决问题的方案，整理成需求，设计成产品推向市场。
一、需求来源
一个产品的需求来源是多种多样的，有的需求靠谱，有的需求不靠谱，需要我们自己学会收集，整理，挖掘。
1. 战略规划
战略规划的需求往往来自于公司老板的想法。很多老板会把一些机缘巧合、经验积累，甚至可能是一拍大腿而来的想法拿来和你交流。首先要恭喜你，老板还是很重视你的，在这家公司你能有很大的发挥空间；同时会有更大的苦难等着你。
老板，尤其是创业公司的老板很多是不懂产品、不懂互联网的。但是他们往往都会听到很多互联网的名词，并且以为自己很懂。这样的结果就是老板的很多想法不能直接变成产品，还会对产品提出一些似是而非的需求。这个时候就要靠产品经理的气场、思维、口才来hold住老板。更关键的是你需要知道老板真正想要什么，想要打什么市场，消费者是谁，钱怎么赚。老板有一项能力一定比你强，就是他的信息接触面。只有你真正知道老板在想什么，要干什么之后，你才能用自己的专业技能为他提出更好的解决方案。
2. 竞品分析
最容易听到的初级产品经理说的一句话就是“我们这个产品是创新的，没有竞争对手”。这句话直接反映了产品经理的格局不够高、视野不够广。
产品是依赖于问题而存在的，几乎所有的问题都是长期存在的，也就是说几乎所有的问题都有现成的解决方法。这些现成的解决方法就是你的竞品。不管这个解决方法有多么low，多么原始，多么和互联网不沾边，你多么瞧不上。但我们在做竞品分析时一定要认真考虑我们的产品和现有的这么多解决方法相比，优势到底在什么地方。这就是竞品分析！
大多数产品经理做的竞品分析只是停留在互联网的区域，这是竞品分析的一个重要部分。但如果你的眼光只是局限在某一个领域，也就很难做出真正伟大的产品。
以后，你如果再觉得自己的产品没有竞争对手的时候，不妨把思路放开后再想想。
3. 运营反馈
产品经理梳理需求后交给开发团队，这是对信息的过滤和加工，降低开发的成本，作为开发团队的最后一道重要防线，帮助开发团队挡子弹。
运营的小伙伴直接面对形形色色的客户，遇到各种各样的问题。他们理应将需求梳理后交给产品经理，作为产品、开发团队的第一道防线，挡掉一部分子弹。但大部分情况，运营不仅不会帮你挡子弹，反而会多补上几枪。这就需要产品经理自己来过滤、整理运营的反馈了。
4. 用户反馈
好的产品经理除了对用户要有理性的数据分析、功能的埋点统计之外，也会找机会直接与用户沟通，获得对用户的感性认识。产品经理是介于理性和感性之间的一种动物。拿到用户反馈后，一定需要分析这些反馈是个性化的，还是普遍性的，这个用户是在我用户池中的哪一组。
用户反馈的不一定是真实的想法，产品经理需要做的第一步仍然是还原最真实的问题，再想出解决方式（需求）。
5. 市场调研
市场调研分为两种，宏观市场调研和消费者调研。宏观市场调研一般通过网上查找相关资料后整理分析；消费者调研是针对个体潜在用户进行交流，获得真实的问题反馈。
通过宏观与微观的调研相结合，能让你对自己的产品所处的生态环境有一个更加全面的了解。
二、需求优先级
拿到所有的需求后，我们需要对需求进行统一管理。需求池就是所有需求的集散地。需求池里面要包括需求的简单描述、需求来源、需求提交的时间、需求提交人。下面就是一个比较完整的需求池：

将需求整理好后，下一步就是最重要的判断需求优先级。
最简单粗暴的方法就是：老板需求 > 我的需求 > 其他人的需求。
这也是很多初学者容易犯的毛病。
一般来说，产品的功能分为三个类别：核心需求、基本需求、扩展需求。
[ol]

核心需求：解决用户问题的最小功能集合。最好只解决一个问题。

基本需求：为了让功能正常使用的流程性需求，比如：登录、注册、后台管理等。

扩展需求：为了用户能有更好的体验而设计的一些小的功能点。
[/ol]
按照需求的分类，结合当前产品推广的方案，自然我们的需求优先级就能定出来了。

三、需求开发流程
1. scrum
关于scrum的详细介绍大家可以在网上找到非常详细的资料，这里就不再多说。scrum的核心是迭代，一般一个迭代周期是一周或者两周。
需求池里面会逐步积累大量的需求，但绝不可能把所有的需求都一次性交给开发团队。这就需要我们在每次的迭代周期前从需求池里面选择适量的需求进入开发过程。
选择的依据一个是前面我们定的优先级、另外就是开发成本，一些不重要，但开发成本较低的需求可以提前塞到这次的迭代中。

2. 需求锁定
当需求进入开发过程后，原则上不允许给开发团队增加另外的需求。也就是说在一个迭代周期内的需求是被锁定的。这种处理方式能最大化提升开发的效率。让开发团队有足够的时间优化代码架构。
3. 特殊需求-bug
Bug在产品上线之前是由测试团队进行测试，开发团队修复。但当bug是在产品上线运营后才被我们或者用户发现，这类bug是需要列入需求池的。紧急的bug可以临时发布版本，一般不是特别紧急的bug会按照普通需求的处理流程来走。

四、版本管理
版本号是迭代开发的标志。很多创业团队开发的产品是没有版本号的概念的，开发的流程也一定混乱。目前有一些通用的版本号规则：
1. 版本号规则
一般版本号为：9.3.6，3.2.0这种格式。

第一位是主版本号：用于产品有重大更新的时候递增，如最近发布的iOS 10。
第二位是次版本号：用于产品新增部分功能、模块，但没有大范围的修改时递增。
第三位是修订版本号：用于产品修复bug，新增小的功能时使用。
第四位是build号：一般用于开发过程管理，不面向普通用户。
2. 版本库
产品的版本库是至关重要的路标，它会反应出来我们之前走过什么路，今后要走什么路。结合运营的指标，我们更是能够分析产品升级给我们的用户量、市场占有率带来是什么样的影响。

需求池、版本库、开发过程管理，是产品经理日常工作的重要组成部分。随后我们会逐步为大家介绍产品经理工作中要注意的一些关键环节，希望能与大家一起进步、成长。