张雪峰：创业团队极速发展过程中的分分合合

题图 from  pixabay.com 

导读：2018第二届研发效能嘉年华专场，云效邀请了饿了么首席技术官张雪峰带来主题为《创业团队急速发展过程中的分分合合》的演讲。本次演讲主要从三个方面进行讲述，首先介绍了著名的康威定律，随后阐述了创业团队不同阶段的分与合，紧接着对分与合中的lesson learned进行了深度地刨析。

直播视频回顾地址：http://click.aliyun.com/m/51153/

PPT下载地址：http://click.aliyun.com/m/51154/ 或点击左下角【阅读原文】进入下载！

以下是精彩视频内容整理：

康威定律@饿了么

康威定律的核心理念就是所谓的软件架构和组织架构是密不可分的，饿了么从创业至今已经有十年之久。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可能是有矛盾的，它们在局部可能都是最优的，但是放在一起确是最次的。不管是组织架构还是软件架构，都是在不停的调整的。

简单总结架构的分分合合，架构可以分为几种，一是组织架构，整个技术的顶层设计。其次就是领域架构，需要找到合适的专家。最后就是技术架构，因为现在已经有很多技术可以直接应用，不需要自己去研发。无论是不是创业公司这些都是至关重要的。

-END-

新书推荐：《深入分布式缓存》

购书，扫描二维码：

关注本公众号，欢迎订阅。

技术琐话

以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。