如何拆解产品需求三个角度

　　今天讨论一个话题：如何拆解需求？
　　相信每一位产品同学都会遇到这样的场景，接收到一个需求，而需求本身是一个结论或者一个方案，对于这个正确的结论或者方案，产品经理处于极度被动而且信息失衡的状态。
　　举一个我经历过的真实案例，既当做是总结复盘，也同时给大家分享一下由此延伸出来的本篇主题：如何拆解需求？
　　OK，我们先看案例。具体业务和项目背景我就不做介绍了，大概描述一下需求框架。
　　我接收到的需求是这样的：在xxx业务里，我要做一个xxx的微信小程序。到此，需求描述就结束了。
　　对于这个需求，产品经理得到的有效信息会非常的贫乏。为什么我要对这个需求打引号呢，因为这称不上是一个有效需求，而是一个结论性方案。
　　当然，从句式表达上来看，这确实是一个诉求，我要这种句式表达的就是一种诉求。
　　但本着为用户负责以及优化资源配置的角度来看，这个结论性的方案真的能解决它背后的问题吗？
　　那什么是结论性方案背后的问题呢？其实就是这个需求对应的场景，一个方案一定是为了解决某一个问题而存在。如果我们进一步把场景这个词细化，能从如下三个角度去拆解一个需求。
　　需求受益人；
　　问题触发节点；
　　迫切程度。
　　从以上三个角度，我们分别定义了需求受益人、问题触发节点、需求迫切程度，这三个角度分别对应了人、问题、优先级。几乎所有的需求都可以从以上三个角度来拆解，接下来分别做进一步研习。
　　1。需求受益人
　　前文有提到，每一个需求都有其对应的场景，提到场景，人是第一要素。如果需求是为了解决一个问题，那首要回答的是，我们解决的是谁的问题。也就是说，如果需求转化成产品方案，经过研发上线变成产品功能，这个功能的受益人是谁？
　　很多时候，我们看似做了很多正确的需求，上线了很多产品功能，结果发现最后压根没人用。其核心原因就是需求受益人不清晰。
　　需求受益人不清晰的原因要么是主观设想，要么是为了方案而方案。前者简单说就是YY，通俗说就是有一种冷叫你妈觉得你冷。后者简单说就是做设计做功能，通俗说就是沉迷在完成任务后的成就感里。
　　找到需求受益人，去感受他们的问题。
　　需求受益人有可能在内部，例如一个批量操作的功能可能会让运营人员的效率直线提升。需求受益人也有可能在外部，例如一个随机播放音乐的功能能解放那些选择困难或者没有选择的人。
　　拆解需求第一步，找到需求受益人。这些人在哪？是否真实存在？如果存在，需求对应的方案是否能让他们产生感知并且能给他们带去价值？
　　找到产品的真实用户，加几个用户的微信，当你需要判断一些需求时，或者需要做一些产品决策时，带上问题和他们聊聊。另外，把自己变成产品用户，场景化的感受一下用户所需。
　　我现在做的一个toB的项目，加了一个重度核心用户，当面对需求方的一些新想法时，我都会和这个核心用户聊一聊，确认他是不是这个需求受益人。过程中，会得到很多的有价值信息输入。
　　如果一个需求讨论开始，我们都无法定义出需求受益人是谁，那很大程度上就是一个看似正确的伪需求。
　　2。问题触发节点
　　对于产品经理而言，要用问题眼光来看待需求，而不要用结论眼光，这两种视角会有非常大的区别。
　　先说结论眼光，很多时候，我们的需求方或者用户提过来的大部分都是一些结论性方案。例如要开发一个什么功能，或者要修改现有的逻辑。
　　此时，如果产品经理不加拆解判断就接受的话，很有可能做了一个正确但无用方案。
　　而这种损害就是一个连锁效应，接收结论、制定方案、产品设计、技术研发、产品上线，牵动的都是一系列资源的投入。
　　好不容易上线了，发现现实情况和当初的设想差距过大，然后再经过方案调整、产品设计、技术研发、产品上线。
　　这么来看，产品经理如果不扮演好守门员的角色，对公司资源的消耗就会非常严重，最终，也无法带来用户价值。
　　接下来，我们再说问题眼光，产品经理以探究问题的角度去拆解需求，也就是说，对应需求所解决的问题是在哪个环节节点？我们制定的产品方案是在什么节点对之前有了提升性的补充？
　　这时候，需求会转变成问题。面对需求方，不要跟我说你想做什么，而是告诉我你遇到了什么问题，而且是在什么时候在完成什么动作时遇到了这个问题。这就是问题出发节点，也是需求的原始起点。
　　找到这个点，才是真正解决问题的开始。很多时候，需求方自己是明白有问题的，基于自己的理解加工后，都会习惯性的得出结论性方案，然后把方案本身当成了需求。
　　找到问题触发节点，探究原始问题，才能get到真正要解决的问题是什么。以免陷入争论和解决一个看似正确的错误问题。
　　3。迫切程度
　　迫切程度对应了需求的优先级，优先级不是单一维度的考量，而是综合多方因素整体衡量。可以通过重要紧急四象限去划分优先级。
　　涉及到需求迫切程度，直接决定的是资源的分配，包括设计资源、研发资源、运营资源。在明确需求受益人和问题触发节点之后，迫切程度的判断就是需求拆解的最后一个环节。
　　提供几个判断需求迫切程度的考虑点，首先是对应需求是否处于关键业务路径上。
　　例如电商业务中，从商品浏览到下单支付的核心路径上，期间的每个节点都是关键节点。如果对应需求是落在这些节点上，都是可以优先考虑解决的，也就是可以提上相对靠前优先级的。
　　另外，对于一些关键性的Bug，例如阻碍用户完成关键业务路径的一些问题，是需要立刻马上解决的。除此之外，对于新特性、优化项或者补充性功能，都可以作为次要优先级在后期迭代。
　　最后
　　上述提供了如何拆解一个需求的三个角度，面对一个需求，分别从需求受益人、问题触发节点、迫切程度来进行分析。可能认知有限而略显片面，从我自己的认知里，这三个考量点基本能覆盖我经历过的一些需求。希望对你有用，也欢迎你留言来说一说，你是如何拆解一个需求的。