揭秘YouTube从乱局中锻造高效敏捷机制，维持文化独立性的同时把握超速增长。了解YouTube独特的策略规划流程、6周冲刺计划及周密的日常会议体系，探索如何在闪电式的业务扩张中保持创新和协调，同时实现顺畅的跨部门合作。本文还将分享实用的敏捷操作模板，供其他企业参考，并适应到不同的团队环境中。
01. YouTube面临文化融合、超速增长和敏捷协作多重挑战
当时，YouTube内部正面临着很多很现实的挑战。
文化融合：公司很早就被收购了，我们必须适应融入Google，一个已经以其仪式感而闻名的科技公司。但YouTube有自己独特的文化和挑战，所以我们在借鉴许多最佳做法的同时，也认识到许多Google的机制并不完全适合。
业务扩张：从2008年到2014年这段时间是 Youtube超速增长 的时期，各项指标的记录都经常被打破，我们的用户群和收入从数百万增长到数十亿，我们的团队的规模必须迅速扩大以跟上这样的发展速度。里德-霍夫曼（Reid Hoffman）现在将这种现象称为 “闪电式扩张”，我们必须适应我们惊人的增长速度。
团队协作：YouTube大多数业务是非常相互关联的，我们在产品上的升级迭代，很快就在创作者和广告商社区中产生了涟漪。我们对我们的市场模式所做的调整必须与关键产品的发布同步进行。协调工程师、产品经理、内容合作经理、市场营销人员、新闻关系人员、律师和其他人员组成的跨职能部门之间的协作是很常见的。
当这些挑战没有得到很好的解决，混乱随之而来。
规划不断调整：感觉我们总是在计划和重新计划，新的计划与工作经常会打乱每个团队正在执行的计划和已经付出的努力。
组织流程混乱： 团队经常抱怨组织流程要么过于自上而下，不允许有创造性的自由，要么过于自下而上，缺乏一致性/优先性。
会议安排冲突：会议没有得到很好的计划，经常缺少合适的人或合适的信息。当所有的会议同时都很重要时，团队很难做出权衡
决策路径模糊：在这样一个相互交织的业务关系中，往往很难知道该聚焦什么优先级
我们慢慢地构建了一套对我们来说很有效的日常运营机制和最佳实践。随着时间的推移，YouTube团队开始以 “可控的混乱 “而闻名，变成了一个能够经营复杂业务并采取有意义的战略举措的高度统一的团队。这样的敏捷文化成为我们的一个亮点，我们的团队坚持把其作为突破困难挑战的驱动力，并吸引着更多志同道合的人加入YouTube。
我承认，当我身在其中的时候，我并不总是觉得我们这套机制有多独特。当我2014年离开YouTube时，其他一些公司的领导人要求我帮助他们了解YouTube的运作方式。其中，Daniel Ek（Spotify首席执行官/联合创始人）他建议我也许可以写下我们关键运营机制的简短总结，以便其他人可以从中学习。开始我是给Daniel回复电子邮件，后来逐渐变成了几页文章，再后来就越写越多。
随着这份资料的丰富与拓展，我发现它可以满足三种不同类型读者的需求。
1、历史研究者。对于那些对Youtube发展历史感兴趣的人来说，这篇内容应该对我们的日常工作如何运作以及权衡进行了很好的总结。
2、管理规则制定者。对于那些通常负责为他们的团队制定计划和进度的读者，我发现小细节往往比看起来更重要。因此，我会在内容中很详细地介绍计划的制定和日常运营的细节，包含具体工作流程，以及权衡利弊的核心决策因素。
3、运营实施者。一些人想拿起这个方法并直接重新实施它。虽然很难将一个团队的工作节奏移植到另一个团队，但很多基本模板都可以在本文找到，可作为一个起点，帮助更多团队实践更高效的敏捷运营机制。
值得注意的是，这已经是一个近十年前的快照。这里的大部分流程后来都被目前的YouTube团队调整过。但是基于当时的YouTube所处的背景以及面临的挑战，无论是对正在面临相同困惑的团队，还是目前团队运作良好，但希望能在未来团队进一步扩大时规避运作混乱风险的团队，定都能从本文获得新的启发。
02. YouTube加速探索推出三大敏捷组织运营机制
虽然这不是一夜之间发生的，但YouTube的日常运作节奏逐渐稳定在下图呈现的这种模式中。
在Google，大多数团队都是按季度进行OKR计划的，也就是3个月的周期。但我们发现这很尴尬，3个月的时间难以匹配上我们闪电式扩张的速度，但对于实现我们更宏大的目标来说，却又太短了。与此同时，谷歌传统的 “70% OKR规则 “更加剧了这种目标制定的难度。
从Google的季度规划流程中分离出来并不容易，因为我们仍然需要与Google团队进行很多协作。但我们发现，转变为6个月/6周的计划模式能更适合我们团队的运作方式。
因此，我们将计划分为两个独立的过程，图中最左边的两部分是我们的6个月的战略计划和以6周为单位的冲刺计划。6个月（24周）的战略计划以确保我们有更充足的时间来完成有价值的目标；6周为单位的冲刺计划能帮助团队聚焦于我们6周内真正能完成的任务；最后是每周日常计划，在有了我们的战略计划和冲刺计划之后，我们就可以专注于推动每周正常的项目执行与运作机制（图中最右的 “绿色 “部分）。
YouTube正是构建了以战略计划、冲刺计划和日常计划为核心的三大 敏捷运营机制 ，实现了“可控的混乱”，以敏捷文化推动组织绩效的提升。接下来，文章会进一步阐述关于实践这三大敏捷运营机制的具体细节以及一些参考模板。
2.1 敏捷机制一：聚焦资源最优分配的战略计划
2.1.1 战略计划：优先排序关键大目标，以主导资源最优分配
战略计划是通过自下而上和自上而下两大关键流程完成两大关键的产出：（a）大目标清单和（b）项目资源分配。
自下而上的过程指的是对每个细分团队（基于公司业务细分设立的团队，例如YouTube的核心业务分为4大聚焦领域，并进一步细分为15大投资领域，甚至可进一步细分）的总结回顾和后续计划进行集中地评审和沟通。自上而下的过程涉及核心团队和支撑团队的头脑风暴，完成大目标（更大且更重要的目标）优先分配与共识，以此保证YouTube推进任务的一致性。
项目资源的规划和分配对于确保我们实际执行中的一致性至关重要。这不仅显示了分配给团队和大目标的总人数，同时也迫使我们在计划阶段就能基于实际资源分配进行决策的利弊权衡。
战略规划需要非常紧凑的一段时间（通常是的3个星期），而且非常全面（公司的每个团队都参与其中）。虽然这是一个时间非常紧的3周，但产出是我们后续运作的重要支柱，大多数YouTube员工可以立即背出当前我们关注的核心大目标，并了解他们的团队如何为其作出贡献。这个过程也是保持团队共识公司核心价值的关键步骤。
（1）自下而上的过程
自下而上的过程，需要全面审查每个团队的状态和目标。每个团队都必须撰写了两部分的内容（通常是4-5页），涵盖了他们在过去6个月中所完成的工作，以及他们在未来6个月中想要关注的内容以及发展计划。
使这一过程尽可能大地发挥作用的核心关键是完成快速评审。我们有大约70个团队的评审需要完成，我们会尽量控制在一周内完成，以减少时间拖得太长而产生不必要的干扰。
我们的做法是让每个团队提前几天发布包含回顾过去和展望未来两部分的文件，然后我（和其他团队负责人）会仔细预读所有的文件。每个团队的审查时间约为10-15分钟（每个投资领域分配约3小时的时间段），也并不需要团队进行内容演示。一般来说，我在开会时都会给团队列出几个重点问题，然后我们就按照这个清单进行讨论。我试图确保我至少完全理解他们想让我知道的三件事，以及能让他们更快发展的三件事，但也经常会问他们写的其他领域的问题。
团队为确保材料做得更好更全面更简洁会付出了很多努力。让团队记录下他们的目标和计划是一种很好强化目标感的仪式，而且这份文件也会成为团队前进过程中的方向指南，为团队成员或者新员工的决策提供参考。
就我个人而言，这一直是我一年中最喜欢的一周，因为能帮助我很好地认识各团队正在进行的所有出色的工作。一些团队在日常工作中或许会受到关注，但大多数（绝大部分）团队并不是，所以这是一个很好的机会，以确保他们的工作被充分理解和认可。团队经常评论说，他们非常重视这个过程给他们带来的反馈和认可，这对他们来说能起到激励的作用。
公平地说，这个过程是一个确实会耗费一定时间，但对我来说，这是非常值得的，且经常得到参与团队的积极评价。
（2）自上而下的过程
自上而下的过程包含以下四大关键步骤：
1、与核心团队（YouTube为科技公司，核心团队主要包括产品、工程和设计团队）开展头脑风暴会议，时间可安排在评审团队文件的2周前。
- 在第一次会议上，我们将总结过去6个月的工作情况，并讨论今后优先目标的不同方案。然后，我们会要求每个人在一个共享的电子表格中加入未来6个月的优先考虑的想法。我们会做一次 “投票”，然后，我将快速浏览并挑选出一系列重要的项目，让我们在下一次会议上继续讨论。本次会议上的投票正是一次初步的筛选，一般来说，我可以增加一些没有得到票数但我仍然认为重要的东西。
- 在第二次会议上，我们将看到关于我们在第一次会议上选择的每个项目的简短幻灯片演示，以更清楚的细节重新规划在上次会议上可能不清楚的目标，等等。在这些介绍之后，我们将再次投票，我将再次选择多个高得分的项目，以继续推进。
2、与支撑团队（主要包括销售、营销等商务团队）的信息补充会议。我们会与每个职能部门（销售、市场等）举行了一系列会议，以获得他们的意见反馈。每个业务职能部门的领导在没有提示的情况下可以提出潜在的优先事项清单，这些优先事项将与核心技术团队的头脑风暴结果进行比较。大多数时候，偏差很小，因为我们倾向于在已输出的结果上听取这些意见，但偶尔这些意见也会导致变化。
3、接着，在完成细分团队的评审之后，所有核心技术成员会重新聚集在一起，做出最终决定。通常，当计划进行到这个阶段，很多数据都会更加明晰，例如我们的总体人数预算应该是多少，我们需要考虑多少有机增长，等等。
- 在会议之前，我通常会提出一个潜在的大目标清单来展开讨论，通常是根据我们最初的结果和我们在团队评审中看到的内容。对于每一个大目标，我们都会指定一个大目标经理。
- 大目标经理的任务是更准确地定义大目标，并列举他们认为在大目标若是要取得成功所需的团队资源（若可能的话，最好列出指定的姓名）。
- 会议期间，重点是调整资源的规划和分配，各大聚焦领域和投资领域的团队将各自提出他们希望分得的资源，然后我们会同时查看每个大目标经理的要求。不可避免地，我们会有太多的大目标需要资源配备，但这有助于我们看到真正的冲突所在。我们连续举行了几轮小组讨论和分组讨论，试图调和这些矛盾。最后，我们通常会达成共识，但如果需要打破僵局，我将作出最后的决定。
4、最后则是正式公告。即便在正式完成大目标决策之后，我们仍需要进一步将这些内容记录下来，并向整个组织的其他成员解释这一切。我将起草一份涵盖被选中的大目标以及原因的总体邮件，每个团队将根据我们的决定填写电子表格以进行人数规划，每个大目标经理将准备他所负责的大目标的总结 “海报”。然后，我们将通过电子邮件发送这些材料，并在第二天召开全体人员会议，让每个大目标经理介绍他们的海报并收集全体成员的问题和反馈。
2.1.2 战略计划实践一：核心成员分配“大石头”的优先级
Youtube在比喻其大目标的时候，会将其称为“大石头”。其核心思想很简单：如果你想填满一个罐子，你先把大石头放进去。然后有足够的空间让小石块、沙子等填入其余部分。但是如果你先放沙子，然后放小石头，再放大石头，大石头就放不下了。
我们在YouTube非常喜欢这个比喻，我们H1/H2战略规划的其中一个核心产出就是挑选出这组”大石头“。我们尝试了许多临时性的方法，但最有成效的方式就是分配100美元的虚拟资金（如果你有一笔虚构的100美元要在每个候选 “大石头” 之间分配，你会如何分配它们？
这里需要注意点是，匿名分配，然后集体看结果，避免决策之间的互相影响。
关键步骤包括：
1、添加候选大石头：在YouTube上，我会首先提出几个供大家参考，而团队成员通过头脑风暴添加他们认为重要的发展方向。重要的是要控制候选长度，注重利弊权衡，所以我会在开始投票之前调整这个名单，删除重复的内容等等。
2、每个人分配他们的资金：每个团队成员应该为每个候选“大石头”分配手上虚拟的100美元，并填上评论。每个人只能看到自己的分配。
3、全员综合评审：下一步是进入揭晓和讨论的阶段。注意，在每个人完成他们的个人分配之前，不要展开这部分内容。可通过表格查看每个“大石头”平均分和分数分布的情况。
2.1.3 战略计划实践二：各团队完成“回顾过去”与“展望未来”
公司业务细分设立的团队，例如YouTube的核心业务分为4大聚焦领域，并进一步细分为15大投资领域，甚至可进一步细分，每个团队可以通过一份简单的文件，展示团队基本信息（包括负责人、团队人数、预计人数和正在招聘的人数）以及团队的战略更新和计划。
最为YouTube团队非常关键的自下而上的流程机制，此机制要求各团队完成写一份包含回顾和计划的文件，包括他们在过去六个月中取得的成就以及他们在未来六个月中想要关注的内容。
模板是相当开放的，各团队可以创造性地使用他们的方法，但有几个关键部分是我非常坚持的：
1、三件高层管理团队必须知道的事情：这可以被理解为摘要，确保关键信息能被高层管理团队悉知。即便是高层团队确实知道团队正在干什么，但是万一他们不清楚呢？
2、三个核心关键能帮助团队高效产出：这些往往是讨论的关键点。例如提出增加资源的要求，即便资源的增长通常会有门槛。更常见的是澄清战略层面的共识，和对其他团队的协作请求等等。
3、目标愿景展示（可以图表的形式呈现）：以更直观的方式展现目标愿景，可以是图表，例如团队希望某项指标突破X值，也可以通过图片甚至是激励性的句子，展现团队的核心驱动力。
模板的其余部分由团队决定，尽管一般来说，他们至少涵盖了成就（向后看）和关键战略下注（向前看）两大部分。
2.1.4 战略计划实践三：基于“大石头”和投资领域进行资源分配
基于 “大石头 “优先级排序和团队评审之后，团队会决策出最终版的“大石头”清单并达成共识，下一步就是分配资源。
关键的挑战是，我们将资源分配给我们的团队（即不同的投资领域），但“大石头”往往需要跨越多个投资领域。例如，为了推出YouTube音乐，我们需要许多团队的帮助，从搜索和发现团队，到纯音频流的新基础设施，再到创作者团队。
我们会通过一个复杂的表格中记录这些资源的分配，资源分配主要有2个组成部分：
1、“大石头”团队（又称 “帽衫小分队”）资源分配。“大石头”是我们从100美元资金分配的优先级工作中产生的，这些 “大石头 “通常会与一个投资领域的团队紧密结合，但有时也会跨越多个团队，我们经常称这些为 “帽衫队”，以表明这些团队成员应该把他们的主要团队看作是大石头团队，而不是他们自己的IA，其标志是回答 “如果要求这个人穿他们团队的帽衫上班，他会穿哪件帽衫。”
- 添加你的“大石头”清单，尽量使分配的人员数量接近目标人数。
- 通常每个人会被分配0-1个大石头。一般认为，一个人被分配到多个“大石头”是不好的做法，但这种情况偶尔也会发生（例如，对于非常专业的技能组合，或一些负责关键路径的团队），在Youtube 这种情况小于1%
- 一般来说，尽量不要将TBH（待招聘人数）分配给“大石头”，“大石头”需要被优先考虑。
可从产品/工程/设计/营销/销售团队负责人中选择“大石头”的负责人
2、投资领域团队资源分配。YouTube团队被组织成15个投资领域团队（被分成4个重点领域），作为我们的主要组织结构和规划与分配的主要单位，每个员工都会属于某一个投资领域。这些团队会在他们的团队文件中提出了他们对人数的要求，也管理着他们的团队成员在 “投资领域 ” 和 “大石头 “之间的资源分配。
- 设定目标人数，基于零基预算法，计算实际需要总人数，包括待招聘的人数（TBH）
- 后续可向招聘团队提供待招聘的人数（TBH）
- 确保大石头的资源分配为最高优先级，尽量不要出现TBH
- 每位成员都会被分配到特定投资领域
- 密切关注大石头的百分比“大石头”所占资源一般在30%上下，以规避赌注过大所带来的风险。
这两个维度之间的资源分配的调整过程是循环进行的，例如：
- “大石头”负责人会提出要求，包括认为在总人数以及他们所需的具体团队/技能方面的需求。
- 投资领域的负责人会在他们的团队文件上提出要求人数，并预计他们团队能为“大石头”贡献什么，以及他们的团队本身所处的投资领域需要什么资源。
- 在与个人进行1对1谈话沟通后，被选中的成员会被分配到 “大石头 “团队。
- 比较要求的预算和分配，看看我们是否实现了资金的平衡。如果没有，我们将再次进行迭代，也许是增加对一个投资领域的资金，或者减少/取消一个“大石头”的优先级。
2.2. 敏捷机制二：共识具体可执行任务的冲刺计划
2.2.1 冲刺计划：以六周为单位，进一步细化分解可完成的具体任务
每6周一次的冲刺计划使团队能够将战略目标进行具体化，并聚焦到他们能够在该时间段内实际完成的事情。与Google “70%的成功 “标准的愿景型OKRs相比，这些冲刺计划的目标是团队可以100%实现的承诺性目标。
我们试图尽可能地保持目标的轻量度，并将时间控制在较短时间内。我们把6周作为理想的运作节奏，主要是因为它与我们的iOS发布的节奏相一致，但就整体规划节奏而言，它也被证明是很好的实践。
冲刺计划的目标计划类似于scrum-of-scrums模式（一种规模化敏捷的框架），包含有两个平行的过程。
1、明确团队目标：
- 执行：每个团队自行开展规划，并对其6周的目标清单进行优先排序。
- 数量：每个团队需要公布他们的目标清单（通常是4-5个）
- 标准：目标是指具体的和可衡量的
- 产出：目标有可能是阶段性目标，因此目标中需添加协作团队。例如：团队A将准备好X，以便团队B可以在下一个冲刺阶段做Y
2、明确协作目标：
- 执行：各团队在一起，讨论彼此团队直接的协作关系
- 产出：记录团队目标汇总表格与冲刺目标表格
2.2.2 冲刺计划实践：明确团队冲刺目标与协作目标
在YouTube，我们在一套非常复杂的电子表格中完成了这一过程，并使用了大量的appscript来尝试模拟多种可编辑的视图。下面表格可供参考。
1、团队目标汇总表格。团队的目标汇总表可与投资领域资源分配表进行对齐。然后添加各团队的冲刺目标和协作目标。目标是具体且和可衡量的。
2、冲刺目标汇总表格。冲刺目标可进一步与“大石头”资源分配表进行对齐，追踪“大石头”完成度，作为填写冲刺目标的一部分，可以指出一个目标是否依赖于前置目标和其他团队，随着冲刺的进展，团队定期更新冲刺目标中每个目标的进展，持续记录目标进度以追踪实际情况。以上内容均可通过项目管理工具以可视化工的方式呈现。
2.3. 敏捷机制三：团队保持高效与协作的日常计划
2.3.1 日常计划：通过四大会议和七大原则，持续实践团队敏捷运营
（1）四种主要会议类型
我们有4种主要的会议类型，并为每种会议定义了明确的期望。
1、信息分享会：属于较大型会议，主要用于广播信息和协调工作，例如周员工会议，数据会议和全体员工大会。
2、决策评审会：为决策而设置，属于小型会议，待决策选项会提前通过电子邮件进行预审，例如产品评审和交易评审
3、项目共识会：也称为小组式1对1，有固定与会人与时间，例如针对投资领域展开的会议，跨职能部门的负责人都会参加
4、1对1沟通：由于项目共识会解决特定的项目讨论，1对1沟通主要承担教练的功能
（2）会议分类的关键优势
以下是将会议分成这四类的一些关键优势：
1、将信息分享会与决策评审会分开：这意味着我们没有试图在员工会议上做出许多重要的决定。这不仅仅是与会者不对的问题，通常决策评审会议的可选与会者名单会包括所有信息分享会的与会人（例如，所有YouTube核心技术的工作人员都是产品审查的可选与会者）。但将决策评审分开是非常重要的，因为会议有非常不同的基调和期望。
- 更加有针对性地出席会议：如果你与决策评审会上的某项决定不相关，你可以放心地跳过，因此，参加决策评审的人一般都能对评审的结果非常感兴趣。
- 减少组织结构所产生的 “阶级系统”。在许多组织中，决策通过组织结构向上传递，其机制是由越来越多的高级员工会议来评审。在这种情况下，我们明确了一个信息，即信息分享会是关于协调、广播等等的，你能否参与决策与你参与了某个信息分享会并没有直接关系。
- 决策会议是非常集中的。通常是针对一个明确阐述的问题，从一组明确定义的选项中做出选择。由于材料总是提前发送，而且事先用电子邮件进行沟通，所以在决策评审会上进行决策讨论比在员工会议上进行讨论要好得多，也更有针对性。
2、将项目共识会（也成为小组式1对1）与 1对1沟通分开：在一个科技公司里，你的大多数团队都是包含跨职能的成员。如果你在1对1会议上进行项目评审和战略讨论，几乎会以电话游戏告终（即不断打电话找他人确定某些信息）。负责某一个项目的项目管理人员会回到他们的工程技术人员那里，说 “Shishir在我们的1对1会议上说了什么”，然后工程技术人员就会把它加入到代办事项中，在他的1对1会议上与你进行进一步讨论。因此召集特定项目的相关人员进行共识比分别与每个成员进行1对1沟通，更有效果，尤其是针对项目执行的相关问题。
3、设定固定时间的项目共识会，以取代临时的会议：记住，核心目标是尽量减少临时会议。一个非常常见的请求是 “我们能不能安排一个会议来讨论X问题？” 我的自然思考过程是，首先询问是否有针对该项目的共识会，并建议在那个会议上进行共识和讨论。首先，它确保了正确的人能被召集起来进行讨论，且不需要做日历协调。其次更重要的是，如此能提前筛选该问题的优先级，若是这个话题不够重要，不足以在项目共识会中讨论，那么它很可能不够重要，也就不适合召开临时会议。
（3）日常工作计划的核心理念
我们每周的工作计划是基于几个关键的理念：
1、尽量避免临时性会议：这肯定是最有争议的，但我们的流程是为了尽可能避免临时会议。我们发现，临时会议有很多弊端。首先，每次会议都需要协调与会者的日程安排，所以会把讨论推后（”我能不能用15分钟来聊一聊X “最终会在2周后发生）。但更重要的是，缺乏明确的结构往往会导致会议没有成效，人们不知道这是一个信息分享会议还是一个决策会议，也不清楚需要什么程度的准备工作等等。因此，对我们来说，创造合适且定期的会议，是提供足够的时间并邀请合适的出席者，减少临时会议的一个很有效的实践。
2、预留分散讨论时间：我们的许多会议后程会包含一个很长的 “缓冲 “时间——分散讨论时间。这段时间故意没有结构化，没有任何议程，唯一的规则是你必须保持在场。这将允许许多 “多线程 “的讨论自然地展开，如果你没有人跟你说话，你可以继续自己的工作，直到有特定的需求或讨论找上你。许多这样的讨论本来会通过临时会议进行讨论，但却在规定好的时间内得到了及时的反馈与处理。因此，YouTube形成了一个更加紧凑的团队，毕竟对某一主题感兴趣的人往往与最初设定的不同。
3、专注提高会议效率：分散时论和邮箱广播均能缩短会议时间甚至代替会议，有几封关键的定期广播邮件是很必要的，包括我周日晚上会给团队发的总结邮件。我们通过这种方式节省了大量的会议时间。
4、开有准备的会议：我们几乎从不在会议上演示任何东西。材料总是提前发送，各成员需要预先阅读材料。我们几乎所有的会议都被安排在30分钟之内，而且经常提前结束。
5、问最关键的问题：团队必须学会提出正确的 “特征问题”，例如通过2个特征问题可以直接且间接地解释所提出的10个问题，从而以正确的方式确定讨论的框架，提炼出最核心的问题，·提出值得时论的议题，而不是急于寻求解决方案。
6、避免重新安排会议时间：高层临时的会议移动，都会对整个组织产生巨大的蝴蝶效应，因为高层会改变自己的日程以配合日常的计划。此外，对会议的准备程度与对会议实际发生的期望是成正比，因此确定性意味着更充分的准备。
7、敢于取消会议：若是能通过有邮件确定的议题就没必要通过会议讨论，由于我们会事先发送的会议的材料，一般来说，在会议之前就能清楚地知道是否有理由开这个会。我们经常发出讨论议程，并通过邮件解决了待商议的问题，然后直接取消会议。
（4）日常计划会议一：信息分享会
信息分享会一般比较大型，主要用于信息广播和工作协调。最重要的是，这些论坛不是决策论坛。例子包括我们的每周员工会议、统计会议和我们的全体员工会议。我们常见的实践包括：
分散讨论：我们经常用分散讨论（Bullpen）来补充这些会议，每个人都必须呆在那里（即使只是在他们的笔记本电脑上工作）。我们避免了许多临时性的会议，因为人们会说 “我们可以在分散讨论的时候聊一聊”。
广播式电子邮件：我们建立了一个模式，通过广播邮件发送一些东西，例如，我在周日晚上给YouTube的核心技术团队发了一封电子邮件，内容是对过去一周的总结和本周需要关注的关键事项。然后，当我们到了周一早上的技术人员会议时，我们就可以专注于人们的问题。我们每周的员工会议只有30分钟，以及一个小时的分散讨论时间。
我们的主要信息分享会议是我们的员工会议，总共包括六种信息分享会。
1、技术成员分享会
- 这是我的主要员工会议，包括我所有的直接PM、Eng、Ux领导，以及一些关键的间接人员（例如我们的测试和设施的负责人以及特定技术领域领导等）。会议有大约20名成员，会议本身是在周一上午举行的，时间为30分钟，由我的助理负责。
- 在会议之前，通常是在周日晚上，我会发送一封电子邮件，说明我对前一周发生的事情的总结，以及我认为下一周的关键优先事项。
- 会议的常设议程项目是评审发布日历，看看那一周有什么要发布的，并评审我每周邮件中的提到的任何问题。有时还有其他议程项目，特别是在绩效评审的阶段，或在H1/H2战略计划期间，但这个会议的正式部分往往会提前结束，然后进入到分散讨论。
- 技术成员分散讨论在员工会议结束后立即开始，通常非常活跃，规则是你必须坚持下去，即使你所做的只是在你的笔记本电脑前工作。一般来说，人们会利用这段时间来处理跨团队的临时讨论。
2、业务成员分享会
- 这是Robert与所有 “业务 “领导人（特别是内容、销售、营销）的分享会。议程由Robert的助理主导会议进程，会议一般持续一个小时。Rober和我会交叉参加彼此的会议，以确保技术和业务方面保持同步。
3、跨职能成员分享会
- 这是一个跨职能的员工会议，包括来自技术人员、业务人员和其他一些人。
- 这是一个非常大的会议，通常60多人被邀请参加。
- 议程是通过一套主要的指标（收入、收视率等），然后通过更新即将推出的产品/活动，并回顾最近推出的一些产品/活动的结果。这个会议是由我的助理和我们的数据科学团队负责人共同负责的。
- 会议被安排在每周三，持续30分钟，尽管它经常提前结束。会议之后也是分散讨论，遵循与技术团队分散讨论相同的规则。
- 考虑到这个会议的规模，对于它的有用性总是有很多争论，我们尝试了很多不同的方式。我的观点（也是大多数人的观点，但不是普遍的共识）是，如果不考虑其他原因，这个会议起到了很好的作用，因为它迫使大家聚在一起参加分散讨论，因为这种水平的跨职能的互动往往是很难正式化（例如，一个二级的内容负责人与一个单独的工程负责人谈论一个某一个问题）。
其他主要的信息分享会包括：
4、全体成员聚会
- 在我这一级，我们每季度举行两次会议，一次只针对技术团队（产品、工程、用户体验），一次针对所有员工。我们讨论过更频繁地举行会议，但决定不这样做，因为（a）Larry/Sergey每周五举行TGIF，而且参加的人很多，所以再增加一个会议似乎很多，而且（b）我们想鼓励每个团队（如浏览者团队、内容团队等）做他们自己的、更频繁的团队聚会。如果不是每周，至少每月一次（像谷歌TGIF）。
5、数据分享会
- 每周五由我们的数据科学团队进行90分钟的会议，简单地介绍了一小部分背景内容，和一长串有趣的数据结果的介绍。
- 我们经常会在90分钟内看完100多张幻灯片（每张幻灯片有4个以上的图表），主要是因为数据非常好，故事也很有意义。
- 开始时是一个小团体的会议，但逐渐地，越来越多的人想参加，我们随后开始在世界各地的许多房间里举行视频会议，以便更多人能够参加。经常可以有100人参加会议。
- 虽然这不是一个正式的决策论坛，但对于大型发布来说，通过这个数据分析是一个必要的要求。例如，如果你要推出一些对指标有重大影响的东西，你就把它带到这个分享会上。团队通常会对指标进行更深入的分析，并做一些诸如 “赢家/输家 “的分析，以了解什么指标会受到发布后的正面或负面的影响。
- 如果有一个问题需要进一步讨论，我们通常会指定一个项目共识会或者产品评审会来跟进这个问题。
6、外出聚餐
- 这是一个非常有趣的传统，大约每隔一周，我们会去一家当地的非常好吃的点心店。我们会公开邀请，一般有20-30人应邀。我们会在午餐时选择一个话题进行讨论，例如，TrueView这个名字就是在那里形成的。
（5）日常计划会议二：决策评审会
决策评审会是明确为决策而设的。有一个非常小型与会者名单，并且每次会议都可以增加新的必要的与会者，我们通常有一个广泛的可选与会者名单。一个描述决策（和待决策的选项）的文件会提前通过电子邮件发送，以使过程更加顺利和高效。通常，在会议召开之前，很多决定都能通过电子邮件达成共识。例子包括产品评审和业务评审。
决策评审会主要包含以下三大评审会。
1、产品评审：关注技术问题
- 这是我负责的评审讨论会，基本上涵盖任何 “技术 “问题，非技术问题会交给业务评审会，对于技术问题，这个评审会是最终的决策论坛，因此我们总会得出结论，例如 ”我们不会做出这个决定，直到{X数据被收集，Y原型被构建，等等}“。。
- 与会者名单由要求评审的团队自定义生成，但技术部门的任何人都是可选的与会者。
- 会议在周一举行，为这周定下基调，没有什么能比一个好的产品回顾来启动一周的工作更让令人感到舒适。
- 会议通常是30分钟的时间，尽管有时人们要求更长的时间。但会议经常提前结束，特别是如果邮件已经针对大部分内容完成了决策。
- 通常周四会通过电子邮件发送出待评审内容文件。非常广泛的群体被抄送，包括每一个PM，每一个技术领导，等等，超过100人将看到这封邮件。整个周五和周末，人们都会给予回复和评论。周日晚上，我一般会阅读文件以及每个人的评论，然后发出我的总结。我的总结一般会成为实际会议的议程。我们会假设每个人都读过这份总结并关注了邮件的内容，然后基于我的总结展开讨论。
2、业务评审：关注业务问题
- 这是由Rober主导的，涵盖任何业务问题。
- 它通常以交易评审为主，例如与新伙伴的内容交易、销售定价/折扣，等等。有一个指定的合规人员，以及一个升级程序（对于较大的交易），以提到Google的交易评审会进行评审。
- 它遵循一个类似的模式，即提前几天发送文件，而不是在会议上花时间与人介绍。
- 与产品评审不同的是，这个会议安排了一套固定的所需与会者，以及一个更窄的邀请名单。既是由于评审的合规性，也是由于（坦率地说）我和Robert的风格不同。
3、工程评审：关注更细致的技术问题
- 这是由我们的高级工程师（我们把这个角色称为 “技术领域负责人”）负责的。
- 它涵盖了技术实施问题，这些问题对于产品评审来说通常过于具体。这个会议通常发生在产品评审之后（产品评审确定了方向，然后工程评审评审了特定的实施选择），有时也会发生在之前（在工程评审期间，我们会确定一个问题会更严重地影响到产品，因此进行升级）。
- 我们有一个核心的技术领域小组，他们是可选的与会者。
- 会议遵循与产品评审相同的模式，即在评审前发送评审材料和进行电子邮件讨论。
（6）日常计划会议三：项目共识会
项目共识会议也被称为 “小组式1对1″。当我注意到我与每个人进行1对1交流，并在讨论过程中需要团队中其他人参与的时候，这就产生了小组式的沟通。例如，我与每个投资领域的负责人团队每周举行一次项目共识会，项目管理负责人、工程负责人和用户体验负责人（以及其他相关的跨职能部门的同行）都会参加。
项目共识会可以指的是任何会议，(a)与会者是固定的（几乎从不增加新的人），(b)它被安排在每周的固定时间（而不需要重新安排），(c)有一个 “滚动 “议程（有一个包含议程和行动指南的文件，如果你没有时间，可在下一次会议上再来讨论滚动的议程）。他们往往可以不那么正式，正如1对1沟通。
这些可能是我们最独特的会议类别。正如我上面所描述的，我们把这些会议当作小组式1对1，为任何我们认为需要持续协调的项目或者团队创建这些会议。它们将其分为几个类别。
1、聚焦领域项目共识。YouTube的技术团队被分为4个聚焦领域（浏览者、创造者、广告商、基础设施）。每个领域每周都有一个小时的时间。与会者通常是该领域的产品、工程和设计负责人，在某些情况下，跨职能团队，例如，销售负责人来参加广告会议，也会发生。会议的模板分为四个部分：
- 人员情况：他们将概述任何新加入或离开他们团队的人，任何重组/重新分配，以及任何新出现的人员问题。
- 发布决策计划：作为一个团队迅速总览当前做出的任何重要决定，并向我介绍即将推出的新产品，以及最近推出的产品的回顾。这个清单可能非常长，所以颗粒度由团队决定，大多数人都非常善于筛选出需要我反馈的启动和决定，或者他们认为我需要了解的地方。
- 指标数据：快速浏览该领域的相关指标（通常是快速的，因为我自己经常看仪表盘）。
- 讨论主题：团队会选择一组主题来进行讨论。这些话题往往是随意的，还没有成型的，他们在寻找方向性的反馈。有时，他们只是在进行头脑风暴，我们会一起使用白板。偶尔，也有一些决定性的议题，规模较小且并不需要进行产品评审的议题。
2、“大石头”项目共识。我们还为每个 “大石头 “设立了一个每周共识会议。这些会议的模板与聚焦领域的会议非常相似，每个”大石头“的负责人针对人员情况、发布决策计划、指标数据和讨论议题逐一进行内容更新。”大石头“的负责人将决定出席会议的人员，我们尽量保持小规模（理想的情况是<5人，偶尔也会<10人）。
3、支撑部门共识。我有几个职能部门，我发现它们需要定期的时间来讨论议题。
- 人力资源团队：跟进正在招聘的一些候选人的情况，协调绩效审查过程，讨论人员问题
- 法务团队：共识事件的背景和相关信息
- 财务团队：处理预算问题，查看财务预测，等等
- 营销团队：评审和判断市场营销的优先事项，评审营销活动
4.、职能部门共识。我倾向于在各职能部门（产品PM、工程Eng、设计Ux等等）之间召开大多数会议，因此我们需要几个特定职能部门的会议。
- 工程团队：工程部的特定主题，如推送过程、代码库和工具选择等
- 产品团队：协调PM在项目中的分配，以及PM在团队中的增加（和删除）
- 特定技术领域：我创建了领域技术负责人的角色，主要包括数据、搜索和App, 我们会聚在一起协调他们应该关注的地方
5、秘书和助理共识。每周一次，我们三个人坐下来，对一周的工作进行总结和计划
- 行政秘书：日常行政管理以及对会议中成员情绪的观察
- 主管助理：代理主管主导公司重要会议，日常沟通事项和工作内容
6、高层团队共识。最后一个是Salar-Shishir-Robert共识会议。我们三个人作为一个三人组管理Youtube，所以我们会确保我们每周至少同步一次。我们经常在晚餐时进行，并讨论那些没有得到解决的棘手问题，等等。
从流程上讲，每种共识会都有一个常设的、共享的谷歌文档，所有与会者都会定期向其中添加主题，以方便信息追踪。我们为这类会议设定了一个时间表，而且我们非常努力地去尝试不移动这些会议，若是有冲突，我们会取消会议，原因参考日常计划的核心理念第六点。
（7）日常计划会议四：一对一沟通
由于项目共识会接管了任何针对项目的讨论或者小组间的信息共识， 1对1沟通一般集中在职业辅导和解决个人问题上。每个1-1会议保留一个常设的、共享的谷歌文档，帮助控制沟通的议程。事实上，我经常将1对1的会议议题推迟到特定的项目共识会上，因为需要其他与会者的参与。
我与一组核心人员（基本上是我的直接汇报人和间隔一级的关键汇报者）有一套固定的一对一沟通，然后有灵活的时间，以便任何人能与我预约时间。
一些有代表性的辅导主题包括：
- 我正在努力完成报告XYZ的ABC情况的分析，这里有什么思考思路吗？
- 我在时间分配管理上总是出问题，我可以如何改进？
- 我似乎很难与我的团队负责人相处，有什么可以改善现状吗？
我有一个经常进行1对1沟通的核心小组，其结构如下：
1、高管直属汇报人：向主管直接汇报的技术团队的负责人，例如产品/工程/设计，每隔一周30分钟
2、高管间接回报人：我通常将其限制在技术团队的成员（只是作为一种划清界限的方式），并将这些会议保持在每月或每季度一次的节奏。
3、关键的跨职能负责人：业务团队的负责人，例如内容/营销/销售/区域总管，每隔一周30分钟。
4、自由可选沟通时间：我设定自由可选沟通时间以处理所有我无法保持在定期时间表上的1对1沟通。我每周留出2小时的弹性时间，分为6个20分钟的时段。人们可以自己预约，一般来说，时间都被预约。
剩下的1对1沟通，我更多是作为被辅导和被反馈的 “接受者”角色：
5、CEO：Salar（YouTube CEO）和我每隔一周会面一次，每次30分钟（但我们常会保持联系）。我们还每隔一周还会和Larry（Google CEO）进行一次联合1-1会谈。
6、咨询顾问：我会与几个关键的顾问专家定期见面。
03. YouTube 实践敏捷组织运营机制关键启示
YouTube正是通过以半年为单位的战略计划，优先排序关键大目标，以主导资源最优分配，并进一步拆解以6周为单位长度的冲刺计划，进一步细化分解可完成的具体任务，最终以四大会议和七大原则为核心的日常计划，持续且高效实践团队敏捷运营，以达成 YouTube 超速增长 。
这套敏捷运营机制成功将战略计划与日常实践进行最大可能的融合，以确保战略方向结合实际的运营资源，同时也为日常执行提供了清晰的前进方向，能为企业实践敏捷文化，转型敏捷组织，提供最佳实践的案例启示。
0 thoughts on “创新案例｜YouTube敏捷传奇：如何在高速增长中构建“可控混乱””
听说YouTube的敏捷文化非常好，这篇文章终于让我了解到更多细节，非常感谢。
看到YouTube的成功，我开始思考如何在我们公司构建敏捷运营机制。这篇文章提供了一些思路。
文章提到的文化融合，对于被收购的企业来说非常关键。学习了解这样的挑战如何克服。
除了敏捷运营机制，有没有其他方式可以促进团队协作和高效沟通？希望作者能够分享更多的经验。
如果我们能够在团队协作上实现类似于YouTube的默契，那么我们一定可以开创更加辉煌的未来
能够在业务扩张期间保持高度统一确实不容易。YouTube的敏捷文化值得学习。
这篇文章提到的挑战，在我们公司也有出现。我们需要借鉴YouTube的做法。
在快速发展的企业中，会议安排也是一个挑战。请问这篇文章有提及YouTube是如何解决这个问题的吗？
像YouTube这样快速发展的企业，面临协作问题是在所难免的。敏捷运营机制可以是解决方案
规划不断调整和组织流程混乱的问题，我们公司也遇到过。希望能够借鉴YouTube的经验。
看到这篇文章，我深有感触。作为一家高增长的企业，我们也曾经历过上述问题。敏捷运营机制是一个很好的解决方案。