临时需求,做,还是不做

临时需求，做，还是不做在产品经理的工作中，临时需求算是最常见的一种需求类型了。经常是毫无预兆就一个零售业消费丢过来，产品经理一脸懵逼。这种时候，这个需求是做呢？还是不做呢？如何处理为好呢？作为一个产品人，可能都经历过下面的场景：版本需求早已商定，开发、测试正在紧锣密鼓地进行中，你也也须投身于这个版本的uat试车以及下一个版本的规划中，眼看着没几天就要上线发版了，这么一来业务小姐姐跑过来说：“我这边有个需求，挺重要的，可不可以帮我加到这个版本一起做呀？”上线时间没变，临时不断增加一个需求，这时候我们是做还是不做呢？一、什么是临时需求首先我们要明确什么是临时临时供给。一般而言，在原本版本功能已定稿的情况下临时添加的需求都可以统称为临时需求，风险问题根据这些资金需求解决的不同问题，我们又可以拆成下面三类：1.缺陷型需求：为了解决现有功能缺陷的需求我们常见的为了解决系统bug提出的需求是一种缺陷型需求。但缺陷型需求不等同于系统bug，而是需求层面的bug。比如产品直接提供昵称了昵称的需求，但没有约定昵称的字数，导致出现超长字符的昵称，属于需求上用的缺陷。这一类供给的特点是：对现有业务有重大影响、一般而言比较紧急。所以，此类需求必须要极快做出重大决策决策。为了便于理解，将缺陷需求的处理流程梳理如下：第一步，判断是否会影响版本上线时间。如果不会，就把这个临时需求加进版本，并且可以按原计划完成；反之，就进行下一步判断。第二步，判断与否有满足需求的B方案，且不会干扰版本计划。如果有且接受B方案，那就使用B方案；反之，就进行下让一步判断。第三步，判断是否可以增设人手/外援完成。如果可以，那就请调资源增设人手/外援完成。反之，就进行下一步来判断。第四步，判断是否可以加班按期完成。如果可以，就拜托开发测试同事技术开发一起加班如期完成；反之，就进行下一步来判断。第五步，判断若资金需求可以砍掉别的需求。如果可以，就砍掉一些没有这个确实重要紧急并且还没有开始做的需求，把这个临时需求加进去。反之，就进行下一步来判断。第六步，判断是否可以延期上线。如果可以，就延期上线；反之，就拒绝不断增加到版本需求。我之前做定价系统的时候，有个新增产品服务的功能，大概流程如下：服务owner在系统新设发起新增服务的申请，填写提供服务相关信息，提交后生成审批手续签报，所有的领导核准通过后，回写信息，系统自动生成服务解码，该服务新增成功。这个功能上线前在测试环境进行UAT测试是没问题的，但是隔了一段时间在生产环境中即将正式使用的时候发现，审批通过后，系统无法生成产品服务编码，也就是无法成功新增产品与服务。最后排查原因，发现就是测试环境的服务编码都是用的将近十位数的编码，而实际的服务编码都是四位数或者五位数，导致在生产状况无法正常生成导致编码。这个功能上的缺陷，导致后续的一系列动作无法进行（无法需要进行定价刷新、产品服务目录发布等等）。这时这时候业务小姐姐就按耐不住了，跑过来说：“这个风险问题你得尽快帮我发版解决啊，不然没法划予了”。这时候，作为产品，拿到这样的临时需求的时候我们确实需要认真思考：该不该在这个版本加上？经过评估，这个问题没有备选的B方案，现在不修复的话，定价后续教育工作无法开展，而且还会影响到其他的业务，所以当时我们把这个反馈给了开发，了人天和当前的计划任务不冲突后，也顺利的加到了当前版本。像下面举的这个例子，是一个非常紧急的缺陷型需求；所以作为临时需求被提出时，我们需要以最快的响应时间去应答用户，尽快给出解决方案，确保正常的业务运转不会受到影响。当然，在实际的工作中，我们遇到的缺陷型需求不都是非常紧急的，可能只是重要，但是使用频率不高，那像这样的缺陷型需求我们就可以暂时先放进需求池，根据优先级评定排期。2.强化型需求：完善现有功能，使得用户体验得到进一步提升的需求强化型需求的特点是：优化大多严格来说一些优化性的需求，是在原有业务需求上，迎合用户操作过程习惯、页面美化等新增加的需求，做了用户满意度会提升，不做用户满意度能下降，重要但不紧急的。此类供给的应对策略，总结起来就一句话：一个原则，两个方式。应对原则：当前版本不处理，但要跟业务明白沟通清楚后续的应对方案，达成双方都认可的战略目标。应对方式一：如果该需求对用户满意度多影响大，那么放到总体规划下一个版本规划中；应对方式二：如果该需求量对用户满意度影响较小，可以考虑不做此类需求。还是定价系统的新增服务页面，这个页面的功能按钮在多个版本做下来，由最初的2个加到6个，前期在实现的时候没太考虑美观度，就单纯的在原有的基础上直接加按钮，导至后面这些功能按钮排成了长长的一行，显得整个页面非常不美观，最终逃不过业务小姐姐的吐槽，急切要求进行整理整顿——这确实是当初设计这些功能按钮的时候没有考虑全面，所以造成了那时的问题。不过，评估下来，这个需求并不影响当前的管理业务开展，不需要着急忙慌加到当前版本，后续版本再进行优化就可以。所以，当业务临时加的需求是强化型需求的时候，作为产品销售方要做的就是把它记录下来，放进需求池，和现有剩余的需求进行优先级排期，不用紧急加到当前版本里面，毕竟这种强化型的需求它不会影响业务正常进度，不应该打乱现有的开发节奏。3.独立型需求：独立于现有功能之外的需求伊奥尔迪县独立型需求指的是现有业务之外的新增需求，是一个新的功能体系。这一类需求，通常是一些跟现有业务存在一定逻辑关系的多少需求零点，是不外乎整体考量而提出的需求。此类需求，要分阶段来看：如果当前业务正处于开发阶段，业务还未成型，那么不建议纳入归入到当前的开发任务中；如果当前金融业务已经到调整期了使用阶段，银行业务整体逻辑已经开始成型，需要丰富更多的投资业务进来，那么可以考虑加入到当前的开发中，将某类需求放进需求池，和现有全部的或进行需求进行优先级排期，在下一个版本规划中实现。继续拿定价系统内举例：某天，业务小姐姐去楼下吃饭的时候，遇到快乐平安组遇见的一个同事，他们一边吃饭冲撞一边采取思想上的碰撞，最后碰撞出个非常好的点子：要将定价协同服务目录对接快乐平安（公司内部的沟通工具），实现一键跳转实时沟通的功能。业务小姐姐一回办公室就跑过来四处寻找我，跟我说了一下这个诉求，让我尽快实现这个妙不可言的需求。定价现有的服务目录是一个独立的存在，消费者查看服务介绍的时候，如果对某个产品服务感兴趣，需要自行记住服务owner,然后去邮件或者快乐平安找到这个人，再跟他进行沟通，也就是说在系统功能层面这里是业务断点的，如果加上这个功能，就可以打通这个断点。这个功能如果可以实现的话，用户体验定会大大提升。这个需求提出时，定价系统内已经在业务定价中正常运行了，可以将此消费需求纳入纳入到消费需求池中，但是作为临时需求加到现有版本的话就没有必要了。二、临时需求发生时如何决策上文中，我们有介绍临时需求的概念，也了说大致一下如何去应对业务小姐姐临时提的缺陷型需求、强化型需求、独立型需