Meegle基本概念¶
介紹¶
初次上手Meegle,如果對於工具內的一些詞彙不熟悉,可以試試在本文中查閱對應的詞彙。
產品結構:它是如何組織工作的?¶
歡迎使用Meegle!為了幫助您更高效地管理工作,請先了解以下核心概念。
空間:團隊高效協同的工作區域 空間是您和團隊進行協作的獨立容器。 您可以根據公司的組織架構或業務場景,建立多個空間,來劃分不同的協同區域; 在每個空間下,你可以設定多個工作項型別,來管理不同的事務型別。 例如:
- 軟體研發空間:管理“迭代”、“需求”、“缺陷”和“版本”等工作項型別。
- 市場運營空間:管理“活動策劃”、“內容製作”和“渠道投放”等工作項型別。
- 法務支援空間:管理“合同評審”和“風險評估”等工作項型別。


工作項型別:管理同一類事項的規則 工作項型別是管理一類事務的標準化“模板”或規則集合。它本身不代表任何一件具體的工作,而是定義了這類工作應該“長什麼樣”以及“如何被管理”。 它定義了:
- 欄位:如優先順序、截止日期、負責人、所屬模組等。
- 流程:包含哪些步驟,例如,需求建立>需求評審>需求開發>需求測試>需求上線等。
- 頁面佈局:詳情頁上展示哪些資訊,以及如何排版。
- 角色:如產品經理、開發、測試、運營等角色,明確專案成員的職責與分工。 例如,配置一個“需求”工作項型別,就是在為所有“需求”制定一套統一的管理標準。



工作項例項:基於工作項型別建立的具體事項 工作項例項是團隊成員在日常工作中,依據“工作項型別”建立出來的具體事務。 它是承載資訊、驅動流程的實體。 簡單來說:
- “需求”是一個工作項型別,而“開發賬號登入功能”就是基於需求工作項建立的一個例項;
- “缺陷”是一個工作項型別,而“修復首頁閃退Bug”就是基於缺陷工作項建立的一個例項;

工作項關聯:把管理物件「連」起來 你可以透過工作項關聯,把不同的工作項鍊接起來,實現專案的上下文聯絡與父子分解,實現端到端的追溯。 例如,一條完整的業務追溯鏈可能如下:
- 頂層目標 “Q4 關鍵成果” (OKR)
- 被拆解為 “重構支付閘道器專案” (專案)
- 專案再關聯到具體的 “支援新支付渠道” (需求)
- 該需求在測試中發現了 “某渠道支付失敗” (缺陷)


協作分工:誰來配置與使用?¶
在Meegle中,使用者主要分為兩類群體,各司其職:
空間管理員:流程的設計者 負責定義“我們應該怎麼工作”。 空間管理員將團隊的管理規範 (SOP) 轉化為Meegle中的系統配置,包括自定義工作項、流程、欄位等,從而搭建起一套標準化的協作框架。
空間成員:專案的執行者 負責執行“我們具體在做什麼”。 空間成員在管理員配置好的框架內,建立和流轉具體的工作項例項,完成資訊的結構化沉澱與高效的任務協同。
基礎概念¶
| 領域 | 名詞 | 英文 | 描述 | 舉例 |
|---|---|---|---|---|
| 基礎概念 | 空間 | Space | 一個組織協作的基本單元,可以是單一專案的管理,多個專案的合集。 | Meegle、飛書套件、飛書文件 |
| 工作項 | Work Item | 一個團隊協同的工作事項,也可以是專案拆解的事項合集 | 需求、缺陷、版本、迭代、里程碑 | |
| 業務線 | Business Line | 業務線管理代表著一種管理模式,管理員可以根據本專案管理需要,按照業務模組、功能模組、人員序列等不同的劃分方式,進行業務線拆分。 | 基礎技術、工程架構、UG、開放能力 | |
| 需求 | Feature | 指使用者解決某一問題/達到某一目標所需的軟體功能,它幫助團隊成員跟蹤具體細節的問題 | xx技術重構、xx自動化接入 | |
| 節點 | Node | 需求的階段分割點,由需求 SOP 的標準任務事項組成 | 產品評審、前端估分、QA測試 | |
| 子任務 | Subtask | 指任務拆解成更小的單元,它可以指派給多名成員負責 | ||
| 缺陷 | Issue | 缺陷是指不符合最初定義的業務需求,其覆蓋範圍高於 Bug | 彈窗不展示、導航欄沒有適配 | |
| 版本 | Version | 是面向使用者交付的需求合集,可以是規劃制的,在某個版本實現指定的需求,時間可根據實際情況可長可短調整;也可以是班車制的,固化封版本發版時間,需求根據完成時間自動上車 版本注重需求,在某個版本實現指定的需求,但是時間可根據實際情況可長可短調整 |
飛書-iOS-5.1 飛書- Android-5.2 | |
| 迭代 | Sprint | 管理組織效能的方法,透過將大顆粒度的專案拆解為可執行的,能在短週期內快速交付的任務,並能迴圈往復執行該生產週期,使開發過程遞增向前。每一次迭代都包括了從需求分析到測試完成,是敏捷的核心。 迭代注重時間,在某段時間去實現優先順序高的需求 |
||
| 專案 | Project | 專案是為完成某一獨特的產品或服務所做的臨時性努力。臨時性是指計劃有確定的開始日期和結束日期。獨特意味著專案的最終結果不重複。 | 釋出會官網 |
排期管理¶
| 領域 | 名詞 | 英文 | 描述 | 舉例 |
|---|---|---|---|---|
| 排期管理 | 角色 | Role | 參與到專案中的各類角色,一個專案需要不同角色的配合支援 | 產品經理、PMO、UI設計、測試 |
| 負責人 | Owner | 負責執行任務的角色 | ||
| 排期 | Scheduling | 對多項任務進行時間規劃 | ||
| 估分 | PD (Person Day) | 估算任務所花費的時間 |
欄位管理¶
| 領域 | 名詞 | 英文 | 描述 | 舉例 |
|---|---|---|---|---|
| 欄位管理 | 欄位 | Field | 定義工作項屬性的基本單元 | |
| 系統欄位 | System Field | Meegle平臺已有的預設欄位 | 名稱/描述/需求文件 | |
| 模板欄位 | 由建立空間時,根據空間模板型別預設的欄位 | |||
| 自定義欄位 | Custom Field | 由空間管理員建立的符合業務需求的自定義欄位 | ||
| 控制元件 | Control | 平臺提供的包含業務封裝邏輯的元件 |
頁面管理¶
| 領域 | 名詞 | 英文 | 描述 | 舉例 |
|---|---|---|---|---|
| 頁面管理 | 表單 | Form | 承載欄位的頁面 | |
| 新建頁表單 | Creation Page Form | 用於新建需求/缺陷/迭代等場景下,承載欄位的頁面 | 在 Meegle中可以使用各種欄位來做資訊的展示 | |
| 詳情頁表單 | Detail Page Form | 承載需求/缺陷/迭代全部欄位的頁面 | 在 Meegle中可以使用各種欄位來做資訊的展示 | |
| 節點流轉表單 | Node Form | 定義該節點完成的標準,可以以表單的形式展示 | 在 Meegle中可以使用各種欄位來做資訊的展示 | |
| 狀態流轉表單 | Status Flow Form | 定義該狀態結束的標準,可以以表單的形式展示 | 在 Meegle中可以使用各種欄位來做資訊的展示 |
流程管理¶
| 領域 | 名詞 | 英文 | 描述 | 舉例 |
|---|---|---|---|---|
| 流程管理 | 流程 | Workflow | 一個事項生命週期的基本步驟,由過程節點及執行方式有序組成 | |
| 節點流 | Node flow | 將工作項拆解為具體可執行的任務,並串聯成有向的流程 | 需求流程 | |
| 狀態流 | Status flow | 將工作項的階段串聯,形成變換規則 | 缺陷流程 |
檢視管理¶
| 領域 | 名詞 | 英文 | 描述 | 舉例 |
|---|---|---|---|---|
| 檢視管理 | 表格 | Table | 欄位資訊的排列組合,以單元格形式排列資料 | ![]() |
| 看板 | Kanban | 管理在製品的一種管理工具 | ![]() |
|
| 甘特圖 | Gantt Chart | 以時間維度,透過條狀圖來顯示專案進度 | ![]() |
|
| 人員排期 | Scheduling | 以團隊維度關注專案的人力投入情況,關注整體資源 | ![]() |
|
| 檢視 | View | 將團隊內高頻關注的工作項查詢維度,固化的一種集合 | ||
| 工作臺 | Work Station | 跨空間專案的聚合,更關注於個人待辦,可透過工作臺快速完成處理ToDo | ![]() |
專案度量¶
| 領域 | 名詞 | 英文 | 描述 | 圖例 |
|---|---|---|---|---|
| 度量 | 度量 | Measure | 度量是對軟體開發專案、過程及其產品進行資料定義、收集以及分析的持續性定量化過程。比如需求吞吐、質量、週期與人力估分等等。 | ![]() |
| 源資料 | Source Data | 針對性度量整個工作項的資料。 工作項,如:需求、缺陷、版本與迭代。 檢視資料,如:進行中需求池、待我處理的缺陷與個人自定義的檢視名稱。 單個例項,如:資料範圍為特定的某個需求、缺陷、版本與迭代等。 |
![]() |
|
| 維度 | Dimension | 維度指的是資料的屬性,可以確定資料在圖表中的分組方式,常用在 X 軸。舉例來說,需求狀態有「開始」、「進行中」、「已完成」等屬性值。在 Meegle中,常用的維度有:需求狀態、業務線、優先順序、人員角色、時間軸與相關的選擇型別欄位。 | ![]() |
|
| 指標 | Indicator | 指標指的是量化衡量標準,常用在 Y 軸。舉例來說,需求數、估分數都是指標。在 Meegle中,常用的指標有:需求、缺陷等工作項資料、估分數。 | ![]() |
|
| 欄位 | Field | 欄位包含一個或更多值(欄位值),是構成指標與維度的基礎,Meegle度量中有三種型別的欄位。 系統預設提供的欄位,如:節點估分、狀態流進入次數等等,也有部分稱作控制元件,比如:人員角色; 管理員自定義欄位,如:A 租戶名稱、B 專案進度等等; 計算欄位:透過對表示式對欄位的組合得出新的維度與指標。 |
![]() |
|
| 柱狀圖 | Histogram | 柱圖可以展示每項資料在一段時間內的變化及資料間的比較情況。如:檢視某段時間內不同業務線的需求數或人效對比;檢視某段時間每月內新建需求數對比。 | ![]() |
|
| 折線圖 | Line Chart | 折線圖是用於觀察資料的趨勢,可以瞭解某一維度在時間上的規律或者趨勢,常與時間搭配。可以用於瞭解需求消化速率等場景。 | ![]() |
|
| 面積圖 | Area Chart | 觀察資料隨著時間的走向與趨勢,除了折線圖外,還可以使用面積圖。面積圖從折線圖演化而來,折線與座標之間進行了顏色的填充,這裡的填充區域即“面積”。另外,面積圖色彩的變化與透明度可以很好的檢視不同資料之間的重疊關係,通常用於累積流看專案進展。 | ![]() |
|
| 環形圖 | Ring Chart | 環形圖是餅圖的變種,用於表示不同分類的佔比情況,透過弧度大小來對比各種分類。環形圖透過將一個圓環按照分類的佔比劃分成多個區塊,所有區塊(圓弧)之和等於 100%。可以很方便的進行兩個圖的對比。一般用來檢視分佈情況,比如質量的佔比。 | ![]() |
|
| 條形圖 | Bar chart | 條形圖其實是柱狀圖的變種,可以展示每項資料在一段時間內的變化及資料間的比較情況。常用主要是:檢視某段時間內不同業務線的需求數量或人效對比。 | ![]() |
|
| 漏斗圖 | Funnel Diagram | 漏斗圖適用於業務流程比較規範、週期長、環節多的單流程單向分析,透過漏斗各環節業務資料的比較能夠直觀地發現和說明問題所在的環節,進而做出決策。 | ![]() |
|
| 指標卡 | Indicator Card | 指標卡用來顯示關心的某一個指標值及其變化趨勢,比如同比、環比等。一般是用來結合統計數值用於展示某主題的核心指標。 | ![]() |
|
| 資料表 | Data Sheet | 可以簡單理解為表格,也就是上面提到各種表的轉換。和透視表不同的是,無法建立交叉管理。 | ![]() |
|
| 透視表 | Pivot Table | 透視表資料透視表是一種互動式動態表格,可以快速彙總大量資料並建立交叉關係。在透視表中可以按照不同的組合方式進行資料計算,它可以幫助分析和組織資料。例如,計算平均值、標準差、計算百分比。 | ![]() |
|
| 組合圖表 | Combination Chart | 由於單一的圖表型別無法滿足多維度的資料展示,組合圖表支援兩種及兩種以上的圖表型別組合起來繪製在一個圖表上,實現更多維度的資料解析。 | ![]() |
|
| 燃盡圖 | Burndown Chart | 是用於表示迭代剩餘工作量的工作圖表,由橫軸(X)和縱軸(Y)組成,橫軸表示時間,縱軸表示工作量。這種圖表可以直觀的預測何時工作將全部完成,常用於軟體開發中的敏捷軟體開發方式,也可以用於其他型別的工作流程監控。 | ![]() |
自動化¶
| 領域 | 名詞 | 英文 | 描述 | 圖例 |
|---|---|---|---|---|
| 自動化 | 流程圖 | Flowchart | 自動化配置後的流程展示形式。 | ![]() |
| 語義化 | Semantization | 流程圖內容的結構化文字展示形式。 | ![]() |
|
| 觸發器 | Trigger | 觸發器是用來啟動自動化過程,由事件來觸發,如建立一個需求,刪除一個缺陷。 | ![]() |
|
| 操作 | Operation | 觸發器觸發後需要進行的動作,操作型別支援通知、欄位操作、節點操作、WebHook 和群組操作等 5 種。 | ![]() |
|
| 條件 | Condition | 將團隊內高頻關注的工作項查詢維度,固化的一種集合。 | ![]() |
WBS¶
| 領域 | 名詞 | 英文 | 描述 | 圖例 |
|---|---|---|---|---|
| WBS | IPD | Integrated Product Development | IPD(Integrated Product Development,整合產品開發)是一套產品開發的模式、理念與方法 ,本質是從市場機會到商業變現(Idea To Market)的產品開發管理模式,主要應用於硬體專案開發流程,旨在最佳化產品設計與開發過程。 IPD 體系中包括市場管理、整合產品開發流程、跨職能團隊管理、產品組合管理、決策與評審機制、公共基礎模組等內容 |
|
| WBS | Work Breakdown Structure | WBS 即工作分解結構(Work Breakdown Structure),WBS 是專案管理的核心工具,以可交付成果為導向,將專案或工作按邏輯和層級關係進行樹形拆解,形成更小、更易管理的可執行單元(工作包)。每個單元包含負責人、排期、交付物等基本資訊,最終形成專案整體的樹狀結構。其本質是對專案團隊為實現專案目標、建立所需可交付物而需要實施的全部工作範圍的層級分解 | ![]() |
|
| 交付物 | Deliverables | 交付物(Deliverables)是專案管理中階段或最終的獨特、可驗證的產品、成果或服務能力,完成全部交付物意味著覆蓋專案範圍。形式包括有形(產品、文件)或無形(服務、狀態報告)。 PPM 目前支援兩種模式: 欄位交付物:管理粒度粗糙,僅標識產物,不管理生產進度; 工作項交付物:管理粒度更細,可管理產出過程、人員、排期等。交付物工作項是 IPD 行業專版預置的一種工作項型別 |
![]() ![]() |
|
| 子工作項 | 普通父子關係,不存在於計劃表中 | |||
| WBS 子工作項 | - | WBS 父子關係,透過計劃表拆解產生的子工作項 | ||
| WBS 子項 | - | 泛指 WBS 計劃表中的子項,包括節點、子任務、WBS 子工作項 | ![]() |
|
| WBS 根工作項 | - | WBS 計劃表中最頂層的工作項 | ![]() |
|
| WBS 父工作項 | - | 相對說法,指 WBS 子工作項直接上級的工作項 | ||
| 事項拆解 | - | 將當前例項(工作項)直接拆解為多個子例項(子工作項),子例項之間無嚴格的流程順序,主要承載具體事項資訊。適用於需要靈活管理末端事項的場景(如專案集的範圍拆解、計劃拆解中的具體任務細化),或使用者希望以 “事拆事” 的方式管理子項(如大需求拆解為多個子需求)。子例項有獨立工作流、資料結構和角色配置,支援多層級巢狀;狀態流工作項僅支援事項拆解 | ![]() |
|
| 流程拆解 | - | 將當前例項(節點流工作項)按其流程拆解為多個節點,下一層例項或任務掛在節點上,節點間有邏輯先後順序。適用於標準化流程管理,需透過節點明確時序依賴和角色協作的場景。節點可關聯子流程、配置交付物和依賴關係;僅節點流工作項支援流程拆解 | ![]() |
|
| 依賴關係 | - | WBS 子項啟動或完成時的強制校驗,目前支援FS和FF兩種型別。FS(Finish to Start)依賴項完成後才允許開始;FF(Finish to Finish)依賴項完成後才允許完成。需開啟高階依賴才能使用此功能 | ![]() ![]() |
|
| 排期依賴 | - | 排期依賴 是專案管理中用於描述 WBS(工作分解結構)中任務間排期影響關係的核心概念,具體指 WBS 中一行任務 A 的排期受另一行任務 B 排期影響的依賴關係(即 A 依賴 B)。排期依賴是排期預設值的計算規則,並非強制約束。支援FS(完成 - 開始)、SS(開始 - 開始)、FF(完成 - 完成)、SF(開始 - 完成)四種型別,支援設定偏移量。排期依賴公式示例:1FS+3wd | ![]() |
|
| 關鍵路徑 | - | 關鍵路徑是專案中帶有依賴關係的一系列任務,可以用來估算專案最短工期。如果關鍵路徑上的任務被延遲,則可能造成整個專案的延期。在計劃表編輯欄上開啟關鍵路徑開關後,在甘特圖上的關鍵任務和連線均會顯示。 關鍵路徑可以有多條,均為【完成該專案的最晚時間節點(按排期計算)】和與此關鍵路徑節點【有依賴關係並無法再向後延期的前序節點】。 |
![]() |
|
| 所屬 WBS 根節點 | - | WBS 根工作項為流程拆解時,WBS 子項及交付物所掛載的WBS 根工作項的節點 | ||
| 所屬節點 | - | 子任務/子工作項/ WBS 子工作項/交付物直接掛載的節點 | ||
| 所屬 WBS 子工作項 | - | 交付物直接掛載的 WBS 子工作項 |




































