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

比如一个需求，如果涉及到多个业务线的协作，那么在需求的早期，就应当引入各业务线接口人角色参与评估，否则就有可能带来在需求进行到一半的时候要做调整变更等需求反复的情况。在这个需求完成开发工作进入到AB实验阶段，其取得的数据结论也应该由各业务线共同讨论决策下一步行动。
那么如何让这一机制能够高效执行呢？
我们首先在飞书项目中为需求配置了一个跨线影响模块的字段。它会作为一个创建需求时的必要的填写项由产品经理来完成。
接下来，我们希望通过这个跨线影响模块所提供的信息，结合需求的其他信息，就能自动的获取到应该引入哪些业务方的哪些人员的参与。这里我们利用飞书项目提供的webhook和open api来达到这一效果。
我们自己起了一个服务。通过在飞书项目上注册需求创建事件的webhook ，我们就能捕获到这个空间下所有需求创建的消息，进而通过解析每个需求的归属业务线、影响到了哪些业务模块等信息，来判断涉及哪些业务方、需要引入哪些关键接口人参与。

文章插图

然后再通过飞书项目的open api能力，自动触发跨线影响评估的审核流程。这些影响到的模块的接口人、关注人，也会通过open api被自动添加上。这一切都是自动完成的。这样，需求的关键角色都能获取到相关信息，不会丢事情。
我们还注册了飞书项目的节点到达事件的webhook 。这些需求的需求启动、实验结论产出等关键流程节点到来时，我们也能捕捉到；然后将其中的关键信息进行解析、汇总，通过飞书机器人分发给参与需求决策的关键角色。通过这种方式，项目信息的触达就能更加高效。
数据驱动与效率度量
字节文化的另一个特点就是数据驱动，用数据说话。抖音的一个需求不知道做得好不好，那就开个AB实验观察下数据。
同样的，我们提升研发效率也希望用数据说话。在对团队内的项目情况进行复盘时，我会用飞书项目的图表功能。比如，我会看下这个双月的需求吞吐情况如何，业务需求多少、技术需求多少， bug数量相比上个双月有没有降低，解决速度有没有提升等等。由此来判断我们团队接下来应该做哪些改进。

文章插图

我们同时也在服务于抖音大团队的效率度量。这是一个更加复杂的工程。举个例子，我们会持续的监测抖音的一个需求从想法提出到交付到用户手中需要多长时间——我们把它叫做交付周期指标，并且需要从这个指标的变化中进行拆解和分析归因。之前已经提到，抖音下各个业务团队的需求流程是不一样的，从效率的角度出发也不应该一样。这么多个团队，工作在不同的飞书项目空间中，采用着不一样的流程定义，在这种情况下，定义什么是需求交付就需要花费一番功夫。
比如对于服务端研发而言，交付指的是代码完成部署和完成线上全量，对于客户端研发而言，交付则指的是版本发布并完成功能全量。我们甚至构建了一个数据平台，用于管理这些度量中的标准概念，同时完成数据采集、清洗和指标呈现的过程。这里面的数据采集工作，我们就是利用了飞书项目提供的丰富的open api能力来实现，需求、节点、节点下的子任务等等数据，都可以通过open api来获取。
当然，做上述工作的前提是，我们需要重视数据资产的沉淀和管理。而飞书项目在这其中起到了至关重要的作用。它使得我们的研发工作提效，项目能够更有体系的进行。