经理|产品上线后“暴雷”，如何优雅地“背锅”？_第三方|支付费用|支付|百分点

编辑导语：面对产品上线后可能出现的问题，产品经理应该如何做好应对策略？首先，产品经理需要找到发生问题的原因；其次，事后做好复盘总结。本篇文章里，作者结合实际经验，对产品上线出现问题的场景下、产品经理应如何应对做了总结梳理，一起来看一下。

文章插图
背锅，其实是个技术活。
上周二鏡同学负责的项目终于上线了，上线后就成功“暴雷”了。
【经理|产品上线后“暴雷”，如何优雅地“背锅”？】事情大概是这样的：
记得那是一个冬天，漫天雪花，我们应收账款融资产品需要对接第三方资金体系，从而实现线上客户资金的支付，当然，作为技术平台产品，我们定位是搭建支付通道，并不实际触碰资金，我们是同第三方支付技术平台公司做对接，背后的资金体系实际是渤海银行（后续有类似产品设计时，大家可参考定位）。
于是乎，我们成立资金体系项目小组，鏡同学亲自担任小组组长，兼产品汪汪、协调队长、技术监督员、卫生红旗手及猿猿饲养员。
原本，贤惠的阿庄都替我把获奖感言写好了：在大家的通力协作下，我们攻坚克难，历经种种险阻，终于按时保质保量的交付了产品，这离不开每一个同学的认真努力和付出奉献，所以，这不是一个人的王者，而是团队的荣耀。
气氛组也早已准备好了，只等夜曲一响，上台领奖。
万万没想到啊，竟然在生产环境遇到了两次阻断，领导一高兴，就给我整了个绝活：来了个通报批评。
其实，犯得错误很低级：
开立虚拟户时，字段规则没有处理好，具体来说，我们只是从产品角度做了相应的规则限制，并没有逐一参考接口文档，最后导致客户信息超出规则限制，无法开立虚拟户，直接影响了业务的实际开展。
举个例子：
我们金融平台的用户（已完成注册、认证等），在开立虚拟户时，有这个字段叫“企业名称”，这个字段是回显用户注册时的数据，并不可编辑，而注册时这个字段的规则，是依据第三方电子签章的接口做的校验，其中，可以输入英文字符。
而我们的客户，企业名称为：xx（中国）有限公司。
逻辑是这样的：

这个企业名称在注册时，用户将括号输入成了英文格式，由于调用的第三方接口并没有限制英文字符格式，所以可正常输入英文括号。
用户在开立虚拟户时，回显该企业名称，同样，包括英文括号。
渤海银行的资金账户体系，该接口不允许包括英文字符。
其接口文档没有写明该字符规则，导致我们也没有做相应处理。
用户在开户提交时，直接报错，无法开户成功，影响实际业务运营，造成了很不好的影响。

因为在测试环境、仿真环境银行接口不校验，所以也没法提前暴露这些问题，以至于就因为中英文字符就阻断了流程。
这个错误实在是有点意外，但直接导致了生产环境阻断，所以说，我们产品被批评也是情理之中。
当时我们解决这个问题之后，便开始进行接下来的工作，我也没有细想，没想到啊，第二个客户在开户时，“经营地址”这个字段同样是因为包含英文字符，第二次在生产环境阻断。
鏡同学当时就被拉去祭旗了，而且，用的是锉刀。
事后，鏡同学仔仔细细地复盘了一下：
1）接口数据对接时，一定要将字段规则确定清楚、准确。
确定清晰的字段规则是产品经理的本质工作，这一点我们确实也做了，在PRD里页面元素描述时也有所体现。
但我们产品经理是有责任的，责任在于没有和第三方技术确认字段规则，因为对方接口文档不够详细，没有明确说不能支持英文字符。