相信很多做产品的同学都会遇到需求上线的情况，但并非每次上线都能发送成功邮件，感谢相关参与同学，大家皆大欢喜，然后开启另一轮产品迭代。那遇到上线失败时该怎么办呢？笔者根据自己过往经验总结如下办法，供大家相互交流讨论：

首先，要分析为什么会上线失败？

        上线失败的原因其实有很多，归结起来主要是如下几方面的原因：

1、产品经理的原因：产品在设计之初考虑不够周全，临上线才知道还有某个需求/某个需求考虑不够周全，此时研发和测试完全来不及开发和测试。

2、研发同学的原因：

测试环境的服务与预发布环境或生产环境有差异，导致测试环境正常，而生产环境出现错误；

研发代码bug，不解释，没有bug的研发都不是好研发；

代码分支合错，不解释，研发同学偶尔有出现粗心的时候；

3、测试同学原因：测试验证不够周全，仅验证了需求本身，没有回归验证全链路产品；

其次，分析能否挽回失败？

对于某些研发原因，比如代码分支合错，部分小bug之类的，其实是可以当天修复当天上线的，但是也需要看测试和研发同学的实际工作情况，个人建议还是以稳为主。

最后，上线失败怎么处理？

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

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

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

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

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

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

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

亲自电话与需求提出方沟通对齐，告知对方补救的方案和时间计划；

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

给个案例参考，欢迎相互交流

各位业务同学、领导：

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

xxx产品部

2021年8月2日