临时需求，做，还是不做？

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

本文插图
作为一个产品人，可能都经历过下面的场景：
版本需求早已敲定，开发、测试正在紧锣密鼓地进行中，你也正投身于这个版本的uat测试以及下一个版本的规划中，眼看着没几天就要上线发版了，这时候业务小姐姐跑过来说：“我这边有个需求，挺重要的，可不可以帮我加到这个版本一起做呀？”
上线时间没变，临时增加一个需求，这时候我们是做还是不做呢？
一、什么是临时需求
首先我们要明确什么是临时需求。一般而言，在原本版本功能需求已定稿的情况下临时添加的需求都可以统称为临时需求，根据这些需求解决的不同问题，我们又可以分为下面三类：
1. 缺陷型需求：为了解决现有功能缺陷的需求
我们常见的为了解决系统bug提出的需求是一种缺陷型需求。但缺陷型需求不等同于系统bug ，而是需求层面的bug 。
比如产品提供了昵称的需求，但没有约定昵称的字数，导致出现超长字符的昵称，属于需求上的缺陷。这一类需求的特点是：对现有业务有重大影响、一般而言比较紧急。所以，此类需求必须要快速做出决策。
为了便于理解，将缺陷需求的处理流程梳理如下：
第一步，判断是否会影响版本上线时间。如果不会，就把这个临时需求加进版本，并且可以按原计划完成；反之，就进行下一步判断。
第二步，判断是否有满足需求的B方案，且不会影响版本计划。如果有且接受B方案，那就使用B方案；反之，就进行下一步判断。
第三步，判断是否可以增设人手/外援完成。如果可以，那就请调资源增设人手/外援完成。反之，就进行下一步判断。
第四步，判断是否可以加班按期完成。如果可以，就拜托开发测试同事一起加班完成；反之，就进行下一步判断。
第五步，判断是否可以砍掉别的需求。如果可以，就砍掉一些没有这个重要紧急并且还没有开始做的需求，把这个临时需求加进去。反之，就进行下一步判断。
第六步，判断是否可以延期上线。如果可以，就延期上线；反之，就拒绝增加到版本需求。
我之前做定价系统的时候，有个新增服务的功能，大概流程如下：
服务owner在系统发起新增服务的申请，填写服务相关信息，提交后生成审批签报，所有的领导审批通过后，回写信息，系统自动生成服务编码，该服务新增成功。
这个功能上线前在测试环境进行UAT测试是没问题的，但是隔了一段时间在生产环境中正式使用的时候发现，审批通过后，系统无法生成服务编码，也就是无法成功新增服务。
最后排查原因，发现就是测试环境的服务编码都是用的将近十位数的编码，而实际的服务编码都是四位数或者五位数，导致在生产环境无法正常生成编码。
这个功能上的缺陷，导致后续的一系列动作无法进行（无法进行定价刷新、服务目录发布等等）。
这时候业务小姐姐就按耐不住了，跑过来说：“这个问题你得尽快帮我发版解决啊，不然没法开展业务了” 。这时候，作为产品，拿到这样的临时需求的时候我们确实需要认真思考：该不该在这个版本加上？
经过评估，这个问题没有备选的B方案，现在不修复的话，定价后续工作无法开展，而且还会影响到其他的业务，所以当时我们把这个反馈给了开发，评估了人天和当前的计划任务不冲突后，也顺利的加到了当前版本。