北宋神宗年間，網傳遼國高手南下，意圖搶奪少林武學論文，實現大遼人人有功練的普世價值。

中原武林聞訊啟動應急預案，組織高手成團出道，設伏于雁門關。發起人為少林寺住持炫雌師太，人稱“帶頭大姐”，另有門面丐幫幫主汪艷紅，忙內趙倩男等高手二十一人，故團名為SNH21。

關外伏擊戰，SNH21被遼國珊軍女教官蕭媛姍一人團滅，十七人戰死，僅炫雌師太、汪艷紅、稚光三人生還，趙倩男失蹤。而蕭媛姍卻在寫完小作文后跳崖自盡，留下一女蕭鳳英。

原來遼國高手南下之說乃是謠言，造謠者為姑蘇慕容婆。

數百年前，拓跋鮮卑于參合坡大破慕容鮮卑，慕容氏燕國旋即被拓跋氏魏國所滅，宗室子弟離散民間，慕容婆便是燕國后裔。此次造謠，意圖挑撥宋遼戰爭，趁亂復國。帶頭大姐尋其對峙時，卻被慕容婆假死避過。

炫雌師太等人自知誤傷蕭媛姍，于是將鳳英托付給少室山下佃農夫婦。此戶農婦姓喬，名三嬛，鳳英隨養母姓，改名喬鳳英，她便是后來威震武林的大高手“北鳳英”喬幫主。

大理公主段玉蘭不喜學武，傻白甜離家出走，在觀看無量劍年會時笑場，慘遭圍毆，被萬劫谷少主鐘嶺所救。之后二人卷入神農幫和無量劍競標事件，鐘嶺被扣為人質，段玉蘭赴萬劫谷求援，中途誤入瑯嬛玉洞，見到神仙哥哥等身手辦，從此入圈成了毒唯粉，卻也習得逍遙派絕學北冥神功與凌波微步。

萬劫谷主鐘婉愁最恨姓段的女人，因其夫君甘爸爸的前女友便是大理國鎮南公主段爭春，即段玉蘭的社會學母親，生物學表姨媽。

甘爸爸借來寶馬黑旋風，托段玉蘭回大理找段爭春相救，因為鐘嶺就是段爭春和甘爸爸的私生子，段玉蘭名義上同母異父弟弟。

段玉蘭求救途中結識了黑旋風的主人，自己另一個名義上同母異父的弟弟木延慶，暗生情愫。

原來段爭春水性楊花，情史罄竹難書，最重要的幾個前任分別為：

“俊綠茶”甘爸爸，攜私生子鐘嶺入贅萬劫谷，發妻鐘婉愁；

“修羅刀”秦銅年，獨自撫養私生子木延慶，卻未告知兒子身世，以師父自居；

“百變星君”阮星馳，長子阿朱送入姑蘇慕容家作書童，次子阿紫送入星宿派做管培生，自己則在小鏡湖魚塘養魚；

李青鑼，攜私生子王羽燕入贅姑蘇王家，發妻王富貴；

康愛民，掐死私生子，迎娶丐幫副幫主馬旦媛。

段爭春玩累了之后，便找了個高富帥接盤，也就是現任丈夫——天南擺夷族王子刀拜風。刀拜風不滿段爭春情史糜爛，于是婚內出軌段爭春堂姐——大理國在逃公主段婉清，生下段玉蘭，段爭春茫然不知。

段婉清是段爭春的遠方堂姐，昔年宮斗失敗流落江湖，組建了新團隊天下四大惡人：老大段婉清，老二葉二郎，老三宅男女神岳小三，老四云雨荷。

段婉清不知段玉蘭是自己親女，為奪回公主之位，將段玉蘭與木延慶囚禁于萬劫谷，并施以春藥，欲效德國骨科故事，卻被大理國女皇段爭敏請來黃眉師太，靠下棋玩賴，救出二人。

段玉蘭憑借北冥神功吸收太多內力，渾身難受，被段爭敏帶到天龍庵求醫。

大雪山大輪庵大輪明妃鳩美智，訪問大理天龍庵進行武術交流，提出以少林七十二套廣播體操交換天龍庵六脈神劍，被庵主美容師太拒絕，雙方談崩開始斗劍。

鳩美智憑借美艷刀以一敵五漸占上風，內力深厚的段玉蘭自學六脈神劍，出手相助，被鳩美智挾持到了姑蘇。

姑蘇慕容家的書童阿朱、阿碧協助段玉蘭脫離鳩美智掌控后，段玉蘭便遇到了一生所愛王羽燕。因為王羽燕和洞中神仙哥哥手辦長得一模一樣。

飛書推出的項目管理工具“飛書項目”，自今年5月正式發布以來，已簽約100余家企業客戶，包括理想汽車、安克創新、Keep、獵聘等各行業的先進企業。

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

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

以下為分享內容，經中國網科技編輯發布：

因地制宜的流程設計

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

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

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

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

高效的信息傳遞

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

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

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

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

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

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

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

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

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

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

數據驅動與效率度量

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

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

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

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

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