行業背景

互聯網效率提升已至臨界點，短期內效用提升空間有限。互聯網的本質是提升效率和效用，效率發展取決於效率差，效用取決於時長和消費能力。行業規模不斷增長，產品快速迭代、信息速率提升為企業的協作效率提出了新的挑戰。無論企業規模大小，需求管理混亂，代碼管理複雜，協作流程冗長等問題至今困擾着這條鏈路上的所有角色，亟需項目管理工具進行產研提效。

## 行業痛點

1. 流程推進困難：多項目並行推進混亂，PMO 一對一私聊進展效率低；相關進展和風險無處暴露，任務負責人不知從何做起。

2. 項目管理複雜：上下游信息的不對稱性加劇了項目執行的難度，導致相關方對項目背景和理解存在偏差，從而使得整個項目執行的各個環節中斷和割裂。

3. 覆盤無從下手：項目執行過程的關鍵信息無處沉澱，收尾後沒有覆盤階段；無法有效預防項目風險，同樣的問題反覆出現。

軟件研發解決方案價值點

1. 獨特節點流工作方式，降低任務的顆粒度，將各階段各角色的任務分工清晰沉澱到流程中，真正做到流程驅動過程，過程反哺流程。通過看板和人力甘特圖功能清晰展現每人每日工作詳情，效率加倍。

2. 將過程交付物沉澱到系統中進行管理，項目收尾階段對交付物進行統一覆盤和迭代；強大的度量功能開箱即用，不需要其他的數據專業團隊，飛書項目可以自動將項目數據轉化為實時更新的可視化圖表，洞察項目執行中的所有風險點。

理念一：流程驅動過程，過程反哺流程

在軟件開發行業，一個項目或產品從立項到開發到上線的流程中涉及項目經理、產品、研發、測試、運營、設計等多個角色，每個角色又有幾十到幾百不等的人員，如此龐大的團隊在協作過程中總是存在各種各樣的問題：

• 每個人使用的工具不統一，數據無法打通，進度全靠口口相傳；
• 流程不清晰，分工不明確，給項目經理的管理帶來極大的挑戰；
• 項目管理工具的人工操作太多，流程感太強反而降低了團隊效率；

1. 減少微觀管理，強調 owner 意識

在協作的同時，飛書項目同樣也強調激發所有角色及人員的創造性，在飛書項目中，排期的顆粒度是以天為單位——為什麼不是小時甚至分鐘呢？飛書項目希望管理者能夠減少微觀的管理，不要試圖去控制團隊成員的每一分鐘時間和每一個細小的 point。相反，任務明確分工後，應該允許每個人有自己獨特的拆解和完成方法，這種粗顆粒度的管理方式鼓勵每個人去主動思考，沉澱出可複用的 sop。

2. 自定義流程 + 靈活裁剪

流程是整個團隊在合作過程中不斷磨合的產物，同時，隨着人員的調整、目標的變更以及管理理念的發展，流程總不會是一成不變的，在一次次的實踐過程中迭代執行流程，使團隊合作逐漸變得高效。同時，先進的流程也應該是靈活可調整的流程。相比其他項目管理工具死板的執行，飛書項目還提供了流程裁剪的功能，通過開關、角色輕鬆的裁剪流程。

場景一：在研發過程中，產品根據用户反饋，發現需要做一個 iOS 適配的功能，那在這個需求中就不需要 Android 端相關的研發、測試人員參與，那可以通過刪除這些角色，進而刪除相關的開發、測試節點，一個流程適配多種需求。
場景二： 對於某類技術需求，可能只是優化了底層的代碼邏輯，不需要 DA 重新進行埋點設計，那可以通過開關來控制「埋點設計」和「AB 方案設計」節點，關閉開關，即可刪除這兩個節點。

3. 最好的流程是沒有流程感

初期為了避免團隊協作的不順暢，便把每個流程節點安排得事無鉅細明明白白，期望團隊所有人員可以清晰自己的任務，但在實踐中我們逐漸發現，當冗餘的流程被擺在枱面上，就需要人工操作不斷的點擊完成系統上的每個節點，彷彿給工具配了個工具人，這和飛書項目的初衷背道而馳。好的流程應該是融入到過程當中，激發人的創造性，而不是束縛了人的思考。飛書項目的願景是希望流程可以驅動成員，通過任務的自動分發，去提醒每個角色需要完成什麼任務和交付物，完成後可以自動流轉節點，既遵循了對團隊來講最高效的流程，又讓每個角色對流程沒有感知。

同時，飛書項目有豐富的第三方集成經驗，提供全面的 OpenAPI 接口和 WebHook 能力，在內外部都有很多成功的實踐。例如，通過平台提供的 GitLab 插件，關聯 GitLab 中的代碼分支和「飛書項目」中的項目需求。關聯後，即可在「飛書項目」中查看需求所關聯的代碼分支及其狀態。同時也可以通過 GitLab 側 merge request 而推動需求的節點流轉。

理念二：上下文清晰可見，上下游信息拉齊

國內外經濟學家都在致力於研究如何消除信息不對稱的影響，經濟學家認為信息不對稱問題固然可以讓市場參與者去解決，但更多的是要依賴分工和市場。同樣，在生活和工作中，我們也在追求信息的對稱以謀求平衡的發展。在組織協作中，每個人接收到的信息參差不齊，再加上團隊人員的流動，對信息的感知更是相差甚遠。上下游的協作者如果對於上下文不夠了解，那麼信息的不對稱必然導致整個項目困難重重。所以，飛書項目支持一鍵拉起需求羣，將相關角色的人員自動拉到羣裏，需求的全部進展和上下文都會展現在羣聊中，即使在執行過程中有新成員的加入，也可以通過爬樓抓取到“原汁原味”的有效信息，而非口口相傳的二手消息。

跟蹤需求進展是項目經理的日常工作，每日每週統計進展，催負責人進度，這一機械化的重複工作佔用了項目經理 80% 的時間，極大的限制了項目經理的思考、創造和生產力。
飛書項目的自動化通知功能解救了項目經理們。有了自動化通知，自動推送需求相關信息——人員變更/節點狀態流轉/排期變更等。

理念三：數據變身圖表，風險無處藏身

運動員在訓練過程中除了每次訓練的成績之外，還要記錄健康數據、飲食數據等，這些相關數據能夠幫助運動員更科學的調整訓練計劃也能避免訓練所帶來的風險。同樣，對於項目來講，項目管理工具就像心電圖一樣，記錄着項目執行過程中的所有數據，通過度量功能可以實時檢測項目中的各種風險，也可以在項目收尾階段對項目收益以及過程數據進行復盤，從質量分析、需求效能等角度不斷迭代執行的效率。

多視角管理

把控全局的負責人

“只需接收有效信息，做出關鍵性決策，工具確實改變了我們團隊和我的工作方式。”
作為管理者，我一直在思考團隊管理的邊界感。我之前總是每天被拉進各種會議，絲竹亂耳案牘勞形的日常工作並沒有給團隊提效，反而所有事情都在拖延等待着我來做決策。於是我們利用工具把協作流程理清，安排每個節點和任務的負責人，給每個成員足夠的發揮空間。
我也會通過視圖來查看需求的進展情況，飛書項目可以篩選出當前延期的需求，點進詳情頁可以瞭解需求的所有信息和延期節點的負責人，點進需求羣即可看到延期的原因，如果有疑問也可以直接在羣內溝通。

在遇到重大決策時，我們也支持民主討論，每個人的視角不同，但都可以對需求的決策產生影響。

跟蹤全程的項目經理

“社恐福音！再也不用天天花大量的時間私聊小李他們問進展催進度了，省下來的 80% 時間可以好好思考團隊如何提效。”
我是一名互聯網公司的項目經理小王，兩年的 PMO 工作經驗，來到公司後發現項目管理制度比較混亂，每個團隊每個角色使用的工具不統一，剛來的時候和大家不太熟，研發的人員資歷很深，不好意思去催任務，導致需求總是 pending 。使用了飛書項目後，這一切機械化的工作就交給系統代勞了，我最常使用的功能是自動化通知，還可以一鍵拉羣或者綁定現有羣，不用一個個往羣里拉人，需求進展直接推送到羣內。
同時，需求狀態的停留時長會直接顯示在視圖中，發現 block 點直接使用“催一催”功能，機器人直接推送提醒完成節點。

以前項目覆盤時，需要導出找交付物、過程數據，從數據收集整理到導入做表需要一個月的時間；現在所有信息都沉澱在系統裏，還有開箱即用的圖表模板，一鍵就可以將表格轉化成圖表，真的太方便了！

聚焦任務的程序員

“上下游信息齊全，跟版需求的狀態清晰，每天到工位後打開甘特圖即可規劃今日工作安排。”
我們的 app 是兩週一個版本，每個版本下會拆解很多個跟版需求，產品評審後的需求進入技術評審節點時羣內會有自動通知，我們可以清晰地看到並行的二十多個需求的狀態、優先級等信息。
在代碼平台提交代碼成功後，對應的需求開發節點能夠自動通過，代碼合入後需求上車節點也能自動完成，項目管理工具並沒有想象中的會給我的工作帶來負擔，反而用起來非常流暢。

“養孩子”的運營

“飛書項目絕不僅僅是產研管理工具，運營的日常工作中同樣可以使用節點流來管理。”
我是負責用户運營的小吳，開始我們以為這款“產研”工具和我們運營團隊沒有關係，後來才發現這工具其實啥都能管。打開飛書項目後，我們看到有運營管理的空間模板，便試着用它來收集管理用户聲音。
自此，每週的用户反饋都沉澱在系統中，在週會前我們會整理出相關的度量圖表，統計用户的使用情況。
同時，和產品的協作也變得更加清晰且可視化，每個月有多少用户反饋，反饋中有多少有價值的需求一目瞭然。

結語

在項目管理的世界裏，沒有一套方法或工具可以解決所有問題，但透明的流程、清晰的上下文和數據化的決策，始終是高效團隊的共同底色。想了解更多企業如何在不同場景下實現流程優化與交付提效，可以前往飛書項目官網，瀏覽更多真實的實踐案例與經驗分享。