临时需求，做，还是不做？( 二 )
像上面举的这个例子 ， 是一个非常紧急的缺陷型需求；所以作为临时需求被提出时 ， 我们需要以最快的响应时间去应答用户 ， 尽快给出解决方案 ， 确保正常的业务运转不会受到影响 。
【临时需求，做，还是不做？】当然 ， 在实际的工作中 ， 我们遇到的缺陷型需求不都是非常紧急的 ， 可能只是重要 ， 但是使用频率不高 ， 那像这样的缺陷型需求我们就可以暂时先放进需求池 ， 根据优先级评定排期 。
2. 强化型需求：完善现有功能 ， 使得用户体验得到进一步提升的需求
强化型需求的特点是：大多属于一些优化性的需求 ， 是在原有业务需求上 ， 迎合用户操作习惯、页面美化等新增加的需求 ， 做了用户满意度会提升 ， 不做用户满意度会下降 ， 重要但不紧急的 。
此类需求的应对策略 ， 总结起来就一句话：一个原则 ， 两个方式 。
应对原则：当前版本不处理 ， 但要跟业务沟通清楚后续的应对方案 ， 达成双方都认可的目标 。
应对方式一：如果该需求对用户满意度影响大 ， 那么放到下一个版本规划中；
应对方式二：如果该需求对用户满意度影响较小 ， 可以考虑不做此类需求 。
还是定价系统的新增服务页面 ， 这个页面的功能按钮在多个版本做下来 ， 由最初的2个加到6个 ， 前期在实现的时候没太考虑美观度 ， 就单纯的在原有的基础上直接加按钮 ， 导致后面这些功能按钮排成了长长的一行 ， 显得整个页面非常不美观 ， 最终逃不过业务小姐姐的吐槽 ， 急切要求进行整理整顿——这确实是当初设计这些功能按钮的时候没有考虑全面 ， 所以造成了现在的问题 。
不过 ， 评估下来 ， 这个需求并不影响当前的业务开展 ， 不需要着急忙慌加到当前版本 ， 后续版本再进行优化就可以 。
所以 ， 当业务临时加的需求是强化型需求的时候 ， 作为产品方要做的就是把它记录下来 ， 放进需求池 ， 和现有剩余的需求进行优先级排期 ， 不用紧急加到当前版本里面 ， 毕竟这种强化型的需求它不会影响业务的正常进度 ， 不应该打乱现有的开发节奏 。
3. 独立型需求：独立于现有功能之外的需求
独立型需求指的是现有业务之外的新增需求 ， 是一个新的功能体系 。 这一类需求 ， 通常是一些跟现有业务存在一定逻辑关系的需求点 ， 是出于整体考量而提出的需求 。
此类需求 ， 要分阶段来看：
如果当前业务正处于开发阶段 ， 业务还未成型 ， 那么不建议纳入到当前的开发任务中；
如果当前业务已经到了使用阶段 ， 业务整体逻辑已经开始成型 ， 需要丰富更多的业务进来 ， 那么可以考虑加入到当前的开发任务中 ， 将此类需求放进需求池 ， 和现有剩余的需求进行优先级排期 ， 在下一个版本规划中实现 。
继续拿定价系统举例：
某天 ， 业务小姐姐去楼下吃饭的时候 ， 遇到快乐平安组的一个同事 ， 他们一边吃饭一边进行思想上的碰撞 ， 最后碰撞出个非常好的点子：要将定价服务目录对接快乐平安（公司内部的沟通工具） ， 实现一键跳转实时沟通的功能 。 业务小姐姐一回办公室就跑过来找我 ， 跟我说了一下这个诉求 ， 让我尽快实现这个妙不可言的需求 。
定价系统现有的服务目录是一个独立的存在 ， 用户查看服务介绍的时候 ， 如果对某个服务感兴趣 ， 需要自行记住服务 owner ， 然后去邮件或者快乐平安找到这个人 ， 再跟他进行沟通 ， 也就是说在系统功能层面这里是存在业务断点的 ， 如果加上这个功能 ， 就可以打通这个断点 。
这个功能如果可以实现的话 ， 用户体验定会大大提升 。
这个需求提出时 ， 定价系统已经在业务中正常运行了 ， 可以将此需求纳入到需求池中 ， 但是作为临时需求加到现有版本的话就没有必要了 。
二、临时需求发生时如何决策
上文中 ， 我们有介绍临时需求的概念 ， 也大致说了一下如何去应对业务小姐姐临时提的缺陷型需求、强化型需求、独立型需求 。
推荐阅读
- 拓客|美发小程序怎么弄才能满足顾客和商家需求？
- 伟华在此|徒有虚名还是拍照神器？华为P40pro初体验
- XLife|平时手机放置的时候正面朝下好还是反面朝下好？你的做法正确吗？
- 5g|5G手机价格还是太贵，不如看看这两部4G手机，性能颜值都很在线！
- 虎子抗癌斗士还是刻意营销？B站一UP主被指靠卖惨获利
- 电动车第一线|电动车用真空轮胎好，还是用有胆轮胎好？告诉你真实答案！
- 中山狐爱数码|NAS还是看硬盘，入手东芝N300系列NAS硬盘
- 界面新闻|虚拟主播抢食直播市场，是造噱头还是好模式？
- 奇艺爱奇艺会员服务「车祸」不断，是贪婪还是困境难解？
- 虎嗅APP|中概股回归，大势所趋还是形势所迫？