在产品经理的工作中，临时需求是最常见的需求类型之一。 总是毫无预兆地失去一个需求，产品经理一脸不知道的样子。 在这种时候，这种需求会做什么呢？ 还是不做？ 我该怎么办？
作为产品的人，你可能经历过以下场景。
版本需求已经确定，开发、测试正在稳步进行。 你也投身于这个版本的uat测试和下一个版本的计划。 很快就会在网上发布吧。 这时，业务姐姐走了过来，说：“我们有需求。 因为非常重要，你能添加到这个版本一起做吗？”
在线时间不变。 暂时增加需求。 这个时候，我们做还是不做？
一、什么是临时需求
首先要明确什么是临时需求。 通常，在确定原始版本的功能要求时临时添加的要求统称为临时要求。 根据这些要求所解决的问题，可以分为三类：解决
1. 缺陷型需求：为了解决现有功能缺陷的需求
系统错误的常见需求是缺陷型需求。 但是，缺陷型需求与系统的bug不同，而是需求水平的bug。例如，产品提供了昵称的需求，但由于没有约定昵称的字符数，出现了超长字符的昵称，是需求上的缺陷。 这种需求的特点是对现有业务有重大影响，一般情况下很紧急。 因此，这种需要必须迅速作出决定。
为便于理解，将缺陷需求的处理流程整理如下。
第一步是确定是否影响版本的在线时间。 否则，可以将此临时需求添加到版本中，按原计划完成； 相反，进行下一个判断。
在第2步中，确定是否存在满足需求的Web计划，而不影响版本计划。 有b方案可以接受的，使用b方案； 相反，进行下一个判断。
第三步，判断能否增设人工/外援完成。 如果可能，请调集资源增设和完成人力/外援。 相反，进行下一个判断。
第四步，确定加班能否按时完成。 如果可能的话，请开发测试的同事一起加班完成； 相反，进行下一个判断。
第五步确定是否可以舍弃其他需求。 如果可能的话，放弃这个没有重要紧急性，还没有开始的需求，添加这个临时需求。 相反，进行下一个判断。
第六步确定是否可以推迟上线。 如果可能的话，推迟上线； 相反，它拒绝增加对版本的需求。
以前制定定价系统的时候，有了新服务的功能。 大致流程如下。
服务owner在系统上开始申请新服务，填写服务相关信息，提交后生成审批签字，所有领导审批通过后回写信息，系统自动生成服务代码，成功添加该服务。
在此功能上线之前在测试环境中进行UAT测试是没有问题的，但是在生产环境中正式使用一段时间后，在批准通过后，系统无法生成服务代码，即无法添加服务。
最后调查原因后发现，测试环境的服务代码使用了近10位的代码，而实际的服务代码为4位或5位，无法在生产环境中正常生成代码。
由于该功能上的缺陷，之后的一系列动作无法进行(无法更新价格、发布服务目录等)。
那时，业务姐姐受不了了，“这个问题请尽快出版解决。 不那样的话就无法开展业务”。 此时，作为产品，当我们得到这种暂时的需求时，我们确实需要认真考虑。 不是应该添加到这个版本中吗？
评估结果表明，这个问题没有替代的B方案，目前不修复就无法开展定价后续工作，也影响到其他业务，所以当时我们对此进行了反馈，评估人与当前计划任务不冲突后，顺利地添加到了当前版本中。
上面列举的例子是非常紧急的缺陷型需求； 因此，如果被提出作为临时需求，我们需要以最快的响应时间响应用户，并尽快提供解决方案，确保正常的业务运营不受影响。
当然，在实际工作中，我们面临的所有缺陷型需求都不是非常紧急，可能只是重要，但使用频率不高。 这种缺陷型需求可以临时放入需求池中，并根据优先级进行排名。
2. 强化型需求：完善现有功能，使得用户体验得到进一步提升的需求
增强型需求的特点大多是一些优化需求，在原有的业务需求中满足用户操作习惯、页面美化等新增加的需求，用户满意度提高，用户满意度下降，重要但不紧急这种需求的应对策略，概括起来说，就是一个原则、两种方式。
应对原则：目前版本不予办理，但必须与业务沟通，明确后续应对方案，达到双方都能接受的目标。
应对方法1 )如果该需求对用户满意度影响较大，则列入下一版本计划；
应对方法2 :如果需求对用户满意度的影响较小，则可能不会进行这种需求。
这是定价系统的新服务页面，该页面的功能按钮由多个版本组成，从前两个到后六个版本。 在前面的阶段，在实现时很少考虑外观，但由于简单地直接添加了按钮，所以后面这些功能按钮排列得很长，整个页面变得非常不美观。 最终逃不出业务姐姐的吐槽，渴望整理整理——。 这确实在当初设计这些功能按钮时没有全面考虑
但是经过评估，这个需求不会影响当前的业务开展，所以不需要马上添加到当前版本中，在后续版本中进行优化就可以了。
>所以，当业务临时加的需求是强化型需求的时候，作为产品方要做的就是把它记录下来，放进需求池，和现有剩余的需求进行优先级排期，不用紧急加到当前版本里面，毕竟这种强化型的需求它不会影响业务的正常进度，不应该打乱现有的开发节奏。3. 独立型需求：独立于现有功能之外的需求
独立型需求指的是现有业务之外的新增需求，是一个新的功能体系。这一类需求，通常是一些跟现有业务存在一定逻辑关系的需求点，是出于整体考量而提出的需求。
此类需求，要分阶段来看：
如果当前业务正处于开发阶段，业务还未成型，那么不建议纳入到当前的开发任务中；
如果当前业务已经到了使用阶段，业务整体逻辑已经开始成型，需要丰富更多的业务进来，那么可以考虑加入到当前的开发任务中，将此类需求放进需求池，和现有剩余的需求进行优先级排期，在下一个版本规划中实现。
继续拿定价系统举例：
某天，业务小姐姐去楼下吃饭的时候，遇到快乐平安组的一个同事，他们一边吃饭一边进行思想上的碰撞，最后碰撞出个非常好的点子：要将定价服务目录对接快乐平安（公司内部的沟通工具），实现一键跳转实时沟通的功能。业务小姐姐一回办公室就跑过来找我，跟我说了一下这个诉求，让我尽快实现这个妙不可言的需求。
定价系统现有的服务目录是一个独立的存在，用户查看服务介绍的时候，如果对某个服务感兴趣，需要自行记住服务 owner，然后去邮件或者快乐平安找到这个人，再跟他进行沟通，也就是说在系统功能层面这里是存在业务断点的，如果加上这个功能，就可以打通这个断点。
这个功能如果可以实现的话，用户体验定会大大提升。
这个需求提出时，定价系统已经在业务中正常运行了，可以将此需求纳入到需求池中，但是作为临时需求加到现有版本的话就没有必要了。
二、临时需求发生时如何决策
上文中，我们有介绍临时需求的概念，也大致说了一下如何去应对业务小姐姐临时提的缺陷型需求、强化型需求、独立型需求。
在这个段落，我们一起提炼总结一下，来说说临时需求发生时该如何进行决策：
判断需求属性：根据需求的特点，判断临时提出的需求是属于缺陷型需求、强化型需求、独立型需求中的哪一种。分析需求：根据需求属性，结合实际情况分析需求对现有业务的影响，以判断需求的重要程度。制定应对措施：根据需求的重要程度，并结合实际的开发进度、开发计划以及开发资源，制定具体的实现方案。除缺陷型需求，其他基本上都是放到后期版本规划中。沟通并确定方案：与业务和开发分别沟通方案的可行性，最终达成意见一致的方案。执行方案：根据最终方案，执行并监控执行结果。三、总结
在产品开发过程中，业务小姐姐跑过来加临时需求的情况时有发生，掌握一定的决策方法，做到临危不乱，这是我们作为产品人必备的素质。
希望通过本文能给大家带来一些小启发，愿大家一起在产品的道路上越走越好。
本文由 @梨子jiang 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议