蜗牛派接需求，是产品经理最常见的工作职责了。无论是业务方提需求、领导下达任务、还是需求评审，总会有很多需求扑面而来。比如要加个功能，或者改个流程…
但是，并非所有需求都经过了深思熟虑，考虑周全。也有些需求，做完了没有任何价值。
那么，你怎么判断这个需求是值得做的？不至于被一些无脑需求牵着鼻子走呢？
拍脑袋，比职级，做实验？
有没有一些系统的判断依据、方法论？
当然有。
一般来说，可以从这四块分析：找出用户和场景，看性价比分析收益，评估方案合理性，最后定优先级和排期。
下面详细说。
一、找出用户和场景
理解需求，第一要务是理解用户和场景，理解谁想解决什么问题。
脱离了这一点，需求极易走偏。
举个例子，一个数据平台产品。领导某天突然提了个想法，觉得现在分析师做了很多报表，但是好多用户没有开通查看权限，不知道这些报表的存在，所以这些报表没有充分用起来。
希望增加一个报表检索和预览的功能，让用户能预览这些报表有哪些字段，然后决定是否申请看数权限。
听起来很make sense。
因为用户不知道有哪些报表，所以需要通过预览去了解，然后申请权限。你看，有用户，有场景，看起来解决了一个真实的问题。
如果你不假所思的去做了，可能不一定达成所愿。
为什么？
如果你再仔细想想，这个需求里的用户和场景是你想的那样吗？
用户和场景，说的是真正存在痛点的人。
在这个需求里，真正存在痛点的，是领导和数据分析师。而不是用户。
真正的需求和场景是，他们做了很多报表，但是不知道如何让用户使用起来。他们希望用户能更好的利用这些报表，让他们有更多价值贡献。
如果你按照之前的逻辑去做，你就会做一个报表预览和权限申请功能。
而用户却不见得买单。
用户看不看得懂这个预览功能，还是其次。更重要的是，一个普通用户能清晰分辨自己需要什么数据吗？他自己会隔三差五的去搜索看看有没有新增看板吗？他自己会不怕麻烦的发邮件申请权限吗？
显然，他们没有这个诉求。
用户不关心你有多少报表，不理解为什么要预览，不希望申请权限。
他们的诉求，是希望看到更多有用的报表，更方便的使用报表，更简单的开启权限。
更好的方案，可能是把报表直接分配给需要的用户，并且增加“new”等字样提示，或者发消息通知，附带报表字段说明，让用户更容易理解，更方便使用，更愉快的接受。
这种情况下，用户和分析师之间才能取得一个良性共赢。
所以你看，用户和场景的不同，会带来完全不同的推导逻辑。
用户和场景，就像是需求的方向。他们一旦出现偏差了，后面的努力就容易白费功夫。
二、分析性价比
理解了用户和场景后，就需要具体分析这个需求的投入产出了。
我们做项目，当然是期望用最低的成本，实现最大的价值，这样才能收益最大化。
相反，如果做的事情非常难，最后收效甚微，谁都会担心自己这么做是否值得。
所以，性价比是我们首先要考虑的事情。
性价比包括价值和成本，我们先说价值。
评估价值，有几个简单的办法：
- 看影响面大不大：正常来说，一个人的个性化需求，显然是没有一群人的共性需求来得有价值。一个用户的产品功能出现了BUG，不必着急。但是如果所有用户，都遇到了BUG，那么就得赶紧处理下了。此外，使用频率也有类似的效果，简单来说，高频需求，就比低频需求更值得投入。
- 看影响程度深不深：同样是BUG，一个是让用户无法付款的BUG，另一个是让用户启动APP的时候多等待了2秒钟。显然是前一个的影响程度更深，更值得做。同样的，如果一个功能的上线，能帮每个用户每天节约1分钟，那就不如另外一个能帮用户节约半小时的产品功能有价值。
- 看有没有附加价值：可能某些功能，只有少数人用，并且对他的帮助也有限。但如果这个用户是你的上级领导，那么好好做这个功能，就具备了附加价值。你好好表现，领导也许看在眼里，将来给你升职加薪。否则，如果你不重视，那么领导将来有可能对你不待见。
有了价值，再看成本。
最好的项目，往往都是那些价值高，但成本相对较低的内容。
如果帮每个用户每天节约半小时的那个功能，需要重构整个系统，整体完成要半年，而节约1分钟的那个功能，只需要1小时，那显然节约一分钟的那个功能性价比更高，短期产生的收益会更明显。
当你需要用巨大的成本，换取微小的收益时。这个需求就不再值得做了。
常见的成本问题，还有开发资源不足、当前技术架构不支持、预算不够等等…
除了时间和金钱成本以外，还有一类潜在成本，是风险带来的。
当我们做的事情，有巨大的风险时，此时项目的性价比也会调低。
比如你爬取了其他媒体有独家版权的视频素材，然后在自家平台上播放。这样即便成本很低，将来也有被告上法庭的风险，一夜回到解放前。因此，这种潜在风险也需要考虑到成本里。
如果经过我们的分析之后，我们判断需求的性价比很高，很值得做。这个时候就进入了下一步，方案评估。
三、评估产品方案
对产品来说，业务方一般都习惯带着方案找过来。
但由于业务方的视角具有局限性，这些方案通常都不是一个好的全局解决方案，反而更像是一个吐槽建议。
产品经理的价值，就体现在对这些需求进行评估和转化上。
一般来说，有这么几个部分需要评估：
- 方案是否最简单最有效
- 方案是否带来负面体验
- 方案是否足够有扩展性
1.方案是否最简单有效
一些方案你听起来很绕、很复杂，最终的效果却差不多，这种时候，很可能是方案不够简单高效。
举个例子，当你希望禁止用户填写某个表单时，你可以把表单里的每一个控件都做成不可编辑，或者提交的时候在后端做校验，不允许保存。
看起来方案很完善，但是成本也不低。
或者你也可以简单直白的把表单填写的入口按钮置灰了，这样的方案就远比前面几种简洁。
2.方案是否带来负面体验
拿前面数据平台的案例来说，如果我们强行给用户加了一个预览功能，把相关的不相关的报表都给用户展现出来，这个时候用户的报表就会特别多，甚至因此找不到自己原来常看的报表了，用户也会因此懵圈吐槽。这就是带来了明显的负面体验。
一般来说，负面体验在可接受范围内，都是可以的。但如果过于难用，就需要想别的方案替代。借用俞军的公式来说，产品价值=(新体验-旧体验)-换用成本。
我们需要确保新功能的价值，要远大于用户付出的代价。
3.方案是否足够有扩展性
有时候我们做项目图简单快捷，喜欢把文案、数据都写死了，或者把页面交互框架、数据层级结构定死了。那么等到未来再想改的时候，几乎是不可能的。
对于一些持续迭代维护的产品而言，还需要考虑长远，留出一定的扩展性。
对产品经理来说，提前考虑未来版本的可能走向，提前将这些信息告诉下游开发，这样未来才能愉快的和技术交流迭代。
甚至对一些通用组件，要提前考虑解耦的事情。比如搭建通用的SDK、前后端分离开发、模块组件化等等。这样未来的维护成本会低很多。
四、确定优先级和排期
经过前面的分析，我们就明白了需求的方向、价值、方案，剩下的就是排期实现了。
这个时候，主要工作就是跟相关同事同步信息，协调资源和时间，让他们开始落地实现。
性价比的分析，会告诉我们需求的优先级，用于权衡不同需求之间的先后关系。
有了这个先后关系和对应原因，我们就能够妥善回复业务方大致排期了。至于具体的完成时间，一般都是需求评审后才能知晓。
实现阶段主要难在资源协调和项目管理，项目负责人要确保大家认可这个事情的价值和目的，并且对齐各方的认知，让大家对具体方案有明确统一的认识。
对于项目里每个任务要拆分足够细，单独评估工时。确保大家每周过进度，解决遗留问题等等…
当然，这也是项目管理领域的知识范畴。
