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

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

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

上线时间没变，临时增加一个需求，这时候我们是做还是不做呢？

一、什么是临时需求

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

1. 缺陷型需求：为了解决现有功能缺陷的需求

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

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

为了便于理解，将缺陷需求的处理流程梳理如下：

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

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

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

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

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

第六步，判断是否可以延期上线。如果可以，就延期上线；反之，就拒绝增加到版本需求。

我之前做定价系统的时候，有个新增服务的功能，大概流程如下：

服务owner在系统发起新增服务的申请，填写服务相关信息，提交后生成审批签报，所有的领导审批通过后，回写信息，系统自动生成服务编码，该服务新增成功。

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

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

这个功能上的缺陷，导致后续的一系列动作无法进行（无法进行定价刷新、服务目录发布等等）。

这时候业务小姐姐就按耐不住了，跑过来说：“这个问题你得尽快帮我发版解决啊，不然没法开展业务了”。这时候，作为产品，拿到这样的临时需求的时候我们确实需要认真思考：该不该在这个版本加上？

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

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

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

2. 强化型需求：完善现有功能，使得用户体验得到进一步提升的需求

强化型需求的特点是：大多属于一些优化性的需求，是在原有业务需求上，迎合用户操作习惯、页面美化等新增加的需求，做了用户满意度会提升，不做用户满意度会下降，重要但不紧急的。

此类需求的应对策略，总结起来就一句话：一个原则，两个方式。

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

应对方式一：如果该需求对用户满意度影响大，那么放到下一个版本规划中；

应对方式二：如果该需求对用户满意度影响较小，可以考虑不做此类需求。

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

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

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

3. 独立型需求：独立于现有功能之外的需求

独立型需求指的是现有业务之外的新增需求，是一个新的功能体系。这一类需求，通常是一些跟现有业务存在一定逻辑关系的需求点，是出于整体考量而提出的需求。

此类需求，要分阶段来看：

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

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

继续拿定价系统举例：

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

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

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

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

二、临时需求发生时如何决策

上文中，我们有介绍临时需求的概念，也大致说了一下如何去应对业务小姐姐临时提的缺陷型需求、强化型需求、独立型需求。

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

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

三、总结

在产品开发过程中，业务小姐姐跑过来加临时需求的情况时有发生，掌握一定的决策方法，做到临危不乱，这是我们作为产品人必备的素质。

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

本文由 @梨子jiang 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议