Linear/五物件關係圖

Initiative 回答的是「這幾個 project 為什麼要一起被推動」。它本身不是一段具體執行的工作，而是一個更高層的主題——例如 提升新用戶轉換率、建立 AI-first 內部工具鏈、降低客服處理成本。

在 Linear 裡，你可以先建立一個 initiative，再把多個 projects 掛在它底下。看 roadmap 時，你不再是看單一專案，而是在看一整條更大的推進方向。

實務建議：別太早開 initiative。多數團隊規模還小時，先把 project 用好；等到「同時有好幾個 project 都在做同一件事」時，再往上補一層 initiative。

Project 回答的是「這一段時間要完成什麼」。它是目標容器——有清楚的開始與結束、可被追蹤的狀態與進度條，並且擁有它底下的 issues。例如 Onboarding 2026 Q2、會員結帳流程重構、客服後台第一版上線。

該開 project 的條件其實很實在：有明確目標、需要一段時間追蹤進度、底下會有多張 issues、希望有人當 lead。如果只是單張票，就別硬升級。

跟 Cycle 的差別：Project 不是時間切片。同一個 project 的 issues 可以分散在好幾個 cycles 完成；一個 cycle 裡也可以同時收好幾個 projects 的 issues。

Cycle 回答的是「這一輪 1–2 週要完成哪些事」。它是 team 層級的時間切片，不是 project 底下的子項目——這是最常被誤解的地方。

一個 cycle 裡可以同時有：Onboarding 2026 Q2 的 5 張 issue、註冊流程簡化的 2 張 issue、再加 2 張不屬於任何 project 的 bug / maintenance issue。同一個 project 的 issues 也可以分散到多個 cycles 裡分批完成。

跟 Sprint 很像，但更輕：少一點儀式感、更偏實用節奏管理。決定哪些 issue 進 cycle 通常由 PM、team lead、engineering manager 一起判斷優先序、容量、依賴。

Issue 是 Linear 的工作原子——所有抽象目標最終都會落到一張具體的 issue 上才算數。它有 title、description、assignee、priority、labels、estimate、state，這些欄位的填寫品質直接決定團隊的執行體質。

從關係圖看，issue 是所有其他物件的會合點：它被 project 持有（也可不屬於任何 project）、被 cycle 切片排進某一輪、被 view 用 filter 查到、最終透過 project 被 initiative 間接代表。

判斷 issue 設計好不好：能不能直接被指派、能不能被估、進度推進時狀態能不能反映真實情況。如果一張票永遠填不滿、推不動，問題通常在拆得不夠細，而不是工具不好用。

很多人第一次用 Linear 會把 Project 跟 View 混掉，因為它們都能把 issue 聚在一起。差別是：Project 是容器（owns issues），View 是視角（queries issues）。

Project 持有目標、有 lead、有 target date、有狀態與文件；View 不持有任何 issue，它只是把一組 filter 條件存起來——符合條件的票會自動顯示進來，條件不再符合時就消失。

所以 「Onboarding 2026 Q2」 是 project，「我手上高優先未完成」 是 view。前者管目標，後者管觀察角度。同一張 issue 可以同時出現在無限多個 views 裡，也可以一個 view 都沒出現在裡面。