Mở đầu — vì sao bài này quan trọng
Có một cám dỗ rất lớn với bất kỳ PM (Product/Project Manager) nào khi Jira nằm trong tay: dữ liệu đã có sẵn, đẹp đẽ, có thể xuất báo cáo trong ba nốt nhạc. Khi tới kỳ đánh giá hiệu suất (performance review), sếp hỏi "team em quý này làm việc thế nào?", và bạn — với hàng tá biểu đồ velocity, số story đã done, số giờ log — cảm thấy mình đang cầm trong tay bằng chứng khách quan để "chấm điểm" từng người.
Đây chính là cái bẫy nguy hiểm nhất mà nghề này giăng ra. Dữ liệu công cụ (tool data) trông giống như thước đo hiệu suất, nhưng nó KHÔNG PHẢI. Khi bạn dùng velocity để so sánh hai kỹ sư, dùng số story point để xếp hạng, dùng số giờ log để đánh giá độ chăm chỉ, bạn không chỉ đo sai — bạn còn phá vỡ chính hệ thống dữ liệu đó. Vì con người thông minh: một khi họ biết con số nào bị dùng để đánh giá mình, họ sẽ tối ưu để làm đẹp con số đó, chứ không phải để tạo giá trị thật.
Bài này giúp bạn hiểu ranh giới giữa "dữ liệu để cải thiện quy trình" và "dữ liệu để đánh giá con người" — và cách dùng Jira đúng đắn trong bối cảnh performance review mà không biến team thành những người chơi trò lách số.
Khái niệm cốt lõi
Vì sao tool data không phải là thước đo hiệu suất
Hãy đi qua từng metric phổ biến để hiểu vì sao chúng sụp đổ khi bị ép làm KPI cá nhân.
Velocity ≠ năng suất. Velocity là tổng story point mà cả team hoàn thành trong một sprint. Nó được sinh ra để team tự dự báo khối lượng công việc cho sprint sau — một công cụ lập kế hoạch, không phải công cụ đo người. Velocity là chỉ số của TEAM, không thể chia nhỏ cho từng cá nhân. Một team có velocity 40 không giỏi gấp đôi team có velocity 20, vì story point là đơn vị tương đối, mỗi team ước lượng theo thang riêng của mình. So sánh velocity giữa hai team giống như so sánh nhiệt độ đo bằng độ C của người này với độ F của người kia.
Số story ≠ đóng góp. Một kỹ sư đóng 15 story nhỏ về sửa nút bấm có "đóng góp" nhiều hơn người đóng 2 story về thiết kế lại kiến trúc thanh toán không? Đếm số ticket thưởng cho việc chia nhỏ công việc và trừng phạt việc gánh vác những vấn đề khó, phức tạp, khó chia. Nó cũng bỏ quên hoàn toàn những đóng góp không sinh ra ticket: giúp đồng đội gỡ bug, review code kỹ, mentor người mới, tham gia thiết kế giải pháp.
Thời gian log (time tracked) ≠ nỗ lực. Người log 8 tiếng/ngày đều đặn chưa chắc làm việc hiệu quả hơn người log 5 tiếng. Time tracking đo thời gian ngồi vào việc, không đo giá trị tạo ra. Tệ hơn, khi log time bị dùng để đánh giá, người ta sẽ "làm tròn lên", log cả những giờ không thực sự productive, biến dữ liệu thành thứ vô nghĩa.
Số dòng code (lines of code) ≠ giá trị. Đây là metric kinh điển bị chế giễu. Một lập trình viên giỏi thường XÓA code, đơn giản hóa, viết ít dòng hơn để giải quyết cùng một vấn đề. Thưởng theo số dòng code là thưởng cho sự phức tạp và nợ kỹ thuật.
Nguyên lý nền tảng: Định luật Goodhart
Toàn bộ bài này xoay quanh một nguyên lý mà mọi PM phải khắc cốt ghi tâm — Định luật Goodhart: "Khi một thước đo trở thành mục tiêu, nó không còn là một thước đo tốt nữa." (When a measure becomes a target, it ceases to be a good measure.)
Nghĩa là gì? Velocity là thước đo tốt để dự báo — CHỪNG NÀO không ai bị đánh giá bằng nó. Ngay khi bạn nói "quý này ai không đạt velocity X sẽ bị đánh giá thấp", velocity lập tức bị thổi phồng: team ước lượng story point cao lên (point inflation), nhét thêm point vào ước lượng, và con số tăng vọt mà giá trị thực không đổi. Bạn đã tự tay phá hỏng công cụ lập kế hoạch của chính mình.
Vậy tool data dùng để làm gì?
Không phải là dữ liệu Jira vô dụng cho performance. Vấn đề là dùng nó đúng vai trò:
- Dùng để cải thiện HỆ THỐNG, không phán xét CON NGƯỜI. Cycle time tăng đột biến? Đó là tín hiệu quy trình có nút thắt cổ chai (bottleneck), không phải bằng chứng ai đó lười.
- Dùng làm dữ liệu ngữ cảnh (context), không phải bản án. Trong review, dữ liệu Jira giúp bạn ĐẶT CÂU HỎI ("Anh thấy có 3 story bị blocked hơn 2 tuần, chuyện gì xảy ra vậy?"), chứ không phải để TUYÊN ÁN.
- Dùng để nhìn xu hướng, không phải chấm điểm tuyệt đối. Xu hướng của cả team theo thời gian có ý nghĩa; con số của một cá nhân trong một sprint gần như vô nghĩa.
Tình huống thực tế
Tình huống 1 — Startup fintech TP.HCM và cuộc đua "cày story point"
Một startup fintech tại Quận 1, TP.HCM (khoảng 25 kỹ sư, chia 4 squad) có một Engineering Manager mới về, quyết định "minh bạch hóa hiệu suất" bằng cách gắn thưởng quý vào story point cá nhân. Anh xuất một bảng xếp hạng từ Jira mỗi cuối sprint, ai hoàn thành nhiều point nhất được vinh danh.
Ba tháng sau, chuyện gì xảy ra? Velocity toàn công ty tăng 60% trên giấy — nghe rất tuyệt. Nhưng số bug production tăng gấp đôi. Điều tra ra: các kỹ sư bắt đầu ước lượng point cao lên cho mọi thứ (một task 2 point giờ được estimate 5), chia nhỏ story để đóng được nhiều ticket hơn, và quan trọng nhất — không ai muốn nhận việc "refactor" hay "sửa bug của người khác" vì chúng "không được tính point cho mình". Việc review code bị làm qua loa vì review không sinh ra point. Một kỹ sư senior giỏi nhất team xin nghỉ, lý do: "Em thấy mình đang bị biến thành cỗ máy đếm ticket."
Bài học: Ngay khi story point trở thành mục tiêu cá nhân (Goodhart), nó ngừng phản ánh giá trị thật. Point inflation làm velocity vô nghĩa, và văn hóa hợp tác bị phá hủy vì mọi hành vi tốt-nhưng-không-sinh-point đều bị bỏ rơi.
Tình huống 2 — Công ty outsourcing Đà Nẵng và bẫy "log đủ 8 tiếng"
Một công ty outsource phần mềm ở Đà Nẵng làm dự án cho khách Nhật, yêu cầu log time trong Jira để tính giờ bill cho khách. Ban đầu hợp lý. Nhưng rồi quản lý bắt đầu dùng chính worklog đó để đánh giá "độ chăm chỉ" nội bộ: ai log dưới 40 giờ/tuần bị nhắc nhở.
Kết quả: kỹ sư học cách log cho đủ. Có người log 8 tiếng cho một task thực chất làm 4 tiếng, phần còn lại "để đấy cho tròn". Có người ngại báo là mình xong việc sớm vì sợ bị giao thêm mà không được ghi nhận. Dữ liệu worklog — vốn để bill khách chính xác — giờ bị thổi phồng, khiến ước lượng dự án sau lệch hẳn, báo giá cho khách Nhật sai, và uy tín với khách bị ảnh hưởng.
Một PM tinh ý trong công ty đề xuất tách bạch: worklog CHỈ dùng để bill và cải thiện estimate dự án, tuyệt đối không xuất hiện trong đánh giá cá nhân. Đánh giá cá nhân dựa trên chất lượng bàn giao, phản hồi của khách, và đóng góp kỹ thuật. Sau khi tách bạch, dữ liệu log time trở lại đáng tin trong vòng hai sprint.
Bài học: Khi một nguồn dữ liệu phục vụ hai mục đích mâu thuẫn (bill khách vs. đánh giá người), mục đích "đánh giá người" luôn làm hỏng độ chính xác. Hãy giữ mỗi metric cho đúng một mục đích.
Tình huống 3 — PM dùng dữ liệu Jira đúng cách trong review
Ngược lại, một PM tại một công ty SaaS ở Singapore phục vụ thị trường Đông Nam Á làm thế này. Đến kỳ review, cô KHÔNG xuất bảng xếp hạng point. Thay vào đó, cô dùng dữ liệu Jira như một "bản đồ để trò chuyện":
Với một kỹ sư có nhiều story bị chuyển tới lui giữa "In Progress" và "In Review" (nhìn qua flow diagram), cô không nói "anh làm việc kém". Cô hỏi: "Em để ý mấy story của anh vòng qua review nhiều lần, mình cùng xem có phải acceptance criteria chưa rõ từ đầu không?" — hóa ra vấn đề nằm ở khâu làm rõ yêu cầu của chính cô, không phải kỹ sư.
Với một kỹ sư có ít ticket nhưng cô biết anh này đã dành 3 tuần gỡ một sự cố hạ tầng cứu cả team, cô ghi nhận đóng góp đó bằng lời và trong đánh giá — dù nó gần như vô hình trên Jira.
Bài học: Dữ liệu Jira mạnh nhất khi dùng để đặt câu hỏi và tìm nguyên nhân hệ thống, chứ không phải để tính điểm. PM giỏi biết những đóng góp giá trị nhất thường không để lại dấu vết trên dashboard.
Hướng dẫn từng bước
Đây là quy trình để dùng dữ liệu Jira lành mạnh trong bối cảnh performance review:
Bước 1 — Tách bạch hai loại metric ngay từ đầu. Vẽ rõ hai cột: (A) System metrics — velocity, cycle time, throughput, dùng để cải thiện quy trình team; (B) Đóng góp cá nhân — đánh giá qua chất lượng, tác động, hành vi hợp tác. Tuyên bố công khai với team rằng nhóm (A) KHÔNG BAO GIỜ dùng để chấm điểm cá nhân. Chính lời cam kết này giữ cho dữ liệu team trung thực.
Bước 2 — Định nghĩa "đóng góp" rộng hơn ticket. Trước review, liệt kê các hình thức đóng góp không sinh ticket: review code chất lượng, mentor, tham gia thiết kế, gỡ bug hộ đồng đội, cải thiện tài liệu, xử lý sự cố. Chủ động thu thập bằng chứng cho những việc này (qua pull request, qua phản hồi đồng đội), vì Jira sẽ không tự nhắc bạn.
Bước 3 — Dùng dữ liệu Jira làm điểm khởi đầu cho câu hỏi, không phải kết luận. Với mỗi mẫu hình bất thường bạn thấy (story tồn đọng lâu, nhiều lần reopen, blocked kéo dài), viết ra một CÂU HỎI mở để hỏi trong 1:1, thay vì một phán xét.
Bước 4 — Nhìn xu hướng team, không nhìn con số cá nhân tuyệt đối. Xem cycle time và throughput của cả team theo nhiều sprint để phát hiện vấn đề quy trình. Đừng bao giờ so sánh point của người A với người B.
Bước 5 — Đối chiếu với ngữ cảnh trước khi kết luận bất cứ điều gì. Một kỹ sư "ít việc" trên Jira có thể đang gánh on-call, đang phỏng vấn tuyển dụng, đang chữa cháy sự cố. Luôn hỏi "chuyện gì phía sau con số này?".
Bước 6 — Ghi nhận công khai đóng góp vô hình. Trong review, chủ động nêu những đóng góp không có trên Jira. Điều này gửi tín hiệu rõ ràng tới cả team: giá trị thật được ghi nhận, không phải trò đếm số.
Lỗi thường gặp & mẹo
Lỗi 1 — Xuất "bảng xếp hạng" story point cho từng người. Đây là con đường nhanh nhất tới point inflation và văn hóa cạnh tranh độc hại. Đừng bao giờ làm.
Lỗi 2 — So sánh velocity giữa các team. Story point là thang tương đối của riêng mỗi team; so sánh chúng là so sánh vô nghĩa, và tạo áp lực khiến team thổi point.
Lỗi 3 — Trừng phạt ước lượng "sai". Nếu bạn phạt người estimate thấp mà làm lâu, họ sẽ estimate cao để an toàn. Estimate là dự báo, không phải cam kết cá nhân — hãy đối xử với nó như vậy.
Lỗi 4 — Coi dữ liệu Jira là bức tranh đầy đủ. Jira chỉ thấy những gì được ticket hóa. Phần lớn công việc kiến tạo giá trị (tư duy, thiết kế, giúp đỡ) không nằm trong đó.
Lỗi 5 — Dùng chung một metric cho hai mục đích mâu thuẫn. Như tình huống Đà Nẵng: log time để bill khách VÀ để đánh giá người sẽ làm hỏng cả hai.
Mẹo: Trước mỗi kỳ review, tự hỏi: "Nếu team biết mình sẽ đo họ bằng metric này, họ sẽ thay đổi hành vi thế nào để làm đẹp nó — và hành vi đó có hại không?" Nếu câu trả lời là "có hại", đừng dùng metric đó để đánh giá cá nhân.
Mẹo: Hãy tách vai. Khi phân tích dữ liệu Jira, đội mũ "cải thiện quy trình". Khi đánh giá con người, đội mũ "tìm bằng chứng về tác động và hành vi". Đừng để hai chiếc mũ đó lẫn vào nhau.
Bài tập thực hành
- Phân loại metric. Lấy 6 metric bạn hay thấy trên Jira (velocity, cycle time, số story done, giờ log, số bug, số ticket reopen). Với mỗi cái, viết một câu: nó dùng để cải thiện HỆ THỐNG hay dễ bị lạm dụng thành đánh giá CON NGƯỜI? Vì sao?
- Viết lại phán xét thành câu hỏi. Cho tình huống: một kỹ sư có 4 story bị "In Review" quá 10 ngày. Viết ra một câu phán xét sai (kiểu "anh này làm việc chậm") và một câu hỏi mở đúng để mở đầu buổi 1:1.
- Dự đoán hành vi lách số. Giả sử công ty bạn quyết định thưởng theo số story hoàn thành mỗi sprint. Liệt kê 3 hành vi mà team sẽ thay đổi để làm đẹp con số này, và tác hại của mỗi hành vi.
- Liệt kê đóng góp vô hình. Nghĩ về một đồng nghiệp bạn đánh giá cao. Liệt kê 3 đóng góp giá trị của họ mà KHÔNG hề xuất hiện dưới dạng ticket trên Jira. Đây chính là những thứ review cần bắt được.
Tóm tắt
Dữ liệu công cụ như Jira trông rất giống một thước đo hiệu suất khách quan, nhưng nó không phải. Velocity không phải năng suất, số story không phải đóng góp, giờ log không phải nỗ lực, số dòng code không phải giá trị. Định luật Goodhart cảnh báo: ngay khi một thước đo trở thành mục tiêu, nó ngừng phản ánh sự thật — con người sẽ tối ưu con số thay vì tối ưu giá trị.
Vai trò đúng của tool data trong performance review là làm dữ liệu ngữ cảnh để cải thiện HỆ THỐNG và để ĐẶT CÂU HỎI, không phải để tuyên án cá nhân. Hãy tách bạch metric của quy trình khỏi đánh giá con người, định nghĩa "đóng góp" rộng hơn ticket, nhìn xu hướng thay vì con số tuyệt đối, và luôn ghi nhận những đóng góp vô hình mà Jira không bao giờ thấy. Làm được vậy, bạn vừa giữ được dữ liệu trung thực, vừa xây được một đội ngũ tin tưởng thay vì lách số.