飞书推出的项目管理工具“飞书项目”，自今年5月正式发布以来，已签约100余家企业客户，包括理想汽车、安克创新(行情300866,诊股)、Keep、猎聘等各行业的先进企业。

(资料图)

飞书项目支持100人以上的大型团队协作，是抖音团队背后的“生产线”。飞书项目帮助抖音实现每周App发版迭代，在抖音团队从百人到千人的规模扩张过程中，保证了整个产研团队高效运转。

“对于抖音这样的超大型应用，团队分工和协作极其复杂，不仅需要科学的管理机制，还需要强力的工具和平台。飞书项目在其中扮演了非常重要的角色，”抖音研发效率部门负责人，近期以“飞书项目如何助力抖音研发效率提升”为题进行了主题分享，总结到飞书项目具有灵活流程设计、高效信息传递、强大数据能力三大优势，是市面上领先的项目管理工具。

以下为分享内容，经中国网科技编辑发布：

因地制宜的流程设计

抖音团队依赖飞书项目来进行项目管理。怎样才能获得更高的效率呢？对于不同的工作内容，应该采用适合其工作流的流程；对于不同的业务线团队，也应该采用适合其协同方式的流程。我们在飞书项目上，针对不同情况配置适合的流程类型。

举个例子，如下图所示，飞书项目上可以方便的创建需求类型模板，代表了团队对于某种工作内容的流程管理。并且进行可视化的呈现，表意清晰，一目了然。

对于核心场景有影响的需求，我们会进行更全面的评估。在需求流程的编排上，我们会引入综合评审节点，让由抖音各业务线负责人组成的委员会参与其中，进行投票决策。

而对于探索型需求，我们期望它的流程更敏捷，以便能够快速试错。在流程的编排上，我们会尽可能减少依赖和等待，让流程节点多一些并行。飞书项目的工作流管理功能，灵活高效的支持了抖音团队在不同场景下的流程管理需求。

高效的信息传递

我个人很喜欢飞书项目的一个小功能，就是一键建群。做项目的都知道，信息不同步很容易带来项目上的问题。服务端研发需求做着做着发现一个坑，于是跟产品经理私聊讨论了一下要做一些小的改动，结果客户端的研发不知道这事，实现完了与服务端联调的时候发现对不上。这样的情况很典型，由此带来的需求的反复，也使得团队的研发效率受到影响。

飞书项目直接提供了一键建群功能。针对每个需求，一键就将需求的创建者、参与方、关注人都拉成一个群，群名就是这个需求的名字，大家关于这个需求的任何问题都在这讨论，任何信息也在这同步，需求的节点流转在群里也有自动提醒。这样，各方的上下文都在这得到了充分的同步，讨论的话题也很专注。这样的沟通很高效。很多团队甚至把拉需求群这个功能在飞书项目上配置成了创建需求时就默认拉群。这跟字节文化里推崇的让信息高效流动，以及“context, not control”的管理思路也是一脉相承的。

事实上，在一个大型组织中，如何高效的进行信息传递是一件有挑战的事情。我们既要保障关键信息能传递到位；又要降低信噪比，不能只是简单粗暴的进行消息广播、让大家都被打扰到。在飞书项目上我们也做了不少这方面的设计。

比如一个需求，如果涉及到多个业务线的协作，那么在需求的早期，就应当引入各业务线接口人角色参与评估，否则就有可能带来在需求进行到一半的时候要做调整变更等需求反复的情况。在这个需求完成开发工作进入到AB实验阶段，其取得的数据结论也应该由各业务线共同讨论决策下一步行动。

那么如何让这一机制能够高效执行呢？

我们首先在飞书项目中为需求配置了一个跨线影响模块的字段。它会作为一个创建需求时的必要的填写项由产品经理来完成。

接下来，我们希望通过这个跨线影响模块所提供的信息，结合需求的其他信息，就能自动的获取到应该引入哪些业务方的哪些人员的参与。这里我们利用飞书项目提供的webhook和open api来达到这一效果。

我们自己起了一个服务。通过在飞书项目上注册需求创建事件的webhook，我们就能捕获到这个空间下所有需求创建的消息，进而通过解析每个需求的归属业务线、影响到了哪些业务模块等信息，来判断涉及哪些业务方、需要引入哪些关键接口人参与。

然后再通过飞书项目的open api能力，自动触发跨线影响评估的审核流程。这些影响到的模块的接口人、关注人，也会通过open api被自动添加上。这一切都是自动完成的。这样，需求的关键角色都能获取到相关信息，不会丢事情。

我们还注册了飞书项目的节点到达事件的webhook。这些需求的需求启动、实验结论产出等关键流程节点到来时，我们也能捕捉到；然后将其中的关键信息进行解析、汇总，通过飞书机器人(行情300024,诊股)分发给参与需求决策的关键角色。通过这种方式，项目信息的触达就能更加高效。

数据驱动与效率度量

字节文化的另一个特点就是数据驱动，用数据说话。抖音的一个需求不知道做得好不好，那就开个AB实验观察下数据。

同样的，我们提升研发效率也希望用数据说话。在对团队内的项目情况进行复盘时，我会用飞书项目的图表功能。比如，我会看下这个双月的需求吞吐情况如何，业务需求多少、技术需求多少，bug数量相比上个双月有没有降低，解决速度有没有提升等等。由此来判断我们团队接下来应该做哪些改进。

我们同时也在服务于抖音大团队的效率度量。这是一个更加复杂的工程。举个例子，我们会持续的监测抖音的一个需求从想法提出到交付到用户手中需要多长时间——我们把它叫做交付周期指标，并且需要从这个指标的变化中进行拆解和分析归因。之前已经提到，抖音下各个业务团队的需求流程是不一样的，从效率的角度出发也不应该一样。这么多个团队，工作在不同的飞书项目空间中，采用着不一样的流程定义，在这种情况下，定义什么是“需求交付”就需要花费一番功夫。

比如对于服务端研发而言，交付指的是代码完成部署和完成线上全量，对于客户端研发而言，交付则指的是版本发布并完成功能全量。我们甚至构建了一个数据平台，用于管理这些度量中的标准概念，同时完成数据采集、清洗和指标呈现的过程。这里面的数据采集工作，我们就是利用了飞书项目提供的丰富的open api能力来实现，需求、节点、节点下的子任务等等数据，都可以通过open api来获取。

当然，做上述工作的前提是，我们需要重视数据资产的沉淀和管理。而飞书项目在这其中起到了至关重要的作用。它使得我们的研发工作提效，项目能够更有体系的进行。

关键词： 抖音研发效率负责人抖音能做到每周迭代 离不开飞书项目