我们无法保证每次的功能更新就一定会受到用户欢迎，这种时候，就需要版本回滚。但回滚对产品来说可是一个巨大的失误。这篇文章，我们来看作者分享的经验。

“让我往前走可以
千万别让我倒退
后面有坑可不一定看得见！”

每个产品经理都希望自己的产品一往无前，就像战场上的冲锋兵。但现实中，却可能都出现过不得不面对的“产品倒车经历”。

2023年5月经历过一次两天业务试用，然后由于暑期流量高峰来临，识别到业务层面的备货风险而被临时叫停的产品上线。以至于主线产品所涉及到的几个耦合上线的数字化业务系统，需要整体回滚处理。

一、回滚的处理过程，涉及到几个方面

• 程序代码层面的版本回退
• 系统已产生数据的处理
• 业务模式的回退

其中，代码的版本回退，是产研团队经历比较多的，一般大点的版本发布都会预留有版本回退的考虑和降级方案。

至于业务模式的回退，如果不涉及对c端流程的变化，那么更多的是内部协作问题，产品上线前产研团队也有义务知会业务团队思考降级业务预案。

而我面临最尴尬的，则是业务在产品试用期间已经是做的正式业务数据了。另外，有一个业务流程，原来是在一个系统里面完成的，上线之后是数据源和末段的输出挪到了另外一个系统，原来系统仅保留了核心的算法计算和处理的部分；因此不只是系统代码回滚、业务模式回退，还加上要处理“身首异处”的数据。

数据处理，我们会首选通过业务调整方式进行数据的调整、修正，即由业务人员通过正常的系统操作实现数据的修正（新增、删除、对冲等）。在业务处理无法实现的情况下，不得不通过上帝之手进行接入：修数据、程序处理，这时候需要产品、研发人员介入，通过程序的修改、数据库的修改来实现对已有系统数据的修正。

而这种方法在产品经理的世界里，越少越好，可以参考之前我们分享过的文章：《产品经理怎么老想着改数据，还玩不玩儿？》

二、事后，忍不住回顾整个过程

首先，产品设计是基于了一定的业务假设进行的，但是团队内部不同业务线的这个业务假设差异巨大，可行性不可同日而语。对有的业务线是易如反掌，对有的业务线则是如山如海。所以从产品路径实现上面，并没有非常优秀的因地制宜的路径。

其次业务的落地意愿YY过于强烈，以至于步子太大扯淡了。强行继续下去的结果，怕少不了各个相关方互相撕逼大战了。当初业务风险识别到了，但是风险的评估和应对显然非常缺失。

即便系统的优化再去做，整体来看也只是工具、术的层面，并不能解决道、法层面的根本问题。结构化的困局，并不是产品路径和优化可以强行解决的。

往后走处理问题倒是也不难，团队通力配合也是轻而易举。

反而很奇怪的现象，越是这种情况，大家配合的意愿、协同的顺畅度、主观能动性反而会比日常工作不知道要高出好多个level。团队的凝聚力、默契反倒是有增益的。

只是对于趋于敏捷的团队来说，团队积极性确实会有损伤。不断的迭代冲刺和交付过程，商业（业务）、技术、产品不得不拧成一股绳形成合力冲刺，尽量减少团队间的斗志消耗和摩擦为上上之选！