專案管理有一套共同語言。搞懂這些詞，跨團隊溝通時就能少一點誤會、快一點對齊。以下依「方法論、規劃排程、工作項、角色、度量、協作」六大類整理，每個詞用一兩句話講清楚。
方法論與框架
瀑布式（Waterfall）
一種線性、階段接續的做法：需求、設計、開發、測試依序完成，前一階段確定後才進入下一階段。適合需求穩定、變動少的專案。
敏捷（Agile）
一套以短週期迭代、持續交付與擁抱變化為核心的價值觀，強調可用成果優於完整文件、回應變化優於墨守計畫。
Scrum
敏捷的一種具體框架，把工作切成固定長度的 Sprint，透過每日站會、Sprint 規劃與回顧，讓團隊小步快跑、持續改進。
看板（Kanban）
以視覺化卡片與欄位呈現工作流的方法，重點在限制在製品數量、讓阻塞點浮現，追求流動的順暢而非固定的迭代。
精實（Lean）
源自製造業的思維，核心是消除浪費、放大價值，把不直接創造價值的環節持續削減。
規劃與排程
甘特圖（Gantt Chart）
以橫條呈現各任務起訖時間與重疊關係的排程圖，適合綜觀時間軸與里程碑。
要徑法（Critical Path Method, CPM）
找出決定專案最短完成時間的關鍵任務鏈；要徑上的任務一延遲，整個專案就跟著延遲。
里程碑（Milestone）
專案中具指標意義的時間點，通常代表一個階段的完成或重要交付，用來檢核進度。
基線（Baseline）
專案在某時點核定的範圍、時程與成本基準，作為後續衡量偏差的參照。
相依關係（Dependency）
任務之間的先後或條件約束，例如「B 必須等 A 完成才能開始」；相依愈複雜，排程愈需要視覺化。
工作項與範圍
Epic
一項較大、需再拆解的工作集合，通常對應一個較高層次的目標或功能主題。
使用者故事（User Story）
從使用者角度描述需求的短句，格式常為「作為某角色，我想要某功能，以達成某目的」。
待辦清單（Backlog）
尚未完成的需求與任務的排序清單，團隊依優先級由上而下逐步取用。
範圍潛變（Scope Creep）
專案範圍在未經正式評估下持續擴張的現象，是延期與超支的常見主因。
驗收條件（Acceptance Criteria）
判定一項工作是否算「完成」的明確條件，讓交付標準不因人而異。
角色與協作
產品負責人（Product Owner）
代表需求方、負責排定待辦優先級並定義價值的角色，是「做什麼」的最終決定者。
Scrum Master
負責促進流程、排除阻礙、維護團隊節奏的角色，重點在服務團隊而非指揮團隊。
利害關係人（Stakeholder）
任何會影響專案或受專案影響的人或組織，例如客戶、主管、跨部門團隊。
跨職能團隊（Cross-functional Team）
由不同專長成員組成、能獨立完成端到端交付的團隊，減少對外部環節的等待。
RACI
釐清權責的對照法，將每項工作標示為負責（Responsible）、當責（Accountable）、諮詢（Consulted）、告知（Informed）。
度量與追蹤
燃盡圖（Burndown Chart）
呈現剩餘工作量隨時間下降的折線圖，用來預測 Sprint 或專案能否如期完成。
速度（Velocity）
團隊在每個迭代平均完成的工作量，作為後續規劃的參考基準，而非考核指標。
在製品限制（WIP Limit）
同時進行中的任務數量上限，用來避免多工造成的切換成本與阻塞。
前置時間（Lead Time）
從需求提出到交付完成的總時間，反映團隊對外的整體回應速度。
週期時間（Cycle Time）
從實際動工到完成的時間，聚焦於執行效率本身。
協作與流程
單一事實來源（Single Source of Truth）
所有人以同一份最新資料為準，避免版本分歧與資訊來回。
工作流（Workflow）
一連串有順序、有條件的任務流轉，把「該由誰、在什麼時候、做什麼」明確描繪出來。
自動化（Automation）
以預設規則自動觸發狀態變更、指派或通知，把重複性動作交給系統處理。
用 Meegle 把術語變成可執行的工作流
懂術語只是第一步，能落地才有價值。Meegle 把 Epic、使用者故事、相依關係與里程碑，直接對應成視覺化工作流上的節點；甘特圖、燃盡圖與速度等度量，也都能在同一平台上即時呈現。團隊不必在白板與試算表之間來回，就能讓「共同語言」變成「共同的執行畫面」。
結語
術語的意義，在於讓團隊用更少的字講清楚更多的事。把這些關鍵詞納入日常，再搭配一套能把它們視覺化的工作流，跨團隊協作就能少一點翻譯成本、多一點對齊。