技术大神忽视业务背景,3次翻车教训

软件架构师和工程师(就是那些设计软件和写代码的高手)根据自己的经验、喜欢用的技术和非功能性需求(比如系统要跑得快、不能卡顿这些要求)来做技术决定。但就算最牛的程序员也会翻车,因为他们经常忘了考虑业务环境——比如用户到底要什么、公司团队实际会哪些技术、钱够不够花这些事。今天我就讲3个真实翻车故事,都是因为没考虑业务环境把软件搞砸的。

第一个:Parse怎么死的
Parse是个很火的移动后端服务(就是帮做APP的人省事的云端工具),不用懂数据库也能快速搭后台。最开始Parse用MongoDB数据库(一种非关系型数据库),图的就是扩展方便、速度快、存JSON数据顺手。但Facebook的工程师团队更熟悉MySQL(另一种关系型数据库),收购后非要硬把Parse从MongoDB改成MySQL。

这个决定纯粹是Facebook自己用着顺手,根本不管Parse原来的用户(那些APP开发者)要的是简单好用。结果迁移过程又慢又难,Parse变得特别难用。

最后用户全跑光了,Facebook在2017年直接关了Parse,坑惨了几千个APP开发者。
教训:死抱着自己公司熟悉的技术,不管被收购产品的用户要什么,等于亲手毁掉它的价值。

第二个:Airbnb用React Native翻车
2016年Airbnb想用React Native框架(一个能同时写安卓和iOS代码的工具)来省时间。虽然技术看着很美好,但他们没料到:做复杂动画时卡成狗、用户嫌不够流畅、最后还是要给两个平台分别写代码。

折腾了两年白花钱,团队天天吵架,功能也做不出来。2018年Airbnb公开宣布放弃React Native,老老实实用原生的安卓和苹果开发工具。
教训:光图省事选新技术,不看看实际业务需求和用户感受,最后又烧钱又闹心。

第三个:GitLab数据删库事件
2017年GitLab(一个代码托管平台)因为没好好做数据备份,有个工程师手滑删了生产数据库,结果备份根本恢复不了——其实他们早该测试备份方案,但一直没当回事。

网站挂了18个小时,虽然他们道歉态度很好,但企业客户全炸了,直接导致客户流失。后来不得不疯狂补窟窿,其他正经工作全耽误了。
教训:对企业级产品来说,不把系统稳定性和数据备份当命根子,分分钟让你见识什么叫社会性死亡。