如何评估需求的可行性

　　当一个需求出现的时候，如何评估做不做？本文作者对这个问题进行了分析梳理，从2个大方向对这个问题总结了自己的看法，与大家分享。
　　作为一个产品人员，接收需求已经成为家常便饭，无论是来自老板老板、运营、用户或者同行建议，经常可能遇到的问题是：这么多的需求，我到底做不做？什么时候做？今天，借着最近许久没提笔总结，来和大家一起讨论，也希望评论中能够有指正和补充。
　　作为大家熟知的重要紧急四象限，不知道被多少人说烂了。但是，问题就在于，你要如何去填充这个四象限？
　　从个人的一个从业经历中，结合日常接触的业务，总结了这么几个方向去拓展细分：
　　一、这个需求类属于bug或是类属于新功能？
　　如果，这个需求类属于bug，一般情况下需要去分析：
　　这个bug是否影响产品的业务主流程？这类型的bug属于救火型，一刻不得耽搁。
　　这个bug影响的用户基数有多少？这个取决于你这个产品的体量。如果是百万用户，影响一两百个无关痛痒；如果是刚起步的，这个 就即为致命了，不改=等死。
　　bug是否影响到特定人人群？如果你的产品比较特殊，比如是一款游戏，bug对99.9%的用户没有影响，可就是让那么一小部分的氪金大佬难受了，那就麻溜的抱着程序员大腿去改吧！毕竟，这些是真正的衣食父母。
　　BUG型需求，一般考虑这三个要素就可以了，而非BUG型需求吗，可能就比较复杂了，我们继续讨论
　　二、新功能类别的需求要如何处理？
　　对于新功能的一个评估，个别参数和BUG的有所类同，也不用着急，我们来一个个的探讨。
　　1. 这个需求面向的用户在产品中扮演的角色是什么？【B TO C】
　　举个比较好玩的例子B TO C TO C，也就是常见的如美团外卖。产品涉及到商家、用户、以及外卖员。外卖员送外卖经常会遇到延迟被投诉的情况，从而导致差评或者罚款。
　　但是，有很多时候，外卖延迟送达可能是因为商家做的慢了，交通堵塞了等客观因素。
　　如果你作为外卖平台的产品经理，收到外卖员给你提的需求：增加一个申诉提交功能，需要可以拍照，用来证明延迟送达外卖不是我的问题，要取消部分差评和罚款。
　　这个时候，这个需求对外卖员是合理的，真实的。但是，作为平台的产品，基于国情，你大概是不能做的。
　　企业都是为了赚钱，他们不会去考虑外卖员的营收如何，他们会在意c端用户舒不舒服，他们也会在意b端商家会不会因为一次延迟送达失去一位c端用户，但是他们真的很难在意外卖员舒不舒服。为什么呢？因为外卖员这个角色，真的太多了，随时可以替换。
　　这也是为什么，我要说，当一个需求出来，我们需要分析需求面向的用户，扮演的角色是什么？如果是产品在意的用户，那这种需求可以考虑。否则，请慎重。
　　2. 继续衍生上一个问题，在常见的TO C产品中，我们要考虑的就是这个需求面向的用户基数如何？以及这部分用户是否为核心用户
　　大多数的TO C产品，很少回去区分核心用户（上面提过的游戏类的除外）。一般是去区分，这个功能面对的用户基数如何。
　　比如，微信要和QQ一样增加一个偏向低领用户的功能。可能，在微信中就不会太实用。毕竟现在微信成人的基数和使用频率更高。
　　3. 这个功能上线后，是否会大家都喜欢，是有隐患？
　　可能，你接受到一个需求，这个需求覆盖了95%的用户，那么我们需要慎重的是：这些功能是否大家都喜欢？
　　继续举例，你作为一个饿了么产品经理，你收到一个用户留言：能不能增加一个定时下单功能，这样我们就可以提前几天把一周额的外卖都定好了。
　　你一看，哎呦，不错啊！这个想法看着很牛逼，于是呢，快马加鞭的就把功能上线了。那么，让我们一起来看看，你可能会遇到哪些问题？
　　针对C端用户，你满足了这个人的需求，那么，存在的隐患有哪些呢？
　　首先是红包机制，一次下五单，减免的金额和五单分开下单的减免金额是一样的，用不了几次用户会发现，你这是在坑我的红包啊？
　　再说个人喜好，我在三天前，下单今天中午要吃肯德基，那么会出现什么情况呢？
　　可能我今天不想吃了，但是我忘记我预定了，当外卖送到，如何处理；可能我今天和朋友约了出去吃饭，但是我忘记预定了，当外卖送到，如何处理；可能今天我上火了，我吃不了炸的，当外卖送到，如何处理；
　　以及更多诸如此类的问题。
　　针对B端用户，隐患又有哪些呢？
　　再说商家可能存在的隐患：一些小作坊，可能突然就不干了，可能突然就停业休息一天。那么，这时候，下单这些商家的用户要怎么维护？他们的损失有谁来弥补？
　　这么联动下去，是不是还得需要增加一套的考核标准，押金体系等等？
　　再回过头来说说对产品本身的影响
　　日活：可能每天打开两次，现在一周打开一次
　　转化：可能一些金主投放的广告，曝光率瞬间就下降了几倍，那这部分的损失完全就不可估量了。
　　所以呢，接收一个需求的时候，一定要考虑好这个需求中的隐患有哪些，切勿被用户牵着鼻子走
　　4. 辨别用户的需求是否只是一个用户期望的解决方案
　　这个也是一个老生常谈的话题，一个最耳熟能详的例子：古人对驿站说，我想要一匹跑得快的马！
　　这个就是典型的，用户把解决方案当需求的案例。在这个案例中，用户的需求其实是：我想要更快的交通工具。在互联网中，这种案例也是很多，也希望大家互相提醒，避免踩坑。
　　5. 回归最根本，必须考虑的一个问题：新功能上线的成本
　　成本这东西，简单来说：需要多少人，需要多少钱，需要多少时间。相信，很多的产品经理，这部分都能考虑的很周到，在基于公司当前项目安排的情况下，都能处理好。
　　至于其他更多的方方面面，其实就没必要细究了。能够掌控好以上的几点，其实也就差不多够用了。