抖音产研实践：流程不能靠“口口相传”

2017年，抖音还只是个 DAU 不足百万的初创项目，短短几年就成为亿级 C 端产品。在字节，这样的 APP 还有很多。字节内部是如何同时支持这么多产品以高效敏捷的方式发展壮大的？

即便是抖音，早期也面临着管理系统多、数据不准确、推行困难的问题。因此，秉承 Context not control 的理念，抖音团队孵化出了可定制、可度量、可迭代的一体化管理工具，让产研工作像“生产线”一样自运转起来。

近期，在稀土掘金技术社区举办的第三届稀土开发者大会上，飞书项目的技术负责人熊典，分享了他在抖音和飞书项目期间沉淀的产研管理理念和实践。

熊典毕业于北京大学法学院，是PKU Helper & 合同家的创始人，进入字节后负责抖音产研流程的工具支持与落地，从 0 到 1 孵化了飞书项目及多个流程平台，目前专注于飞书项目产品的打磨和迭代，致力于打造最优的产研流程工具。本文是他在稀土开发者大会上演讲内容的整理。

当讨论产研效能的时候，我们在讨论什么

大家好，我是熊典。今天的主题是字节跳动的产研管理实践，核心是如何用工具助力产研效能。

字节跳动做了很多产品，头条、抖音、飞书、西瓜视频等等。其中有初创产品，也有千人协作的大团队；有 Demo 工程，也有千万行代码工程；也有从内部工具走出去成为拥有亿级 DAU 的产品。比如说我所在的飞书项目，就是这样的情况。

那么字节内部是怎么支持这么多产品，高效地协作开发的呢？其实是我们的理念和工具。在字节，我们有围绕着以飞书项目为核心的一系列工具来支持我们的产研体系，包括 Bits 研发平台、 Libra 的 AB 实验平台等等。这些工具背后其实有统一的理念：

高效协作：字节之前有一条字节范叫Context not control，就是希望所有参与到项目里的人都能够拥有最多的上下文。

高效产出：当所有人在一起协作的效率很高的时候，最后的问题就会变成每个角色自己如何保持专注做到最好。

伴随成长：字节所有的 APP 都是从 0 开始做的，第一天可能只有三个人的小团队在做这个产品，最终却可能成为一个成千上万人的部门，整个过程不是一蹴而就的，而是一个连续的、过渡的状态。那么我们就需要流程可定制，可度量，可迭代的工具循序渐进地支持一个团队从三人到千人的发展过程。

那么什么才算是好的产研效能？其实就是两点：第一，交付速度快，团队敏捷，这就是能；第二，产研节奏好，资源不空转，这就是效。

除了效能之外，还需要关注两个点。一个是稳定性，另一个是承诺必达。总的来看，我们实际的关注点其实就是交付速度、资源利用率和交付确定性。

我 2017 年刚进字节的时候，抖音还是一个 DAU 不足百万的初创项目，我们的晨会就是做各种流转登记。当时我们也用 Google Sheets管理需求，在 IDE 里去做本地开发，用 GitLab 做 MR 管理，用 Jenkins 做持续集成，用 JIRA 去跟进 Bug 和任务。但这样多系统并存存在很大问题：一是数据不准确；二是不够及时；三是难推行。

我们现在是怎么做的？我们做了两件事：数据中心+操作终端。

数据中心：我们现在有一个平台，就是飞书项目，它有非常强大的可定制能力，任何数据都可以被建成字段、建成流程，结构化地存储在里面。

操作终端：当我们搞定协作问题的时候，剩下的瓶颈在哪？在于每个人自己的效率。所以我们想让每个人都能专注自己的事，顺便完成数据收集的工作。

我们想要去收集这些数据，对很多一线同学来说肯定是很困难的，因为大家会觉得这是一个额外的工作，所以我们必须要做很多的额外的事情来帮助大家去减负。

在流程中自然产生数据

大家可能会有疑问，就是你好像说得很简单啊，那具体怎么做？研发场景到底有什么东西是可以自动收集？到底能给研发减多少负？

字节在做 Mobile APP 研发的时候，首先会制定一个版本日历，每个需求采取跟车机制，版本不等需求。

经过这样的流程之后，除了一些必须人工介入的工作，很多节点都变成了自动化工作。而这些人工作业也能顺便将信息沉淀到统一的数据中心里去，方便进一步统计和度量分析。

指标收集之后，又该如何做度量分析？

我们认为度量有几大原则：

第一，用度量去寻找问题和检验效果，但不要与一线同学的绩效挂钩。

第二，要在全局范围内做数据度量，不要把眼光局限在开发活动。

第三，需要形成度量检验的固定周期，不要做一次性工作。

前面提到交付速度、利用率和稳定性，它们对应到很多的指标，我们应该如何去落地这些指标？

传统方法是依靠人工，先从五花八门的系统里导出数据，然后做数据清洗，再导入到本地 Excel 中，再填写公式，最后复制图表到文档中胜场度量报告。

抖音早期没有工具的时候，很多数据格式不统一，PMO 同学需要花两周去清洗、定位、校准、粘贴这些数据，这件事就像是“人力杀手”。

现在有了工具的加持，我们可以很自然地去做这些事情：

第一步，数据沉淀。我们把五花八门系统数据用结构化的方式无缝收集到一起。

第二步，指标沉淀。在系统里面，借助公式字段可以形成标准化的指标和图表。

第三步，定期推送。我们可以基于自动化能力去做自动化定期推送，或者是做预警处理。

最后一步，实时关注。系统里可以动态关注这些数据，方便实时下钻和分析。

用度量来做流程迭代

当我们拿到度量分析结果之后，又该如何去优化流程？

一般情况下，我们有这样一个流程：

但在日常工作中，实际流程可能长这样，有很多奇奇怪怪的节点冒出来。

因此我们需要调整流程，但调整完之后，怎么推进落地？

一个办法就是开会，层层传递，那有没有更好的办法，让流程迭代自然推行下去？我们可以用度量来做流程迭代。

举个例子，我们在双周会上发现，近期的需求交付时间变长了，然后下钻发现，“多语言文案”这个节点的时长是上升的。原来是近期国际化动作增加，对多语言的要求变高，导致整个时间周期拉长。定位到了问题，我们就针对性地将“多语言翻译”节点提前，在“需求详评”结束后就进入这一环节。

但是这样又会出现新的问题：有些需求走的是旧流程，有些走的是新流程，怎么办？

飞书项目里有一个功能叫做模版升级，能够直接把历史需求升级到新的状态，过程中会自动记录新旧流程里面所有的 DIFF。用这样的方式，我们把选择权交给了每个需求的负责同学，他可以自己选择是否升级进行中的需求，升级之后可以享受到流程上的便利。

流程 SOP 是可沉淀的企业资产

我们从三人小组的抖音到现在万人团队的抖音，这个过程不是一蹴而就的，而是连续的。在这个过程中，我们必须要借助一些工具才能管理好成千上万的需求以及它们在成千上万个版本流程里的行为。

有一句我们认为非常有价值的话：“流程 SOP 其实是可沉淀的企业资产。”不要把流程当成需要口口相传的事情，而是要把它真正沉淀下来，做好迭代，这对产研效能会有非常大的帮助。

飞书项目内置了完整的产研管理能力，从源数据驱动的指标收集，到开放能力建设，再到度量分析的图表和自动化推送，最后到流程的管理、沉淀和迭代。