写在前面

如果你在工作中碰上那些给你挖坑或者带你踩坑的猪队友，你会怎么办？

正文

后台有个老铁就跟我说了这么一件事。

他是产品经理，上周刚加班搞定一个老板很重视的需求，熬了几个夜终于上线了。

这周陆续收到用户反馈，说其中一个功能的历史数据没有了，各种投诉就直接过来了。

在后台一查，原来是新版本完全覆盖了老版本的数据，没有做数据上新老版本兼容，导致更新了新版本的用户看不到之前的老数据。且后台上线后，老版本的用户也看不到之前的数据了。

这个问题最先被反馈到产品经理这，产品去问测试，测试说已经都测过没问题才发包的。产品去问研发，研发说新版代码里已经做了数据兼容的调整。

没办法，让研发老大带着下面的人去检查线上代码，发现提交上去的代码中果然没有完成数据兼容。可去发布前的测试代码中一看，这部分代码却存在。

原来，最后提交代码的程序员没有把这部分代码合并到主分支里面去。

因为表现层的功能测试都没问题了，且数据代码也写好了，所有人都以为万事俱备，没想到被一个代码提交给搞砸了。

幸亏数据有备份，经过恢复处理后这才回归了正常。

原本大家等着靠这个项目拿个季度奖，没想到被队友给坑了，而且是一个本该完全避免的失误。

所以，产品测试完没问题真不是最后一步。在有条件的团队，一定要做灰度上线，把出问题的概率控制在最低。

据我了解，微信团队每次更新产品都是逐步灰度放量，一旦遇到问题就立马回滚，非常灵活。

这些都属于产品技术的基本功，在快速跑需求的同时，也得时刻降低技术负债，多给自己留一些后路。