Đo lường kỹ thuật không cần Jira
Bạn không cần Jira để đo những gì quan trọng. Cách theo dõi sức khỏe kỹ thuật từ Git, CI và các công cụ nhóm đã dùng.
By Ellis Keane · 2026-03-23
Các nhóm nhỏ có khả năng quan sát kỹ thuật tốt nhất thường là những nhóm đã ngừng chạy theo các chỉ số mà Jira muốn họ theo dõi.
Tôi biết điều đó nghe có vẻ như tôi đang cố tình phản bác, và thành thật mà nói, có thể một chút như vậy – nhưng tôi đã dành phần lớn ba năm để tận tâm duy trì sprint board, groom backlog và cập nhật ước tính cho những ticket đã làm được một nửa trước khi ai đó mở Jira sáng hôm đó. Cứ hai tuần, chúng tôi lại ngồi trong phòng (thực ra là Zoom – đó là năm 2023) và nhìn chằm chằm vào biểu đồ velocity không cho biết điều gì mà chúng tôi chưa biết từ việc nói chuyện với nhau. Chỉ số kỹ thuật không cần Jira không phải là thứ tôi tìm kiếm. Nó xảy ra khi tôi ngừng giả vờ rằng biểu đồ velocity đang nói với tôi điều gì hữu ích.
Nếu nhóm của bạn đủ nhỏ để ngồi quanh một bàn, bạn có thể không cần Jira để biết mình đang làm thế nào. Bạn cần những tín hiệu tốt hơn từ các công cụ mà bạn đã dùng.
Đây không phải bài viết "Jira tệ". Jira là một công cụ tốt cho các tổ chức cần theo dõi theo kiểu Jira (và ở một quy mô nhất định, họ thực sự cần). Nhưng nếu bạn là engineering manager tại một startup 10–40 người, trả tiền cho Jira chỉ để tạo biểu đồ velocity thì giống như mua lò công nghiệp để hâm nóng bữa trưa.
"Trả tiền cho Jira chỉ để tạo biểu đồ velocity giống như mua lò công nghiệp để hâm nóng bữa trưa." attribution: Chris Calo
Các chỉ số Jira thực sự đo điều gì
Nói thẳng: hầu hết các chỉ số Jira đo lường việc sử dụng Jira, không phải sản lượng kỹ thuật. Story points đo khả năng ước tính story points của nhóm. Velocity đo mức độ nhất quán của nhóm trong việc lấp đầy sprint với cùng một dung lượng. Burndown chart đo xem ai đó có nhớ kéo ticket qua bảng vào chiều thứ Năm không.
Không có gì trong số này là hoàn toàn vô dụng. Nhưng tất cả đều là chỉ số quy trình được ngụy trang thành chỉ số năng suất lập trình viên, và khoảng cách giữa hai loại là nơi engineering manager đánh mất phương hướng.
Tôi đã từng là EM dành gần một tiếng trước cuộc họp với stakeholder để nhào nặn dữ liệu Jira thành slide deck cho thấy "chúng ta đang đúng tiến độ". Stakeholder gật đầu, hỏi một câu về bug đăng nhập từ thứ Ba tuần trước, rồi cuộc họp kết thúc. Cái giờ đó là cho slide deck. Câu trả lời thực sự là "hỏi kỹ sư".
Nếu các chỉ số của bạn cần bảo trì nhiều hơn công việc chúng đo lường, thì chỉ số mới là vấn đề.
Cycle time từ Git, không phải từ bảng ticket
Với các nhóm sản phẩm nhỏ, cycle time thường là chỉ số có tín hiệu cao nhất mà bạn có thể theo dõi. Nó đo khoảng thời gian từ commit đầu tiên đến deploy lên production, và bạn có thể suy ra hoàn toàn từ lịch sử Git và CI pipeline – không cần bảng ticket.
Các thành phần:
- Dấu thời gian của commit đầu tiên trên branch hoặc PR
- Dấu thời gian merge PR
- Dấu thời gian deploy (từ CI/CD – GitHub Actions, CircleCI hoặc bất cứ thứ gì bạn đang dùng)
Khoảng chênh lệch giữa 1 và 3 là cycle time của bạn. Chia thành các phân đoạn – thời gian viết code (từ 1 đến lúc mở PR), thời gian review (từ lúc mở PR đến merge) và hàng chờ deploy (từ merge đến production) – và bạn có một bản chẩn đoán cho biết công việc thực sự bị đình trệ ở đâu.
Khi tôi làm điều này lần đầu cho nhóm của mình, các con số thực sự đáng ngạc nhiên. Tôi đã giả định rằng thời gian review là điểm nghẽn của chúng tôi (ai cũng luôn giả định như vậy phải không?). Hóa ra giai đoạn coding-to-PR của chúng tôi ổn, review cũng ổn, và chúng tôi mất trung bình khoảng hai ngày giữa merge và deploy vì môi trường staging không ổn định và không ai ưu tiên sửa nó. Một biểu đồ velocity không bao giờ có thể phát hiện ra điều đó.
Cách đo
Nếu bạn dùng GitHub, bạn có thể kéo dữ liệu này bằng CLI:
```bash
Get merged PRs for the last 30 days
gh pr list – state merged – limit 50 – json number,createdAt,mergedAt,headRefName ```
Với dấu thời gian deploy, hầu hết hệ thống CI đều cung cấp qua API hoặc webhook. Ánh xạ SHA merge của PR với các sự kiện deploy, và bạn có cycle time được phân đoạn theo từng giai đoạn.
Mẹo: Nếu CI của bạn không cung cấp dấu thời gian deploy rõ ràng, một cách đơn giản nhất là Slack bot đăng lên kênh #deploys với commit SHA. Bạn nhận được dấu thời gian, nhật ký dễ đọc và – như một hiệu ứng phụ – một kênh cho bạn biết bạn ship thường xuyên thế nào.
Thông lượng code review
Review throughput – số PR được review theo kỹ sư mỗi tuần và thời gian trung vị từ lúc mở PR đến lần review đầu tiên – cho bạn biết nhiều hơn về sức khỏe nhóm so với bất kỳ chỉ số sprint nào. Nó bị đánh giá thấp.
Tại sao? Vì hành vi review là một chỉ số dẫn trước. Khi thời gian review tăng lên, thường có nghĩa là kỹ sư đang bị quá tải, chuyển đổi ngữ cảnh quá nhiều, hoặc (và đây là điều không thoải mái) tránh code của nhau. Bất kỳ điều nào trong số đó đều đáng biết trước khi nó xuất hiện như một deadline bị bỏ lỡ hai tuần sau.
GitHub cung cấp dữ liệu này qua API. Các trường quan trọng là createdAt trên PR và submittedAt trên sự kiện review đầu tiên.
Con số tôi theo dõi là số giờ trung vị đến lần review đầu tiên. Theo kinh nghiệm của chúng tôi ở một số nhóm nhỏ, nhịp review lành mạnh thường dưới khoảng 8 giờ. Khi nó liên tục vượt quá một ngày, điều gì đó về mặt cấu trúc đã thay đổi – và dù đó là gì, nó vô hình trong Jira.
Tỷ lệ họp trên quyết định
Đây không phải chỉ số kỹ thuật truyền thống, và tôi nên thẳng thắn: đây là heuristic thô, không phải KPI. Nhưng với các nhóm nhỏ, tôi thấy nó tiết lộ nhiều điều đáng ngạc nhiên.
Đếm số cuộc họp nhóm của bạn tuần này. Đếm các quyết định cụ thể được đưa ra từ đó (không phải "chúng ta nên xem xét X" – quyết định thực sự với người chịu trách nhiệm và bước tiếp theo). Chia cái sau cho cái trước.
Nếu ít hơn một nửa cuộc họp của bạn tạo ra một quyết định, đáng hỏi liệu những cuộc họp đó có xứng đáng với thời gian của chúng không. Một số cuộc họp tồn tại để giảm rủi ro hoặc chia sẻ ngữ cảnh, và điều đó hợp lý – không phải mọi thứ đều cần kết thúc bằng một nghị quyết. Nhưng khi bạn bắt đầu theo dõi điều này dù không chính thức (tôi thực sự giữ bảng đếm trong sổ tay), bạn sẽ phát triển cảm giác về cuộc họp nào có tính xây dựng và cuộc họp nào chỉ là nghi lễ chưa ai đặt câu hỏi.
Tôi đã theo dõi điều này trong khoảng một tháng, và nó thay đổi cách tôi lên lịch họp nhiều hơn bất kỳ bài viết năng suất nào từng làm. Khi bạn thấy rằng standup thứ Hai của mình chưa tạo ra một quyết định nào trong ba tuần liên tiếp, việc huỷ nó không còn cảm thấy cực đoan nữa.
Xây dựng chỉ số kỹ thuật không cần Jira: dashboard nhẹ
Bạn không cần công cụ BI cho điều này. Một trang Notion, một Google Sheet, hoặc một bài đăng Slack hàng tuần với bốn con số là đủ:
- Cycle time trung vị (từ Git/CI) – chúng ta đang ship nhanh hơn hay chậm hơn?
- Thời gian trung vị đến review đầu tiên (từ GitHub) – nhóm có review kịp thời không?
- Deploy frequency (từ CI hoặc kênh #deploys) – chúng ta ship thường xuyên thế nào?
- Tỷ lệ họp trên quyết định (đếm thủ công) – các cuộc họp có xứng đáng không?
Bốn con số, tất cả có thể suy ra từ các công cụ bạn đã có, không cái nào yêu cầu duy trì bảng Jira. Cập nhật hàng tuần. Nếu một con số di chuyển theo hướng sai trong hai tuần liên tiếp, hãy điều tra. Nếu nó ổn định, hãy để yên.
Vấn đề không phải là xây dựng hệ thống giám sát (xin đừng – các kỹ sư của bạn sẽ ghét bạn và họ có lý do chính đáng). Khả năng quan sát nhóm kỹ thuật nên đến từ bản thân công việc, không phải từ việc yêu cầu mọi người báo cáo về công việc.
Các chỉ số kỹ thuật tốt nhất rẻ để thu thập, khó làm giả và cho bạn biết điều gì đó có thể hành động. Story points thất bại ở cả ba tiêu chí.
Khi nào bạn thực sự cần bảng ticket
Tôi đã nói đây không phải bài viết "Jira tệ" và tôi có ý đó. Có những tình huống hợp lệ khi theo dõi chỉ số mà không có công cụ quản lý dự án trở nên thực sự vô trách nhiệm:
- Các ngành có yêu cầu tuân thủ cao nơi audit trail về trạng thái nhiệm vụ được yêu cầu theo pháp luật
- Các tổ chức kỹ thuật lớn hơn nơi các phụ thuộc liên nhóm khiến việc phối hợp không chính thức không khả thi
- Các tổ chức có chức năng quản lý dự án chuyên biệt cần nguồn sự thật chính thức giữa các nhóm
Nếu đó là tình huống của bạn, Jira (hoặc Linear, hoặc Shortcut) là lựa chọn đúng. Điều tôi lập luận là với các nhóm nhỏ, duy trì một công cụ nặng chỉ để lấy chỉ số là một sự đánh đổi tồi. Bạn sẽ kết thúc bằng việc tối ưu hóa cho mô hình công việc của công cụ thay vì công việc thực tế của nhóm.
Và thành thật mà nói? Ngay cả các nhóm dùng Jira cũng sẽ được lợi từ việc bổ sung dữ liệu bảng với các chỉ số từ Git ở trên. Jira cho bạn biết mọi người nói họ đang làm gì. Git cho bạn biết họ thực sự đang làm gì. Cả hai đều hữu ích, nhưng chỉ có một cái miễn nhiễm với màn kịch cập nhật trạng thái.
Nếu câu hỏi về chỉ số cứ xuất hiện tại startup của bạn, hãy thử dashboard bốn con số trong một tháng. Chỉ số kỹ thuật không cần Jira có thể nghe như đi mà không có lưới an toàn – nhưng khi bạn thấy bao nhiêu tín hiệu sống trong lịch sử Git và CI pipeline, bạn sẽ tự hỏi bảng ticket đã thêm vào điều gì.
Tự động hiển thị cycle time, PR bị đình trệ và điểm nghẽn review – không cần script tùy chỉnh hay bảng Jira.
Q: Bạn có thể thu thập các chỉ số kỹ thuật có ý nghĩa mà không cần công cụ quản lý dự án không? A: Có. Cycle time (từ commit đầu tiên đến deploy), review throughput và deploy frequency đều nằm trong lịch sử Git và CI pipeline của bạn. Với các nhóm dưới khoảng 40 kỹ sư, những chỉ số này thường sắc nét hơn và khó làm giả hơn so với bất cứ thứ gì từ bảng ticket – và không yêu cầu ai kéo thẻ qua bảng để duy trì độ chính xác.
Q: Sugarbug có tự động hiển thị các chỉ số kỹ thuật không? A: Sugarbug kết nối với GitHub, Linear, Slack và lịch để xây dựng đồ thị tri thức về hoạt động của nhóm. Nó đánh dấu các mẫu như PR bị đình trệ, điểm nghẽn review và các quyết định chưa được giải quyết – bao gồm nhiều tín hiệu được mô tả ở đây mà không yêu cầu bạn viết và duy trì script tùy chỉnh với GitHub API.
Q: Làm thế nào để được chấp thuận ngừng dùng Jira cho các chỉ số? A: Trình bày như một thử nghiệm, không phải sự nổi loạn. Chạy các chỉ số từ Git song song với dashboard Jira hiện có trong bốn tuần, rồi so sánh những con số nào thúc đẩy thay đổi thực sự. Nếu các chỉ số Git chứng minh có thể hành động được hơn (và theo kinh nghiệm của chúng tôi, chúng thường như vậy), trường hợp này tự chứng minh.
Q: Sự khác biệt giữa chỉ số quy trình và chỉ số hiệu suất là gì? A: Chỉ số quy trình (story points, velocity, burndown) đo mức độ nhất quán của nhóm trong việc tuân theo quy trình. Chỉ số hiệu suất (cycle time, deploy frequency, review throughput) đo những gì nhóm thực sự chuyển giao và nhanh như thế nào. Các nhóm nhỏ hầu như luôn nhận được nhiều tín hiệu hơn từ loại sau, vì các chỉ số hiệu suất được suy ra từ bản thân công việc chứ không phải từ các cập nhật trạng thái thủ công.