Bài 30 — OKR Tracking trong Jira — Jira and Agile Tools Mastery

Mở đầu — vì sao bài này quan trọng

Hầu hết đội ngũ sản phẩm đều gặp một nghịch lý quen thuộc: OKR (Objectives and Key Results) được viết rất hùng hồn trong buổi kickoff đầu quý, dán lên một slide đẹp đẽ, rồi... nằm im trong Google Slides cho tới buổi review cuối quý mới có người mở ra xem lại. Trong khi đó, 100% công việc thực tế của team lại chạy trong Jira. Kết quả là bạn có hai thế giới song song không nói chuyện với nhau: một thế giới "chiến lược" (OKR) và một thế giới "thực thi" (backlog, sprint, epic). Khi sếp hỏi "Objective tăng trưởng retention đang đi tới đâu rồi?", PM phải hì hục mở 5 tab, tổng hợp thủ công, và câu trả lời thường là một con số phỏng đoán.

Bài này giải quyết đúng khoảng trống đó: làm sao để OKR không còn là tài liệu chết, mà là thứ được cập nhật tự động từ chính công việc team đang làm trong Jira. Khi bạn kết nối được Key Result với các epic/story cụ thể, mỗi lần một issue chuyển sang Done thì tiến độ OKR nhích lên theo — không cần ai ngồi gõ tay báo cáo nữa. Đây là kỹ năng phân biệt một PM "quản lý task" với một PM "dẫn dắt kết quả". Với PM ở thị trường Việt Nam, nơi ban lãnh đạo ngày càng đòi hỏi minh bạch số liệu và OKR đã phổ biến ở các công ty như MoMo, VNG, Tiki, Base.vn, thì đây là năng lực rất thực tế để ghi điểm.

Khái niệm cốt lõi

Trước khi bàn công cụ, cần nắm lại nhanh cấu trúc OKR để ánh xạ đúng vào Jira:

Objective: mục tiêu định tính, truyền cảm hứng, trả lời câu hỏi "Chúng ta muốn đạt điều gì?". Ví dụ: "Trở thành ứng dụng thanh toán được người dùng trẻ tin dùng nhất".
Key Result (KR): 2–4 kết quả đo lường được cho mỗi Objective, trả lời "Làm sao biết ta đã đạt?". Ví dụ: "Tăng retention D30 từ 22% lên 35%".
Initiative / công việc: các dự án, epic, story mà team thực sự làm để tác động lên KR.

Vấn đề mấu chốt của OKR trong Jira là ánh xạ ba tầng này: Objective và KR là cấp chiến lược (thường vượt ra ngoài một team, kéo dài cả quý), còn epic/story/task là cấp thực thi (nằm gọn trong Jira). Có ba nhóm cách tiếp cận để nối chúng lại, và bạn cần chọn đúng theo quy mô tổ chức.

Pattern 1 — Native: dùng custom field "OKR Link" trên epic

Đây là cách nhẹ nhất, không tốn tiền plugin, phù hợp team nhỏ tới trung. Bạn tạo một custom field (thường là kiểu Labels, Select list, hoặc Short text) đặt tên "OKR Link" hoặc "Key Result", rồi gắn nó vào issue type Epic. Mỗi epic khi được tạo sẽ được gán vào đúng KR mà nó phục vụ. Sau đó dùng JQL và dashboard để tổng hợp tiến độ theo từng KR.

Ưu điểm: miễn phí, kiểm soát hoàn toàn, dễ báo cáo bằng JQL ("Key Result" = "KR1-Retention"). Nhược điểm: Jira không hiểu "OKR là gì" — nó chỉ thấy một cái nhãn. Bạn phải tự tính % tiến độ, tự cập nhật giá trị hiện tại của KR (ví dụ retention đang là bao nhiêu), vì con số đó thường nằm ở hệ thống analytics chứ không phải Jira.

Pattern 2 — Plugin: OKR Board for Jira, hoặc Atlassian Goals

Khi tổ chức lớn hơn và cần OKR có "hình hài" thật sự (có tiến độ %, có trạng thái on-track/at-risk/off-track, có cây phân cấp Objective → KR), bạn dùng công cụ chuyên dụng:

Atlassian Goals (tính năng gốc của Atlassian, có trong gói Premium/Enterprise của Jira Cloud và Atlassian Home): cho phép tạo Goal, gắn Goal vào epic/project ngay trong Jira. Đây là hướng "chính chủ", tích hợp mượt nhất với hệ sinh thái Atlassian và đang được đầu tư mạnh.
Marketplace apps như OKR Board for Jira, Okera, Oboard: cài từ Atlassian Marketplace, cung cấp giao diện OKR riêng, tự tính rollup tiến độ từ các issue được link, có dashboard trực quan. Chi phí thường tính theo số user/tháng.

Ưu điểm: tiết kiệm thời gian vận hành, tiến độ tự động rollup, báo cáo đẹp cho lãnh đạo. Nhược điểm: tốn phí, và nếu chọn app bên thứ ba thì phải cân nhắc rủi ro vendor (bài 58 sẽ bàn kỹ về đánh giá app marketplace).

Pattern 3 — External: Tability (và các nền tảng OKR chuyên biệt)

Khi OKR là văn hóa toàn công ty, vượt xa phạm vi đội kỹ thuật (marketing, sales, vận hành cũng dùng OKR), người ta thường dùng một nền tảng OKR chuyên biệt như Tability, Weekdone, Perdoo hay Gtmhub, rồi tích hợp một chiều với Jira: Tability tự kéo dữ liệu tiến độ epic từ Jira về để cập nhật KR. Nghĩa là OKR sống ở Tability, còn Jira là nguồn "bằng chứng công việc".

Ưu điểm: OKR liên phòng ban thống nhất một chỗ, có check-in định kỳ, nhắc nhở, phân tích xu hướng. Nhược điểm: thêm một công cụ nữa để team học và duy trì; dữ liệu bị tách khỏi nơi làm việc hằng ngày của dev.

Nguyên tắc chọn pattern

Tôi thường tư vấn theo quy mô: dưới ~30 người và OKR chủ yếu quanh sản phẩm → Native. Từ 30–200 người, nhiều team cùng dùng Jira → Atlassian Goals hoặc plugin. Trên 200 người, OKR là văn hóa toàn công ty → external như Tability. Đừng chọn công cụ nặng hơn nhu cầu — đó là lỗi phổ biến nhất.

Tình huống thực tế

Ví dụ 1 — Startup fintech ở TP.HCM: bắt đầu từ Native

FinToday, một startup ví điện tử giả định ~25 người ở Quận 1, có một Objective quý: "Biến FinToday thành ví hằng ngày của sinh viên". KR gồm: KR1 – tăng transaction/user/tháng từ 3,2 lên 6; KR2 – tăng retention D30 từ 22% lên 35%; KR3 – ra mắt 3 tính năng chia tiền nhóm.

PM không có ngân sách plugin, nên chọn Native. Anh tạo custom field Select list tên "Key Result" với 3 giá trị KR1/KR2/KR3, gắn vào Epic. Mỗi epic được map: epic "Ví chia tiền nhóm" → KR3, epic "Cải thiện onboarding" → KR2. Trên dashboard, anh tạo 3 gadget Progress bar theo JQL cho từng KR, hiển thị % epic đã Done. Riêng con số retention thực tế (22% → hiện tại) thì mỗi thứ Sáu anh cập nhật thủ công vào một trang Confluence gắn kèm.

Bài học: Native đủ dùng và tốn 0 đồng, nhưng nó chỉ cho biết "công việc đã làm xong bao nhiêu", không tự biết "chỉ số kinh doanh đã dịch chuyển chưa". PM phải kỷ luật cập nhật giá trị KR thật từ analytics — nếu không, dashboard sẽ báo "80% done" trong khi retention vẫn giậm chân, tạo cảm giác an toàn giả.

Ví dụ 2 — Scale-up thương mại điện tử: chuyển sang Atlassian Goals

Một scale-up e-commerce ở Hà Nội, ~120 người, 6 squad cùng dùng Jira. Trước đây mỗi squad tự quản OKR trong file riêng, tới cuối quý CPO phải gom báo cáo từ 6 nguồn khác nhau — mất gần 2 ngày và số liệu hay lệch. Họ nâng lên Jira Premium và triển khai Atlassian Goals.

Giờ đây mỗi Goal ("Giảm tỷ lệ hủy đơn từ 18% xuống 10%") được tạo một lần, gắn với các epic của cả squad Logistics lẫn squad Payment. Khi các epic con hoàn thành, tiến độ Goal tự cập nhật; trạng thái tự chuyển màu on-track/at-risk dựa trên check-in hằng tuần. CPO mở một view duy nhất thấy toàn cảnh 6 squad.

Bài học: khi số team và số người tăng, chi phí vận hành thủ công của Native vượt xa chi phí license của giải pháp gốc. Điểm chuyển đổi thường rơi vào lúc bạn có nhiều hơn 3–4 team cùng chạm vào một Objective. Ngoài ra, việc dùng công cụ gốc của Atlassian giúp tránh rủi ro phụ thuộc app bên thứ ba.

Ví dụ 3 — Công ty công nghệ ~300 người: OKR toàn công ty với Tability

Một công ty SaaS Đông Nam Á (giả định, trụ sở Singapore, R&D ở Việt Nam) ~300 người, OKR áp dụng cho cả Sales, Marketing, CS lẫn Engineering. Nếu ép tất cả vào Jira thì các phòng phi kỹ thuật sẽ khổ. Họ dùng Tability làm "ngôi nhà OKR" toàn công ty, và bật tích hợp Tability–Jira: mỗi KR kỹ thuật được nối tới một JQL filter hoặc epic, Tability tự kéo % hoàn thành về cập nhật KR mỗi ngày.

Kết quả: CEO thấy toàn bộ cây OKR công ty ở Tability; đội engineering vẫn làm việc thuần trong Jira mà không phải update OKR hai lần. Check-in tự động nhắc mỗi thứ Hai.

Bài học: ở quy mô liên phòng ban, "nơi sống của OKR" nên trung lập với công cụ của từng phòng. Jira lúc này đóng vai nguồn dữ liệu, không phải nơi hiển thị OKR. Nhưng đổi lại, bạn phải chấp nhận một tích hợp cần bảo trì và một công cụ nữa để onboard người mới.

Hướng dẫn từng bước

Dưới đây là quy trình triển khai theo Pattern Native (nền tảng nhất, và ai cũng nên biết trước khi lên plugin):

Chốt cấu trúc OKR trước, đừng đụng Jira vội. Viết ra 1–3 Objective và 2–4 KR mỗi Objective trong Confluence hoặc Google Doc. Mỗi KR phải có: giá trị nền (baseline), giá trị mục tiêu (target), đơn vị đo. Nếu KR không đo được, đừng đưa vào Jira.

Tạo custom field. Vào Settings → Issues → Custom fields → Create custom field. Chọn kiểu Select List (single choice) nếu mỗi epic phục vụ đúng 1 KR, hoặc Labels nếu một epic có thể chạm nhiều KR. Đặt tên rõ ràng, ví dụ "Key Result (Q2)".

Gắn field vào screen của Epic. Trong Screen configuration, thêm field vừa tạo vào màn hình Create/Edit/View của issue type Epic. Nên giới hạn field này chỉ ở cấp Epic để tránh nhiễu ở cấp story.

Map từng epic vào KR. Rà soát backlog epic hiện có, gán mỗi epic vào đúng KR. Epic nào không phục vụ KR nào thì đánh dấu "BAU" (business as usual) hoặc "Tech debt" — chính việc này giúp lộ ra bạn đang tiêu bao nhiêu năng lực cho việc không thúc đẩy mục tiêu.

Xây JQL nền tảng. Ví dụ: "Key Result (Q2)" = "KR2-Retention" để lấy toàn bộ epic của KR2; thêm AND statusCategory = Done để đếm epic đã xong.

Dựng dashboard. Tạo dashboard "OKR Q2", thêm gadget Progress Bar / Pie Chart / Two Dimensional Filter Statistics cho từng KR để hiện tỷ lệ epic Done trên tổng.

Thiết lập nhịp cập nhật KR thật. Đây là bước hay bị bỏ. Chỉ định người sở hữu mỗi KR (KR owner) và một cadence check-in cố định (thường thứ Sáu hằng tuần) để cập nhật giá trị chỉ số thực từ analytics — vì Jira chỉ biết công việc, không biết chỉ số kinh doanh.

Review nhịp đôi. Trong sprint review hoặc buổi OKR check-in tuần, đối chiếu hai con số: % công việc đã xong (từ Jira) và % KR thực tế đã đạt (từ analytics). Khoảng chênh giữa hai con số này chính là tín hiệu quý giá nhất.

Nếu sau vài quý bạn thấy bước 7–8 quá thủ công và team đã đông, đó là lúc nâng cấp lên Atlassian Goals hoặc Tability.

Lỗi thường gặp & mẹo

Nhầm "công việc xong" với "KR đạt". Đây là cạm bẫy chết người. Hoàn thành 100% epic không có nghĩa retention đã tăng. Luôn tách bạch output (Jira) và outcome (chỉ số). Dashboard Jira chỉ nói bạn đã làm xong, không nói bạn đã thắng.
Gán KR vào cấp story thay vì epic. Sẽ tạo hàng trăm điểm gắn nhãn, rối và khó bảo trì. Giữ mối liên kết OKR ở cấp Epic, để story kế thừa ngữ cảnh từ epic cha.
Đặt quá nhiều KR. Mỗi Objective quá 4 KR sẽ khiến team mất tập trung và dashboard thành mê cung. Ít mà sâu.
Chọn plugin nặng khi team còn nhỏ. Trả tiền cho OKR platform khi mới 15 người là lãng phí. Bắt đầu Native, nâng cấp khi nỗi đau vận hành thủ công thực sự xuất hiện.
Không có KR owner. OKR "của tất cả mọi người" là OKR của không ai. Mỗi KR cần một cái tên chịu trách nhiệm cập nhật và giải trình.
Mẹo — dùng Automation. Với Jira Automation (bài 21), bạn có thể tự động gửi cảnh báo Slack khi một epic thuộc KR quan trọng bị chuyển sang "Blocked", để KR owner phản ứng sớm.
Mẹo — link hai chiều bằng Confluence. Nhúng dashboard Jira vào trang OKR Confluence để lãnh đạo có một "single source of truth" gồm cả câu chuyện chiến lược lẫn số liệu thực thi.

Bài tập thực hành

Thiết kế OKR của chính bạn. Chọn một sản phẩm bạn đang/đã làm. Viết 1 Objective và 3 KR đo lường được (có baseline, target, đơn vị). Ghi rõ đâu là output, đâu là outcome.

Dựng Native trong Jira. Trên một Jira Cloud dùng thử miễn phí, tạo custom field "Key Result", gắn vào Epic, tạo 5–6 epic mẫu và map vào 3 KR. Viết 3 câu JQL: (a) tất cả epic của KR1, (b) epic đã Done của KR1, (c) epic chưa gán KR nào.

Xây dashboard. Tạo dashboard hiển thị tiến độ 3 KR bằng gadget Progress Bar hoặc Pie Chart. Chụp lại và tự đánh giá: nhìn dashboard này, lãnh đạo có trả lời được "chúng ta đang đi đúng hướng không?" không.

Quyết định nâng cấp. Viết một đoạn ngắn (5–7 câu) lập luận: với đội của bạn hiện tại, nên ở Native, hay chuyển sang Atlassian Goals, hay dùng Tability? Nêu điểm chuyển đổi cụ thể (số team, số người, phạm vi phòng ban).

Tóm tắt

OKR chỉ tạo ra giá trị khi nó gắn với công việc thực và được cập nhật thường xuyên — và Jira chính là nơi công việc thực đang diễn ra. Có ba pattern để nối OKR với Jira: Native (custom field "OKR Link"/"Key Result" trên epic — miễn phí, phù hợp team nhỏ), Plugin (Atlassian Goals hoặc app marketplace như OKR Board for Jira — tự động rollup, phù hợp nhiều team), và External (Tability và tương tự — OKR toàn công ty, Jira làm nguồn dữ liệu). Chọn pattern theo quy mô, đừng chọn thứ nặng hơn nhu cầu.

Điều quan trọng nhất cần khắc cốt: Jira cho bạn biết công việc đã xong bao nhiêu (output), nhưng KR đo lường kết quả kinh doanh thực (outcome) — hai thứ này không tự động bằng nhau. Một PM giỏi luôn theo dõi cả hai và đọc kỹ khoảng chênh giữa chúng. Hãy bắt đầu đơn giản với Native, thiết lập nhịp check-in kỷ luật với KR owner rõ ràng, và chỉ nâng cấp công cụ khi nỗi đau vận hành thực sự đủ lớn để đáng đầu tư.