产品上线后“暴雷” 如何优雅地“背锅”？

上周二鏡同学负责的项目终于上线了， 上线后就成功“暴雷”了。

事情大概是这样的：

记得那是一个冬天，漫天雪花，我们 应收账款融资产品需要对接第三方资金体系 ，从而实现线上客户资金的支付，当然，作为技术平台产品， 我们定位是搭建支付通道，并不实际触碰资金， 我们是同第三方支付技术平台公司做对接，背后的资金体系实际是渤海银行。（ 后续有类似产品设计时，大家可参考定位 ）

于是乎，我们成立 资金体系项目小组 ，鏡同学亲自担任小组组长，兼产品汪汪、协调队长、技术监督员、卫生红旗手及猿猿饲养员。

原本，贤惠的阿庄都替我把获奖感言写好了：在大家的通力协作下，我们攻坚克难，历经种种险阻，终于按时保质保量的交付了产品，这离不开每一个同学的认真努力和付出奉献，所以， 这不是一个人的王者，而是团队的荣耀。

气氛组也早已准备好了， 只等夜曲一响，上台领奖。

万万没想到啊，竟然在生产环境遇到了两次阻断，领导一高兴，就给我整了个绝活： 来了个通报批评。

‍ ‍

开立虚拟户时，字段规则没有处理好，具体来说，我们只是从产品角度做了相应的规则限制，并没有逐一参考接口文档，最后导致客户信息超出规则限制，无法开立虚拟户，直接影响了业务的实际开展。

举个例子：

我们金融平台的用户（已完成注册、认证等），在开立虚拟户时，有这个字段叫“ 企业名称 ”，这个字段是回显用户注册时的数据，并不可编辑，而注册时这个字段的规则，是依据第三方电子签章的接口做的校验，其中， 可以输入英文字符。

而我们的客户，企业名称为：xx（中国）有限公司。

逻辑是这样的：

1. 这个企业名称在注册时，用户将括号输入成了英文格式，由于调用的第三方接口并没有限制英文字符格式，所以可正常输入英文括号。

2. 用户在开立虚拟户时，回显该企业名称，同样， 包括英文括号。

3. 渤海银行的资金账户体系，该接口不允许包括英文字符。

4. 其接口文档没有写明该字符规则 ，导致我们也没有做相应处理。

5. 用户在开户提交时，直接报错，无法开户成功，影响实际业务运营，造成了很不好的影响。

因为在测试环境、仿真环境银行接口不校验，所以也没法提前暴露这些问题，以至于 就因为中英文字符就阻断了流程。

这个错误实在是有点意外， 但直接导致了生产环境阻断，所以说，我们产品被批评也是情理之中。

当时我们解决这个问题之后，便开始进行接下来的工作，我也没有细想，没想到啊，第二个客户在开户时，“经营地址”这个字段同样是因为包含英文字符，第二次在生产环境阻断。

鏡同学当时就被拉去祭旗了，而且，用的是锉刀。

事后，鏡同学仔仔细细地复盘了一下：

1，接口数据对接时，一定要将字段规则确定清楚、准确。

确定清晰的字段规则是产品经理的本质工作，这一点我们确实也做了，在PRD里页面元素描述时也有所体现。

但我们产品经理是有责任的，责任在于没有和第三方技术确认字段规则，因为对方接口文档不够详细，没有明确说不能支持英文字符。

2，处理技术对接需求时，要查看接口文档。

如果有条件，还是建议产品同学，在遇到对外接口对接的需求设计时，看一下需求文档，重点看一下接口字段规则的定义。

同时，产品规则一定要满足接口标准，所以，一定记得和第三方技术做沟通确认。

3，出现问题要有类比意识，同步核验同类的产品规则。

企业名称没有做好字段限制，在出问题后，应该第一时间类比全局和思考，不仅要洞察问题的本质，产品经理也一定更要有敏感意识，我们最初并没有意识到，只是排查到是这个字段规则有符号，就只解决了这一个字段。

结果在 “经营地址”这个字段上， 又出现了同样问题，同样也是包括英文符号，导致又线上阻断，我们特别被动，客户体验极差，业务受连累，显得我们产品设计不够专业，项目的过程管理也不够精细。

4，组织沟通解决时，要形成书面记录。

鏡同学当天下午紧急组织了沟通对接会，组织我们技术人员同第三方人员召开视频会议，重新梳理了所有接口对接的字段规则。

这里提醒下，会议沟通前，产品要将需要沟通的问题，比如，字段规则提前罗列清楚，等待对方确认，方便高效沟通。

同时，如果有和第三方对接的功能设计，产品经理牢记一定要达成共识， 形成书面成果，避免沟通偏差 。

5，风险识别后，通知相关方。

在这个功能修复后，其实无法在仿真环境测试，必须在生产环境才可以测试， 这个属于风险点，意味着，生产环境仍有可能存在问题。

这是因为银行测试环境接口不开放，属于技术限制，可以理解，但产品经理更应该注意的是，要识别到这是一个风险，记得提前给相关方发送邮件，尤其运营人员，说明风险点和应对方案，抄送给所有需要的人，也便于协同应对。

这次暴露出来的问题，让鏡同学还是深有触动，更加意识到基础产品设计不做详尽和彻底，抱有侥幸心理，则大概率就会存在墨菲定律。

出现问题，正确的应对态度， 首先应该是解决问题， 比如，我们应该及时组织沟通会； 其次应该是分析原因，找到根本之法， 比如，我们如果意识到是字段规则设定不一致的问题，就会全局梳理，而不会等到第二次暴雷； 最后，一定要有敏感思维， 吸收教训，转化为成长经验。

其实， 错误本身也是发现真理的加速器， 每个产品同学在日常工作中，不可避免的会遇到各种产品错误或者产品事故，重要的是如何应对。

而将错误转化为成长经验，这可能才是正确的“背锅”姿势。

··················END··················