字節(jié)跳動收獲總結：產品規(guī)劃、PRD編輯、評審及復盤總結

1、字節(jié)跳動收獲總結：產品規(guī)劃、PRW輯、評審及復盤總結/新公司實在太忙，現(xiàn)在才利用地鐵時間完成第二篇復盤總結，希望對大家有所啟發(fā)和幫助。本文總結了之前工作中，是如何完成需求方向確定，PRD輯，需求評審，產研高效協(xié)作和復盤總結的，筆者希望看完這篇文章后，讀者朋友都可以在當前團隊試用這套產品管理方法，一些產品新人可以了解到如何做產品規(guī)劃 ，如何寫出一份結構完整的PRD如何應用靜默評審提升評審/會議效率，如何做復盤因作者只在飛書產品線工作，受限于個人能力和視野局限，文中內容既不能代表飛書更不能代表字節(jié)，僅是個人對過去一年多的復盤思考，不足之處歡迎評論區(qū)拍磚交流。筆者現(xiàn)在在貝殼金服，如果想要內推貝殼金服

2、或貝殼的同學可以聯(lián)系我哈，如果想要內推字節(jié)的同學也可以聯(lián)系我，我去找朋友幫忙內推，祝好運二、產品規(guī)劃、落地和復盤任何方法都有適用場景，個人感覺飛書的需求管理更適合于 To C 的產品，而且一定程度上產品經理要有主導權，pm可以有效的控制節(jié)奏，如果是業(yè)務主導的隨時插入需求的團隊并不是很適用，如前文所說，產品的規(guī)劃是按照雙月緯度去推進的，雖然會有偶爾插入需求的情況，但是大多數(shù)需求都是在雙月會上拉齊不同團隊間的認知，協(xié)調好跨團隊的資源，按照節(jié)奏進入產研流程中。產品規(guī)劃 -one page prerelease前文中提到，我在飛書的時候，團隊是有年度規(guī)劃復盤會和雙月規(guī)劃復盤會。 當產品定位確定，年度目

3、標和方向給出后，雙月的規(guī)劃會更多的是一個目標拆 解的過程中的中間環(huán)節(jié)，它連接著年度目標和具體落地方案，即是年度目標的 細化，也是對具體方案的抽象。一個完整功能的一頁紙即可，以開發(fā)布會的視角去抽象和組織信息，以純用戶視角去編輯內容，需要體現(xiàn)產品的用戶價值， one page prerelease 內容上主要包含三個部分，標題， 2-4 個簡短說明，一張示例圖，如果需要可以補充一段注釋。? 標題。一句話說明功能提供給用戶的最主要價值是什么。? 說明。簡要介紹這個功能是什么，如何幫助用戶提升哪方面的效率，如 果有數(shù)據(jù)可以寫上預計對核心指標的影響。? 示例圖?？梢允堑捅Ｕ媸疽鈭D，也可以是高保真效果圖，

4、還可以是競品或相關產品的拼接圖，核心是體現(xiàn)出這個功能未來可能是什么樣子的，價值是什么?？梢远嗫刺O果和google的發(fā)布會，如何用一頁PPT對一個產品的核心價值做抽象，喬幫主的發(fā)布會值得反復學習，不堆砌硬件指標，用與用戶相關的數(shù)據(jù)震撼觀眾，用一張圖加一段文字，甚至只是一張圖，讓觀眾為之瘋狂。因為底層上來說，雙月會上是爭取團隊資源做目標功能的評審會，需要大家認同當前做這個功能是有意義或價值的，所以在編輯內容過程中，需要對目標用戶價值做出抽象，同時要符合產品定位和年度目標，當然所在領域的頭部競品和相關領域的頭部產品都可以是思路來源，比如 gmail 的年度發(fā)布會說了什么，微軟在企業(yè)知識圖譜上即將上線

5、哪些功能，在這個階段需要pm既要向外看，看市場的同類產品的規(guī)劃方向，也要向內看，做功能抽象和用戶價值提其實任何職級的PMffi可以考慮試用一下，對當前所負責的功能進行一頁紙規(guī)劃抽象，可以想象一下你正在發(fā)布會上介紹這個功能，如何做才有可能讓用戶為其買單，有助于提升抽象能力，提升產品看問題的高度。產品方案落地-PRD上一篇文章對于PRD真板用一張圖做了簡要介紹，本文詳細敘述一下這套模板。模板可以看做是一套思維范式，可以統(tǒng)一團隊看問題的視角和思考模式，一份結構合理而完整的PRD真板可以幫助創(chuàng)作者聚焦問題并發(fā)散思路，當團隊中所有人用一套模板時，有利于評審時文檔閱讀者快速檢索定位到自己的目標信息。相關人

6、員。介紹清楚功能需求的相關方，包括產品Owner,相關PM設計師，UX,研發(fā)leader ,研發(fā)同學，算法leader ,算法同學，前端，后端，SDK。 如果存在跨業(yè)務線的情況需要把相關同學全部寫明，方便后續(xù)溝通復盤。評審記錄。因為一個需求有可能內部多輪評審，包括跟老板的評審，都會有一 些重要的修改方向，通過評審記錄完成關鍵意見和方向記錄，因為通過靜默評 審答疑會在文檔右側的區(qū)域進行評論交流，所以評審記錄更多是對每一次評審 中重大改動意見的記錄。? Change Log。因為會有可能出現(xiàn)多次修改，包括文字，原型圖片等，包括進入測試環(huán)節(jié)的一些邏輯補全，都需要以表格的形式記錄好，方便研發(fā)和測試同學

7、查看。? 名詞解釋。文檔中可能包含一些需要說明的企業(yè)黑話或專有名詞解釋，方便非內部團隊同學閱讀文檔，比如一些常規(guī)搜索評估指標，MRR， topN有點比，NDC等? 背景。用文字清晰的描述需求的背景信息，如果已有功能的優(yōu)化，可以將數(shù)據(jù)看板掛在背景模塊，背影模塊需要寫明為什么做這個這個功能，用戶價值是什么，公司價值是什么，對齊那個年度或閱讀OKR。? 目標用戶。包括主要用戶，次要用戶，關鍵用戶，負面用戶? 用戶場景。用實際的案例描述用戶場景，比如小王在什么情況有什么訴求產品方案：? 解決哪些問題。以列表形式列出該功能可以解決的問題? 目標。定義需求數(shù)據(jù)目標，如果包含了新的指標可以說明指標計算方 法

8、，指標可以拆分一級指標，二級指標或三級指標? 方案設計。以金字塔原理組織需求內容，這塊從閱讀者視角去組織信 息，總分結構，復雜功能可能涉及到功能模塊的抽象和拆解參考資料：? 競品分析。列出所選競品，將競品文檔鏈接添加在此處。? 相關文檔。包括需求的歷史相關文檔，用戶訪談文檔，數(shù)據(jù)報告文檔，埋點文檔當負責一些比較大型的項目，受限于當前技術能力或技術資源，需求需要拆分成多期落地實現(xiàn)時，微軟的PRD真板比較好用，這是我在貝殼這邊學到的，同 樣分享給大家。Document Properties? Feature Owner 。同上文中的相關人員? Related Document 。同上文中參考資料-

9、 相關文檔Abstract 。對功能的頂層抽象，抽象出系統(tǒng)或功能的主要價值，一般3-5 點。有點像是雙月會上的產品用戶價值，同時說明系統(tǒng)/ 功能對公司的價值，可以按照 1 分鐘電梯演講提煉和抽象內容。User Scenario 。描述清楚用戶場景，同上文中的用戶場景Feature Requirements 。明確列出功能需求，并且給出評級，通過p0s0-p2s2定義產品功能重要程度，通過功能列表的定義，確定哪些功能當前重要緊急， 方便切分版本。Scope for this wave 。根據(jù)上面的評分，確定哪些功能在這一期的范圍內，哪些不在。Detailed Design同上文的產品方案與字節(jié)

10、prd 模板有以下幾點差異，對功能的優(yōu)先級和重要程度界定，方便后續(xù)版本管理和規(guī)劃。幾個重點：? 多思考，多問為什么。剛開始做產品經理的時候很容易憑感覺設計，感覺應該怎樣就怎樣， prd 模板就是一套思考范式，梳理清楚背景，描述清晰的用戶場景，明確要解決的問題，定義精確的目標，同時對競品有深入的理解和調研，再來設計產品，這些前置的準備其實就是我們這個功能為什么這樣設計的原因。而且因為評審方式的原因，就需要提前切換成文檔的讀者模式，看一下哪些點可能有疑惑。同時，為了防止評審中被 challenge 的尷尬，所以需要提前自己多問自己為什么這么設計，你的設計是當前能找到的最好設計嗎？? 終盤反推思維。

11、在飛書學到一個產品設計思考方法，在產品設計的時候可以一定程度上先跳過技術和人力壁壘，考慮最優(yōu)的體驗應該是什么樣的，然后在根據(jù)當前的實際能力和人力，去做方案降級，這樣我們能確保產品的方向是對的，同時設計上可以更好的兼容未來的優(yōu)化，不太會出現(xiàn)全盤推翻重做的情況。產品復盤不知道大家發(fā)現(xiàn)沒有，每次我們準備跳槽面試的時候，我們往往會有一波感知 明顯的能力提升，因為我們需要對自己過去一段時間的工作進行系統(tǒng)性的梳 理，這個過程伴隨著歸納總結，并且找到一些數(shù)據(jù)去佐證自己的價值，為談薪 獲取籌碼。筆者認為，產品的設計能力提升需要做定期的復盤，復盤包括幾個方面：用戶 問題反饋，目標用戶訪談和數(shù)據(jù)分析，因為飛書會有

12、雙月規(guī)劃復盤會和年度規(guī) 劃復盤會，所以有一個機制幫助產品定期對自己所負責功能進行總結反思。用戶問題反饋。上線后會收到字節(jié)同學在bug 或問題反饋群中提的意見，復盤中需要將這些問題梳理出來，確定是設計問題還是系統(tǒng)bug,并且與反饋問題的同學交流溝通，挖掘問題背后的訴求。目標用戶訪談。除了做問題反饋用戶的訪談外，還需要做目標用戶的訪談，關于目標用戶訪談的方法網(wǎng)上有不少，就不在這塊贅述，在雙月會的匯報文檔中可以將這部分內容放在相關文檔出處，歸納提煉出來的一些意見可以放到正文中。數(shù)據(jù)分析。數(shù)據(jù)可以一定程度上真實反應用戶的行為，所以所有功能上線前均 需要做完善的埋點設計，方便分析用操作行為，輔助產品優(yōu)化

13、方案，監(jiān)控問 題，在復盤時可以作為量化的指標，防止大家憑感覺給反饋。準確的數(shù)據(jù)埋點 是公司寶貴的數(shù)據(jù)資產，通常來說，在沒有做基于數(shù)據(jù)模型驅動用戶行為的設 計時，往往前端用戶埋點會非?；靵y，導致即使有算法工程師介入，也只能服 務端取業(yè)務數(shù)據(jù)，行為數(shù)據(jù)無法使用，還需要長時間的補埋點，積累數(shù)據(jù)后， 才能獲取到準確的數(shù)據(jù)，歷史用戶行為數(shù)據(jù)往往無法使用，這是一種極大的浪 費，后面計劃寫一篇文章，總結一下我在這塊的思考總結，感興趣的朋友可以 提前關注哈。、需求評審現(xiàn)在發(fā)現(xiàn)并不是所有的公司的產品方案都會有一個嚴格的內部評審機制，飛書 的評審機制比較完整，分享給大家。第一輪，雙月會上基于 prerealeas

14、e 完成優(yōu)先級拉齊第二輪，產品團隊內部的評審（ 復雜方案會切分成多輪多次評審）第三輪，內部討論一致的方案跟老板和各團隊一起評審第四輪，拿著產品團隊對齊的方案跟研發(fā)評審排期 過程中都會與對應的 engineer leader 持續(xù)交流，會不斷打磨產品方案。個人感覺上，這個過程是對產品來說壓力最大也是提升最大的，后面換了新的產品老大，流程上做了一些調整，上了一套系統(tǒng)去管理需求，將產品上線相關的所有節(jié)點均包含在內，包括翻譯，法務，數(shù)據(jù)等，因為后面的流程我沒有走過，暫不做展開介紹。向上 -對功能的頂層抽象因為需求評審的過程中會有高級別的老板參與評審，這類評審可能不太關注具體細節(jié)的設計（也有可能非常非常

15、非常關注字節(jié)），但是會關注對功能場景的抽象是否準確和深入，用戶需求場景的本質模型是什么？一些頂級競品如微軟的Team， Google G suite 是如何做的，當前這個功能是否與其他非直接競品的底層邏輯一致，比如郵件服務是如何設計過濾器的，電商平臺是如何做信息篩選的，如何實現(xiàn)的重要信息標記、提取和顯示等。為了可以順利評審過關，PM需要做很多抽象工作，嘗試回答現(xiàn)實場景中，用戶 需求的本質是什么，類似訴求下當前的解決方案有哪些，哪些我們可以借鑒，進而去設計我們自己解決方案，當然有可能抽象錯了，也會在評審過程通過提問回答獲得糾正。向下 -每個設計點多次自我拷問 - 我為什么這么設計？評審過程中先是

16、小團隊內部多人評審，使用靜默評審的方式，對文檔中疑惑點或者問題點進行劃線提問，默讀過程中，功能owner先用文字回答問題，閱讀完成后開始以回答問題為主的評審，如果文字回答滿意可以不用復述問題，如果需要調整，評論下面創(chuàng)建todo 。因為參與到評審中的角色會比較多（組內產品和小組leader ,相關功能pmy數(shù)據(jù)同學，算法同學等） ，所以在上評審之前需要自己問清楚自己為什么這么設計。包括但不限于交互設計，信息結構，競品設計，策略，埋點，指標等。評審方式 -靜默評審上一篇文章中提到了整體操作流程，這次補上一些圖示。? 創(chuàng)建日程，將參加評審同學添加至日程，并編輯會議摘要，說明評審內容，參與者收到飛書

17、push 日程的消息，會議開始前X 分鐘自動追加一個消息提醒?會議開始后，通過日程快速創(chuàng)建會議群，群內發(fā)出待評審PRD大家在各自電腦打開閱讀文檔，對疑惑/ 質疑點時劃線編輯評論? 一次PRD審控制在45分鐘，PRD乍者組織評審，一般會15分鐘閱讀 文檔，過程中PRD乍者通過文字回答評論提問，閱讀完成后文檔底部點 贊代表閱讀完成，多數(shù)人點贊后開始對評論答疑討論，并記錄 todo好處：? 通過閱讀而不是presentation 展開方案討論，讓評審更客觀，不會被演講者帶節(jié)奏；? 要求文檔邏輯更加清晰簡潔（ 15 分鐘可以讀完）；? 評審過程基于問答更加聚焦，不容易跑題；? 問答過程記錄在文檔評論區(qū)

18、，同時記錄 todo ，節(jié)省部分會后整理會議紀要時間看到這里，你可能會推理出飛書的評審會非常多，一個功能的迭代有可能多輪評審，而團隊中每個成員還需要參與到組內或組間其他人的需求評審，所以評審比較耗時。我的理解是飛書的產品設計過程通過這種評審會（ 30 到 45 分鐘的評審會），讓想法充分交流，評審過程中的靜默問答模式讓產品對自己的方案更加負責，上線前長時間的內部灰度確保產品質量，所以這么多倫的評審也不是適用于所有組織和團隊，但是這個過程中形成的壓力會磨練pm做更深層的抽象，對每個細節(jié)都有充分的考量，長期訓練下來，有助于形成產品體感。而且評審過程中會看到高級別的pm如何提問，能問出好的問題是非常

19、非常重要的。愛因斯坦曾經說過：“提出一個問題比解決一個問題更重要”。而靜默評審是一個幫助低階產品學習高階產品如何看產品，如何提問題的非常好的學習場景。其實網(wǎng)上一直流傳著產品和研發(fā)水火難容的故事，之前的公司中，與研發(fā)配合時感覺還好，都能很快跟開發(fā)打成一片，和小自己 10 幾年的研發(fā)同學稱兄道弟。在 58 和字節(jié)的時候，都會有一個小圈子，也可以稱為產品的智囊團。先有產品證明自己的專業(yè)性，同時找到想把事情做好的關鍵成員，PM說要做什么功能給 出方案，前后端研發(fā)，算法，設計會幫著看方案是否有可以優(yōu)化的點，哪里有漏洞幫我想到，研發(fā)主動提出更好的技術實現(xiàn)方案，大家為了把事情做成做好而愉快配合。也會遇到不好

20、溝通的研發(fā)，但總能找到突破口。但最近因為配合的產研團隊都在其他城市，所以遇到了一些協(xié)作問題，這讓我開始思考，為什么會有這種情況出現(xiàn)，是否有什么機制可以一定程度解決這個問題？感覺在58 的時候是運氣比較好，遇到了靠譜的同學，而字節(jié)是有一套機制和文化讓人變得靠譜，文化的部分放到下一章，先來說一下機制。本質上來說，產品經理和研發(fā)，設計，算法等工作性質不太一樣，也就是為啥pm剛出來就是“經理”的原因，因為我們輸出文檔和原型，具體實現(xiàn)都是研發(fā)，設計和算法來落地，我們的價值是通過合作方來實現(xiàn)的，而且一般情況下產品會對產出負責。就如同西游記中師徒四人，產研協(xié)作中，產品就如同唐僧，經常說的就是：“我要什么”，

21、具體都要看孫悟空們落地。而這個過程中往往是產品經理扛著老板的壓力和業(yè)務的壓力，要給孫悟空們壓時間和提意見，工齡長了之后，其實研發(fā)容易從對事情負責變成對任務負責，產品給出要給出沒有問題的需求，研發(fā)不出 bug 的實現(xiàn)，一旦看到有問題的方案就會開懟。筆者認為最底層上來看，這是把事做成做好的壓力沒有傳達到團隊成員的原 因，更像是其他人在幫產品實現(xiàn)功能。如果希望團隊高效協(xié)作，需要保證團隊 內部的成員大家對做成一個事情負責，而不是只對自己所負責的工作負責。字節(jié)的解決方案時增加一個角色，項目級別團隊都會有一個engineerleader ，這個角色不單單只是協(xié)調研發(fā)測試資源，組織站會，為團隊爭取留時間余量

22、和匯報進度，這個角色需要同產品 owner 高度配合，這個角色需要在研發(fā)評審前，和產品就產品方案達成一致，過程中可以提各種問題，但是對齊后，那么方案的設計和落地就是兩人共擔。研發(fā)的老大開會的時候不會找產品，直接找對應的 engineer leader ，這個角色就是研發(fā)中的那個對項目結果負責的人，扛著對應的壓力，因為他是研發(fā)體系的人，在處理內部矛盾上比產品直接協(xié)調好很多，而且我發(fā)現(xiàn)，越是高階的研發(fā)負責人，越是懂業(yè)務，很多研發(fā)老板同時負責產研團隊，換個角度來看，這種角色是研發(fā)負責人的種子。五、Owner意識這個話題前一篇文章也提到過，但是還是想拉出來說一下，之前和一個關系非常好朋友聊百度搜索廣告

23、面對客戶需求，產品反應速度慢的問題（可能是有的產品哈）。因為字節(jié)也在做搜索廣告，所以有些類似的場景，面對客戶的一個需求，字節(jié)可能是對接人快速飛書建群，拉上相關產研同學，鎖定問題，討論方案，排期規(guī)劃，有可能1-2 周內開發(fā)上線，效率非常高，百度有可能耗費更久的時間走流程，一個需求從一線到研發(fā)會經歷很多個角色，每個角色可能都有自己的考 量。因為沒在百度待過，但是當時在字節(jié)的時候也有百度跳過來的同學，感覺投入度超高，非常有Owner意識，閑聊時他們會說在百度并不是這個狀態(tài)。從我對 自己投入度復盤來看，字節(jié)讓我投入度超高主要有以下幾點原因： 承諾一致。說服力和細節(jié)中提到了公開承諾的力量，因為人本能的會

24、 保持自己行為和承諾一致，可能是人類為了協(xié)作對抗危險，演化寫進我們基因 中的一套底層編碼，還記得前文中提到年度，雙月，內部評審會嗎？因為字節(jié) 在乎數(shù)據(jù)，所以大量功能都會提前做出數(shù)據(jù)目標承諾，在多輪需求溝通（公開 承諾）后，沉沒成本不多增加，你會感覺這個需求或功能就是你的，千萬不能 做砸了，進而會給自己持續(xù)增壓。文化和價值觀改變行為-字節(jié)范兒。當年的BAT三家巨頭中，阿里最講企業(yè)文化建設，組織中甚至有政委的角色，沒在阿里待過，但是從一些花邊新聞可以看出，阿里是一個非常重視價值觀和公司價值一致的公司，騰訊和百度似乎沒有這么明顯，三家中阿里的強度和壓力也是最大的。字節(jié)沒有政委，但字節(jié)范兒就是字節(jié)的文

25、化價值觀統(tǒng)一的密碼，每個公司都有自己的文化價值觀，但是字節(jié)范的落地是我見到最NB的，當前字節(jié)范包含六句話：“追求極致、務實敢為、開放謙遜、坦誠清晰、始終創(chuàng)業(yè)，多元兼容”，如何讓這么抽象的概念深入人心，進而影響行為呢？通過大量的重復出現(xiàn)（辦公室墻上，會議室未接入屏幕，食堂電視， 360環(huán)評，衛(wèi)生間宣傳畫），來說兩個場景， 360環(huán)評和衛(wèi)生間宣傳畫。衛(wèi)生間宣傳畫。在58 我看到的衛(wèi)生間“展示位”給了公司季度業(yè)績，猜測目標是為了激勵員工努力？回憶當時似乎沒有太強烈的感覺，在貝殼，看到的衛(wèi)生間海報是介紹哪些行為不對，主強調正確行為引導。但是字節(jié)的衛(wèi)生間海報就是宣傳公司核心價值觀- 字節(jié)范兒，用漫畫的形

26、式告訴這些抽象概念對應的是什么行為，我在的這一年中經歷過一次海報替換，但最終換回了最初我入職的那一套，感覺這個真的能體現(xiàn)出字節(jié)范兒是什么，大家可以感受一下。至少我感覺通過漫畫我能夠快速將字節(jié)范兒的抽象概念快速的與日常工作聯(lián)系在一起了。360環(huán)評。在字節(jié)，試用期需要邀請其他人360環(huán)評， 8 月（年中）和3 月（年終）會有 360 環(huán)評決定績效，環(huán)評中會需要對被測評人的字節(jié)范兒給出評分和描述，環(huán)評工具會舉例可以如何去寫，產品一般需要給20-50 個合作方寫環(huán)評，所以這個過程中自己持續(xù)的給別人打環(huán)評的過程中，變向的也是在告訴自己什么是公司鼓勵的行為，也是講抽象概念具象化到自己身邊同學行為的一個過程

27、。周圍同事都很拼。前文中提到了，評審會和討論會占用大量的白天時間，雖然每個半小時到 45 分鐘，但是產品有整塊的時間還是要到晚上，因為字節(jié)有一個補貼政策，就是公司附近租房子有每月補貼1500 元，所以很多同學都住得離公司特別近，而且字節(jié)的食堂，下午茶，晚上零食水果是真的香，所以基本上你會發(fā)現(xiàn) 9 點后很多人都不會走，也不著急走，而且確實又很多白天接回來的活要干，所以就出現(xiàn)了大面積的加班。雙月會匯報壓力。在飛書經歷了兩個階段，第一個階段，飛書PM人數(shù)不多（60人左右），那時候的雙月會都是每個人去說明自己的上個雙月做了什么功能，上線后數(shù)據(jù)表現(xiàn)如何，與之前的數(shù)據(jù)承諾有何差異，未達成的原因，優(yōu)化的思路

28、是什么，雙月會上大家往往壓力報表。第二個階段，飛書的PM人數(shù)太多了，雙月會上是組長在替具體功能負責人解釋說明復盤內容。就是這一點改變，壓力指數(shù)會降低非常非常多。如果希望產品的投入度提升，可以考慮讓執(zhí)行產品直接給老板匯報，或者面對多人challenge 的場景，匯報人的投入度和圍觀別人替自己匯報的投入度真的是完全不一樣。六、其他飛書的有些功能非常贊，所以有些離開字節(jié)的同學會抱怨沒辦法再用飛書特別遺憾，文末我想分享一個飛書的小功能，其中部分模塊我也有參與設計優(yōu)化，真的感覺這個功能可以非常直觀的體現(xiàn)飛書的產品定位和目標，分享給大家，大家做產品的過程中可以做類似的思考和細節(jié)設計。前一篇總結中提到，飛書定位就是解決團隊高效協(xié)同，希望讓用戶的每一次click 都能是最快捷高效的，一次點擊，即使幫助用戶節(jié)省 0.5 秒，當一個企業(yè)每天幾萬人多次使用時，所節(jié)省出來的時間也將非?？捎^。本文想要分享的小功能是飛書的一個全局功能，在IM 和文檔中可以快捷觸發(fā)。先來描述 IM 協(xié)調溝通中的幾個辦公場景的痛點：經常需要在群聊中群內某人/ 某些人，希望他們可