产品经理系列（8）：需求上线失败怎么办？

产品基本功 2023-07-31 04:45:09

相信很多做产品的同学都会遇到需求上线的情况，但并非每次上线都能发送成功邮件，感谢相关参与同学，大家皆大欢喜，然后开启另一轮产品迭代。

那遇到上线失败时该怎么办呢？笔者根据自己过往经验总结如下办法，供大家相互交流讨论：

一、分析为什么会上线失败？

上线失败的原因其实有很多，归结起来主要是如下几个角色的原因导致：

产品在设计之初考虑不够周全，临上线才知道还有某个需求没设计，导致流程无法闭环，此时研发和测试完全来不及开发和测试，比如履约过程中缺货标记之后，没有缺货订单的处理逻辑；
产品设计本身存在缺陷，在测试验证的过程中，发现按照新版本的产品需求，与该需求之前的逻辑或者别的需求存在逻辑冲突，是一个此对彼错的情况，比如数据需求中相同数据指标，不同统计口径，将会导致用户对数据的信任度缺失而弃用产品。

研发代码bug，俗话说，没有写过bug的开发不是好开发，而产生bug的原因有很多：

测试环境的服务与预发布环境或生产环境有差异，导致测试环境正常，而生产环境出现错误，测试环境与生产环境的配置不同，这个问题在绝大多数的公司都存在，基于成本考虑，测试环境的流量相对于生产环境没那么大，所以基本上是测试环境的服务配置低于生产环境，而不同的服务配置可能导致代码的运行效果不同。

代码分支合错，这个问题虽然不常见，但是在我无数次上线失败的经历中，还真有不少研发同学犯这个错误，其实对于做过开发或者熟悉开发代码合并流程的同学应该知道，代码分支的命名基本都是英文的，而相近版本的命名更相近，在不注意的情况下，是很容易合并错误的。

测试验证不够周全，仅验证了需求本身，没有回归验证全链路产品，导致局部功能正常，但是完整的数据流存在问题，比如会员卡状态禁用，只保障了卡状态的禁用功能正常，但是对于会员卡状态的状态广播未做测试，导致POS业务没有收到状态变更，引起POS仍能刷卡消费，而实际系统已经无法积分和消费，产生错误；
测试分工出现遗漏，临上线才知道某个需求无人来测。这个错误很少发生，但是对于大型复杂系统来说，其实容易出现这个分工偏差。

这个其实就需要具体问题具体分析了，对于某些研发原因，比如代码分支合错，部分小bug之类的，其实是可以当天修复当天上线的，但对于方法错误等比较复杂的错误，其实很难短时间解决。

那么怎么决定能否挽回呢？建议拉着相关产品、研发、测试同学一起，就相关问题进行讨论，主要讨论三点：

最后形成结论，该问题是否需要当晚进行修复。

如果经过产品、研发、测试同学的原因分析，综合评估发现不能当天修复上线，那就需要做好以下两件事：

针对不同的原因，输出不同的解决方案，并对解决方案制定相关责任人和时间节点，建议沟通的内容形成既要，可以群通知，也可以邮件周知，主要包括：

【背景】：上线失败的原因说明；

【方案】：失败原因的处理方案；

【计划】：处理方案的时间节点

【责任人】：处理方案的相关责任人及分工；

主要包括业务方、相关领导。这里有两个点需要注意一下：

亲自电话与需求提出方沟通对齐，告知对方补救的方案和时间计划；
邮件周知相关方：邮件的内容建议与相关产品、研发和测试沟通对齐话术，避免存在理解偏差，造成不必要的团队不和谐。之前我遇到一起就是没有与研发和测试沟通对齐话术，而是直接生硬地说了失败的原因和计划，其实本身是没错的，只是对于问题的责任方可能不太好，可以润色一下话术，尽量强调改进方案和计划，弱化问题的责任方。