饿了么：极速发展过程中的分分合合

■文/云迹九州

俗话说，天下大势，分久必合，合久必分。对任何的软件组织和技术创新公司来说，也是一样，没有一种完美的组织架构可以适配公司发展的所有阶段。尤其是创业团队，公司从零到一、从一到十、从十到百，更是这样。创业团队在不同阶段，分分合合无法避免。饿了么CTO张雪峰先生对此做了详细阐述，并对分与合中的经验教训进行了深度地剖析。

康威定律与饿了么

康威定律是在软件开发过程中，关于软件架构和组织架构的一个定律，其核心理念就是软件架构和组织架构密不可分。搞技术的人往往更重视软件架构，希望搭建一个各项功能都非常强大、可以适配企业发展各阶段的架构，其实，这样完美的架构是不存在的。对于组织架构也是一样，一个团队的带头人，很难在创业之初就搭建完善的组织架构，而是要在团队规模稳定增长、爆发式增长的过程中，不断进行调整和优化。那么，如何才能在组织架构和软件架构中达到平衡？

饿了么从创业至今已经有10年之久。2009创业之初，技术团队只有1人，也没有软件架构。在2009—2013年的稳定发展期，技术团队发展到了几个人，但当时也只有两个系统，分别是用户下单的系统和商户处理订单的系统，那时还没有物流，都是商家自己完成配送。爆发增长期是2013—2014年，在短短两个月内，订单数量从10万猛增到100万，技术团队只有35人，由于订单数量的剧增，考虑引入专业的运维团队。实际上，这一阶段饿了么团队的发展没有赶上业务的发展。到2016年底，技术团队已经达到900人，从35人到900人的发展过程中出现了很多分分合合，包括组织架构和软件架构。到2017年年底，团队人数已达到1800人，也在不断尝试新的挑战，比如智能调度、异地多活、与百度外卖融合等。总的来说，没有哪一种架构是一劳永逸的，所以技术团队一定要贴近业务，更多地为业务服务，如果能未雨绸缪自然是最好，大大超前则是非常困难的。

创业团队不同阶段的分与合

对饿了么所在的外卖行业来说，创业之初是业务来驱动组织架构。这里的组织架构不完全是整个公司的组织架构，也包括了技术和产品团队的组织架构。公司进入稳定发展后，业务也进入了稳定期，这就需要开始寻找下一个突破点或者说是爆炸点，这个时候一定要创新。在这个阶段，饿了么主要通过下到基层，亲自与商家面对面地交流，了解痛点。饿了么在这一阶段尝试着给商家做一个系统，甚至给商家买电脑、装软件，鼓励更多的小餐馆使用这个系统。尽管刚开始的时候，系统可能会瘫痪、出错，但是通过线下的沟通交流以及对新系统的不断改进，整体效率有了爆发式的增长。这样的一个创新在当时是突破性的。因此，在创业初期，一群人在会议室里进行头脑风暴是一种创新的方式，但你同样需要留出一些时间去到线下，去了解你的业务、了解潜在客户的痛点。解决痛点的创新，才是本质上的创新。

找到了痛点所在，把问题解决以后，当订单数量从10万猛增到100万，又出现了一些问题。比如系统会经常瘫痪，因为业务的扩张速度已经超过了技术的扩张速度和它所能承载的能力，要通过业务来驱动组织架构的变化和调整。因此，支撑业务的架构和技术对业务发展非常重要。

总的来说，初创时期组织架构的调整不单单是技术团队的调整，也会涉及非技术的业务团队的调整。因为在这一阶段，我们更多的是探索新的商业模式。之后的组织架构的调整则是以技术团队为主。当业务规模达到千万级别时，就要完成精细化的过程，核算每一单的成本、利润，以及IT成本在其中所占的比例都是非常重要的。如果遇到内部战略调整和外部环境变化等非常规情况，也会临时做出调整。

创业团队或组织架构调整有两条分合规则。第一，高耦合、低内聚时，要考虑把高耦合变成低耦合，把低内聚变成高内聚，这是分与合的一个规则。具体来说，就是高耦合时进行拆分，低内聚时进行合并。第二，团队的稳定性也是需要考虑的问题，当两个系统交互非常多，也就是分与合的规则搞不定的时候，我们就会考虑引入中间层。虽然引入中间层会导致性能上出现一些问题，但是在一定场景下也是一种比较合适的解决方案。

例如，外卖营销的领域归属与跨团队交互问题，凡是盈利的公司都会涉及营销到底属于哪个团队的问题。营销会涉及大数据、算法以及战略业务单元（BU），表面上交易是通过APP或者红包分享等方式进行的，但事实上这只是个支付界面，在其背后是很复杂的。做业务的团队可能对大数据、算法不是很专业，这就需要跨团队交互。这个时候，我们就成立了一个新的团队，即增长团队。这个团队负责围绕营销的生命周期工作，相当于又合在一起成为一个特殊的团队，既不属于大数据团队，也不属于BU研发团队。

分与合中的经验教训

在创业之初，公司只有一个老板、一个程序员和一个业务员，也就是创业团队三驾马车，包括技术、产品和业务组成了最初的创业团队。这时，因为人少，做技术的也可以同时做产品和运营的活，做产品的也可以帮助技术完成一些简单的工作。但是，当规模发展到一定的阶段，相互之间会对自己负责的业务产生一些争议。对于饿了么当前的阶段，我们已经完成了大部分的基础设施和技术可拓展性布局，接下来就要考虑如何深挖，通过技术手段支持业务、深挖业务，实现持续增长。

发展过程中，如何处理产品、技术、运营三大组织间分与合的关系？在一级部门上，倾向产品（CPO）、技术（CTO）分离，而在二级部门上，倾向产研（PD）合一。CTO虽然有直线产品团队，但需要配合CPO进行整体产品规划与相关流程规范；CPO虽然有直线技术团队，但也需要配合CTO进行整体技术规划与相关流程规范。整体上，属于虚实汇报的一种，不同角色依照不同规范进行。

创业之初的关键就是要“快”，简单来说就是怎么发展快就怎么发展。技术人员最擅长做怎样的架构，就用怎样的架构。进入稳定发展期后，这个阶段要求稳，快已经不是最重要的，稳定下来之后再去发展技术问题。到10倍高速发展期的时候，随着业务的快速增长，技术也需要快速发展，这时做平衡是有一定难度的，对于公司来说是一个比较痛苦的过程。随着持续高发展后人员增多，流程规范也一定要跟上。此外，一定要鼓励员工创新，鼓励创新是公司今后发展的源泉，只有不断创新才有可能不断地突破发展。

饿了么在创业初期是没有KPI（关键绩效指标）的，随着不断的发展，KPI的数字越做越多，慢慢上升到OKR（目标与关键成果法）。OKR也只是一个工具，如果站在公司的角度，OKR就是全局最优，公司就一个或两个大的指标，然后分解，而不是像之前那样每个团队都有自己的指标。但是，OKR也会有自己的矛盾，这就是局部最优与全局最优，站在组织架构的角度来讲，局部最优到最后往往演变为局部的PK。如果出发点是全局最优，这时就需要在某一时刻要牺牲某个团队的某个指标去保护大的指标。因此，局部最优与全局最优是一个很关键的问题。对于如何拆分团队问题，到底是按业务模块来拆分还是按功能方式来拆分，饿了么针对这个问题的做法就是随机应变，没有固定的分法与绝对的答案。

如果现实情况暂不适合团队拆、并，或引入中间层，如何处理这个问题是关键。首先可以跨团队共担OKR，也可以临时成立虚拟团队或成立特殊虚拟团队，如增长团队。但是，增长团队也存在一个问题，增长团队不是每个公司都能做，因为这需要一个产品负责人（PO），他需要懂一些技术、产品、数据甚至还要懂一些AI、运营，可能还需要去线下跑商户，这样全才的角色是很难找到的。

归根到底，不管是软件架构还是组织架构，解决的是两个问题，一个是复杂度问题，一个是稳定性问题。复杂度问题包括团队复杂度和技术复杂度；稳定性问题包括团队稳定性和技术稳定性。有时两个KPI可能是有矛盾的，它们在局部可能都是最优的，但放在一起却是最次的。这里的建议是，先解决复杂度问题，再解决稳定性问题，否则技术债的利息将越来越高，直至不可承受。

如果非要对公司的架构进行分类，可以分为三种：首先是组织架构，它是整个技术的顶层设计；其次就是领域架构，需要找到合适的专家深入业务领域；最后就是技术架构，因为现在已经有很多技术可以直接应用，不需要自己去研发，所以只要实现极致运营就可以了。无论是不是创业公司，是在哪一种业务领域，组织架构和领域架构的设计搭建都是绕不开的，只能依靠自己的不断摸索，不断试错。