编辑导语：很多做产品的同学，在需求上线时，本应该皆大欢喜，却突然出了岔子，需求上线失败了该怎么办？作者分享了需求上线失败的原因以及应对的方法，我们一起来看戏吧。

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

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

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

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

1. 产品经理的原因

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

2、研发同学的原因

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

• 对产品需求的理解存在偏差，比如产品需求本意是希望做到账号维度的数据权限区分，而开发同学理解成了角色维度的权限区分；
• 粗心了，多写了一个标点符号或者用错标点符号，虽然这个错误很低级，一般是新手研发容易犯这种错误；
• 方法错误，对实现某种逻辑的方法存在问题，导致实现效果与预期存在偏差；
• ……

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

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

3. 测试同学原因

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

二、分析能否挽回失败？

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

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

• 问题产生的原因是什么？
• 问题的修复方案是什么？
• 修复方案的责任人和时间需要多久？

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

三、上线失败怎么处理？

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

1. 后续处理方案和计划

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

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

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

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

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

2. 周知相关方

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

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

四、案例参考

各位业务同学、领导：

非常抱歉周知你xxx需求因xxx原因上线失败，针对该原因，我们同产品、研发、测试及业务同学沟通商讨出xxx方案，该方案计划xxx时间点完成上线，责任人分别是产品-xx，研发-xx，测试-xx，请各位周知，若时间点存在改动，我会提前周知大家，谢谢。

xxx产品部

2021年8月2日

作者：iJob，如果你对商业、产品感兴趣，欢迎交流沟通，微信公众号：商业案例研究

本文由 @企荣之路 原创发布于人人都是产品经理。未经许可，禁止转载。

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