面向BUG，聊聊需求优先级的判定方法

　　本文给大家介绍一个作者常用的优先级界定方法，作者把他理解成判断优先级的三个阶段性方法，分别对应不同阶段的产品人，不同重要性的需求。一起来看看
　　功能越多，BUG越多，互联网是个缺少耐心的市场，往往上一个版本的BUG还未完全修复，就已经奔波在下一个版本的需求开发上，最终的结果便是产品的功能以极快的速度增长，而BUG的增长速度甚至比功能的增长速度还要更快，是以功能越多，BUG越多。
　　这也导致有一些BUG可以存续数年的时间，有的BUG在功能下架之前都未能修复，这就是真实的产品迭代路，并不是我们想象当中那般完美。
　　有时追求完美，强调质量产品人，或许显得并不是那么正确。
　　人人的经典BUG，第一次关注到这个BUG是在三年前，我刚开始写文章的时候，实际上，这个BUG的存续时间或许远超3年，在我写文章之前，他可能就已经存在了。
　　连续两篇相同的文章，除此之外，还有神奇的“1”参数值，也存续了许久，至今任未修复。
　　即便是以底线，克制著称的微信，也存在类似的寿命极长的BUG，这里就不列举出来了。
　　换个视角，BUG也是需求
　　以前有朋友问我，产品经理是否需要对BUG进行决策，BUG是否修复是否由产品经理说的算。严格意义上来讲，这并不是绝对性的问题，我只能告诉他，产品经理拥有解决BUG的能力，也拥有对BUG进行决策的决策权，但决策权并不等于你一定要这么做，这也的决策权只是一种补充，又或者是特殊情况的特殊处理方式。
　　因为BUG，也是需求的一种，我们可以将对某个BUG的处理，列入需求清单，只需要转变一下我们看待BUG的视角，将BUG的现象定义为“当前正确”，将BUG的修复处理定义为“优化方案”。
　　当我们将内容重复出现理解为过去正确的需求时，我们便可以提出优化的需求，比如我们认为重复出现的设计并不是很好，因此将这里的产品设计方案进行了优化调整，这样一来，BUG就成为了需求。
　　实际上，大部分BUG，都可以站在需求的视角进行处理。
　　某种意义上，产品和测试在面对开发时，有一些相同的成分存在，我们都能向研发提出技术性需求，只是这种需求的表现形式发生了变化，内容也不太一样。
　　产品经理提出的需求是定义式的需求，我们定义要做什么，而测试提出的是纠正性需求，对错误的实现方式，按照产品经理的定义进行纠正，前者是后者的标准，后者是前者的边界补充。
　　一旦将边界放宽，BUG成为了正确的输出结果时，我们便可以对输出结果进行重定义，按照需求迭代的思路，将其优化调整为我们期望的结果，BUG也就不再是BUG，而是变成了产品的输出需求。
　　是需求，就具备需求优先级
　　如果我们将BUG转变成产品需求，也就具备了需求优先级的特点。我们要做的，其实就是需求优先级的界定；我们要做的，其实从未改变，未增加，也未减少。
　　需求优先级，对于产品人而言并不陌生，但掌握到精髓其实还是很难，多数情况，我们的优先级都是由领导决策，大概只有你成长为负责人以后，在无数的坑里自行领悟出优先级的判定方法。
　　我相信，大部分产品人的成长环境并不理想，也许你的leader都无法告知你准确的优先级判定方法，也许你正确的判。，在某些环境里，会被视为错误的，尽管结果上来讲证明了你是正确的，也没有意义。
　　这是由团队环境决定的事物，所以如果你的团队里，存在一位产品人，能有清晰的判断思路，或者你的leader向你展现了一些专业手段。那么我建议你紧密跟随，努力学习，即使收入低一点也没关系，这些成熟的方法会让我们少走很多弯路，并且这也的leader是可遇不可求的。
　　请倾听一下，埋怨leader，埋怨环境的产品人心声，太多的产品人渴望一位leader而不可得了。
　　这里给大家介绍一个我常用的优先级界定方法，我把他理解成判断优先级的三个阶段性方法，分别对应不同阶段的产品人，不同重要性的需求。
　　这三个阶段性方法，分别是影响面积判定，性价比判定，以及目标匹配度判定。
　　1。影响面积判定
　　这是最基础的一个判断方法，也是初期产品经理可以掌握的一个方法，他主要是面向功能性的需求进行优先级判定。
　　我将其定义为：影响面积大的优先于影响面积小的，影响面积极小的滞后观察，影响面积极大的最优先处理。
　　大小的判定是相对概念的判定，并不是说影响100万用户，就是影响面积大，放到微信数亿用户的体量里，这100万用户也是影响面积极小的一个存在。
　　与影响面积类似的判断方法还有严重度。
　　严重度大小判定：阻塞性业务优先于概率性错误，而概率性错误优先于使用体验。
　　影响面积的判定，又或者是严重度大小的判定，均是针对功能的实现覆盖面积的角度来判断，对应的也是处于功能产品阶段的产品人，此时我们更关注的是功能结果。
　　我将产品人的发展阶段宽泛的定义为三个阶段，从初往高，分别对应功能阶段的产品经理，设计阶段的产品经理以及需求阶段的产品经理，每个阶段的跨度大概都是23年的时间。
　　2。性价比判定
　　性价比判定对应的是设计阶段的产品经理，如果说影响面积是考虑的功能收益，影响越大，功能收益越大，那么性价比判定就是在收益的基础上，增加了成本因素，将收益和成本进行综合考虑的一种判定方式。
　　有的需求，能够有极大的覆盖面积，但却需要付出极大的成本，这其实是不太推荐的，成本越高，风险也就越高，除非我们能找到一种低成本的实施方案，或许会让效果有一些折扣，但却是必要的。
　　性价比的判定，通常会引入多种成本维度，包括开发成本，运营成本，商业成本，资源成本等多个维度的成本进行综合考虑。
　　最开始，我们或许只能考虑到开发成本，这得益于我们从业的前两年时间，让我们对功能的实施成本有了大致的经验预判，而其他环节的成本也是我们和对应团队的合作经验得到，在缺少经验时，往往需要多次沟通，多次交流，才能让我们的判断稍微准确一些。
　　作为一个综合电商平台而言，我们考虑增加一个自动秒杀模块。
　　自动秒杀的设计，将会随机从平台的商品里生成秒杀队列，这可以减少商户的运作成本，他们基本不用运营维护，每天都会生成秒杀专区。
　　除此之外还会给予到秒杀商品大图展示，如果能为每一款商品定制秒杀的专属配图，这对消费者会产生极大的吸引力，因为这些商品展示的大图，都能带上很吸引人的信息。
　　然而这个功能却需要所有的商户参与进来，每个商户都需要对每个商品增加一张秒杀的活动配图，这些配图并不是每时每刻都在被使用，实际上相同周期里，大部分的图片素材都是不会被使用的。
　　相对这个需求的价值而言，所需要付出的成本也是极大的，尽管这是一个很好的idea，但他依然不会进入到开发排期，除非我们有一些特殊的设计，能将成本降低下来。
　　我们在产品生涯的第二个阶段，设计阶段，会更多的考虑成本，价值衡量这样的度量维度，产品于我们而言，不应该是有和无的关系，还会增加一层类似分数值的概念，满分100分的设定里，我们也会越来越倾向于高分的方案。
　　3。目标匹配度判定
　　当你成长为更专业的产品经理时，你会发现我们不仅仅不会修复一些BUG，甚至对于一些性价比高的事情也不会去做，即使他的成本并不高，即使他能为我们带来可观的数据，我们也会因为目标不匹配而放弃掉这个方案。
　　目标匹配度判定对应的是第三阶段的产品人，我们开始深入思考需求，而这里的关键点在于匹配。
　　产品是一个较长周期持续存在的事物，每个阶段都有不同的诉求，根据市场环境，根据公司策略等等许多因素，我们会得到某一个周期的核心目标，此时，我们的需求和决策都会围绕目标展开。
　　你一定知道百度近期的一个事件，根据百度官方公告：由于系统维护原因，百度贴吧2017年以前的帖子将会无法访问，修复事件将会另行通知。
　　随后，微信在短时间内无法修改头像和昵称，各个内容平台都无法分享内容至微信。
　　背后的原因是国家净网行动的实施，而在这个时间点里，大家达成一致的目标均是围绕内容处理展开，有的是清除历史数据，有的是禁止外部不可控的数据进入。
　　相对于这个目标而言，其他事情的优先级都需要降低，否则，你可能赢了结果，输了官司。
　　如果说影响面积判定，让我们认识到了收益，而性价比判定让我们认识到了成本，那么第三阶段的目标匹配度判定则是会让我们认识到“正确性”。
　　坚持做正确的事情，提出这款产品应该提出的需求，往他应该发展的方向去发展，是我们对正确性诠释之一，同时也是中高端职场核心之一。
　　我们身处职场，对于产品经理而言，什么是职场呢？职场就是信息不透明，信息不对等的重灾区，当上级做了决策，当公司决定了发展策略，定下了阶段性目标时，其实没有人会完整的告诉你为什么这么做，有些事情，背后的信息，并不是我们产品人所能接受的。
　　朋友告诉了我这样一个故事，老板委托他做了一个功能，这个功能看上去与产品格格不入，并且对活跃，转化都没有什么帮助，唯一的作用就是一种理财的尝试。他十分不能理解，直到最后偶然得知，当时公司的现状几乎接近资金断裂，需要一笔资金作为周转。如果不是这样一个功能，可能当月就会面临发不出工资的问题，尽管拥有成熟且健康的现金流。
　　在这样一个信息不对称，信息不透明的环境，我们唯有响应目标，并且以共同的目标建立什么是正确的衡量标准，才能保障项目的健康发展。
　　如果你发现了一个潜力极大的需求，并且有时效性，错过了就失去了，那么你应该先和上层沟通，先改变目标，再落地方案，而不是表面执行A目标，背后实施B目标的方案，这很有可能带来企业生存级的危机。
　　逻辑总结
　　本文我们通过BUG引入，输出了我对需求优先级判定的三个方法，分别是：功能层面的影响面积判定，设计层面的性价比判定，以及需求层面的目标匹配度判定。
　　正文也聊到了这些内容：
　　大部分BUG都可以转变成需求的视角，对于产品人而言，BUG也是需求的一个子集，或许有点特殊，但他依然是需求，依然遵循需求优先级的判定方法。
　　需求优先级的界定是一个相对的概念，而非绝对的概念，我们只能说A需求相对B需求优先级更高，而不能单独的说A需求优先级高。
　　希望这篇文章，对你有所帮助，后续也会持续输出逻辑案例性的文章。