需求，是产品经理工作中接触最广泛的词。不管是来自用户还是老板，产品经理总会收到各种各样的需求。
产品经理需要在接到需求时辨别真伪、在迭代时排列需求优先级、在开发时处理需求变更、在上线后分析需求效果给出反馈。在这一系列过程中，都需要产品经理做好需求管理工作。
这是针对需求管理的系列文章，共计五篇。
这是第二篇。
需求已经从各种角色、渠道汇总给了产品经理，那谁的需求是第一优先级呢？
自己的需求是第一优先级。
不管是用户、老板、客户，还是同事的需求，归根结底都是对产品的需求。
所有的需求都需要经过产品经理的过滤，成为自己的需求。一味的听命执行，是对产品不负责任的表现，也不利于自己的成长。
过滤需求的过程，是产品经理重新思考的过程。重新思考需求是否合理、对目标是否影响、影响是好是坏、影响程度大小。过滤之后，需求都将被消化，变成产品经理自己的需求。
紧接着就是三个要做的事情：
- 需求判断：需求做不做
- 版本计划：需求的优先级和版本计划
- 信息同步：将进展同步给需求方
01 需求判断
主要判断需求做不做。
有以下三点的需求绝对不做：
涉及底线的需求不做。产品经理要坚守底线，对产品和用户负责，也对自己负责。比如同事说用户就是用来打扰的，就是要强推提高点击率。这个时候就需要产品经理在坚守底线（不打扰用户）的情况下，寻找其他可行的方案。
对产品价值有影响的需求不做。这类需求对价值有显性或隐性的影响。比如当年淘宝发现有很多商品来源是百度搜索，这个时候该强化搜索路径给自己导流吗？答案是否定的。淘宝立即封闭了搜索渠道，只能通过平台搜索到商品。因为淘宝的价值就是流量，一旦流量被别人控制，就只能任人摆布了。
短期阵痛，但长期无价值的需求不做。这类需求可能是为了应对当前问题临时提出的。比如双十一，一台快递分拣机不够用，是不是要再买一台？肯定不买。一年一次的需求应当考虑非产品的手段解决，比如去大学招一些临时工就解决了。
当需求确定做之后，就要确定时间排期。这就是版本。
02 版本计划
小步快跑，快速迭代。注定了一个产品版本不能做太多需求。
快速迭代不是无谓的迭代，而是每个版本都有要验证的目标和期望结果。影响版本目标实现的需求，是第一优先级的需求，需要在第一时间做的需求。
除了目标需求外，还要一大类是优化需求。关乎用户体验和流畅性，是让产品好用的需求。
在需求的优先级排序上，经验是：影响目标大 ＞ 影响目标小＝优化体验大＞优化体验小。
对体验的影响大小，我们可以从影响的用户范围、影响的程度、复现频率和严重性几个方面来判断，基本不用严谨的数据分析，只靠主观感觉就能判断，而且基本都是准确的。
但对目标的影响大小如何判断呢？如果通过主观来判断，就太武断。目标需求是产品的核心需求，如果对影响大小判断失误，那浪费的不仅仅是开发资源，更是宝贵的时间。天下产品，唯快不破。
我们可以预估需求上线后的数据表现来判断。预估数据做有依据的猜测，通过对相似功能、行业数据、历史数据、竞品情况等多方面综合评估。预估数据需要多加练习和经验技巧。后面针对预估数据我会再写一篇文章来详细讲讲。
确定需求的优先级后，我们就可以按照版本的节奏安排开工。剩下的就是将计划同步给各需求方了。
03 信息同步
如果需求安排上了，信息很好同步，大家其乐融融。关键是需求没安排上，产品经理该怎么办。如何优雅的拖一个需求呢？
从两个方面寻找突破口。
判断对方的急迫程度。如果对方不着急，那就比较容易同步了。但对方若着急，产品经理秉着负责的态度，就需要配合对方积极寻找替代方案，在需求未上线的时间内，怎样解决面临的问题。记住对方的核心是解决问题，不是需求上线。
判断对方的重视程度。对方不重视的需求，也好处理。给出较长的时间排期，对方也会接受。但若是对方比较重视的需求，就需要再从时间的角度考虑。重要且紧急的需求，理应放在版本开发中。但若没放进去，也需要耐心说明有其他更为重要的事情要做，希望对方理解，同时积极的寻找当前的解决方案。
在同步前，尽量已经想好可执行的替代方案。这样沟通起来就更加容易了。
综上，产品经理要海纳百川，将需求过滤化为己用。然后根据版本目标来合理安排需求优先级，管控版本节奏。
