日，国家标准化管理委员会印发《关于下达2022年第二批推荐性国家标准计划及相关标准外文版计划的通知》（国标委发[2022]22号），其中由美团联合中国饭店协会、中国标准标准化研究院申报的《绿色外卖管理规范》国家标准获批立项。 “绿水青山就是金山银山”，党的十八大以来，生态文明建设纳入国家发展总体布局，建设美丽中国成为人民心向往之的奋斗目标。2020年，国家发展改革委、生态环境部印发的《关于进一步加强塑料污染治理的意见》提出，建立健全电商、快递、外卖等新兴领域企业绿色管理和评价标准。
为进一步促进行业绿色发展，美团联合《绿色外卖管理规范》国家标准起草组，深入分析当前外卖包装原材料采购、加工烹饪与餐厅运营、包装与材料使用、垃圾处理等全生命周期现状。据悉，此次由美团牵头起草并获批立项的《绿色外卖管理规范》，提出了绿色外卖管理的术语和定义、餐饮企业及互联网平台管理要求、绿色外卖质量管理等内容，以期引导外卖相关企业提高资源利用效率，降低包装耗用量，减少环境污染。
一直以来，美团关注外卖行业环保问题，积极联合生态各方探索绿色转型。早在2017年，美团就发起了外卖行业首个关注环保的行动——“青山计划”，希望发挥连接优势，带动外卖全产业链和消费者，共同推动行业环保进程。
“青山计划”设立了绿色包装、低碳生态、青山科技、青山公益四大板块，着眼于生活服务业绿色低碳发展，带动生态各方共建共享。五年来，“青山计划”始终围绕“更好生活、更美自然”的愿景，开展外卖包装创新，发布绿色包装名录，孵化适用新型产品；推进塑料餐盒回收再生，开展回收试点，并在厦门、杭州、上海等地落地规模化常态化回收项目；搭建商户绿色经营知识体系，建设商家和用户便捷参与机制；设立青山科技基金，以科技驱动绿色转型。
2017年发起“青山计划”的同时，无需餐具”功能也在美团外卖正式上线启用，旨在鼓励餐饮商家与消费者参与环保行动。此外，美团更是推出了荣誉勋章、虚拟能量、外卖优惠券等多种形式，鼓励商家和用户参与低碳环保行动，进一步为建设绿色外卖打开通路。
未来，美团还将持续落实“青山计划”，携手社会各方共同关注环保事业发展，助力行业绿色低碳发展。
本文源自中国网科技
团外卖自2013年创建以来，业务一直在高速发展，从早期单一的美食业务发展成为包含闪购、跑腿、闪付、营销、广告等在内的平台业务。每个业务团队虽然都有不同的业务形态，但是几乎都有相同的诉求：需求能不能尽快的上线？本文将从外卖的历史实践中，浅谈一个好的持续交付需要综合考虑哪些关键因素，希望对大家有所帮助或启发。
0. 前言
美团外卖自2013年创建以来，业务一直在高速发展，目前日订单量已突破3000万单，已成为美团点评最重要的业务之一。美团外卖所承载的业务，从早期单一的美食业务发展成为了外卖平台业务。目前除餐饮业务外，闪购、跑腿、闪付、营销、广告等产品形态的业务也陆续在外卖平台上线。参与到美团外卖平台的业务团队，也从早期的单一的外卖团队发展成为多业务团队。每个业务团队虽然都有不同的业务形态，但是几乎都有相同的诉求：需求能不能尽快地上线？
然而，Native应用的发布依赖于应用市场的更新，周期非常长，非常不利于产品的快速迭代、快速试错。同时，作为平台方，我们需要考虑到各个业务团队的诉求，统筹考虑如何建立怎么样的模型、配套什么样的技术手段，才能实现最佳的状态，满足各业务更短周期、高质量的交付业务的诉求。本文会首先回顾美团外卖从早期的月交付，逐渐演变成双周交付，再从双周交付演变成双周版本交付配合周动态交付的过程。然后从外卖的历史实践中，浅谈一个好的持续交付需要综合考虑哪些关键因素，希望对大家有所帮助或启发。
1. 交付模型
一个需求从产生到交付再到用户的手上，要经历需求调研、需求分析、程序设计、代码开发、测试、部署上线等多个环节。在整个过程中，由于涉及到不同角色的人员，而不同角色人员的认知存在差异，不同的程序语言存在差异，不同的开发方式也存在差异。在整个交付需求的过程中，还面临着需求可能会被变更、交付周期可能会被变更等各种情况。这些情况使得需求的交付变得非常复杂、不可预期。
而软件开发的首要任务就是持续、尽早地交付有价值的软件。怎么解决这一问题，是软件工程一直在研究的话题。早在20世纪50年代，软件领域就在积极地探索设计什么样的模型可以解决这些问题。常见的包括瀑布流模型、迭代模型、螺旋模型、敏捷模型等等。由于篇幅原因，本文不再做详细的介绍。
2. 什么是持续交付
关注持续交付，不同的企业、不同的团队站在不同的角度存在不同的定义。《持续交付2.0：业务引领的DevOps精要》一书认为，站在企业的角度，将持续交付定位为一个产品价值的开发框架，是一个工具集，其中包含了一系列的原则和众多实践，帮助提升企业的内部运转速度和交付效率。
从知乎话题“如何理解持续集成、持续交付、持续部署”，我们可以看到大部分研发团队，会从软件研发的角度进行定义，他们将软件的开发步骤拆解为持续集成、持续交付、持续部署，其中持续集成指开发人员从编码到构建的过程。持续交付指将已经集成构建完成的代码，交付给测试团队进行测试的过程。持续部署指将测试通过的软件交付给用户的过程。而产品团队会站在产品的角度来看，他们认为持续交付，是从需求的PRD文档提出来，到用户能够感受到这个需求的周期。
从美团外卖业务的角度，我们可以将持续交付定位为“外卖用户”和“外卖团队”之间的紧密反馈流。而外卖团队涉及到PM、UI/UE、RD和QA角色。如下图所示，产品同学从市场或用户的需求和反馈中收集到需求，转换为需求PRD文档，交由设计交互同学设计成期望用户所见的界面和行为，然后交给研发团队进行调研实现。研发团队实现后，再交给测试团队进行测试。等测试团队完成测试后，提交到应用市场，最终交付到用户手上，这个过程是本文所考虑的交付。“持续”指的是，外卖团队将外卖的业务拆分成不同维度的子业务，每个子业务持续通过这个迭代流程不断地优化各个子业务达到最优，从而使整个外卖业务达到最优。
< class="pgc-img">3. 外卖持续交付模型的变迁史
3.1 外卖的早期交付模型
早期外卖的交付模式为“串行交付”，一个版本完成后，开启下一个版本。整个交付过程包括需求评审、需求开发、迭代提测、一轮提测、二轮提测、三轮提测、灰度提测和全量发布8个环节：
< class="pgc-img">由于美团的外卖业务是一个双平台业务，需要同时开发外卖App和美团App。在人力安排上，我们会分成两个组，App组和频道组并行开发。App组开发当前的版本业务，频道组同步上个版本的业务到当前的美团平台版本。整个版本周期耗时六周半左右，遇到节假日会顺延，全年能发版11～12个，版本交付周期如下图所示：
< class="pgc-img">交付模型中关键点
- 需求评审分为主打需求、非主打需求和统计需求。
- 主打需求：客户端开发10d之前进行评审，评审8d后UI提供初稿，评审14d后UI定稿。
- 非主打需求：两个三方评审窗口，窗口1为窗口2的前5d，窗口2为上一版本二轮测试地一天，UI定稿需要在客户端开发第一周内完成。
- 统计需求：需求收集截止到立项评审前一天，三方评审为非主打需求评审后第二天。服务器在需求评审后，客户端开发第一周前，提供接口文档。
- 客户端开发周期为两周，客户端开发第5个自然日API提测，客户端开发第5天发迭代提测包，第二周结束发提测包。
- QA验收提测包，一轮3d、二轮3d、三轮1d。
- 灰度3d，需避开节假日前发灰度。
- 全量发布电子市场。
单月发版优缺点
优点：
- 每个版本可根据当版的情况控制版本的周期，可同时支持多个大需求的并行开发。
- 版本较为固定，各角色的分工明确，开发人员在开发期较为专注，开发效率高。
- 测试周期长，App能够得到充分的测试。
缺点：
- 版本迭代周期较长，从需求评审开始到需求灰度，需要6.5周。无法满足日益增长的业务诉求，对于一些尝试性项目，无法满足PM急迫上线验证效果的需求。
- 发版频率低，每年只有11~12个版本。对标其他互联网公司，业务产出相对较低。
- 每个角色的利用率不高，如RD在开发期的时候，QA处在待测试状态。
3.2 双周迭代的交付模型实践
为了满足日益增长的业务诉求，我们提出了双周发版的交付模式，从而实现业务的快速迭代。贯彻的总体原则为：评审、开发、测试完全并行，以两周为固定周期，以需求维度持续交付。
3.2.1 双周迭代模型
在切换双周迭代模式之前，需要落地一些准备工作。例如统一版本排期的时间表、确定项目中各个角色的交付时间，让PM、UI、客户端RD、服务端RD和QA，各角色都能够清晰的知道自己接入的时间点，并在规定的时间点交付内容。由于各角色的任务和分工得到了明确，减少了协作中的沟通成本，各角色也可以如齿轮一样，持续产出交付给下游团队，整个交付周期效率得到了有效的提升，一个版本的周期缩短为5.5周，发版次数上升到22~24版本。
版本各个角色分工详情示意图如下所示：
< class="pgc-img">双周模型中关键点：
- W1需求评审：周三PM组织三方评审业务需求+埋点需求+UI需求。
- W2排期：周三API RD出排期，周四客户端RD出排期，UI产出视觉初稿。客户端RD排期需细化至需求可提测时间点，便于QA、PM和UI提前协调测试、验收时间。
- W3接口评审+服务端先行开发：接口文档，UI资源周四前到位。
- W4客户端开发，周四API提测（最晚）。
- W5客户端开发+冒烟测试：RD开发完后直接冒烟测试，以需求维度交付给QA，不需要等到最后一天集中冒烟测试；需求交付后，PM与UI可介入验收环节。
- W6客户端测试+周二服务端上线：客户端一轮测试结束前，PM与UI应完成需求验收。
- W7灰度+周二全量理想状态一个版本的周期为五周半。
- W3时，PM会继续组织三方评审；W4时，API继续开发下版本；W5时，客户端RD会继续下一个版本的开发。
3.2.2 分组交付
双周迭代模式的变化也推动我们在人力分配方面的改进，人力安排演变经历了三个过程：
< class="pgc-img">在双周迭代的过程中，客户端的交付是连贯的，理想状态是每个RD可以隔版进行需求开发。但是大家都知道，写完需求是不可能没有Bug的，需求的估时也不可能都是5的倍数，这样就会造成很多RD既要开发当前版本，又要解决上个版本的Bug。这间接引入了2个问题：
- 个人成长方面：单个RD可能会在同一个时间段内，出现又要评审需求、又要开发需求、又要改Bug，时间长了会堆积疲惫感。另外，需求的估时不是5的倍数，每个版本单个RD是否能满人力工作是不确定的，不利于资源的分配。
- 人力分配合理性：版本的需求是存在不确定性的，而App的需求熟悉度是存在和RD一一对应的。当熟悉度最高的RD在上个版本的时候，当前版本的版本主R就会很头疼，是“能者多劳”还是“合理分配”，给人力分配的合理性又带来了新的挑战。
后来我们经过内部研究，提出了AB分组的方案，保证AB组是隔版本进行开发。当组内需求拆分有冲突时，需要在内部协调消化，避免RD出现每个版本都会参与开发的情况发生。
< class="pgc-img">AB分组施行以后每个RD都是各版本开发的，不会出现同一个时间段内，要处理上个版本的Bug和当版需求的情况。但业务的熟悉度和RD的强对应关系还是没有得到解决，所以我们就进一步的思考，提出采用业务维度AB组。如下图所示，我们先将同学进行业务划分，在以业务组进行AB的划分。当然这个业务组人员的数量需要考虑业务的规划情况，当某一个业务需求量增长上来的时候，业务组的大小也需要同步进行增长。
< class="pgc-img">3.2.3 双周迭代的优缺点
双周迭代的优点：
- 提高了业务迭代效率，从而提升了业务的产出，以一月能够完成二个版本的交付速度，持续地交付版本，达到一年交付20-24个版本的交付目标。
- 在人力整合利用上更加合理化，各角色都能够持续的产出，版本的交付周期变为5.5周。
双周迭代的不足：
相比之前的当月发版，虽然双周迭代带来一定收益，但还是存在一些客观的问题：
- 从评审到交付，发布周期还是太长，产品快速上线的诉求依然不能得到很好的满足。
- 敏捷性受到一定影响，对于特定需求和小需求不是很友好。
3.3 双周结合周交付的模型实践
外卖在历经了双周迭代后，一定程度的缩短了版本交付周期，提高了业务迭代效率，优化了人力安排，但是仍然存在一些问题。对于一些简单的需求来说，像外卖中“我的页面”模块的点击热区扩大（“我的页面”已经是RN页面），实际上开发只需要2天，却仍然要跟随版本迭代的节奏，5.5周后才能上线，需求交付周期仍需进一步缩短。另外，外卖自研动态化框架Mach在大量业务的应用落地，多种开发流程及交付需要，使得双周交付越来越难满足外卖业务版本迭代及交付的节奏。
3.3.1 动态化能力的建设
为了满足业务需求的快速上线及外卖面临的包体积的压力，外卖引入了动态化来解决此类痛点问题。外卖动态化能力建设的思路主要是：核心流程页面区域动态化，区域动态化方案采用外卖自研的Mach动态化框架，核心流程采用区域动态化，保证页面的稳定性及用户体验，非核心流程页面MRN化（Meituan React Native），通过MRN来替换所有的低PV页面，下线Native页面。具体技术细节可参考《React Native在美团外卖客户端的实践》一文。
目前外卖低PV的MRN页面数量已达：56/67。已经覆盖了外卖所有的低PV页面，除核心流量页面均为MRN页面，从页面数量维度，MRN页面占比已达83.58%。
Mach区域动态化覆盖了首页核心流量区、二级金刚页、订单页、点菜页及搜索页。目前上线的模板数已达43个。
3.3.2 双周迭代&周迭代
在完成了外卖动态化能力的建设后，外卖业务逐渐演进出了两类需求：
- 主版本需求，主版本需求主要是Native方式实现，结合少部分动态化需求。
- 敏捷开发需求，主要通过动态化和敏捷模型的加入实现高效的版本迭代，动态化主要指上节所介绍的动态化能力的建设，敏捷模型采用前文所说的敏捷模型。
面对上述两类需求，现有双周迭代及分组交付流程，对于部分特定需求及小需求不太友好。目前无法做到需求最快速上线，如上述“我的页面”点击热区扩大。
因此，我们在双周迭代的基础上，演进出了现在的双周迭代结合周迭代的交付模型。交付模型图如下：
< class="pgc-img">双周迭代结合周迭代的交付模型是在原有双周迭代的基础上，保持主版本需求双周迭代不变，增加每周的动态上线窗口。以每周二为动态上线窗口时间，周五为提测DeadLine，根据动态化需求的开发及提测时间来动态搭车上线。
目前，外卖的周迭代需求分为两类：
- 纯动态化需求，根据需求开发及测试排期选择上线窗口，搭最近一次的上线窗口。
- 动态化结合Native需求，跟随主版本交付流程，在提测周发版上线，主要面向敏捷迭代内容。
纯动态化需求由于不依赖Native发版，无需依赖Native的全回归，开发完成可随时提测，提测后功能测试完成即可上线，可以做到需求的最快速上线。敏捷迭代内容，不依赖主版本的评审，采用自主评审，自主决策跟版的策略。
而多种动态化方案的开发模式，需要统一的动态化发版及上线能力的支撑。外卖周迭代发版及上线具体可以分为两步：
- 发版。将动态化模板进行打包，得到Bundle并上传，通过Talos平台（美团内部自研）进行打包。Talos是基于前后端分离思想设计的一套前端DevOps解决方案。
- 上线。将通过Talos打包得到的Bundle上线发布，发布通过EVA客户端动态分发平台进行线上发布。
具体流程如下图所示：
< class="pgc-img">截止目前，外卖周迭代发版经过了15个上线窗口，共计发版50+次。
双周迭代结合周迭代的交付方式进一步缩短了版本的交付周期，从需求收集评审到需求上线对于敏捷需求可以缩短到3.5周。对于纯动态化需求可缩短到1周，最终做到了需求评审做到了需求的快速上线、快速验证、快速修复，敏捷迭代。
3.4 自动化版本管理系统
在施行了双周迭代结合周迭代后，大大缩短了需求的上线周期，但是同时也提升了版本流程管理的复杂度。怎么样保证版本流程的正常运作呢？外卖C端涉及开发人员分为A、B组及敏捷开发人力；同时涉及美团频道及外卖App双平台，需要考虑双平台的版本迭代周期；涉及阶段多，各阶段都需要人工操作，执行事件多，双端执行事件总计40+；涉及双版本并行开发，仓库代码管理复杂。
原有版本迭代流程，版本各阶段的所有事件都由相应负责人执行。
- 分支创建、版本降级检查、每日QA包号周知，仓库集成及基础库同步、打包，提测邮件等都由迭代工程小组人员负责执行。
- 仓库拉出Release分支，提审灰度后分支合并、集成、发版由外卖各仓库负责人负责执行。
- 周迭代、迭代、一轮、二轮、三轮提测阶段冒烟周知，则通过排班的形式，在冒烟提测当天，由人工提醒并监督。
在版本迭代流程上会耗费了大量的人力。如何解放这部分人力，让整个版本迭代流程自动化，做到无人值守，减少人工操作的失误。这是此前外卖前端技术团队面临的非常头疼的问题。
在我们规范了双周迭代&周迭代的流程后，版本各阶段的时间能够基本固定。为了能够做到自动化，我们把版本各阶段需要人工操作的事件整理归类，把事件确定到当前版本的固定一天固定时间点。以一个版本为例，我们整理归类如下：
< class="pgc-img">确定好所有事件的执行时间后，我们便尝试把所有需要人工操作的事件自动化。并通过在确定的时间去触发，来做到整个版本流程的自动化。
早期的版本管理，我们依托于Gulf（美团内部日期管理系统）、QA-Assistant系统（美团内部事件通知系统）、CI及大象（美团内部通讯工具）消息，通过在Gulf系统提前配置好各版本各事件的时间，并通过QA-Assistant配置人员名单及消息，在固定时间节点，Gulf去触发QA-Assistant，通过上述方式，做到了各类提醒的自动化，并且在CI上部署上自动化Job，由人工触发。
但是通过这种方式，存在一些弊端：
- 版本各节点事件都需人工单独一个个配置，且Gulf和QA-Assistant系统的触发一直需要关注。
- 仍然需要大量人工操作，只能做到流程的半自动化，人力还是无法做到解放。
- 版本流程无法做到可视化。
为了解决上述问题，我们和Tide版本管理系统（美团内部组件）共建，实现了现在的外卖C端自动化流程管理。
以Gulfstream的版本排期为基准，通过Tide版本管理系统进行事件触发。通过脚本将CI、Stash仓库管理系统、HyperloopX发版打包系统、大象整合，做到代码/分支管理自动化、打包集成自动化、周知提醒自动化、版本流程可视化。
在版本开始前配置好当前版本，后续则会在版本的每个关键节点自动执行需要执行的事件。
< class="pgc-img">Tide版本管理可视化界面如下，按照版本各阶段及时间线顺序排列：
< class="pgc-img">各类事件提醒及执行通知如下：
< class="pgc-img">各类提醒确认结果即时展示：
< class="pgc-img">3.5 CI建设
在CI建设方面，我们工作主要集中在以下5个阶段：准备阶段、PR检测、开发阶段、提测阶段和发版阶段。
< class="pgc-img">下面介绍三个CI工作中，外卖场景下的特定检查：
- Aimeituan工程独立编译自动配置：同事反馈配置团App源码依赖的配置项较繁琐，切换开发分支时需要反复进行配置，为了提供RD的开发体验。通过脚本自动修改WM提测分支的源码依赖配置项，只需修改Aimeituan的gradle.properties一个属性实现源码依赖切换，实现一键切换的功能，提高版本开发效率，优化项包括：
- 业务方依赖只保留团首页和外卖业务。
- 只保留开发调试必要的插件：ServiceLoader和WmRouter，提高编译速度。
- 只保留调试Flavor：提高编译速度。
- 业务库检测是否有PR未合入：版本快速迭代对代码管理也带来了挑战，发生了几次因为RD未及时合入代码，影响QA提测进度的问题。因此在打提测包之前增加了一个检测环节，如果检测到有PR未合入提测分支，将在大象群统一周知发起人，提高版本的交付质量。
- 定时检测壳工程是否有更新，自动触发打包，保证QA第二天能回归前一天所有的修改，避免测试返工的问题，提高版本测试有效性。
总结
- Aimeituan独立编译配置从5～10分钟（同事反馈从修改配置到同步完成的耗时）降低到45s左右，优化了80%～90%。
- 在经过了几个版本的实践证明，自动化检测PR合入是有必要的，而且能够有效降低开发人为失误导致漏提交代码发生的概率。
- 每天早上同步Aimeituan的Release分支，及时周知负责人同步结果，减少人工Check的重复工作。
3.6 部署发布
部署和发布，对于移动App来说，已经到了最后的环节。我们认为的部署行为主要指将一个还处在测试的版本提交到测试环境，然后让QA进行测试，发布行为主要指将测试完成的稳定版本提交到线上环境交付给用户。当然对于部署和发布，每个团队都可以思考自己的定义。例如我们进一步的细化部署和发布的行为，可以划分为部署测试环境、部署线上环境、部署回滚、发布灰度、发布灰度监控、发布全量、发布回滚、发布监控等等。下面主要介绍外卖业务在部署发布中，建设的业务事务流和无人灰度监控。
3.6.1 发布事务流
发布在整个交付过程中是最重要的一环，而这个环节涉及的角色主要是RD和QA。我们需要明确的定义这个环节RD和QA的事务，避免角色间沟通不畅，跨角色的任务不清的问题。外卖通过持续的优化流程，明确流程的操作行为，来监督流程的正常运行，形成当前的事务流，如下图所示：
< class="pgc-img">这里需要重点讲解图中的关键点：
- 事务流中，RD负责交付代码到测试环境，QA同学负责测试环境的和线上环境的验证。RD和QA角色按照时间顺序，各自前面工作和后面工作，事项归属清晰明确。
- 流程中设置TL Approve和QA Approve。同时RD作为代码的完成者，只具备测试环境的部署权限，最终线上的权限由QA掌控，做到了上线的双角色Check，避免了RD即是“裁判员”又是“运动员”的情况。
- 当完成测试时候，部署线上环境和线上环境发布，都做到自动执行，通过自动化的手段节约重复的工作。
3.6.2 无人值守灰度
一个功能上线，往往要经历灰度到全量的过程。由于灰度已经是到了交付到用户手上的最终环境，灰度前的检查和放量都非常重要，需要做到万无一失。灰度的次数往往是全量次数的2~3倍，这使得灰度的成本在整个交付流程中也变得非常高。理想情况下，我们希望发布前的流程都做到自动化，灰度的过程，也无需人工参与，自动的放量、停灰、全量，出现异常自动执行灰度SOP、监控项也在灰度的时候自动开启，出现异常自动同步信息给相关方。但在实际过程中，由于平台的差异，部分环节还是很难做到，例如iOS的发布。下图是外卖业务无人值守灰度的流程：
< class="pgc-img">其中几个关键点：
- 起始点来源于我们录入的GulfStream日期。由于双周迭代后，版本的迭代周期是可预期的，所以能够以季度维度录入GulfStream中，由此处触发整个链条的启动。
- 我们利用Tide版本管理系统，将版本的日期自动读入，在需要发布的节点前，自动检查，做好自动化检查。部分无法自动化的，由Tide系统提醒RD和QA去做检查。
- 定义好灰度放量策略，在发布时按照设定策略，自动发布放量。
- 外卖业务非常复杂，监控的内容也很复杂，对这个环节不是很熟悉的同学，是很难胜任监控运维工作的，自动化更是无法执行。因此外卖的策略是将监控报警标准化，制定SLA，分级别定义监控、报警、预案、执行人，当版本发布后，触发监控Job，以分钟级去CAT（已经开源）、Sniffer、Crash等等平台去拉取当前灰度版本的数据和定义的指标比较。如果在合理定义范围内，继续监控。如果出现异常，大象定向通知相关处理人。这样使得灰度的自动化监控工作的执行过程是可操作的。
4. 外卖持续交付的总结
美团外卖业务，应该建立怎么样的模型、配套什么的技术手段，才可以在更短的周期内，高质量地交付业务，满足各团队的发展呢？我们从早期的单月交付，到双周交付，再到双周交付结合周交付，我们在不断地尝试和演进外卖的持续交付模型。随着不断的深入了解，我们发现这是一个很大的话题。到目前为止，美团外卖团队在这条路上只能算得上是刚刚起步。不过，在实践的过程中，我们也逐渐地摸索到一些经验，在此分享一下我们的思考。
4.1 遵循原则
首先我们认为持续交付需要遵循以下的原则。
持续自动化
在我们整个交付的过程中，有大量的工作是会重复进行的，如果我们不能将这些重复的操作逐渐变成自动化，我们就需要频繁、反复地去做一些看不到收益，但是又不得不去进行的事情。随着交付的内容变得越来越多，交付的速度要越来越快，团队的疲劳感会越来越重，最终疲于奔命。在实际的工作中，由于发布的形态流程的不标准、生成环境和数据的不一致，我们无法一次性做到所有环节自动化，但这不影响我们先站在全局去思考，去持续地拆解子问题，将子问题逐渐地变成自动化。随着整个交付过程的自动化程度不断提升，整个流程会变得简单容易，这样开发人员可以更加聚焦在完成功能本身的工作上。
前置解决
大部分人心理上对于比较麻烦、比较痛苦的事项，都倾向不做或者拖到最后去做。由于存在这样的心理，如果在交付流程中遇到问题，我们的方案很容易掉到一个陷阱中，倾向保持现状或延后再处理。但是，对于一个多人协作交付的业务来说，这是非常不可取的，越往后处理，对整个交付的影响越大，处理效率越低下。举个例子来说，一个PR可能导致一个历史功能不可用，如果我们在这个同学提这个PR的时候就拦截到，那么只会影响这个同学，也不需要回溯问题；如果延到代码集成环节，那么就需要想办法去找到是谁，然后因为什么原因提这段代码，本次集成就可能直接导致失败，影响其他正在集成的代码。如果拖到测试环境，那么就会涉及至少RD和QA等两个角色去追寻这个问题。所以在持续交付的过程中，我们尽可能尽早地将问题在刚出现时就解决掉，保障整个交付流水线的通畅。
版本化
在我们持续交付的过程中，要将每个环节尽可能的版本化。不仅仅从代码方面版本化，针对数据、配置、环境都可以进一步的版本化。版本化的好处是不言而喻的，首先在实现版本化的过程中，尽可能地将各个环节解耦开，让环节和环节之间没有强依赖。当某一个环节出现异常的时候，我们可以很快地降级到无问题的版本，从而保障整个流水线的持续运转。版本化的另一个好处，就是可回溯，当出现异常的时候，我们可以很快地对比历史版本和当前版本的差异，缩小范围，快速的定位问题。
持续反馈
在整个交付的过程中，每个环节都可能出错。当出错的时候，需要快速地反馈到相关的负责人。该负责人也需要尽快地将反馈的问题处理，给予一个稳定的版本。如果没有反馈这个环节，导致了整个交付流水线被阻塞的人，可能完全不知道自己造成了阻塞。另外，在一个功能的交付过程中，可能会有多次提交代码、多次集成、多次测试，如果每次是什么样的结果，都无法得到反馈，那么整个交付的风险会逐渐累积。只有将问题更早地反馈、更早地处理，才能有效地降低整个功能交付的风险。
持续分解改进
不管我们当前将整个交付的过程做到了多么高效，未来随着业务的发展，组织成员的加入和离开，交付的过程都在逐渐发生衍变。而这个变化，随着时间的推移，交付的效率又会开始逐渐下降。如果要长久地保持交付效率能够有持续的改善，我们需要不断地对抽象的交付过程进行分析，层层剥离，将整个交付过程转变成一系列小而可以解决的问题，然后持续地解决这些小问题。
不管我们当前将整个交付的过程做到了多么高效，未来随着业务的发展，新成员的加入和离开，交付的过程都在逐渐发生衍变。正如《谈谈持续集成，持续交付，持续部署之间的区别》一文提到的“持续部署是理想的工作流”一样，想一劳永逸解决所有问题是一种理想的工作状态。
随着时间的推移，交付的过程会出现新的问题，交付的效率又会开始逐渐下降。如果要长久地保持交付效率能够有持续的改善，我们需要不断地对抽象的交付过程进行分析，层层剥离，将整个交付过程转变成一系列小而可以解决的问题，然后持续地解决这些小问题。
4.2 关键步骤
针对上述原则，我们可以进一步地来指导外卖持续交付中的关键过程。通过前文所讲，我们认为持续交付就是从产品同学收集到需求，提交到研发团队，最终形成稳定的产品交给用户手上的过程，针对这个过程主要细化包括：
提需求
持续交付启动的第一环对应的就是PM提需求。俗话说“万事开头难”，“提需求”看似是一件容易的事情，其实背后是一个非常复杂的问题，涉及到策略选择、动态规划、排队论等一系列的理论。往往在大部分的团队中，“提需求”被认为是最简单的事情，这使得整个交付流程后续的工作，无法高效开展。我们细分析下，需求根据大小可以分成大需求、小需求；根据优先级可以分成高、中、低需求；根据开发的人员不同，又可以分成前端需求、后端需求、策略需求等等。
需求提出来后，怎么快速地判断出如何划分这个需求，需求的优先级是什么，需求的上线时间怎么样，谁来做这个需求，这个需求会涉及到谁。在涉及到这个需求和其他需求的比较时，才能回答刚才提到的问题，这又涉及到需求的定义，需求产出比的基线问题。在外卖的交付模型中，对于“提需求”，主要遵循的是组织管理原则，即以组织结构为单位，当前组织下的PM给予当前组织下的RD提出需求，需求的优先级也以当前组织下的事项进行综合考虑。这样的好处，不言而喻，比较敏捷。劣势是当遇到跨组织需求，工作成本会急剧增加。
同时，我们通过交付模型，将提需求的时间点可预见，在每次提需求的环节，严格要求每一组织下的需求给予明确的优先级。每次提出的需求数量、需求评审时长标准化。并且配套标准的需求模板，让PM在提出需求时，自我完成需求边界检查，需求涉及方的前置沟通。通过这样的组织管理手段、模板管理手段、流程标准化手段，来尽可能地保证提需求的质量。
提代码
当单个RD同学认为已经基本完成了功能开发后，就会进入到提代码的环节，也可以叫做代码集成环节。这个环节是个人行为和整体交付产生对接的环节。在这个环节我们要确保个人的行为不影响整体的流水线的进行。如何保障，我们采用的手段主要是本地检查+CI检查+集成测试。当代码检查通过后，代码的集成是自动完成，无需个人干预。
不过，这里也存在一个矛盾点，如果本地检查+CI检查项+集成测试项越来越多，检查的时间将会非常长，这将会使得每次提交代码变得异常痛苦。而如何解决这个问题？最好的手段，我们认为是通过持续优化代码的架构，来让每次RD的代码修改尽可能范围小。这样对于有特定范围的修改，本次CI检查就存在可简化的可能性。
部署测试
当完成代码集成后，就需要进入到测试环节了。那首先我们需要将代码部署到测试环境，因为外卖主要提供App供测试包，所以我们的部署，主要就是打出App包来，周知QA测试。目前外卖的测试，分位一轮新功能测试、二轮全回归测试、三轮主流程回归测试。新功能因为新引入，可能存在前置条件，而在本次测试的过程中，存在需要编写自动化用例和人工测试的用例。
但对于老功能，我们希望未来能够尽可能地采用自动化为主的方式。而在实践的过程中，我们发现自动化测试的一个很重要的前置条件是，数据和环境的可配置性、稳定性。试想下，数据不稳定，一会返回是空，一会返回不为空，是没办法自动化测试校验的。对于这个问题，目前我们的思路是通过建立各环节下根据标准协议定义的Mock数据，将复杂的全链条，拆分成不同节点，在通过配置去控制数据的环境。通过保障每个环节下的质量，来确保整体的质量。
线上监控
保障外卖业务正常线上运行，会需要监控多项的指标。对于如何做好线上监控，我们的思路是设立好各项基线的标准基线，通过脚本获取线上的版本，当检测到新版本，就会自动的创建当前版本的监控。当监控发现线上指标的值和设定的指标基线出现降低时，发生报警行为。而自动化监控最需要考虑的是误报率的问题。版本的发布正常通常又会分为2个阶段，灰度阶段和全量阶段。
全量阶段量大，比较稳定，误报率较低。而灰度阶段，量小，不稳定，容易出现误报。而解决这个问题，最好的办法是，本次灰度对比上一次灰度的指标，而非对比上一次全量的指标，维度一样，可以有效地减少误报率。
< class="pgc-img">5. 展望
当前，美团外卖业务仍然处于快速增长阶段，建立怎么样的流程、配套什么的技术手段，才能满足在更短的周期内，高质量地交付业务，进而满足各个业务的发展呢？毫无疑问，持续交付是解决这个问题的重要一环。但针对持续交付这个主题，美团外卖也算是刚刚起步。
未来我们的建设主要集中在2个方向，精细化运营持续集成和建设自动化测试。如上文所述，随着业务越来越复杂，涉及的角色越来越多，代码集成的管控需更加严格，而严格的代码集成管控将增加团队成员每次提代码的痛苦。如何做到差异化的检查和准入，将是未来持续集成的建设方向。
我们可以针对不同类型的PR，不同时间节点下的PR，实施不同的差异化定制规则检查，在合入质量和检查周期上寻找到一个合适的平衡点。另外对于测试环节，目前美团外卖还是主要集中在人工保障环节，大量的测试Case。我们希望未来能够尽可能地采用自动化为主的方式进行测试，而让QA可以集中精力测试新功能或非常边界异常的场景验证。
6. 参考文献
- 如何理解持续集成、持续交付、持续部署
- 谈谈持续集成、持续交付、持续部署的区别
- 持续交付2.0：业务引领的DevOps精要
作者简介
- 晓飞，2015年加入美团，美团外卖团队技术专家。
- 王鹏，2017年加入美团，美团外卖团队高级工程师。
- 江伟，2018年加入美团，美团外卖团队高级工程师。
招聘信息
美团外卖长期招聘Android、iOS、FE高级/资深工程师和技术专家，base北京、上海、成都，欢迎有兴趣的同学投简历到tech@meituan.com（邮件标题注明：美团外卖前端团队）。
军在港交所敲钟之后，追光灯转移到了王兴身上。
6月25日，港交所正式披露美团点评的招股说明书， 9月份在香港上市，上市当天市值510亿美元，超越小米和京东，成为中国仅次于BAT的第四大互联网公司。但上市不足一月，市值跌了25%。
有人说，中国的互联网分为上下两场，上半场以马云、李彦宏、马化腾、刘强东为代表，而下半场搅浑移动互联网这趟水的，就是王兴、张一鸣和程维。
江湖上关于美团和王兴的传言、评论和猜测很多，其实大家就想剖开美团迷之“野蛮”的边界，看看他的核心是什么。
美团简介
一般来说，美团的业务通常被称为一纵一横
- 一纵：与吃相关的业务：外卖（食品新零售）、到店（内容/deal)、餐饮店赋能（SAASERP）、食物供应链。
- 一横：吃以外的业务即，“生活的更好”的业务：酒店、电影票、门票和娱乐。
基于以上多元化且复杂的业务范围，美团到底是一家做什么的公司很难说明白。
- 其一，她所涉及金融、生活服务、吃、酒旅、文娱和出行等行业，竞争对手的体量和战斗能力每年都在呈指数级增长。
- 其二，美团的业务开始都不是原创，但在进入新兴领域之后，又总能后来居上，干掉领域老大，并且在其内部，后来的业务替换前面的业务，建立一种内部连续性创新增长引擎，而核心要素又是啥？
美团定位
在做美团之前，创始人王兴其实就有N次创业，2005年做校内网，2007年做饭否，2008年做海内网，这一些似乎都在为美团铺路，而其本人也说美团将会是其最后一个创业项目。
2009年，王兴提出的“四纵三横”理论：将互联网领域分为四块——资讯（百度）、交流（腾讯）、娱乐（盛大游戏）、商务（阿里巴巴）。所以他2007年饭否对标新浪，05年校内对标人人网，08年的海内网对标开心网，这些项目都是王兴以“社交形式”做电商的最早尝试。
2017年，美团联合创始人王慧文在演讲中提到美团内部很早就有“AB分类法”，他们认为中国电商大致可分为两类：履约在线上的和履约在线下的。
履约线下的除了阿里爸爸做实物电商外，其实生活服务类电商是一块很大的蛋糕。
携程做了异地生活服务电商，那么美团就做本地生活服务电商。
八年抗战，千团大战、外卖厮杀、圈地融资、烧钱补贴……淌出一条血路，清理战场，美团从餐饮团购这样的单点服务，到酒店，出行，新零售和金融，美团呈现出的个性迷之“野蛮”。
在那份五百字的招股书中：
2017年，美团完成超过58亿笔交易，交易金额高达人民币3570亿元，为3.1亿用户交易用户及约440万活跃商家提供服务，业务范围覆盖全国2800余县市。2017年，中国互联网用户数共7.72亿，中国有约1180万本地服务商家。
第三方数据显示出：中国近一半互联网用户在美团，三分之一的本地服务商家在美团。
所以，美团是不折不扣的互联网准巨头，美团拥有惊人的用户量和用户粘性。
由此，我们可以得出美团的定位就是：超级生活服务电商平台。
美团聚焦
所谓竞争并不是在原有领域把人挤掉，而是新的战场扩大，新的玩家占据新的战场，创新永远在边缘。
——王兴
这一段话说明了美团为何会选择本地生活服务电商。
创新永远在边缘，不要与巨头硬碰硬，而是选择从低端入场：
- 实物电商在选品、价格和物流上一定要具备足够的客户体验，淘宝聚划算做的是实物团购，要与之PK，必须自建物流，而这些并非是团购网站的优势。
- 生活服务是非标商品，更需要细节运营，并且毛利率极低，这些脏活累活，巨头看不上。照王慧文的话说是“我们爱上了含金量极低的活儿”。
- 行业蛋糕足够大。王兴在2013年指出，淘宝与天猫是商品电子商务，我们完全有理由相信服务类的电子商务规模不逊于商品类的电子商务。
在2010-2011年团购成交类项目中，58%是实物电商，只有40%多是生活服务团购电商，王兴当时只投了一小部分在实物，其他all in在生活服务类——
事实证明他确实发现了一片巨大蓝海，并且有人说千团大战中的其他友商其实不是美团干掉的，而是被聚划算打死的。
美团打法
低端入场的战略定位之后，如何落地？
美团升级通关打怪之后，把终极BOSS阿里给打出来了，那么他们两者最重要占据的都是场、流量和平台。
场是结果，一般要从人和货入手。那么如何抓关键要素？
李善友教授在《美团分形》演说中引入“创新之父”熊彼特的创新理论：组合创新。
组合创新，将所有要素的重新排列组合。
——熊彼特
李教授谈到：组合创新包含两个步骤：
- 第一个步骤是将经济体拆分到足够的小颗粒，往下拆的每一步，找到基本要素就深一步；
- 第二个步骤用不同方式将其组合，关键点就是寻找那个成功要素作为“1”，组合其他要素。
阿里的“1”是商家。阿里使命“让天下没有难做的生意”，所以阿里所有的商业模式都围绕服务商家的利益来打。亚马逊的“1”是顾客，亚马逊使命是“成为全世界最以消费者为中心的公司”。
团购鼻祖Groupon则是在商家身上获取价值，毛利率高达40%，因此Groupon选商家第一，消费者第二。
美团在2010年定了企业使命：We help people eat better, live better.
回到价值排序：客户分消费者和客户两端，两端都重要，都要服务好。若有冲突，选择将消费者排第一位，若没有消费者，商户不会用我们。
——王兴
亚马逊的贝索斯讲过：有许多方法能将业务集中与一点——以竞争为中心，以产品为中心，以技术为中心，以商业模式为中心，或者以为用户为中心。
显而易见，他讲的的是战略。
战略本身什么都不是，企业的管理、增长各种问题像一个球，如何找到支点撬动球，战略起到撬动其他资源的杠杆作用。（李善友《美团分形》）
而对于美团，以用户为中心就是她的战略。
消费者第一
“消费者第一”对于美团来说意义深远。
“消费者第一”美团的战略破局点，帮助美团挨过资本寒冬
2008年团购鼻祖Groupon成立，2009年6月获得1.4亿美金融资，2011年6月申请IPO，预期估值250亿美元。
就是这只大洋彼岸的大蝴蝶煽动了岸这边的“千团大战”。
千团大战，不是1000家，而是5000家。
一时间中国的VC和创业者都像打了鸡血一样“跑马圈地”，2011年广告大战爆发—— 团宝网 5.5亿广告；糯米砸了2个亿；团购网3-4个亿。
CNNIC报告显示：当年团购增长125%，市场推广费用涨幅10倍，10倍市场推广费用获得2倍用户增长，背后即有10倍投资人砸的钱。
而美团在资金上处于劣势：
- 2010年底，美团A轮融资1200万美元，红杉资本投的钱
- 2011年7月，B轮获得5000万美元投资。
而对手“拉手网”前三轮融资就累计1.6亿美元，大众点评是1.27亿美元。
那么，砸与不砸呢？作为创业者，王兴既想把盘子做大，又担心没有资本弹药。有限的资源怎么用？于是他请教关明生。
面向商家即B端广告没用，商家端广告投放再多，也不如有执行力的线下部队好用。而对于消费者C端，阿里的经验是线上广告性价比远远大于线下。
——关明生
其实就是回归到本质思考：
- 消费者第一：线上广告要比线下广告好
- 商家第二：地推团队比广告效果好
按照“消费者第一”的战略，王兴制订的战术是：
- 坚决不打线下广告；
- 疯狂采集线上流量；
- 建立强大的地推部队。
于是，美团开始在PC端线上疯狂采集流量，从UV到订单转化率美团能达到30%。他们想办法弄明白美团的每一位用户来自哪个渠道，对一次、二次消费情况做统计分析，摸清渠道性价比，甚至，把竞争对手的关键词全都给买了。
很快，Groupon的市值在2012年跌到25亿美金，中国千团大战随着Groupon的破灭而彻底熄火。
回头看，如果不是坚持“消费者第一”的路数，2011年美团不打线下广告，没有烧很多无谓的钱，在寒冬时保存好现金流，是美团做的最正确的选择之一。
“消费者第一”美团的增长引擎，以10倍速增长放大
以消费者第一思想为指导，美团提出了“三高三低”：高科技，低毛利；高效率，低成本；高品质，低价格。
首先，消费者要什么东西？永远要低价格、高品质其次，如何做到低价格，高品质？对运营有什么要求？要高效率，低成本。
我们给消费者价格肯定是商家给我们的价格加上运营成本，能降低运营成本的话，就不用加价许多。
如何提升效率？不能光靠大家加班加点，那是有限度的。还需要IT系统技术提升管理效率，需要高科技，但高科技不一定高毛利。
苹果是典型的高科技，高毛利，不过还有其他例子，亚马逊就是高科技、低毛利，这还需要大规模。
如果低毛利是规模小，便没有了商业价值。若它有巨大规模，哪怕低毛利，也有伟大的商业价值，亚马逊证实了这一点。
——王兴
秉承以上原则，王兴在2012年的时候，将美团对标亚马逊。
亚马逊的贝索斯是一个天才型的掌舵者，他的一段谈话很经典：
“未来10年，什么是不变的”永远要比“未来十年，什么是变化的”问题重要。战略，应该是all in 所有资源在不变事务上。在瞬息万变的零售业，什么是永恒不变的？
客户要低价，想要更快捷配送，要更多选择，这一点，未来十年不会变。
——贝索斯
亚马逊专注用户体验，并且认为是远大于客户期望的。
以最低价格，快速配送和无线选择是亚马逊的目标点。
美团利器
那么，对标亚马逊的美团，有什么杀伤性武器？
利器一：高科技
招股书上，美团对自己的定位是：用科技链接消费者和商家，并提供服务。
大数据和人工智能的突破能更高效重构产业链条。并明确本次发售所得款项净额的35%，用于升级技术并提升研发能力。
2011年，在所有人狂砸钱投广告的时候，王兴在开发IT系统，招聘技术和研发人员。
李志刚在《九败一胜》中写道：王兴是一个相信科技是第一生产力的人。
他说，在这个行业，或许科技的价值在短期内提现不出，但长远来看，多数人都低估了科技在其中的价值。
所以才有了后来外卖业务的外卖超级大脑——O2O实时物流配送智能调控系统，根据不同配送场景，智能调试，让订单和骑手智能匹配，保持运力，处于最优状态，
才有了美团开发到极致的AI语音调配手机通话；才有了号称全球最大规模同城实时配送网络——2017全年实现了29亿笔交易量；才有了平均配送时长的不断缩短，从2015年的平均41分钟缩短到2017年的28分钟。
试想一下，一个外卖公司有超过一万名的网络工程师，什么感觉？
有数据统计：美团在2015-2017年间，研发开支分别投入12亿元、24亿元和36亿元。依赖运营外技术的迭代优化，美团实现了最优配送路径。
利器二：移动互联网
一个行业要素要产生5到10倍变化时，行业才有可能百倍爆发。——王兴
2012年是互联网元年。
但在2011年3月4日，美团上线一周年时，第一版美团移动端就已上线。
在PC端千团大战硝烟弥漫时，王兴就成立了独立小分队开发APP，当时20个人全部鼓励使用HTC智能手机，有一个实习生负责开发APP。
在零推广预算情况下，借助支付宝赞助，获得第一批用户几千人。
- 2011年底，移动端占总交易额的5%，正式跑通业务小闭环。
- 2012年，终结所有PC端投入，坚决转型移动互联网，所有资源all in 移动端。同年，移动端交易额占比升到了20%。
- 2013年，移动端交易占比达到70%，提前一年完成移动互联网转型。
2012、2013年，移动互联网刚刚开始，是移动用户的超级红利期。无论买预装或下载都十分便宜。抓住这个窗口期大规模洗吸用户的只有两人，王兴和张一鸣。张一鸣在2012年创办了。
——梁宁
有人说美团是赢在“用户流量”，上述梁宁的话能证实这一点，而这种早期流量的积累更多归因于王兴对中国互联网进入下半场的判断——捆绑移动互联网。
这也是后来美团能在外卖领域后来居上，赶超饿了么的一个重要原因。
强大地推
美团有另一个称号叫“死人堆里爬出来的公司”。
2011年爆发的千团大战到2014年，由5000家打到仅剩下176家，死亡率是96.5%。到2015年10月，美团与大众点评合并，市场份额高达82%，千团大战终结的同时，团购时代也接近尾声。
美团当时面临的竞争对手主要有：
- 2VC模式：拉手网
- 并购模式：窝窝团
- 价值创造模式：大众点评网
其中以拉手和大众点评最红：
- 拉手网是2010年3月18日上线，2011年4月累计融资1.6亿，号称“18个月上市的公司”在11月份随着Groupon上市市值蒸发一半后，同期上市失败。
- 大众点评2003年成立，是早期的餐馆点评，2011年4月前累计融资1.2亿，到了2015年累计融资10亿美元以上，是美团最后期的主要对手。
如果说早期美团在互联网和技术能力上很好适应了消费者第一选择，那么如关明生所说，在商家第二时，线下运营能力成为核心。美团就暴露了巨大的短板。
而这时，王兴六顾茅庐，邀请阿里中供系干嘉伟的加入，建立强大的地推部队，则成为了千团大战打赢的关键。
江湖人称的“阿干”，也成为了这场大战中美团的灵魂人物。
干嘉伟建议王兴，美团前期增长关键在于供给端拉动需求端——执行“狂拜访、狂上单”策略，业绩就能慢慢好起来。
整理阿干在混沌上的演说主要有三大策略：
1. 美团扩张策略——核心
阿干老师认为，团购市场存在规模效应和网络效应，最终形成了“721”市场格局：第一名占70%市场份额；第2名20%苦苦支撑；最后一名10%朝不保夕。
美团的目标要成为70%，要赢全国。
全国拥有350个地级市（州），2800多个县（区），弹药有限，怎么打？
我们把350多个地级市及以上城市划分为SABCD五级，S级是北上广深这样的超级城市，AB级是各省省会，加上宁波和苏州这样的副省级城市，CD则是四五线城市。
——阿干
他认为，S级城市是兵家必争之地，绝大多数竞争对手都会投入巨大的资金和资源，但没有任何一家公司会取得绝对性胜利，而哪家做不下去了，也一定是最后关头才会关停这些城市的业务。所以这些城市具备很长的竞争周期。
而美团要做的就是保存实力，在S级城市只要咬住前三名，将资源投入到AB级城市，半年时间会取得领先优势，到时再侧翼进入一二级城市。
对于CD级城市，他认为不用打，人家做不好自然会撤，到时美团再去收割那些被培育过的市场即可。
2. 美团的补贴策略：花钱买来的流量没有价值，供给端才是核心
美团不补贴C端，而是补贴那些对消费者具备独特性供给的供给端，美团同样花钱，但只补贴供给的制高点。
C端补贴是扬汤止沸，相互捅刀子，而B端才是釜底抽薪。
3. 美团的盈利策略
美团将全国市场分为几个行业，在全国70多个城市每个行业设定一个毛利率，并且设1000多个管理节点，每个节点设计合理毛利润。并且通过IT管理系统强制实施，每个销售员在导入合同时都需要通过毛利率审批这一关。
就这样，慢慢拼凑出一个整体的毛利率，在行业巨亏的2012年，美团居然在11月开始神奇盈利了。
而以线上著称的大众点评，即便在2014年在腾讯投后引入大批腾讯人才，也因缺少线下地推运营能力而未起色。即便后来同样引入阿里系的干将，但留给他的时间不多。
据说：在美团与大众合并前，美团的现金流已经断了，美团就这么在死人堆里幸存了下来。
在后来与饿了么一战中，干嘉伟又转变了思路，在外卖市场，他发现撬动量不在供给端了，而是到了需求端。
面对美团锁定的校园市场，学生是需求端，那么什么是他们最关心的——当然是补贴。
这时，地推部队的策略就改成了“少上商家，多发传单，多做促销”。
并且得益于早期建立的完善数据统计系统，他们测算出7%的关键节点，以总成交量的7%作为节点，少于这个数就狂补贴，多了这个数就停止。
饿了么当时占领了12个城市，都是一线城市，但团队就只有300人，美团又一次遵循套路，低端颠覆方式进入二三线城市，并且发挥强大的地推优势，开启抢滩计划，平均每一天半收割一个城市，6个月后完成60个城市覆盖。
所以，强大的地推部队成为美团致胜的一个关键因素。
独立小分队
伴随千团大战结束，团购业务发展缓慢并慢慢消失，外卖崛起。外卖业务崛起是很正常的现象，与美团的运营能力无关
首先团购业务必定或多或少会影响到商家的生意，然后伴随需求侧升级，人们生活圈关注半径慢慢扩大，肯定不仅局限于吃。
这时美团就从供给侧和需求侧同时升级：
- 供给侧：美团与点评合并后，收购了支付公司钱袋宝，在店家安装扫码优惠买单业务，从消费者到本地生活服务场商户面去消费转变为我去帮商户做互联网服务。从2C到2B。
- 需求侧：到店业务不断扩大，住宿、门票、交通和自由行等“一站式”预定需求都满足，业务不断交叉协同，用户流量也被交叉利用。
前文提到美团在外界通过低端颠覆，总能不断赶超前人，创造阈值效应。而在其内部，旧业务不断替换新业务，形成自己的创新增长引擎。
独立小分队是关键。
混沌大学李善友教授同样引用了一段理论：克里斯坦森的《创新者的窘境》。
企业面临新业务时有三种方法可变革自己的思维方式：
- 收购一家有新流程和价值观的公司
- 把公司转型为适应新流程和价值
- 成立独立小机构，在小机构里跑通业务线，跑通闭环，寻找新的增长引擎。
携程选择的是第一种方式，通过竞争和收购方式进入市场垄断，实现超额利润，这个模式的好处是减少竞争，提高盈利。缺点就是用户体验被忽视。
而“消费者第一”的王兴显然不会这么干，他在组织形式上采用第三种方式——建立独立小分队。
独立小分队是在荒野里生长，公司对他的状态是做的好，就投入资源，做不好，就关掉。既给予团队充分的独立性，独立渠道和小规模的试错成本，同时也给自己的发展带来无限可能。
美团的版图扩张，前期都是独立小分队的成果，并且屡试不爽。比如：外卖业务。
2012年底，团购业务如火如荼时，王兴担心下阶段新兴模式出现会把自己干掉，于是果断成立了创新产品组，但并未对外宣布。团队开始架构是产品经理为首，几个工程师，2-3个人组成小组。这帮人像雷达一样把领域内如饿了么之类的APP扫射一遍，
把一个人从想吃饭到吃完饭后所有的动作去拆，思考哪一个节点会有商业机会。
2013年外卖立项，他们用了一个星期开发产品，并在美团总部周边发传单测试，从十几单到200单，在三个月内验证可行。2013年10月份，美团外卖上线，饿了么一家独大，市场份额超过50%。
这时的美团策略就有三个字：抄，抄，抄
最初产品形态，包括UI跟饿了么高度相似。
你面对标杆企业，你能学好就是一个能力了。
——王慧文
6个月的抄袭，是为了获得独立认知，找出对手漏洞，然后干掉对方。之后就有了前文提到的地推部队的校园之战
以及后来打入百度地盘，锁定白领市场，发现履约是关键性因素在骑手配送体系上的重度投入。
互联网下半场
2016年，王兴抛出著名的理论——互联网的下半场。
互联网的上半场得力于人口红利，美团住的是用户流量拼的是客户数，但在下半场，就是APRU值（每户平均价值）。
意思是，互联网的用户数不可能像以前那样翻倍增长了，因为互联网格局已定，但是每个用户可创造的价值远不止翻倍的空间。
所以，基于前文的分析，美团三板斧：
- 需求侧（消费者第一）：拥抱移动互联网，高科技砸钱
- 供给侧（商家第二）：建立强大的地推部队，打造强悍的运营能力
- 链接端口（美团第三）：三高与三低增长飞轮设置
但是，互联网的下半场，打怪打出终极BOSS阿里，美团的增长引擎基于流量之外，还有什么是可以立足江湖的？
准巨头不好当，看看武林各高手的增长引擎就知道了：
- 苹果：硬件手机/IOS系统（移动操作系统）
- 亚马逊：电商/AWS（业务流程管理开发平台）
- 腾讯：PC端的QQ/微信/支付/游戏开发
- 阿里：淘宝（2C）/蚂蚁金服/阿里云/菜鸟
马爸爸有钱是天下皆知，菜鸟通过收购民营快递资本硬生生把京东份额逼到50%以下，今年年初更全资收购饿了么，收购金额大概是90亿美元。
在饿了么外卖业务正式被阿里巴巴接手后，口碑也在10月和饿了么合并，整合百度外卖并改名为“饿了么星选”。
另，在招股书上写道：美团要构建一套基于餐饮业务的数据服务系统。
其实就是餐饮云计算，美团在夯实护城河道路上不遗余力，已投资了餐饮店几乎能得到的一切信息设施，菜单，定位、收银、SAAS、ERP等。
除了定位超级本地生活服务平台外，要么继续紧盯大众、高频与刚需空白市场，将传统产业与互联网深度融合抑或是开始全球扩张计划，也未可知。
正如王兴著名的“边界与核心”：
太多人关注边界，而不关心核心。万物其实没有简单边界，所以我不认同给自己设限，主要核心是清晰的。
我们到底服务什么人？给他们提供什么服务？我们就会不断尝试各种业务。
——2017年6月，《财经》小晚对话王兴
一切静待时间验证。
- 混沌大学李善友教授：《美团分形》
- 梁宁：《美团的开局与破局》
- 《财经》小晚：《对话王兴》
- 李志刚：《九败一胜》
作者：Alice，公众号：Alice 二三事
本文由 @Alice 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自网络
