位置:人生美文网 > 职场 > 正文 >

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

2020年11月19日 20:06来源:未知手机版

沙葛,水瓶男喜欢你的表现,亚航订票攻略

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

功能越多,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是可遇不可求的。

本文地址:http://www.weixinrensheng.com/zhichang/2399007.html 转载请注明出处!

今日热点资讯