抖音技术能力大揭密!钜惠大礼、深度体验,尽在火山引擎增长沙龙,就等你来! 立即报名>> 了解详情
写点什么

专访饿了么张雪峰:未长夜痛哭者,不足以语人生

2016 年 5 月 12 日

潘石屹说,现在是创业的黄金时代。饿了么作为中国互联网创业圈大只独角兽,2014 年底研发团队大约 35 人,2015 年春节后翻番到了 70 人左右,2016 年春节后上海、北京两个研发中心达到近 900 人,预估 2016 年中接近 1000 人。在此过程中,随着业务极速发展,组织架构变化、研发流程优化更是家常便饭,个中酸甜苦辣。不过无论如何变化,有一点却是不变的:研发管理,没有所谓 Best Practice(最佳实践),只有适应业务发展且生命周期有限的 Suitable Practice。

2016 年 7 月 15-16 日, ArchSummit 全球架构师峰会将在深圳举行,本届大会,我们邀请了饿了么 CTO、 EGO 会员张雪峰老师,前来分享《创业团队极速发展过程中的分分合合》的内容, 讲述创业研发团队几十倍极速发展过程中的组织架构优化和流程优化的实践经验。

我们就来采访一下张雪峰老师,分享他这一路历程,以及饿了么团队一些有趣的独家内幕。

InfoQ: 在饿了么技术团队中,你能描述一下你作为 CTO 的角色职责吗?

张雪峰:主要是五方面职责:

  1. 找到合适人才;
  2. 组建合理团队;
  3. 稳定交付产品;
  4. 极致经营产品;
  5. 当然,个人认为最重要也是最难做到一点:如何让团队 continuously enjoy woking and result?如果无法让团队始终充满激情,不可能有持续极致成果。

InfoQ: 请介绍一下你离开携程加入饿了么的初衷,饿了么最吸引你的地方在哪里?

张雪峰:我外表看着文静或行事貌似稳重,但骨子里还是一个比较喜欢折腾的技术男。在携程稳定工作两年多后,出现了三个机会:
(1)携程鼓励内部创业,当时和几个志同道合同事准备申请内部创业项目,主要涉及旅行规划与全流程服务(大概是蚂蜂窝 + 世界邦 + 妙计旅行合体,不同点是可基于携程已有丰富数据积累),不过有点可惜,在集团层面汇报 BP 时被毙掉了;
(2)当时计划和几个朋友出来创业,做物流相关产品(不同于饿了么目前重点发展的[即时配送]);
(3)接受当时朋友 Mark(张旭豪,饿了么 CEO,四大饿人之首)、Raymond(汪渊,饿了么联合创始人,四大饿人之一)邀请,加入饿了么。

加入饿了么之前,我主要作为 Raymond 私人技术顾问,偶尔出出主意或聊聊技术。后来,Mark、Raymond 和我谈了几次,了解到我心有纠结后,直接告诉我,也别考虑什么大公司内部创业或和朋友出来创业了,直接加入饿了么,这两问题不都解决了吗?后来仔细想想,也真是这么回事,那就直接加入吧。

饿了么最吸引我的主要原因不是 big title,而是创始团队尤其 Mark & Raymond 给予的 fully trust。考虑加入一个新团队,最高层信任比其他什么都重要。另外一个原因就是年轻有冲劲,一个以 90 后为主的创业团队,感觉和我在携程时的 80 后为主乃至平级以 70 后居多的团队,感受完全不一样。

饿了么除了王祖蓝那句传播较广的“饿了别叫妈,叫饿了么!”,还有一句内部流传更广且被很多同学视为行动座右铭的话:饿了么,和你一起拼!

InfoQ: 2015 年你入职饿了么的时候,研发团队 100 人左右,而现在整个队伍已经超过 1000 人,你是如何看待这样的极速发展?

张雪峰:人数 10x 不难,主要难在三点:
(1)系统稳定性是否可以同步 10x 提升?
(2)需求同步 10x 爆炸后,是否可以有所为有所不为?
(3)个人认为最重要也是最难做到一点:组织架构是否可以持续敏捷并适应软件架构的不断变化与调整?

关于第一点[系统稳定性],主要涉及四方面建设:流程规范、理念提升、技术保障、高效工具。

关于流程规范,人少可以吼一嗓子马上解决问题,人多肯定不行,尤其人多了大家可能不在一个楼层甚至不在一个城市办公,流程规范虽有所制约,但必不可少。

关于理念提升,和技术文化还不太一样,很多时候,一起故障引发客人投诉或业务吐槽,或长时间无法恢复导致严重事故及业务损失,比不断强调系统稳定性或生产无小事更有效,很多时候,反面案例或身临其境都是最好的[理念提升]教材。

关于技术保障,在绝大部分大型互联网企业中都是核心技术团队,只不过,绝大部分时间他们都以 Silent Hero 方式坚守一线,为所有其他技术团队保驾护航。

在当前开源理念盛行、分享无处不在大环境下,高效工具(Engineering Productivity)不是没有,而是太多,无论拿来主义还是自研,关键看是否适应现有团队习惯(人少可以强扭,人多只能适应)。工具就像春晚,人人满意基本不可能,能满足大部分同学核心诉求即可(少数服从多数)。

关于第二点[有所为有所不为],主要还是取舍问题,PM 需要取舍,Arch 同样需要取舍。在团队爆炸、需求爆炸的极速发展阶段,对 PM 或 Arch 来说,绝大部分时间在做的事,就是[两害相权取其轻]。

关于第三点[组织架构和软件架构间关系],康威定律已经讲得很清楚,如果说有点新意,无非就是针对不同类型团队的 virtual/override。

InfoQ:在饿了么工作一年的时间里,如何带领整个技术团队?遇到过什么样的困难?经历了哪些重大事件的考验?

张雪峰:(1)#1 中已经提到,基本就是按这个思路和时序,不断循环优化;
(2)大困难主要两方面:系统稳定性 10x 提升,团队稳定性尤其中坚力量稳定性尽可能保持不变或在可控范围内波动;
(3)过去一年经历三次 P0 故障:红包金额发放异常、支付完成状态异常、机房核心主备全挂,这三次最严重级别 P0 故障,除了很对不起业务团队及 PR 同学,也让技术团队充分意识到 Design for Failure 重要性与必要性,总结起来就是:一障抵千言,没经历过重大故障处理或造成重大故障的技术人员,很难真正成长起来或独当一面(少数天才或天赋异禀者除外)。

InfoQ:可以介绍一下饿了么超高订单流量所带来的压力背后的技术支持吗?

张雪峰:这个话题太大了,如果大家有时间参加 ArchSummit 2016 深圳大会,我们负责订单、运单的两位同学将带来干货分享。

这里只列举我个人认为比较重要的几点:
(1)低耦合(绝大部分架构师已熟知并实践),高内聚(不少架构师有可能忽视或无视);
(2)KISS;
(3)Design for Failure;
(4)Automation Everywhere;
(5)SOLID/Elemental Design Patterns/Design Patterns(三者类似,归为一类,后两者都有同名书出版,尤其中间的 EDP 更是把软件抽象做到了极致)。

把「低耦合 & 高内聚」放首位,是因为 TA 不仅和软件架构骨肉相连,还与组织架构密不可分(康威定律)。

InfoQ:饿了么如何成长为大只独角兽?在与美团的战争中,如何做才能够胜出,或者说不败?

张雪峰:外卖 O2O 的市场很庞大,而且还在不断培育和催熟中。长远来看,高度专注的公司才能持续提供高效率高标准的服务,最终获得用户和市场。饿了么团队从 2008 年开始创业,2009 年正式上线,到现在八年左右的时间,我们一直做着同样一件事情。

目前,围绕“美好生活,触手可得”,饿了么已初步建立起由交易平台、即时配送和供应链组成的到家服务生态体系,通过对整个外卖链条的上下游进行覆盖,从根本上提升用户的体验,并逐步构建起自己的核心竞争力。

InfoQ:听说饿了么的 CEO 很强硬,且从未给别人打过工,你作为 70 后的 CTO,如何看待近 90 后的 CEO?平时工作中会有冲突吗,如何处理?

张雪峰:纠正一下,Mark(张旭豪,饿了么 CEO)不是强硬,是霸气,还不是侧漏那种。Mark 85 年出生,我 76 年出生,但因为前面 #2 中提到的 fully trust(霸气和强硬区别之一),所以我俩间的配合,不存在(工作)代沟。

平时工作中肯定存在分歧,但没出现过大的异议或原则性冲突。我俩都是理工男,分歧处理方式也挺简单,要么他说服我,要么我说服他,印象中没出现过需要引入第三者协调场景。

InfoQ:你自己曾经创业,对想要创业的人有什么样的创业指导,有什么感悟或经验可以和大家分享?

张雪峰:我那段创业经历虽然辛苦,但需要我管的非技术或非研发杂事不多,这些都是 CEO、人事、财务、行政扛着,我就搞好 #1 中提到的几点即可,总结起来就是技术人最喜欢的创业五字真言:痛并快乐着。

站在一个技术从业人员角度,结合我曾经创业失败的体会,大概有这么几点分享:
(1)找到真正需求,而不是创造[伪需求];
(2)先做出最小可用产品(MVP),然后根据市场反馈再定是继续迭代优化,还是迅速调整方向;
(3)既然很多创业者只缺一个程序员,那就对你的程序员好一点,再好一点。刚开始创业,更需要 full-stack engineer,而不是各种 big title(研发总监、架构师、CTO);
(4)即使 full-stack engineer,也不是真的全能选手,所以,机房 / 网络 / 服务器 / 存储 / 监控 / 告警 / 安全甚至数据库什么的,可以考虑适当交给云计算。

我肯定没资格提什么创业指导,强烈建议联系采访上海滩乃至中国互联网创业圈[奇葩]一般的存在:以 CEO 张旭豪为代表的饿了么创始团队,江湖人称[四大饿人]。

InfoQ:感谢你接受我们的采访。期待你在 ArchSummit 全球架构师峰会上的分享。

2016 年 5 月 12 日 22:276829

评论

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

LeetCode 169. Majority Element

liu_liu

算法 LeetCo

区块链应用层——生态体系的上层建筑

CECBC区块链专委会

区块链技术 生态体系

从一段 Dubbo 源码到 CPU 分支预测的一次探险之旅

yes

dubbo cpu

企业中台化落地:从战略分析到战术实践及架构演进过程

Barry的异想世界

架构设计 策略模式 模板方法模式 中台架构 领域驱动设计DDD

【高并发】面试官:讲讲什么是缓存穿透?击穿?雪崩?如何解决?

冰河

缓存 面试 穿透 击穿 雪崩

重新学习了一遍ThreadLocal

熊斌

学习

华为与第四范式,正在酝酿一个帮企业跳出AI悖论的“秘密计划”

脑极体

不草率,你只管下载资料,剩下的交给「哇哦」

小Q

Java 学习 架构 面试 分布式

week11--作业

Geek_165f3d

Golang领域模型-实体

奔奔奔跑

go 架构 领域驱动设计 DDD 微服务拆分

我们该怎么保护手机屏幕前的父母?

徐说科技

手机 短视频

布式系统消息异常该何去何从

架构师修行之路

分布式 异步

spark总结

金沙账号审核不通过维护不给提现风控怎么回事?怎么办

过山太阳

内容审核 提现不了

认证、授权、鉴权和权限控制

哈库拉玛塔塔

spring security 用户权限 鉴权 权限

Spring Security 主要类解释

哈库拉玛塔塔

springsecurity

Java四种引用类型:强引用、软引用、弱引用、虚引用

简爱W

我理解的面向对象(ObjectiveSql 实践)

Braisdom

Java ORM框架 ORM

不使用Raft算法,就能简单做集群leader选举

架构师修行之路

分布式 架构师

计算机的时钟(三):向量时钟

ElvinYang

CString 类的线程不安全问题

C语言与CPP编程

c c++ 编程语言

为什么每个微服务要有自己独立的数据库?

码猿外

数据库 架构 微服务

SpringCloud轻松集成Dubbo实现RPC调用

Barry的异想世界

微服务 dubbo nacos RPC spring cloud alibaba

以大数据为依托提升基层治理效能

CECBC区块链专委会

大数据 信息化管理

一文带你了解微服务架构和设计(多图)

Phoenix

架构 分布式 微服务

Go: 理解 Sync.Pool 的设计

陈思敏捷

go golang sync sync.pool pool

HashMap将cpu打满始末

林昱榕

hashmap 线程安全 cpu 100% cpu飙满

oeasy教您玩转 linux 010212 管道 pipe

o

记录问题 INSERT INTO table ... SELECT ... FROM dual WHERE not exists (...)问题

浅^安

sql SQL语法 sql查询

区块链激励层——区块链生态建设的驱动力量

CECBC区块链专委会

区块链技术 驱动力量

浮点数的秘密

C语言与CPP编程

c c++ 编程语言 浮点数

Study Go: From Zero to Hero

Study Go: From Zero to Hero

专访饿了么张雪峰:未长夜痛哭者,不足以语人生-InfoQ