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

15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

本文给大家介绍一个作者常用的优先级界定方法,作者把他理解成判断优先级的三个阶段性方法,分别对应不同阶段的产品人,不同重要性的需求。一起来看看~

功能越多,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万用户也是影响面积极小的一个存在。

与影响面积类似的判断方法还有严重度。

严重度大小判定:阻塞性业务优先于概率性错误,而概率性错误优先于使用体验。

影响面积的判定,又或者是严重度大小的判定,均是针对功能的实现覆盖面积的角度来判断,对应的也是处于功能产品阶段的产品人,此时我们更关注的是功能结果。

我将产品人的发展阶段宽泛的定义为三个阶段,从初往高,分别对应功能阶段的产品经理,设计阶段的产品经理以及需求阶段的产品经理,每个阶段的跨度大概都是2-3年的时间。

2. 性价比判定

性价比判定对应的是设计阶段的产品经理,如果说影响面积是考虑的功能收益,影响越大,功能收益越大,那么性价比判定就是在收益的基础上,增加了成本因素,将收益和成本进行综合考虑的一种判定方式。

有的需求,能够有极大的覆盖面积,但却需要付出极大的成本,这其实是不太推荐的,成本越高,风险也就越高,除非我们能找到一种低成本的实施方案,或许会让效果有一些折扣,但却是必要的。

性价比的判定,通常会引入多种成本维度,包括开发成本,运营成本,商业成本,资源成本等多个维度的成本进行综合考虑。

最开始,我们或许只能考虑到开发成本,这得益于我们从业的前两年时间,让我们对功能的实施成本有了大致的经验预判,而其他环节的成本也是我们和对应团队的合作经验得到,在缺少经验时,往往需要多次沟通,多次交流,才能让我们的判断稍微准确一些。

作为一个综合电商平台而言,我们考虑增加一个自动秒杀模块。

自动秒杀的设计,将会随机从平台的商品里生成秒杀队列,这可以减少商户的运作成本,他们基本不用运营维护,每天都会生成秒杀专区。

除此之外还会给予到秒杀商品大图展示,如果能为每一款商品定制秒杀的专属配图,这对消费者会产生极大的吸引力,因为这些商品展示的大图,都能带上很吸引人的信息。

然而这个功能却需要所有的商户参与进来,每个商户都需要对每个商品增加一张秒杀的活动配图,这些配图并不是每时每刻都在被使用,实际上相同周期里,大部分的图片素材都是不会被使用的。

相对这个需求的价值而言,所需要付出的成本也是极大的,尽管这是一个很好的idea,但他依然不会进入到开发排期,除非我们有一些特殊的设计,能将成本降低下来。

我们在产品生涯的第二个阶段,设计阶段,会更多的考虑成本,价值衡量这样的度量维度,产品于我们而言,不应该是有和无的关系,还会增加一层类似分数值的概念,满分100分的设定里,我们也会越来越倾向于高分的方案。

3. 目标匹配度判定

当你成长为更专业的产品经理时,你会发现我们不仅仅不会修复一些BUG,甚至对于一些性价比高的事情也不会去做,即使他的成本并不高,即使他能为我们带来可观的数据,我们也会因为目标不匹配而放弃掉这个方案。

目标匹配度判定对应的是第三阶段的产品人,我们开始深入思考需求,而这里的关键点在于匹配。

产品是一个较长周期持续存在的事物,每个阶段都有不同的诉求,根据市场环境,根据公司策略等等许多因素,我们会得到某一个周期的核心目标,此时,我们的需求和决策都会围绕目标展开。

你一定知道百度近期的一个事件,根据百度官方公告:由于系统维护原因,百度贴吧2017年以前的帖子将会无法访问,修复事件将会另行通知。

随后,微信在短时间内无法修改头像和昵称,各个内容平台都无法分享内容至微信。

背后的原因是国家净网行动的实施,而在这个时间点里,大家达成一致的目标均是围绕内容处理展开,有的是清除历史数据,有的是禁止外部不可控的数据进入。

相对于这个目标而言,其他事情的优先级都需要降低,否则,你可能赢了结果,输了官司。

如果说影响面积判定,让我们认识到了收益,而性价比判定让我们认识到了成本,那么第三阶段的目标匹配度判定则是会让我们认识到“正确性”。

坚持做正确的事情,提出这款产品应该提出的需求,往他应该发展的方向去发展,是我们对正确性诠释之一,同时也是中高端职场核心之一。

我们身处职场,对于产品经理而言,什么是职场呢?职场就是信息不透明,信息不对等的重灾区,当上级做了决策,当公司决定了发展策略,定下了阶段性目标时,其实没有人会完整的告诉你为什么这么做,有些事情,背后的信息,并不是我们产品人所能接受的。

朋友告诉了我这样一个故事,老板委托他做了一个功能,这个功能看上去与产品格格不入,并且对活跃,转化都没有什么帮助,唯一的作用就是一种理财的尝试。他十分不能理解,直到最后偶然得知,当时公司的现状几乎接近资金断裂,需要一笔资金作为周转。如果不是这样一个功能,可能当月就会面临发不出工资的问题,尽管拥有成熟且健康的现金流。

在这样一个信息不对称,信息不透明的环境,我们唯有响应目标,并且以共同的目标建立什么是正确的衡量标准,才能保障项目的健康发展。

如果你发现了一个潜力极大的需求,并且有时效性,错过了就失去了,那么你应该先和上层沟通,先改变目标,再落地方案,而不是表面执行A目标,背后实施B目标的方案,这很有可能带来企业生存级的危机。

逻辑总结

本文我们通过BUG引入,输出了我对需求优先级判定的三个方法,分别是:功能层面的影响面积判定,设计层面的性价比判定,以及需求层面的目标匹配度判定。

正文也聊到了这些内容:

  1. 大部分BUG都可以转变成需求的视角,对于产品人而言,BUG也是需求的一个子集,或许有点特殊,但他依然是需求,依然遵循需求优先级的判定方法。
  2. 需求优先级的界定是一个相对的概念,而非绝对的概念,我们只能说A需求相对B需求优先级更高,而不能单独的说A需求优先级高。

希望这篇文章,对你有所帮助 ,后续也会持续输出逻辑案例性的文章。

#专栏作家#

枯叶,微信公众号:产品经理充电站。人人都是产品经理专栏作家。近9年经验的产品经理,擅长社交、社区、细分群体挖掘。

本文由 @枯叶 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!