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

由推出的项目管理工具Project，自今年5月正式发布以来，已签约100多家企业客户，包括李，安科创新，Keep，招人等各行业先进企业。

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

像Tik Tok这样的超大型应用，团队分工协作极其复杂，不仅需要科学的管理机制，还需要强大的工具和平台舒菲项目在其中扮演了非常重要的角色Tik Tok R&D效率部负责人最近几天以舒菲项目如何帮助Tik Tok提升R&D效率为主题进行了分享，总结出舒菲项目具有流程设计灵活，信息传递高效，数据能力强大三大优势，是市场领先的项目管理工具

基于当地条件的工艺设计

Tik Tok团队依靠舒菲项目进行项目管理怎样才能获得更高的效率对于不同的工作内容，应采用适合其工作流程的流程，对于不同的业务线团队，也应该采用适合他们协作方式的流程在飞本项目上，我们针对不同的情况配置合适的流程类型

例如，如下图所示，在舒菲项目中可以很容易地创建需求类型模板，它代表团队某项工作内容的过程管理而且视觉呈现，表意清晰，一目了然

对于探索性需求，我们期望其过程更加敏捷，以便能够快速试错在流程的安排上，我们会尽可能的减少依赖和等待，让流程节点更加并行舒菲项目的工作流管理功能灵活高效地支持Tik Tok团队在不同场景下的流程管理需求

高效的信息传输

个人比较喜欢舒菲项目的一个小功能，就是一键建群做项目的都知道，信息不同步很容易导致项目出问题服务器端的R&D需求在做，发现了一个漏洞，于是我和产品经理私聊，讨论一些小改动结果客户端的R&D并不知道这件事，联调完成才发现和服务端不匹配这种情况很典型，由此带来的重复需求也影响了团队的R&D效率

飞书项目直接提供了一键建群功能对于每个需求，需求的创建者，参与者，关注者都是一键拉进一个群，群名就是需求的名称关于需求的任何问题都在这里讨论，任何信息都在这里同步需求的节点流转也在群内自动提醒这样各方的语境在这里完全同步，讨论的话题也很聚焦这样的沟通效率很高很多团队甚至在舒菲项目中配置了拉需求组的功能，在创建需求时默认拉需求组这符合字节文化倡导的信息高效流动和上下文，而非控制的管理思想

事实上，在一个大型组织中，如何高效地传递信息是一个挑战要确保关键信息能够传递到位，降低信噪比，不能只是简单粗暴的播报新闻，让大家都被打扰我们在飞书项目中也做了很多这方面的设计

例如，如果一个需求涉及多个业务线的协作，那么在需求的前期就应该引入各个业务线的接口的角色来参与评估，否则可能会导致在需求进行到中间的时候出现调整，变更等重复需求这个需求完成后，开发工作就进入了AB实验阶段，其得出的数据结论也要由各业务线讨论决定

那么如何高效地实现这种机制呢。

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

接下来，我们希望通过这个跨线影响模块提供的信息，结合需求的其他信息，自动得到应该引入哪些业务方，哪些人员的参与在这里，我们使用舒菲项目提供的webhook和open api来实现这个效果

我们自己开始了一项服务通过在舒菲项目上注册需求创建事件的webhook，我们可以在这个空间中抓取需求创建的所有信息，然后通过分析每个需求所属业务线的信息，以及哪些业务模块受到影响，来判断涉及哪些业务方，需要引入哪些关键接口人员参与

然后，通过舒菲项目开放的api能力，自动触发跨线影响评价的审核流程这些受影响模块的接口和追随者也将通过开放api自动添加这都是自动完成的这样，需求的主要参与者可以在不损失任何东西的情况下获得相关信息

我们还注册了舒菲项目节点到达事件的webhook当这些需求的需求启动，实验结论输出等关键流程节点到来时，我们也可以捕捉到，然后对关键信息进行分析总结，通过飞书机器人分发给参与需求决策的关键玩家这样，可以更有效地获得项目信息

数据驱动和效率衡量

字节文化的另一个特点是数据驱动，用数据说话不知道Tik Tok的一个需求做得好不好，我们开个AB实验观察数据吧

同样，我们希望用数据来提高R&D效率在团队中回顾项目情况时，我会使用舒菲项目的图表功能比如我会看这个双月刊的需求吞吐量，业务需求和技术需求，bug数量相比上个双月刊有没有减少，解决速度有没有提升等等由此可以判断我们团队下一步应该做哪些改进

同时，我们也为Tik Tok的大型团队提供效率测量服务这是一个更复杂的项目比如，我们会持续监测Tik Tok的一个需求从提出想法到交付给用户需要多长时间——我们称之为前置时间指标，需要从这个指标的变化来拆解分析归因如前所述，Tik Tok每个业务团队的需求流程是不一样的，从效率的角度来看应该也不一样如此多的团队，在不同的舒菲项目空间工作，采用不同的过程定义在这种情况下，需要花费一些努力来定义什么是需求交付

比如对于服务器端的R&D，交付是指代码的完整部署和完整上线量，对于客户端R&D，交付是指版本的发布和完整的功能数量我们甚至建立了一个数据平台来管理这些指标中的标准概念，并完成数据收集，清理和指标呈现的过程这里的数据收集工作是通过使用舒菲项目提供的丰富的开放api功能来实现的需求，节点，节点下的子任务等数据可以通过开放api获得

当然，做好以上工作的前提是需要重视数据资产的沉淀和管理飞行图书项目在其中发挥了至关重要的作用它使我们的R&D工作更有效率，项目可以更系统地进行