临时需求,做,还是不做?

在产品经理的工作中,临时需qiú算是最常见的一种需qiú类型了。经常是毫无预兆就一个需qiú丢过来,产品经理一脸懵bī。这种时候,这个需qiú是做呢?还是不做呢?如何处理为好呢?

作为一个产品人,可能都经历过下面的场景:

版本需qiú早已敲定,开发、测试正在紧锣密鼓地进行中,你也正投身于这个版本的uat测试以及下一个版本的规划中,眼看着没几天就要上线发版了,这时候XX姐跑过来说:“我这边有个需qiú,挺重要的,可不可以帮我加到这个版本一起做呀?”

上线时间没变,临时增加一个需qiú,这时候我们是做还是不做呢?

一、什么是临时需qiú

首先我们要明确什么是临时需qiú。一般而言,在原本版本功能需qiú已定稿的情况下临时添加的需qiú都可以统称为临时需qiú,根据这些需qiú解决的不同问题,我们又可以分为下面三类:

1. 缺陷型需qiú:为了解决现有功能缺陷的需qiú

我们常见的为了解决系统bug提出的需qiú是一种缺陷型需qiú。但缺陷型需qiú不等同于系统bug,而是需qiú层面的bug

比如产品X了昵称的需qiú,但没有约定昵称的字数,导致出现超长字符的昵称,属于需qiú上的缺陷。这一类需qiú的特点是:对现有X有重大影响、一般而言比较紧急。所以,此类需qiú必须要快速做出决策。

为了便于理解,将缺陷需qiú的处理liú程梳理如下:

第一步,判断是否会影响版本上线时间。如果不会,就把这个临时需qiú加进版本,并且可以按原计划完成;反之,就进行下一步判断。

第二步,判断是否有满足需qiú的B方案,且不会影响版本计划。如果有且接受B方案,那就使用B方案;反之,就进行下一步判断。

第三步,判断是否可以增设人手/外援完成。如果可以,那就请调资源增设人手/外援完成。反之,就进行下一步判断。

第四步,判断是否可以加班按期完成。如果可以,就拜托开发测试同事一起加班完成;反之,就进行下一步判断。

第五步,判断是否可以砍掉别的需qiú。如果可以,就砍掉一些没有这个重要紧急并且还没有开始做的需qiú,把这个临时需qiú加进去。反之,就进行下一步判断。

第六步,判断是否可以延期上线。如果可以,就延期上线;反之,就拒绝增加到版本需qiú。

我之前做定价系统的时候,有个新增X的功能,大概liú程如下:

Xowner在系统发起新增X的申请,填写X相关信息,提交后生成审批签报,所有的X审批X后,回写信息,系统自动生成X编码,该X新增成功。

这个功能上线前在测试环境进行UAT测试是没问题的,但是隔了一段时间在生产环境中正式使用的时候发现,审批X后,系统无fǎ生成X编码,也就是无fǎ成功新增X。

最后排查原因,发现就是测试环境的X编码都是用的将近十位数的编码,而实际的X编码都是四位数或者五位数,导致在生产环境无fǎ正常生成编码。

这个功能上的缺陷,导致后续的一系列动作无fǎ进行(无fǎ进行定价刷新、X目录发布等等)。

这时候XX姐就按耐不住了,跑过来说:“这个问题你得尽快帮我发版解决啊,不然没fǎ开展X了”。这时候,作为产品,拿到这样的临时需qiú的时候我们确实需要认真思考:该不该在这个版本加上?

经过评估,这个问题没有备选的B方案,现在不修复的话,定价后续工作无fǎ开展,而且还会影响到其他的X,所以当时我们把这个反馈给了开发,评估了人天和当前的计划任务不X后,也顺利的加到了当前版本。

像上面举的这个例子,是一个非常紧急的缺陷型需qiú;所以作为临时需qiú被提出时,我们需要以最快的响应时间去应答用户,尽快给出解决方案,确保正常的X运转不会受到影响。

当然,在实际的工作中,我们遇到的缺陷型需qiú不都是非常紧急的,可能只是重要,但是使用频率不高,那像这样的缺陷型需qiú我们就可以暂时先放进需qiú池,根据优先级评定排期。

2. 强化型需qiú:完善现有功能,使得用户体验得到进一步提升的需qiú

强化型需qiú的特点是:大多属于一些优化性的需qiú,是在原有X需qiú上,迎合用户cāo作xí惯、页面美化等新增加的需qiú,做了用户满意度会提升,不做用户满意度会下降,重要但不紧急的。

此类需qiú的应对策略,总结起来就一句话:一个原则,两个方式。

应对原则:当前版本不处理,但要跟X沟通清楚后续的应对方案,达成双方都认可的目标。

应对方式一:如果该需qiú对用户满意度影响大,那么放到下一个版本规划中;

应对方式二:如果该需qiú对用户满意度影响较小,可以考虑不做此类需qiú。

还是定价系统的新增X页面,这个页面的功能按钮在多个版本做下来,由最初的2个加到6个,前期在实现的时候没太考虑美观度,就单纯的在原有的基础上直接加按钮,导致后面这些功能按钮排成了长长的一行,显得整个页面非常不美观,最终逃不过XX姐的吐槽,急切要qiú进行整理整顿——这确实是当初设计这些功能按钮的时候没有考虑全面,所以造成了现在的问题。

不过,评估下来,这个需qiú并不影响当前的X开展,不需要着急忙慌加到当前版本,后续版本再进行优化就可以。

所以,当X临时加的需qiú是强化型需qiú的时候,作为产品方要做的就是把它记录下来,放进需qiú池,和现有剩余的需qiú进行优先级排期,不用紧急加到当前版本里面,毕竟这种强化型的需qiú它不会影响X的正常进度,不应该打乱现有的开发节奏。

3. X型需qiú:X于现有功能之外的需qiú

X型需qiú指的是现有X之外的新增需qiú,是一个新的功能X。这一类需qiú,通常是一些跟现有X存在一定逻辑关系的需qiú点,是出于整体考量而提出的需qiú。

此类需qiú,要分阶段来看:

如果当前X正处于开发阶段,X还未成型,那么不建议纳入到当前的开发任务中;

如果当前X已经到了使用阶段,X整体逻辑已经开始成型,需要丰富更多的X进来,那么可以考虑加入到当前的开发任务中,将此类需qiú放进需qiú池,和现有剩余的需qiú进行优先级排期,在下一个版本规划中实现。

继续拿定价系统举例:

某天,XX姐去楼下吃饭的时候,遇到快乐平安组的一个同事,他们一边吃饭一边进行思想上的碰撞,最后碰撞出个非常好的点子:要将定价X目录对接快乐平安(X内部的沟通工具),实现一键跳转实时沟通的功能。XX姐一回办公室就跑过来找我,跟我说了一下这个诉qiú,让我尽快实现这个妙不可言的需qiú。

定价系统现有的X目录是一个X的存在,用户查看X介绍的时候,如果对某个X感兴趣,需要自行记住X owner,然后去邮件或者快乐平安找到这个人,再跟他进行沟通,也就是说在系统功能层面这里是存在X断点的,如果加上这个功能,就可以打通这个断点。

这个功能如果可以实现的话,用户体验定会大大提升。

这个需qiú提出时,定价系统已经在X中正常运行了,可以将此需qiú纳入到需qiú池中,但是作为临时需qiú加到现有版本的话就没有必要了。

二、临时需qiú发生时如何决策

上文中,我们有介绍临时需qiú的概念,也大致说了一下如何去应对XX姐临时提的缺陷型需qiú、强化型需qiú、X型需qiú。

在这个段落,我们一起提炼总结一下,来说说临时需qiú发生时该如何进行决策:

  1. 判断需qiú属性:根据需qiú的特点,判断临时提出的需qiú是属于缺陷型需qiú、强化型需qiú、X型需qiú中的哪一种。
  2. 分析需qiú:根据需qiú属性,结合实际情况分析需qiú对现有X的影响,以判断需qiú的重要程度。
  3. 制定应对措施:根据需qiú的重要程度,并结合实际的开发进度、开发计划以及开发资源,制定具体的实现方案。除缺陷型需qiú,其他基本上都是放到后期版本规划中。
  4. 沟通并确定方案:与X和开发分别沟通方案的可行性,最终达成意见一致的方案。
  5. 执行方案:根据最终方案,执行并监控执行结果。

三、总结

在产品开发过程中,XX姐跑过来加临时需qiú的情况时有发生,掌握一定的决策方fǎ,做到临危不乱,这是我们作为产品人必备的素质。

希望X本文能给大家带来一些小启发,愿大家一起在产品的道路上越走越好。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 临时需求,做,还是不做? https://www.xiongfawang.com/2523.html

常见问题

相关文章

临时需求,做,还是不做?-海报

分享本文封面