Mở đầu — vì sao bài này quan trọng
Trong nghề BA, có một câu hỏi tưởng đơn giản nhưng lại khiến cả team đau đầu mỗi cuối sprint: "Việc này thực ra tốn bao nhiêu thời gian?" Khi PM hỏi tại sao một feature trễ hai tuần, khi kế toán cần phân bổ chi phí dự án cho từng khách hàng, khi bạn muốn ước lượng sprint tiếp theo cho chính xác — tất cả đều dựa trên dữ liệu thời gian. Mà nếu không ai log time một cách kỷ luật, mọi con số đều là phỏng đoán.
Time Tracking trong JIRA chính là cơ chế biến "cảm giác bận rộn" thành dữ liệu định lượng. Với vai trò BA, bạn không chỉ là người ghi nhận thời gian của bản thân, mà còn là người thiết kế cách team đo lường, người đọc báo cáo để rút ra insight, và là cầu nối giữa effort thực tế với estimate trong các tài liệu phân tích. Khi dự án scale lên, hoặc khi công ty làm theo mô hình outsourcing tính phí theo giờ (rất phổ biến ở các công ty phần mềm Việt Nam như FPT Software, KMS, NashTech), kỹ năng quản lý time tracking trở thành yếu tố sống còn để bảo vệ ngân sách và uy tín của team.
Bài này tập trung riêng vào hai trụ cột: JIRA Time Tracking built-in (cơ chế gốc của JIRA) và Tempo Timesheets (plugin time tracking phổ biến nhất trên Atlassian Marketplace). Chúng ta sẽ không lan sang reporting tổng quát hay plugin khác — chỉ đào sâu đúng mảng đo lường và quản lý thời gian.
Khái niệm cốt lõi
Bộ ba trường thời gian built-in của JIRA
JIRA gốc cung cấp ba trường thời gian gắn liền với mỗi issue, tạo thành một hệ thống tự cân bằng:
- Original Estimate (Ước lượng ban đầu) — đây là con số bạn đặt ra trước khi bắt đầu: "Tôi nghĩ task này tốn 8h." Nó là baseline, lý tưởng là không nên sửa sau khi đã chốt, vì nó dùng để so sánh ước lượng với thực tế.
- Time Spent (Thời gian đã log) — tổng thời gian thực tế đã được log vào issue qua các work log. Mỗi lần bạn "Log Work" 2h, con số này cộng dồn lên.
- Remaining Estimate (Thời gian còn lại) — ước lượng còn bao nhiêu để hoàn thành. Đây là trường thông minh nhất: mỗi lần bạn log work, JIRA tự động trừ phần đã làm khỏi Remaining (trừ khi bạn chỉnh tay).
Đơn vị thời gian và cách JIRA quy đổi
JIRA dùng các ký hiệu: w (week), d (day), h (hour), m (minute). Ví dụ 2d 4h nghĩa là 2 ngày 4 giờ. Điểm cực kỳ quan trọng mà nhiều người mới sai: một "day" trong JIRA không mặc định là 24h. Admin cấu hình trong Time Tracking settings hai thông số:
- Working hours per day — thường set 8h.
- Working days per week — thường set 5d.
1d = 8h và 1w = 40h. Nếu công ty bạn làm 8.5h/ngày (kể cả nghỉ trưa tính công), admin phải sửa cho khớp, nếu không mọi báo cáo sẽ lệch.Work Log — đơn vị nhỏ nhất
Mỗi lần log time tạo ra một work log entry, gồm: số thời gian, ngày bắt đầu, người log, và mô tả (work description). Đây là dữ liệu thô để Tempo và các report tổng hợp lên. Một issue có thể có hàng chục work log từ nhiều người.
Vì sao cần Tempo? Giới hạn của built-in
Built-in của JIRA đủ để log time per-issue, nhưng nó không trả lời được những câu hỏi cấp quản lý:
- Tuần này cả team An log bao nhiêu giờ, phân bổ ra sao giữa các dự án?
- Bạn Minh đã đủ 40h/tuần chưa, có ai log thiếu không?
- Giờ làm của team Account A so với budget khách hàng còn dư bao nhiêu?
- Worklog calendar / Timesheet — giao diện lịch tuần để mỗi người nhìn thấy và điền giờ trực quan, thay vì phải mở từng issue.
- Accounts — "tài khoản" gắn với khách hàng hoặc cost center, để gom giờ theo mục đích tính phí (billable) hay nội bộ.
- Approval workflow — team lead duyệt timesheet hàng tuần như duyệt chấm công.
- Tempo reports — báo cáo theo người, theo team, theo account, xuất Excel cho kế toán.
Tình huống thực tế
Tình huống 1 — Outsourcing tính phí theo giờ tại một công ty software Đà Nẵng
Công ty Enlab Software (giả định hợp lý, mô hình rất phổ biến ở Đà Nẵng) ký hợp đồng T&M (Time & Material) với một khách hàng Úc: tính phí 25 USD/giờ, trần 320 giờ/tháng cho team 4 người. BA của dự án — chị Thảo — chịu trách nhiệm đảm bảo mỗi giờ tính cho khách đều có work log chứng minh.
Tháng đầu, team chỉ dùng JIRA built-in, ai log thì log, ai quên thì thôi. Cuối tháng tổng work log chỉ ra 268h, trong khi thực tế team làm gần đủ 320h. Hậu quả: công ty mất 52 giờ x 25 USD = 1.300 USD doanh thu vì không có bằng chứng để bill. Khách hàng cũng không tin tưởng vì con số trông "thiếu thuyết phục".
Sang tháng hai, chị Thảo triển khai Tempo. Chị tạo một Account tên "Client-AU-2026" gắn billable, yêu cầu mọi work log phải thuộc issue của dự án này. Mỗi sáng team có thói quen mở Tempo timesheet điền giờ hôm trước. Cuối tuần chị duyệt approval. Kết quả: tháng đó bill đủ 318h, và khi khách thắc mắc về một ngày log cao bất thường (14h), chị mở Tempo report ra chỉ rõ từng work log description cho khách xem.
Bài học: Với mô hình tính phí theo giờ, time tracking không phải thủ tục hành chính — nó là hóa đơn. Built-in không đủ; cần Account + approval của Tempo để biến giờ thành tiền có thể bảo vệ được.
Tình huống 2 — Ước lượng sprint lệch tại một startup fintech TP.HCM
Một startup fintech ở Quận 1 (gọi là PayNow) có team 6 dev + 1 BA. Sprint nào cũng commit 50 story points nhưng chỉ làm xong 35. PM đổ lỗi cho dev "làm chậm", dev nói "estimate sai". Không ai có dữ liệu.
BA tên Khoa quyết định bật Original Estimate và bắt buộc log time trong 3 sprint. Anh không cần Tempo phức tạp, chỉ dùng built-in và xuất số. Sau 3 sprint, dữ liệu cho thấy: các task gắn nhãn "integration với cổng thanh toán" có Original trung bình 6h nhưng Time Spent trung bình 16h — lệch gần 2.7 lần. Trong khi đó task UI lệch không đáng kể.
Insight rất rõ: vấn đề không phải dev chậm mà là team systematically under-estimate các task tích hợp bên thứ ba vì không tính thời gian chờ sandbox, debug webhook, xử lý lỗi từ phía đối tác. Khoa cập nhật nguyên tắc estimate: nhân hệ số 2.5 cho mọi task integration. Sprint sau, velocity dự báo khớp gần 90%.
Bài học: Cặp Original Estimate vs Time Spent là công cụ học hỏi mạnh nhất của BA. Nó không để "đổ lỗi" mà để phát hiện loại công việc nào team luôn ước lượng sai, từ đó cải thiện chất lượng phân tích đầu vào.
Tình huống 3 — Phân bổ chi phí R&D để hưởng ưu đãi thuế
Một công ty sản phẩm vừa ở Hà Nội muốn chứng minh phần trăm effort dành cho hoạt động R&D để làm hồ sơ ưu đãi (nhiều công ty công nghệ VN quan tâm việc này). Kế toán cần biết: trong quý, bao nhiêu giờ nhân sự dành cho phát triển sản phẩm mới (R&D) so với bảo trì (maintenance).
BA cấu hình hai Tempo Account: "RnD-NewProduct" và "Maintenance-BAU". Mỗi work log được gán account tương ứng. Cuối quý, Tempo report xuất ra: 4.200h R&D / tổng 6.800h = 62%. Con số này có dữ liệu work log chi tiết đứng sau, đủ độ tin cậy để đưa vào hồ sơ.
Bài học: Tempo Account biến time tracking từ công cụ nội bộ thành nguồn dữ liệu tài chính/pháp lý. Một BA giỏi thiết kế cấu trúc account trước, để dữ liệu thu thập được đúng ngay từ đầu chứ không phải "vá" lại sau.
Hướng dẫn từng bước
Phần A — Bật và dùng Time Tracking built-in
- Kiểm tra cấu hình admin. Vào Settings → System → Time Tracking. Xác nhận "Hours per day" (vd 8) và "Days per week" (vd 5) khớp thực tế công ty. Chọn format hiển thị (pretty:
4h 30m). - Đảm bảo field xuất hiện trên màn hình. Trong screen scheme của project, kiểm tra "Time Tracking" field nằm trong Create/Edit/View screen. Nếu BA không thấy ô Original Estimate khi tạo issue, nguyên nhân thường ở đây.
- Đặt Original Estimate khi tạo issue. Lúc tạo Story/Task, điền ước lượng ban đầu, vd
1d(= 8h). - Log Work khi làm. Mở issue → nút More → Log Work (hoặc dấu ⋯). Nhập "Time Spent" (vd
3h), "Date Started", và mô tả ngắn gọn việc đã làm. Để Remaining Estimate ở chế độ "Adjust automatically" cho lần đầu. - Điều chỉnh Remaining khi cần. Nếu phát hiện task khó hơn, chọn "Set to" và nhập lại Remaining thủ công.
- Đọc thanh time tracking. Trên issue sẽ có thanh ba màu: xanh (đã log), cam (còn lại), và tỷ lệ. Nếu thanh vượt 100% original, task đang over-budget.
- Cài đặt từ Marketplace. Admin vào Apps → Find new apps, tìm "Tempo Timesheets", cài (có bản trial 30 ngày).
- Thiết kế cấu trúc Account. Trước khi cho team dùng, ngồi với kế toán/PM liệt kê các cost center hoặc khách hàng. Tạo Account trong Tempo → Accounts, gắn billable/non-billable, link tới customer.
- Liên kết Account với project. Trong cấu hình account, chọn project nào được phép log vào account đó.
- Hướng dẫn team dùng Timesheet view. Mỗi người vào Tempo → My Work / Timesheets, dùng giao diện lịch tuần kéo-thả hoặc click vào ô ngày để log work trực tiếp lên issue.
- Thiết lập approval. Bật Period Approval: team member "Submit" timesheet cuối tuần, lead "Approve" hoặc "Reject" kèm comment.
- Xuất report. Vào Tempo → Reports, lọc theo người/team/account/khoảng thời gian, xuất Excel hoặc xem biểu đồ phân bổ.
Lỗi thường gặp & mẹo
- Log time một cục cuối sprint. Đây là sai lầm phổ biến nhất. Log dồn 5 ngày vào thứ Sáu khiến dữ liệu sai ngày, mất chính xác và dễ quên. Mẹo: tạo thói quen log mỗi cuối ngày, hoặc bật Tempo nhắc nhở (reminder) cho người chưa đủ giờ.
- Sửa Original Estimate giữa chừng. Khi over-budget, nhiều người "sửa" Original cho đẹp báo cáo. Làm vậy là phá hủy khả năng học hỏi từ độ lệch estimate. Mẹo: giữ nguyên Original, chỉ điều chỉnh Remaining. Original là lịch sử, đừng viết lại lịch sử.
- Nhầm "ngày JIRA" với ngày thực. Báo cáo ra 40h nhưng manager nghĩ là 40h/24 = chưa tới 2 ngày. Mẹo: luôn thống nhất với team "1d = 8h" và viết rõ trong tài liệu onboarding.
- Không gán Account ngay từ đầu. Triển khai Tempo nhưng để mọi giờ rơi vào "No Account" thì mất hết giá trị phân bổ. Mẹo: set account mặc định cho project, hoặc đặt rule bắt buộc chọn account khi log.
- Bắt log time mà không giải thích lý do. Team sẽ chống đối vì cảm giác bị "soi". Mẹo: truyền thông rõ time tracking để cải thiện estimate và bảo vệ team khỏi over-commit, không phải để đánh giá năng suất cá nhân.
- Quên rằng sub-task ảnh hưởng parent. Time logged trên sub-task có thể cộng dồn lên parent (tùy cấu hình). Mẹo: thống nhất log ở cấp nào — thường log ở sub-task để chi tiết, và xem tổng ở Epic qua Tempo.
Bài tập thực hành
- Thiết lập built-in: Tạo một Story "Phân tích yêu cầu module thanh toán" với Original Estimate
2d. Log Work 3 lần ở 3 ngày khác nhau: 4h, 6h, 5h, mỗi lần để Remaining tự điều chỉnh. Sau đó chụp lại thanh time tracking và trả lời: task này over hay under budget? Lệch bao nhiêu giờ so với Original?
- Phân tích độ lệch: Lấy 5 issue đã đóng trong một project thật (hoặc tự tạo dữ liệu). Lập bảng so sánh Original Estimate vs Time Spent cho từng issue, tính % lệch. Nhóm các issue theo loại công việc và xác định: loại nào team ước lượng sai nhiều nhất? Viết một câu insight như BA Khoa trong Tình huống 2.
- Thiết kế Account (trên giấy): Giả sử bạn là BA của một công ty outsourcing có 3 khách hàng và 1 mảng sản phẩm nội bộ. Hãy phác thảo cấu trúc Tempo Account: đặt tên, billable/non-billable, project nào gắn vào account nào. Giải thích tại sao chia như vậy.
- Mô phỏng tính phí: Với mức 25 USD/giờ, nếu team log được 318h trong tháng nhưng có 12h bị reject do thiếu work description, doanh thu thực bill được là bao nhiêu? Bạn sẽ làm gì để 12h đó không bị mất ở tháng sau?
Tóm tắt
Time tracking là cách BA biến effort thành dữ liệu định lượng phục vụ ba mục đích: cải thiện estimate, tính phí dự án, và phân bổ chi phí. JIRA built-in cung cấp bộ ba Original Estimate, Time Spent, Remaining Estimate với cơ chế tự cân bằng — đủ cho việc log per-issue và phân tích độ lệch ước lượng. Khi cần quản lý ở cấp team, khách hàng, hay tài chính, Tempo Timesheets bổ sung timesheet trực quan, Accounts để gom giờ theo cost center, approval workflow, và report xuất Excel.
Ba nguyên tắc vàng cần nhớ: log time đều đặn hàng ngày để dữ liệu chính xác; giữ nguyên Original Estimate để học hỏi từ độ lệch; và thiết kế cấu trúc Account trước khi triển khai để dữ liệu đúng ngay từ đầu. Đừng quên thống nhất "1d = 8h" để mọi báo cáo cùng một ngôn ngữ. Khi làm tốt, time tracking không phải gánh nặng hành chính mà là tài sản dữ liệu giúp team ước lượng chính xác hơn và bảo vệ ngân sách dự án.