飛書推出的項目管理工具“飛書項目”，自今年5月正式發(fā)布以來，已簽約100余家企業(yè)客戶，包括理想汽車、安克創(chuàng)新(行情300866,診股)、Keep、獵聘等各行業(yè)的先進企業(yè)。

(資料圖)

飛書項目支持100人以上的大型團隊協(xié)作，是抖音團隊背后的“生產(chǎn)線”。飛書項目幫助抖音實現(xiàn)每周App發(fā)版迭代，在抖音團隊從百人到千人的規(guī)模擴張過程中，保證了整個產(chǎn)研團隊高效運轉。

“對于抖音這樣的超大型應用，團隊分工和協(xié)作極其復雜，不僅需要科學的管理機制，還需要強力的工具和平臺。飛書項目在其中扮演了非常重要的角色，”抖音研發(fā)效率部門負責人，近期以“飛書項目如何助力抖音研發(fā)效率提升”為題進行了主題分享，總結到飛書項目具有靈活流程設計、高效信息傳遞、強大數(shù)據(jù)能力三大優(yōu)勢，是市面上領先的項目管理工具。

以下為分享內容，經(jīng)中國網(wǎng)科技編輯發(fā)布：

因地制宜的流程設計

抖音團隊依賴飛書項目來進行項目管理。怎樣才能獲得更高的效率呢？對于不同的工作內容，應該采用適合其工作流的流程；對于不同的業(yè)務線團隊，也應該采用適合其協(xié)同方式的流程。我們在飛書項目上，針對不同情況配置適合的流程類型。

舉個例子，如下圖所示，飛書項目上可以方便的創(chuàng)建需求類型模板，代表了團隊對于某種工作內容的流程管理。并且進行可視化的呈現(xiàn)，表意清晰，一目了然。

對于核心場景有影響的需求，我們會進行更全面的評估。在需求流程的編排上，我們會引入綜合評審節(jié)點，讓由抖音各業(yè)務線負責人組成的委員會參與其中，進行投票決策。

而對于探索型需求，我們期望它的流程更敏捷，以便能夠快速試錯。在流程的編排上，我們會盡可能減少依賴和等待，讓流程節(jié)點多一些并行。飛書項目的工作流管理功能，靈活高效的支持了抖音團隊在不同場景下的流程管理需求。

高效的信息傳遞

我個人很喜歡飛書項目的一個小功能，就是一鍵建群。做項目的都知道，信息不同步很容易帶來項目上的問題。服務端研發(fā)需求做著做著發(fā)現(xiàn)一個坑，于是跟產(chǎn)品經(jīng)理私聊討論了一下要做一些小的改動，結果客戶端的研發(fā)不知道這事，實現(xiàn)完了與服務端聯(lián)調的時候發(fā)現(xiàn)對不上。這樣的情況很典型，由此帶來的需求的反復，也使得團隊的研發(fā)效率受到影響。

飛書項目直接提供了一鍵建群功能。針對每個需求，一鍵就將需求的創(chuàng)建者、參與方、關注人都拉成一個群，群名就是這個需求的名字，大家關于這個需求的任何問題都在這討論，任何信息也在這同步，需求的節(jié)點流轉在群里也有自動提醒。這樣，各方的上下文都在這得到了充分的同步，討論的話題也很專注。這樣的溝通很高效。很多團隊甚至把拉需求群這個功能在飛書項目上配置成了創(chuàng)建需求時就默認拉群。這跟字節(jié)文化里推崇的讓信息高效流動，以及“context, not control”的管理思路也是一脈相承的。

事實上，在一個大型組織中，如何高效的進行信息傳遞是一件有挑戰(zhàn)的事情。我們既要保障關鍵信息能傳遞到位；又要降低信噪比，不能只是簡單粗暴的進行消息廣播、讓大家都被打擾到。在飛書項目上我們也做了不少這方面的設計。

比如一個需求，如果涉及到多個業(yè)務線的協(xié)作，那么在需求的早期，就應當引入各業(yè)務線接口人角色參與評估，否則就有可能帶來在需求進行到一半的時候要做調整變更等需求反復的情況。在這個需求完成開發(fā)工作進入到AB實驗階段，其取得的數(shù)據(jù)結論也應該由各業(yè)務線共同討論決策下一步行動。

那么如何讓這一機制能夠高效執(zhí)行呢？

我們首先在飛書項目中為需求配置了一個跨線影響模塊的字段。它會作為一個創(chuàng)建需求時的必要的填寫項由產(chǎn)品經(jīng)理來完成。

接下來，我們希望通過這個跨線影響模塊所提供的信息，結合需求的其他信息，就能自動的獲取到應該引入哪些業(yè)務方的哪些人員的參與。這里我們利用飛書項目提供的webhook和open api來達到這一效果。

我們自己起了一個服務。通過在飛書項目上注冊需求創(chuàng)建事件的webhook，我們就能捕獲到這個空間下所有需求創(chuàng)建的消息，進而通過解析每個需求的歸屬業(yè)務線、影響到了哪些業(yè)務模塊等信息，來判斷涉及哪些業(yè)務方、需要引入哪些關鍵接口人參與。

然后再通過飛書項目的open api能力，自動觸發(fā)跨線影響評估的審核流程。這些影響到的模塊的接口人、關注人，也會通過open api被自動添加上。這一切都是自動完成的。這樣，需求的關鍵角色都能獲取到相關信息，不會丟事情。

我們還注冊了飛書項目的節(jié)點到達事件的webhook。這些需求的需求啟動、實驗結論產(chǎn)出等關鍵流程節(jié)點到來時，我們也能捕捉到；然后將其中的關鍵信息進行解析、匯總，通過飛書機器人(行情300024,診股)分發(fā)給參與需求決策的關鍵角色。通過這種方式，項目信息的觸達就能更加高效。

數(shù)據(jù)驅動與效率度量

字節(jié)文化的另一個特點就是數(shù)據(jù)驅動，用數(shù)據(jù)說話。抖音的一個需求不知道做得好不好，那就開個AB實驗觀察下數(shù)據(jù)。

同樣的，我們提升研發(fā)效率也希望用數(shù)據(jù)說話。在對團隊內的項目情況進行復盤時，我會用飛書項目的圖表功能。比如，我會看下這個雙月的需求吞吐情況如何，業(yè)務需求多少、技術需求多少，bug數(shù)量相比上個雙月有沒有降低，解決速度有沒有提升等等。由此來判斷我們團隊接下來應該做哪些改進。

我們同時也在服務于抖音大團隊的效率度量。這是一個更加復雜的工程。舉個例子，我們會持續(xù)的監(jiān)測抖音的一個需求從想法提出到交付到用戶手中需要多長時間——我們把它叫做交付周期指標，并且需要從這個指標的變化中進行拆解和分析歸因。之前已經(jīng)提到，抖音下各個業(yè)務團隊的需求流程是不一樣的，從效率的角度出發(fā)也不應該一樣。這么多個團隊，工作在不同的飛書項目空間中，采用著不一樣的流程定義，在這種情況下，定義什么是“需求交付”就需要花費一番功夫。

比如對于服務端研發(fā)而言，交付指的是代碼完成部署和完成線上全量，對于客戶端研發(fā)而言，交付則指的是版本發(fā)布并完成功能全量。我們甚至構建了一個數(shù)據(jù)平臺，用于管理這些度量中的標準概念，同時完成數(shù)據(jù)采集、清洗和指標呈現(xiàn)的過程。這里面的數(shù)據(jù)采集工作，我們就是利用了飛書項目提供的豐富的open api能力來實現(xiàn)，需求、節(jié)點、節(jié)點下的子任務等等數(shù)據(jù)，都可以通過open api來獲取。

當然，做上述工作的前提是，我們需要重視數(shù)據(jù)資產(chǎn)的沉淀和管理。而飛書項目在這其中起到了至關重要的作用。它使得我們的研發(fā)工作提效，項目能夠更有體系的進行。

關鍵詞： 抖音研發(fā)效率負責人抖音能做到每周迭代 離不開飛書項目