不用 Jira 也能追蹤的工程指標
不用 Jira 也能量到真正重要的指標。教你從 Git、CI 與團隊現有工具追蹤工程健康度與交付節奏。
By Chris Calo · 2026-03-23
真正能看清工程團隊狀態的小團隊，通常是那些不再追著 Jira 預設指標跑的團隊。
我知道這聽起來像在唱反調，老實說也許有一點 – 但我花了將近三年，認真維護 sprint 看板、梳理 backlog、更新那些在大家打開 Jira 之前就做了一半的工單估點。每兩週我們會坐下來開會（好啦，是 Zoom，畢竟那是 2023 年），盯著 velocity 圖看半天，結果它告訴我們的東西，我們早就從日常對話中知道了。「不用 Jira 的工程指標」不是我主動去找的做法，而是我不再假裝 velocity 圖真的有用之後，自然發生的結果。
如果你的團隊小到可以坐同一張桌子，你大概不需要 Jira 來知道團隊好不好。你需要的是從既有工具裡拿到更好的訊號。
這篇不是在說「Jira 很爛」。對需要 Jira 式追蹤的大型組織來說，它是好工具（而且到某個規模後確實需要）。但如果你是 10–40 人新創的工程主管，只為了做 velocity 圖而付費用 Jira，跟買一台工業級烤箱來熱便當差不多。
「只為了做 velocity 圖而付費用 Jira，跟買工業級烤箱來熱便當差不多。」 – Chris Calo
Jira 指標到底在量什麼
直接講白一點：多數 Jira 指標量的是 Jira 的使用行為，不是工程產出。故事點數量的是團隊估故事點數的能力。Velocity 量的是團隊能不能穩定把 sprint 填到差不多容量。燃盡圖量的是週四下午有沒有人記得把工單拖到下一欄。
這些不是完全沒用。但它們是流程指標，卻常被包裝成開發者生產力指標，而工程主管最容易失焦的地方，就在這個落差裡。
我也當過那種在利害關係人會議前花大半個小時把 Jira 資料修成投影片、只為了顯示「我們進度正常」的 EM。對方點點頭，問了一個上週二登入 bug 的問題，會議就結束了。那一小時是給投影片的。真正的答案其實是「直接問工程師」。
如果你的指標比它要衡量的工作還難維護，問題就是指標本身。
週期時間要看 Git，不是工單看板
對小型產品團隊來說，週期時間通常是訊號最強的指標。它衡量從第一個 commit 到正式上線部署的時間，你可以完全從 Git 歷史和 CI 流程推算出來 – 不需要工單看板。
組成如下：
- 分支或 PR 的首次 commit 時間戳
- PR merge 時間戳
- 部署時間戳（來自 CI/CD – GitHub Actions、CircleCI，或你正在用的系統）
第 1 到第 3 的差值就是週期時間。再切分成編碼時間（1 到 PR 開啟）、Review 時間（PR 開啟到 merge）、部署排隊時間（merge 到上線），你就得到一套診斷工具，能直接看出工作實際卡在哪裡。
我第一次幫團隊做這件事時，數字真的讓人意外。我原本以為瓶頸是 Review 時間（大家都以為是這裡，不是嗎？）。結果編碼到 PR 很順、Review 也還行，但 merge 到部署平均要多卡兩天，原因是 staging 環境不穩，而且一直沒人排優先修。Velocity 圖永遠不會把這件事凸顯出來。
怎麼量
如果你用 GitHub，可以用 CLI 拉資料：
```bash
取最近 30 天已合併 PR
gh pr list --state merged --limit 50 --json number,createdAt,mergedAt,headRefName ```
部署時間戳大多數 CI 都能透過 API 或 webhook 拿到。把 PR merge 的 SHA 對上部署事件，就能得到分階段的週期時間。
Tip： 如果你的 CI 很難乾淨吐出部署時間戳，超簡單的解法是做一個 Slack bot，把部署訊息丟到 #deploys 並附 commit SHA。你會拿到時間戳、可讀紀錄，還會順便得到一個能看出出貨頻率的頻道。
Code Review 吞吐量
Review 吞吐量 – 每位工程師每週 Review 的 PR 數量，加上 PR 開啟到首次 Review 的中位數時間 – 通常比任何 sprint 指標更能反映團隊健康。這個指標被嚴重低估了。
為什麼？因為 Review 行為是領先指標。當 Review 時間開始拉長，通常代表工程師過載、情境切換太頻繁，或（比較尷尬但很常見）大家在迴避彼此的程式碼。這些都值得在它變成兩週後的延遲交付之前就先看到。
GitHub API 有這些資料。關鍵欄位是 PR 的 createdAt，以及第一個 Review 事件的 submittedAt。
我最常看的數字是首次 Review 的中位數小時數。以我們在幾個小團隊的經驗，健康節奏通常低於 8 小時。當它穩定超過 1 天，通常就是結構性問題變了 – 而這在 Jira 裡幾乎看不到。
會議對決策比
這不是傳統工程指標，先說清楚：它是粗略的經驗法則，不是 KPI。但對小團隊來說，我覺得它意外地有用。
先算這週團隊開了幾場會。再算這些會議產出幾個具體決策（不是「我們再研究看看 X」，而是有 owner 和下一步的明確決策）。後者除以前者。
如果不到一半的會議產出決策，就值得問這些會議是否真的有回收價值。有些會議是為了降風險或同步脈絡，這很合理 – 不是每場都要當場定案。但你只要開始追這個數字，即使很輕量（我當時就是拿筆記本畫正字），很快就會有感哪些會議在推進事情，哪些只是沒人質疑過的儀式。
我大概追了一個月，對排會方式的影響比任何生產力文章都大。當你清楚看到週一 standup 連三週零決策，取消它就不再是激進作法。
不靠 Jira 建工程指標：一個輕量儀表板
你不需要 BI 工具。Notion 頁面、Google Sheet，或每週一則 Slack 貼文加四個數字就夠：
- 週期時間中位數（來自 Git/CI）– 我們出貨變快還是變慢？
- 首次 Review 時間中位數（來自 GitHub）– 團隊 Review 是否即時？
- 部署頻率（來自 CI 或 #deploys）– 我們多久出貨一次？
- 會議對決策比（手動記錄）– 會議有沒有真正創造價值？
四個數字，全都能從現有工具推算出來，不需要維護 Jira 看板。每週更新一次。若某個數字連續兩週往壞方向走，就去查原因。若維持穩定，就先別動。
重點不是打造監控系統（拜託不要 – 工程師一定會不爽，而且他們是對的）。工程團隊可見度應該來自工作本身，不是靠要求大家額外回報工作。 That’s the principle behind a single view of what the team is doing: the signals already exist in your tools, and how managers see team progress without asking for status reports is really about connecting those signals, as is task visibility across Linear, GitHub, Slack, and Notion.
最好的工程指標要便宜好收集、不易被操弄、而且能導向可執行行動。故事點數三項都沒過。
什麼時候你真的需要工單看板
我前面說這不是「Jira 很爛」文，我是認真的。有些情境下，不用專案管理工具來追蹤指標，確實會變成不負責任：
- 高度合規產業，任務狀態的稽核軌跡是法規要求
- 較大型工程組織，跨團隊相依讓非正式協調不可行
- 有專職專案管理職能的組織，需要跨團隊一致的單一事實來源
如果你是這種情境，Jira（或 Linear、Shortcut）就是對的選擇。我的論點是，對小團隊來說，只為了指標而維護重量級工具通常是爛交易。你最後優化的是工具的工作模型，不是團隊的真實工作。
而且老實說，就算團隊用了 Jira，也很適合補上前面那套 Git 衍生指標。Jira 告訴你人們說自己在做什麼。Git 告訴你人們實際做了什麼。兩者都有用，但只有一個不受狀態更新表演影響。
如果你們新創最近一直被問工程指標，試著把這個四數字儀表板跑一個月。聽起來「不用 Jira 的工程指標」像少了安全網，但當你看到 Git 歷史和 CI 流程裡其實有這麼多訊號，你會開始懷疑工單看板到底多加了什麼。
自動浮現週期時間、停滯的 PR 與 Review 瓶頸 – 不用自訂腳本，也不用 Jira 看板。
Q: 沒有專案管理工具也能拿到有意義的工程指標嗎？ A: 可以。週期時間（第一個 commit 到部署）、Review 吞吐量、部署頻率都在 Git 歷史和 CI 流程裡。對 40 人以下的團隊來說，這些指標通常更有訊號、更不容易被操弄，而且不需要任何人為了維持準確性去拖工單卡片。
Q: Sugarbug 會自動呈現工程指標嗎？ A: Sugarbug 會連接 GitHub、Linear、Slack 和行事曆，建立團隊活動的知識圖譜。它會標記停滯的 PR、Review 瓶頸、以及沒有收斂的決策等模式，涵蓋本文多數訊號，不需要你去寫和維護 GitHub API 腳本。
Q: 要怎麼說服團隊不要再用 Jira 來看指標？ A: 把它包裝成實驗，不是革命。先把 Git 衍生指標和既有 Jira 儀表板並行 4 週，再比較哪些數字真的促成變化。若 Git 指標更可執行（以我們經驗通常是），答案會自己出來。
Q: 流程指標和績效指標有什麼不同？ A: 流程指標（故事點數、velocity、燃盡圖）衡量團隊遵循工作流程的一致性。績效指標（週期時間、部署頻率、Review 吞吐量）衡量團隊實際交付了什麼、速度如何。小團隊幾乎都能從後者拿到更多訊號，因為它來自工作本身，不靠手動狀態更新。