编辑导语：作为一名B端产品经理，有时候可能会接到客户突然提出来的“紧急需求”，这种时候，该怎么做才能既让客户满意，又不伤害原系统呢 ？本文作者总结出了三点注意事项，一起来看一下吧。
一名B端产品经理可能时不时会接到客户提出的“紧急需求”。
之所以“紧急”，可能是因为客户前期没有和乙方沟通好，需求提出时已接近项目上线时间；或是一拍脑袋想出一个新主意，不顾项目进度执意加塞需求；或是对某个服务环节产生不满，故意为难乙方；亦或是下周突然要与领导汇报……
遇到这种情形，产品经理是否应该马上开始着手需求设计呢？
当然不是。
除了本已存在于客户原始规划中的需求，这类“紧急需求”往往在提出时就非常欠考虑。有时就算看起来非常不起眼的改动，也会对整个系统造成意想不到的混乱。
那么在这时，产品经理该怎么做，才能既让客户满意，又能不伤害原系统、不拖累项目进度，更不给自己埋坑？踩过无数坑的我，对此总结了三点注意事项，希望可以帮助减少处理紧急需求时的手忙脚乱。
01 最简化原则
怎么做最简单？这是接到紧急需求时产品经理需要优先思考的问题，也就是从系统整体考虑，如何用最小的改动满足客户需求。比如，如果可以复用已有组件，就不做重复开发；如果可以只让前端修改，就不动后台；如果可以只加字段，就不开新接口……
另外，客户有时因为需要某些数据，所以要求乙方给报表加字段、增加报表的导出功能等。如果数据量不大，此时可以考虑请后台直接导出，再由人工对数据进行二次处理。如果导出频率较低，后续可以维持此流程；如果导出频率较高，则要协调人力尽快开发功能。
如果是SaaS产品，变更一个功能，将不止影响一家企业，因此SaaS产品经理非常看重需求通用性。但在支持紧急需求的情况下，有时并不能只考虑通用性，毕竟通用性强的需求往往意味着逻辑多、开发量大。此时可以先上线一个简单功能，再根据自己的规划，后期做功能变更或扩充。
02 不要盲目相信原始需求
时间的紧迫容易让人缺少正确判断，更容易让产品经理只顾解决问题，拿到客户的原始需求就直接开工。事实上，就算此时时间紧迫、不便与客户直接接触，产品经理也应该花一点时间，联系销售、售前等部门同事，了解需求究竟从何而来，弄清客户的真正意图。
我曾接到这样一条紧急需求，客户要求将我们的学员端登录页改造得与管理端相同。已经被其他需求压得喘不过气的我准备直接向研发提出“为该企业定制一个和管理端相同的学员端登录页”，此时一位前端工程师提醒我，管理端和学员端的前端架构不一样，不是复制一个登录页给学员端就可以，现在给的开发时间完全不够。
这才让我冷静下来思考这个需求的合理性，我开始回想我了解到的需求背景：客户在使用我们的平台之前，管理端和学员端是一起的。这次更换平台，客户并不想改变已有习惯，但我们又不可能真的把两端放在一起。因此双方各退一步，最后客户与售前将需求确定为：保持管理端和学员端的登录页是两个登录地址，但样式相同。
很明显，要求页面样式相同只是表面需求，客户的深层需求其实是不想把管理端和学员端割裂。这样一想，也就不必拘泥于做一个新页面了。我很快改变了思路：给客户定制一个管理端至学员端的免登。这就已经足够。
不盲目相信原始需求，看清客户的真正意图，除了能获得一个更好的需求设计，有时还能因此看清这条需求其实完全没必要做，进而直接消灭需求，这对项目组所有人来说是再好不过的事情。
03 不要盲目复用已有功能
在上文的最简化原则中提到，“如果可以复用已有组件，就不做重复开发”。这个方法对处理紧急需求十分有效，但并不是减少产研工作量的万金油。两个提出相同需求的客户可能有两种完全不同的使用场景，因此在功能看似可以复用时并不意味着需求就此万事大吉，说不定在复用后就被客户投诉“根本不能用”。
我们把上面的例子反过来。假设客户直接提出了“我需要从A平台无需再次登录就可以跳到B平台”，此时研发告知产品经理，此前在某定制项目中开发过相同的功能，复用即可，于是产品经理欣喜地在需求中写下“复用XX项目的免登功能”。
结果需求上线当日被提报生产问题，原因是已有的免登功能仅支持手机号登录，现在客户用的是邮箱登录。
这个例子看起来可能有些极端和好笑，但事实上我曾见过不止一位产品经理犯过类似的错误（包括一些资深的产品经理，以及我自己），也就是急于复用现有功能，忘记将功能放在客户场景中，考虑整个业务流程是否已完成闭环。
以上三点就是我对紧急需求处理的一些看法，也是我对自己过往工作的总结，不足之处还请大家多多指点，也欢迎大家共同讨论。
作者：JaneGinkgo，还在不断学习中的95后产品经理。