从0到1,创新项目架构取舍之道

2020 年 4 月 10 日

从0到1,创新项目架构取舍之道

大家好,我今天的分享主题是“从 0 到 1:创新项目架构取舍之道”。大概一两年前,饿了么的 CTO 在会上问大家,你们觉得像饿了么这样级别的互联网公司,最重要的资产是什么?作为一个技术领导者,有没有考虑过这个问题?到底是数据、代码、客户、人才、系统?其实到最后会发现每一种资产都很重要,还有创新能力也非常重要。

我今天也会提到一些这方面的考虑,主要内容是以下四点:

创新项目从 0 到 1 架构演进策略:一个项目从 0 到 1,你要上来就搭个大的架构还是慢慢来?顾虑是对手可能比你还敏捷,中间有很多环节顾不上,别人上的我也要上,那怎么办?
成熟技术体系中如何快速创新:饿了么这么大一个公司,已经拥有成熟的体系,如果想做一些创新,怎么才能实现?
敏捷迭代中的技术债如何偿还?
技术怎么与创新业务齐头并进?这两点都围绕技术问题展开,情况是开始可能技术不够成熟,后面功能越来越丰富,数据越来越多,是不是可以做技术驱动业务的事情?

一、案例引入

我们用一个案例来分析:去年饿了么做了无人货架这个业务,无人货架是 2017 年新零售行业的一个风口,很多公司的办公室里面都有。去年的 9 月份开始,到现在不足一年,所以还有很大的发展空间。它的作用是放在办公室里面,如果你饿了,想吃点什么喝点什么,走过去扫码就可以。

为什么它是新零售的风口?跟你在路边买水果直接扫码有什么区别?我们展开来讲:

  • 无人货架模式定位在办公室里,这是一个封闭的公共空间。如果想吃饭可以叫饿了么,但是想吃点零食或者喝点水,无人货架三十秒之内就可以拿到手,而且不用考虑我什么时候去买去囤,因为随时都可以。

  • 货架面对空间里这么多的人,核心问题是怎样最大程度地满足需求,以及在此基础上是否能给一些新的口味。甚至再进一步,在这些流量上能不能做一些拓展,架子上没有的东西是不是也可以卖,比如新鲜水果。很多公司可以看到有冷柜和热柜,热柜负责保温的,标准化的场景是可以热乎着吃,放个豆浆、包子等。所以无人货架是一个很好的零售业务场景。

  • 我们可以对接企业的需求,比如老板看大家挺累,我们来喝个下午茶,买光架子上的零食水果,大家随便吃也没多少钱。所以这个模式有很多展开空间,未来行业里,会有更多的玩法。

二、创新项目从 0 到 1 架构演进策略

去年 8 月 6 日业务团队提出要试水项目的时候,我们知道一些创业公司做的风生水起,甚至一些大公司比如京东、顺丰、苏宁都已经开始进入这个领域,包括后来的猎豹。这个业务上我们是后来者,后发优势就是你知道别人是怎么做的,但面临的压力也很大。试水期间(8 月 6 日~23 日),我们做了商品调研、业务场景调研,也提了一些解决方案,跨部门协作开发,还做了 Demo 在公司里试用。

9 月 6 日无人货架项目立项;9 月 20 日 V1.0.0 产品正式上线。整个过程看起来还比较顺利,业务总体反馈也都比较好。但是当时这个项目没有任何后端体系,比如营销后台、运营后台、供应链等,就是业务团队去买一堆货,自己往上面放,这种模式完全不可控,不具备扩展性。

11 月 20 日,我们打通了饿了么当时原有的供应链系统。到今年 3 月 5 日,对接饿了么新零售地网供应链系统,采购仓储物流这些都打通了。CRM、预售、拼团、鲜食等都是今年上半年我们做的一些拓展尝试,下一步也会做智能货柜。

三、成熟技术体系中如何快速创新?

我们说一下成熟体系和创业公司的区别是什么。

饿了么拥有一个大型、成熟、弹性、多活的技术体系。日订单量千万级别,整个技术团队上千人,系统指标要求很高,所以基础设施必须完善,不可能靠人力天天操作;架构设计有严格的评审机制和一套规范的操作流程。2017 年饿了么做了一个行业比较牛的“异地多活”,在两个机房之间可以调度流量,并做日常演练。最后就是容器化、混合云、计算力外卖等,这些关键词大家可以网搜一些文章了解一下。面对这样的体系,我们刚才说的无人货架这种短平快小项目如何应对?

分析一下其中优劣:

  • 首先要求一定是快,而且需求可能变。今天这么玩,明天一拍脑袋那么玩,即敏捷迭代,快速试错,灵活响应。你不能跟他说你能不能有点谱,因为大家都不知道该怎么玩。那优势在于饿了么有非常完善的机制,高水平人才充足,比如我们想成立一个团队,拉起来很容易。业务立项会分到某一个技术团队,前后端测试、项目管理等的磨合过程中,团队配合度已经很好。不必从 0 到 1 建设一个新的产品技术团队。

  • 但是劣势就是我们有太多条条框框,由于饿了么体系很大,架构规范严格,不可能自己再做一套用户体系,不可能自己做支付,一定得对接公司的。那就得跨团队沟通。做这样一个试水的创新项目,跟公司整体项目的级别一定是不匹配的。有时就是需要去刷脸,才能把这些提上去。

  • 最后,如果我们今天数据出了一个 bug,想把数据修一下,不行。按照严格的操作流程,这个事情不能你去操作;而且要进行评估:风险有多大,一次要多少条,会不会对性能有影响。这个时候可能业务团队已经忍不了,所以其实是优势劣势并存的。

我们要把这个事情做成的话应该怎么办?首先得有一支能打的团队:召之即来、来之能战、战之必胜。我们搞的是一个独立的项目,全新的系统,但是所有参与项目的人,都是从各个团队拉过来的。团队都坐在一起,在“小黑屋”里,环境相对来说封闭,能更专心,更高效,更团结一心。以创业的状态进行,把所有的任务都排好然后开始开发,最后所有的任务都是完成状态。

上帝用七天创造了世界,我们最终用六天把这个项目做好了。期间有什么事情?除了刚才讲的攒人,还有对架构的取舍。

  • 微服务:虽说一开始没有那么多要拆分的微服务,但是毕竟是互联网主流架构,要把系统做得特别灵活,为了能拓展。但也不需要考虑那么远,所以有考虑,以后再说;
  • 技术栈:饿了么现成的拿过来用,大家都熟,再选择其他技术栈是不太可能的;
  • 自有的 IDC:很多创业公司都是在阿里云上做起来的,我们当时也考虑说是不是干脆找个阿里云。阿里云都在自己手里头,想怎么玩怎么玩,不用关心公司的条条框框。但是最后想了一下,还是要用自己的系统。因为比如你要跟公司的用户系统、公司的用户系统、支付系统打通,你不能说我外挂一下,除非自己做。不能自己再做一套基础的体系,成本太高了。跟很多创业公司不同,他们往往数据库只有一个,反正用户数据少,能活着就行,但我们在一个体系里面,这些技术是现成的,我们要用;
  • 异地多活:有没有必要呢?有必要,但是暂时可以绕过。因为我们一般切换服务的时候是在晚上,是有人在办公室甚至熬夜到两三点钟会用无人货架,但是毕竟不是常态。我们先不考虑多活,因为实现多活更复杂;
  • 中间件:一定是公司现成的,包括数据库的中间件,数据的备份等;
  • 测试环境:也是公司现成的,同上;
  • 持续部署:需要知道谁发了什么版本,而且要有工具想回滚就能回滚;
  • 容器化:暂不考虑,我们直接来台虚拟机当成裸机来用也 OK,容器化有更高的技术复杂度,我们现在只要做一个简单的业务跑起来;
  • 日志监控:日志监控这个体系是公司现成的,对当前的业务有很大帮助。当时我办公室的电视上接了个监控视图,有天早上一看,业务量爆增,我说这一定有问题,查了一下发现有人在爬我们的数据,这种情况如果没有监控,你根本就不知道。

四、敏捷迭代中的技术债如何偿还?

同样的我们欠了很多债,下面分析一下:

  • 业务层:包括一开始只是设置价格就进行销售,没有做营销、促销,运营的策略等。比如说在不同架子的相同的位置上摆不同的货,这些都是后来做的,一开始没有考虑,都是放上去就 OK。供应链,业务级的监控,权限(运营、业务操作等这些权限),一开始也没有做那么多,是后来补上的;
  • 应用层:反爬、埋点、缓存、搜索、多活等这些也是这样。多活,刚才说了,影响不大但是是有影响的;
  • 数据层:我们一开始对用户的行为数据没有埋点收集(比如,他进来浏览了多少东西然后跳出了,或者他点了什么是不是失败的),当时没有考虑那么多。但毕竟有个基础的东西在,比如最后一个爬虫,我们做好了也可以爬别人,看看其他公司的怎么样;
  • 系统层:容器化暂时不用。

对于现在这个架构,我们做的取舍其实是一种选择,以最快满足业务上线,具备基本功能为目标,而不是一拍板就定了。

五、技术怎么与创新业务齐头并进?

再往下延伸,要考虑几个问题:

  • 调整策略,从突击队到正规军:现在我们已经有上万的点位,已经有稳定的业务,那后面如果想怎么着就怎么着,想怎么变就怎么变,想怎么玩就怎么玩,想怎么抓数据就抓数据,这个一定是有风险的。一开始,从 0 到 1 搞起来,这个阶段有点损失没关系。但是一旦业务、技术、运营都是稳定团队的话,就需要转换你的战略。不再用突击,要用正规军的方法;

  • 控制节奏,提高协同效率:我们会调整我们项目的结构,提高协同的效率,大家提前做沟通,做一些规划;

  • 合理分配资源,偿还技术债;

  • 架构规划,模块拆分;

  • 沉淀数据,智能运营:把这些数据收集起来,一个业务没准两三年以后能有更大的市场,那这些数据沉下来就是有价值的。比如前两天饿了么就在准备重启一个去年被停掉的项目,那个项目之前运行了大概两年,一旦老板决定重启,我们所有的代码、数据都还在,可以随时使用。不过要想重启,可能最大的问题是人,就是原来那些人去做其他项目了,有多少人还留在这个团队都不好说。但数据代码的资产都还在,很快就能拉起来;

  • 做减法,保持架构健康度:之前做这么多需求,业务团队有这么多想法,现在都还有用吗?不见得。很可能一个东西上来之后发现用户不买账,但它还是系统的一部分,依然天天运行着,还要考虑他的运维等,这时候做减法更能保持架构的健康度。

六、总结

所以总结一下:在风口创新里面,快一定是第一位,天下武功唯快不破。既然技术要去支持业务,那绝对不能拖后腿;但从 0 到 1 并不需要想那么多,以 MVP 为第一目标,不追求技术先进、架构完美。

还有,既然我们是一个比较成熟的体系,而且相对来说更有经验,那么我们要适度地前瞻一些。把产品、把架构设计得稍微好一点、灵活一点,将来拓展就不用改太多,不用推翻了就要重来,然后针对不同阶段、不同策略,适时做一些调整。

最后,技术上,先支持业务,深入理解业务,再驱动业务。一开始业务人员让你干什么你就干什么。接下来你还要深入理解,然后才能和业务的同学平等对话。如果业务是比较轻量级,2C 的,这种情况下大家要互相沟通。如果你已经做的量级非常大,可能从业务、从运营的角度来讲,难以了解全国情况,比如我们做的 O2O,基于地理位置不同,各地都不太一样。全国各地业务什么特点这都不好说,需要有一个强大的体系把数据收集起来,去做数据分析,去做策略指导业务,而不是靠一个人即兴的想法。所以我们要做到更好,就需要更多的数据,根据这些数据来分析用户,可以去看我们业务的趋势,能做一些更好的指导,接下来可能成为用技术驱动业务。不是说用人员驱动业务,而是一套比较大的系统,这个系统能够驱动业务,把公司业务能力固化在体系里。

最近一个在政府单位工作的同学和我聊起创新,创新很重要,但更重要的是有没有一个合理的体系,换句话说就是不能指望某个人力挽狂澜,不是一个有志之士想激发创新,就能创新。要靠一个公司或者一个组织,要有活力,要能保证多样性,要能够实时变化,这需要一套体系。所以在座的各位手里都有那么多数据,希望我们可以给后面的人留存更多的资产,能给我们后面的业务给予指导和帮助。

Q & A

Q1:快速迭代的时候,你的时间有限,像这种时间控制里面有什么东西?

A1:没有更多的选择,但是一旦你迭代的节奏调整过来,每个迭代多少大家都是有数的,而且一个比较好的团队有这个优势,开发一定要自测。

Q2:货架的数据是从哪些维度进行收集?

A2:比如登录网站,或者打开一个 APP,你是在什么样的环境下(4G、3G、WiFi 还是其他的),还有比如你使用什么样的手机、登录进来之后你先点了什么,这些都是可以记录的。最常见的,如果你前面的页面做得不那么友好,可能用户找不到他想要的东西,因为手机屏幕很小,需要翻页,那么怎么翻是合理的?一定是按照货架上的顺序吗?不见得。一开始大家都在乎货架上的顺序,从上到下第一层、第二层、第三层、第四层,但是我可能上来就想拿最底层的。或者说如果有促销,那把促销的东西放在最上面,让人看到,给他引导。这些东西可以通过你的布局操作,但前提是有数据,你才能进行设计,不然你不知道他是不是按照你预想的来做。

本文转载自 IT 民工闲话 公众号。

原文链接: https://mp.weixin.qq.com/s/w_bnKYmg5_8KZx3H9Xp6RQ

2020 年 4 月 10 日 14:37 125

评论

发布
暂无评论
发现更多内容

ARTS打卡Week 02

teoking

objective-c LeetCode WebRTC

工作 vs 生活

shengjk1

B端产品经理养成记(2):用户故事

涛哥

产品经理 需求 产品开发

做PO难,难于上青天

刘华Kenneth

敏捷 产品经理 决策 PO

B端产品经理养成记(1):业务场景

涛哥

产品经理 需求 产品开发

戒掉手机吧

鼎玉谷

人生 手机 时间 浪费 控制

draw.io-取代visio的流程图绘制工具

Rice嵌入式开发技术分享

chrome vscode 写文章神器 draw.io

不吹不黑!GitHub 上帮助人们学习编码的 12 个资源,错过血亏...

JackTian

GitHub 程序员 编码 开源项目 学习资源

时代在变,产品运营能力很重要

夜来妖

程序员人生 程序人生 产品经理 产品推荐 程序媛

【ARTS打卡】Week01

Rex

学习笔记

【5月】本月读书学到了什么

Neco.W

创业 读书感悟 阅读量

使用Kotlin语言初始化数组

mengxn

数组 kotlin 初始化

RocketMQ - 高可用设计

Java收录阁

RocketMQ

1 ARTS 2020-05-31

3.141516

LeetCode

游戏夜读 | 关于构图的困难

game1night

写博客的那些事

shengjk1

RocketMQ - 如何实现事务消息

Java收录阁

RocketMQ

钢铁侠马斯克之仰望星空

池建强

创业 马斯克 Space X

ARTS Week2

丽子

Kafka系列9:面试题是否有必要深入了解其背后的原理?我觉得应该刨根究底(上)

z小赵

大数据 kafka 实时计算

John 易筋 ARTS打卡Week 02

John(易筋)

ARTS 打卡计划 ARTS活动 arts

【openlayers】在vue中使用ol

学习委员

JavaScript html Vue 地图 openlayers

Element-UI实战系列:Table+Pagination组件实现已选和全选功能

brave heart

Vue 前端 Element

工厂模式(四)泛型工厂之MyBatis Mapper代理

LSJ

Java 设计模式 泛型 工厂注册中心

如何用CSS选择符(数字开头) 杀死队友

学习委员

JavaScript html css3 Web 前端鬼画符

MAC OS 下 HomeBrew 使用

耳东

macos brew homebrew

你会写测试用例吗

鱼贩

ARTS(2020-05-25/2020-05-31)

天行者

正确阅读

ARTS week 2

刘昱

转行程序员浅谈进程间的socket通信

WB

Linux socket 转行程序员

ARTS打卡第一周5.25-5.31

我笔盒呢

从0到1,创新项目架构取舍之道-InfoQ