飛書推出的項目管理工具“飛書項目”，自今年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)勢，是市面上領先的項目管理工具。

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

因地制宜的流程設計

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

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

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

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

高效的信息傳遞

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

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

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

比如一個需求，如果涉及到多個業(yè)務線的協(xié)作，那么在需求的早期，就應當引入各業(yè)務線接口人角色參與評估，否則就有可能帶來在需求進行到一半的時候要做調(diào)整變更等需求反復的情況。在這個需求完成開發(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ù)說話。在對團隊內(nèi)的項目情況進行復盤時，我會用飛書項目的圖表功能。比如，我會看下這個雙月的需求吞吐情況如何，業(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ā)效率負責人抖音能做到每周迭代 離不開飛書項目