2018第二届研发效能嘉年华专场,云效邀请了饿了么首席技术官张雪峰(空心菜)带来题为《创业团队急速发展过程中的分分合合》的演讲。本次演讲主要从三个方面进行讲述,首先介绍了著名的康威定律,随后阐述了创业团队不同阶段的分与合,紧接着对分与合中的lesson learned进行了深度地刨析。
数十款阿里云产品限时折扣中,赶快点击这里,领券开始云上实践吧!
直播视频回顾戳这里
PPT下载请点击
以下是精彩视频内容整理:
康威定律@饿了么
康威定律的核心理念就是所谓的软件架构和组织架构是密不可分的,饿了么从创业至今已经有十年之久。2009创业之初的技术团队只有1个人,也没有软件架构。在09年到13年的稳定发展期技术团队发展到了几个人,并且当时也只有两个系统,分别是用户下单的系统与商户处理订单的系统,那时还没有物流,都是商家自己完成配送。爆发增长期是13年到14年,在短短两个月内订单数量10万猛增到100万,技术团队只有35人,由于订单是数量的剧增,考虑引入运维。到2016年底,技术团队已经达到900人,从35人到900人的发展过程中也出现了很多分分合合,包括组织架构和软件架构。到2017年底,已达1800人,也在不断尝试一些新的挑战,比如智能调度、异地多活、饿百融合。
创业团队不同阶段的分与合
创业之初仅就饿了么这个行业来说是业务来驱动组织架构,进入稳定发展后,这时业务也进入了稳定期,这就需要开始去做下一个突破点或者说是爆炸点,也就是必需要创新。对于饿了么来说,在发展的稳定期期间尝试着给商家做一个系统,甚至给商家买电脑装软件。通过线下的沟通交流,包括自己去体验痛点。经过不懈努力对新的系统不断的改进找到了痛点所在,把问题解决。当订单数量达到10万时,就出现了一些问题。比如系统会经常瘫痪,业务的不断扩大已经超过了技术所能承载的力量,所以支撑业务的架构和技术对业务发展非常重要。
创业团队或组织架构有两条分合规则,一是高耦合低内聚时就要考虑把高耦合变成低耦合,把低内聚变成高内聚,这是分与合的一个规则。团队的稳定性也是需要考虑的问题,当两个系统交互非常多也就是分与合的规则搞不定的时候,我们就会考虑引入中间层。虽然引入中间层会导致性能上出现一些问题,但是在一定场景下也是一种比较合适的解决方案。
这里有相关案例,外卖营销之领域归属与跨团队交互,凡是涉及到盈利的公司都要涉及到营销到底属于那个团队的问题。营销会涉及到大数据、算法以及BU,表面上交易是通过app或者红包分享等方式进行的,但事实上这只是个支付界面,在其背后是很复杂的。对于做业务的团队可能对大数据、算法不是很专业,这就需要跨团队交互。
分与合中的lesson learned
在创业之初公司只有一个老板、一个程序员和一个业务员。也就是创业三马车,包括技术、产品加业务组成了最初的创业团队。发展过程中会有一些痛点,即产品、技术、运营三大组织间的分分合合问题。在一级部门上,倾向产品、技术分离 (CTO & CPO),而在二级部门上,倾向产研(PD)合一(横向技术团队无此问题)。CTO虽然有直线产品团队,但需要 follow CPO 整体产品规划与相关流程规范 (实际很少过问产品问题),CPO虽然有直线技术团队,但需要 follow CTO 整体技术规划与相关流程规范 (实际很少过问技术问题)整体上,算虚实汇报的一种,不同角色 follow 不同规范。
创业之初的关键就是要“快”,简单来说就是怎么发展的快就怎么发展,PHP + RN 最好。进入稳定发展期后,这个阶段要求稳,快已经不是最重要的,稳定下来之后再去发展技术问题。到10倍高速发展期的时候,随着业务的快速增长,技术也需要快速发展,这时做平衡是有一定难度的,对于公司来说是一个比较痛苦的过程。随着持续高发展后人员增多时流程规范也一定要跟上。其次就是一定要鼓励员工创新,鼓励创新是公司今后发展的源泉,只有不断创新才有可能不断的突破发展。
饿了么创业初期是没有KPI的,随着发展KPI的数字越做越多,慢慢上升到OKR。OKR也只是一个工具,许多公司在实践说自己是OKR,但实际并非如此。OKR如果站在公司的角度就是全局最优,公司就一个或两个大的指标然后分解,而不是说像之前一样每个团队都有自己指标。但OKR也会有自己的矛盾,这就是局部最优月全局最优,站在组织架构的角度来讲,局部最优到最后往往演变为局部的PK。如果出发点是全局最优,这时就需要在某一时刻要牺牲某个团队的某个指标去保护大的指标。所以局部最优与全局最优是一个很关键的问题。对于如何拆分团队问题,到底是按业务模块来拆分还是按功能方式来拆分团队。饿了么对于这个问题的做法就是随时应变,没有固定分法与绝对的答案。
如果现实情况暂不适合团队拆、并或引入中间层,如何处理这个问题是一个关键,首先可以跨团队共担OKR,也可以临时成立虚拟团队或成立特殊虚拟团队,如Growth Team,但Growth Team也存在一个问题,Growth Team不是每个公司都能做,因为这需要一个PU,他需要懂一些技术、产品、数据甚至还要懂一些AI、运营,可能还需要去线下跑商户,这样的全才的角色是很难找到的,最终找到一个大家都认可的 PO (product owner) 领衔主演。
归根到底,不管是软件架构还是组织架构解决的是两个问题,一是复杂度问题,不管是团队复杂度还是技术复杂度;一是稳定性问题,包括团队稳定性与技术稳定性问题。有时两个KPI可能是有矛盾的,它们在局部可能都是最优的,但是放在一起确是最次的。不管是组织架构还是软件架构,都是在不停的调整的。
简单总结架构的分分合合,架构可以分为几种,一是组织架构,整个技术的顶层设计。其次就是领域架构,需要找到合适的专家。最后就是技术架构,因为现在已经有很多技术可以直接应用,不需要自己去研发。无论是不是创业公司这些都是至关重要的。
关于饿了么研发效能提升的更多干货分享,欢迎关注云效Work Like Alibaba系列直播。
用云效,体验阿里巴巴研发速度。
更多精彩内容请点击 2018第二届研发效能嘉年华干货集结看这里