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

2 评论 8889 浏览 10 收藏 10 分钟

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

背锅,其实是个技术活。

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

事情大概是这样的:

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

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

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

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

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

其实,犯得错误很低级:

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

举个例子:

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

而我们的客户,企业名称为:xx(中国)有限公司。

逻辑是这样的:

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

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

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

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

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

事后,鏡同学仔仔细细地复盘了一下:

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

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

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

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

↑-文档里没写不支持英文,但应该确认

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

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

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

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

企业名称没有做好字段限制,在出问题后,应该第一时间类比全局和思考,不仅要洞察问题的本质(划重点:一个高阶产品经理必备的隐性技能)。产品经理也一定更要有敏感意识(敏感意识,高级产品经理的首要技能。),我们最初并没有意识到,只是排查到是这个字段规则有符号,就只解决了这一个字段。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#专栏作家#

产品大峡谷,公众号:产品大峡谷,人人都是产品经理专栏作家。七年B端产品经理,供应链物流与金融领域,擅长需求设计、业务指导、商业观察等。

本文原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 哇塞 你竟然直接把业务方的名字打了上来 是不是有点不好

    来自广东 回复
    1. 多谢提醒哈,不过已经脱敏的,这个实际是第三方支付公司,重点是想表达咱们在产品设计时需要注意字段规则。

      来自河南 回复