飛書推出的項目管理工具“飛書項目”，自今年5月正式發布以來，已簽約100余家企業客戶，包括理想汽車、安克創新、Keep、獵聘等各行業的先進企業。
飛書項目支持100人以上的大型團隊協作，是抖音團隊背后的“生產線”。飛書項目幫助抖音實現每周App發版迭代，在抖音團隊從百人到千人的規模擴張過程中，保證了整個產研團隊高效運轉。
“對于抖音這樣的超大型應用，團隊分工和協作極其復雜，不僅需要科學的管理機制，還需要強力的工具和平臺。飛書項目在其中扮演了非常重要的角色，”抖音研發效率部門負責人，近期以“飛書項目如何助力抖音研發效率提升”為題進行了主題分享，總結到飛書項目具有靈活流程設計、高效信息傳遞、強大數據能力三大優勢，是市面上領先的項目管理工具。
(資料圖片僅供參考)
以下為分享內容，經中國網科技編輯發布：
因地制宜的流程設計
抖音團隊依賴飛書項目來進行項目管理。怎樣才能獲得更高的效率呢？對于不同的工作內容，應該采用適合其工作流的流程；對于不同的業務線團隊，也應該采用適合其協同方式的流程。我們在飛書項目上，針對不同情況配置適合的流程類型。
舉個例子，如下圖所示，飛書項目上可以方便的創建需求類型模板，代表了團隊對于某種工作內容的流程管理。并且進行可視化的呈現，表意清晰，一目了然。
對于核心場景有影響的需求，我們會進行更全面的評估。在需求流程的編排上，我們會引入綜合評審節點，讓由抖音各業務線負責人組成的委員會參與其中，進行投票決策。
而對于探索型需求，我們期望它的流程更敏捷，以便能夠快速試錯。在流程的編排上，我們會盡可能減少依賴和等待，讓流程節點多一些并行。飛書項目的工作流管理功能，靈活高效的支持了抖音團隊在不同場景下的流程管理需求。
高效的信息傳遞
我個人很喜歡飛書項目的一個小功能，就是一鍵建群。做項目的都知道，信息不同步很容易帶來項目上的問題。服務端研發需求做著做著發現一個坑，于是跟產品經理私聊討論了一下要做一些小的改動，結果客戶端的研發不知道這事，實現完了與服務端聯調的時候發現對不上。這樣的情況很典型，由此帶來的需求的反復，也使得團隊的研發效率受到影響。
飛書項目直接提供了一鍵建群功能。針對每個需求，一鍵就將需求的創建者、參與方、關注人都拉成一個群，群名就是這個需求的名字，大家關于這個需求的任何問題都在這討論，任何信息也在這同步，需求的節點流轉在群里也有自動提醒。這樣，各方的上下文都在這得到了充分的同步，討論的話題也很專注。這樣的溝通很高效。很多團隊甚至把拉需求群這個功能在飛書項目上配置成了創建需求時就默認拉群。這跟字節文化里推崇的讓信息高效流動，以及“context, not control”的管理思路也是一脈相承的。
事實上，在一個大型組織中，如何高效的進行信息傳遞是一件有挑戰的事情。我們既要保障關鍵信息能傳遞到位；又要降低信噪比，不能只是簡單粗暴的進行消息廣播、讓大家都被打擾到。在飛書項目上我們也做了不少這方面的設計。
比如一個需求，如果涉及到多個業務線的協作，那么在需求的早期，就應當引入各業務線接口人角色參與評估，否則就有可能帶來在需求進行到一半的時候要做調整變更等需求反復的情況。在這個需求完成開發工作進入到AB實驗階段，其取得的數據結論也應該由各業務線共同討論決策下一步行動。
那么如何讓這一機制能夠高效執行呢？
我們首先在飛書項目中為需求配置了一個跨線影響模塊的字段。它會作為一個創建需求時的必要的填寫項由產品經理來完成。
接下來，我們希望通過這個跨線影響模塊所提供的信息，結合需求的其他信息，就能自動的獲取到應該引入哪些業務方的哪些人員的參與。這里我們利用飛書項目提供的webhook和open api來達到這一效果。
我們自己起了一個服務。通過在飛書項目上注冊需求創建事件的webhook，我們就能捕獲到這個空間下所有需求創建的消息，進而通過解析每個需求的歸屬業務線、影響到了哪些業務模塊等信息，來判斷涉及哪些業務方、需要引入哪些關鍵接口人參與。
然后再通過飛書項目的open api能力，自動觸發跨線影響評估的審核流程。這些影響到的模塊的接口人、關注人，也會通過open api被自動添加上。這一切都是自動完成的。這樣，需求的關鍵角色都能獲取到相關信息，不會丟事情。
我們還注冊了飛書項目的節點到達事件的webhook。這些需求的需求啟動、實驗結論產出等關鍵流程節點到來時，我們也能捕捉到；然后將其中的關鍵信息進行解析、匯總，通過飛書機器人分發給參與需求決策的關鍵角色。通過這種方式，項目信息的觸達就能更加高效。
數據驅動與效率度量
字節文化的另一個特點就是數據驅動，用數據說話。抖音的一個需求不知道做得好不好，那就開個AB實驗觀察下數據。
同樣的，我們提升研發效率也希望用數據說話。在對團隊內的項目情況進行復盤時，我會用飛書項目的圖表功能。比如，我會看下這個雙月的需求吞吐情況如何，業務需求多少、技術需求多少，bug數量相比上個雙月有沒有降低，解決速度有沒有提升等等。由此來判斷我們團隊接下來應該做哪些改進。
我們同時也在服務于抖音大團隊的效率度量。這是一個更加復雜的工程。舉個例子，我們會持續的監測抖音的一個需求從想法提出到交付到用戶手中需要多長時間——我們把它叫做交付周期指標，并且需要從這個指標的變化中進行拆解和分析歸因。之前已經提到，抖音下各個業務團隊的需求流程是不一樣的，從效率的角度出發也不應該一樣。這么多個團隊，工作在不同的飛書項目空間中，采用著不一樣的流程定義，在這種情況下，定義什么是“需求交付”就需要花費一番功夫。
比如對于服務端研發而言，交付指的是代碼完成部署和完成線上全量，對于客戶端研發而言，交付則指的是版本發布并完成功能全量。我們甚至構建了一個數據平臺，用于管理這些度量中的標準概念，同時完成數據采集、清洗和指標呈現的過程。這里面的數據采集工作，我們就是利用了飛書項目提供的豐富的open api能力來實現，需求、節點、節點下的子任務等等數據，都可以通過open api來獲取。
當然，做上述工作的前提是，我們需要重視數據資產的沉淀和管理。而飛書項目在這其中起到了至關重要的作用。它使得我們的研發工作提效，項目能夠更有體系的進行。
責任編輯：Rex_08
營業執照公示信息