Mở đầu — vì sao bài này quan trọng
Bạn có thể là một PM giỏi về tư duy chiến lược, hiểu khách hàng sâu sắc, vẽ roadmap đẹp như tranh — nhưng nếu đội kỹ thuật không biết tuần này phải làm gì, mọi thứ vẫn đứng im. Đó chính là khoảng trống mà Jira lấp đầy. Jira là công cụ quản lý công việc phổ biến nhất trong các đội phát triển phần mềm, và ở Việt Nam, từ các công ty outsource như FPT Software, TMA Solutions cho đến các startup như Tiki, MoMo, Base.vn, gần như nơi nào có team engineer là nơi đó có Jira.
Với một PM, Jira không chỉ là "chỗ để ghi việc". Nó là nơi ý tưởng sản phẩm của bạn được chuyển hóa thành những đơn vị công việc cụ thể mà developer có thể nhặt lên và làm. Nó là nguồn dữ liệu thật về tiến độ — không phải tiến độ mà ai đó "cảm thấy", mà tiến độ đo được. Và nó là ngôn ngữ chung giữa bạn, designer, engineer và quản lý cấp trên.
Điều quan trọng cần hiểu ngay từ đầu: bạn không cần trở thành chuyên gia cấu hình Jira. Việc dựng workflow phức tạp, phân quyền, tự động hóa thường thuộc về Scrum Master hoặc Jira Admin. Cái bạn — với tư cách PM — cần làm chủ là biết tổ chức công việc của sản phẩm một cách rõ ràng, viết issue tốt, đọc được board để biết tình hình, và dùng Jira như một công cụ giao tiếp thay vì một cái máy ghi sổ. Bài này sẽ tập trung đúng vào điều đó.
Khái niệm cốt lõi
Jira được xây dựng quanh bốn khái niệm nền tảng. Nắm chắc bốn cái này, bạn sẽ tự tin dùng được 80% công việc hằng ngày.
Project — Chiếc hộp chứa lớn nhất
Project (dự án) là container — chiếc hộp lớn nhất chứa toàn bộ công việc liên quan đến một sản phẩm hoặc một mảng sản phẩm. Mỗi project có một mã viết tắt gọi là Project Key, thường là vài chữ in hoa. Ví dụ một app ví điện tử có thể có project key là PAY, và mọi công việc trong đó sẽ được đánh số PAY-1, PAY-2, PAY-101...
Mã số này quan trọng hơn bạn tưởng. Khi developer commit code, họ thường ghi PAY-234: Sửa lỗi nạp tiền, khi designer trao đổi họ nói "cái ticket PAY-234 đó", khi sếp hỏi "tính năng quét QR đến đâu rồi" bạn chỉ cần đưa link PAY-234. Một mã số nhỏ trở thành điểm neo cho toàn bộ cuộc trò chuyện về một mẩu công việc.
Issue — Đơn vị công việc
Issue là trái tim của Jira — mỗi issue là một đơn vị công việc. Đừng để chữ "issue" (vốn nghĩa là "vấn đề") làm bạn hiểu nhầm; trong Jira nó chỉ có nghĩa là "một việc cần làm". Issue có nhiều loại (issue type), và bốn loại bạn gặp nhiều nhất là:
- Epic — một khối công việc lớn, kéo dài nhiều tuần đến vài tháng, thường tương ứng với một tính năng lớn hay một mục tiêu sản phẩm. Ví dụ: "Tính năng thanh toán bằng mã QR". Một Epic chứa nhiều Story bên trong.
- Story (User Story) — một mẩu giá trị mang lại cho người dùng, đủ nhỏ để hoàn thành trong một sprint. Story thường viết theo công thức "Là [ai], tôi muốn [làm gì], để [đạt được gì]". Ví dụ: "Là người dùng, tôi muốn quét mã QR của cửa hàng để thanh toán nhanh mà không phải nhập số tài khoản."
- Task — một việc cần làm nhưng không nhất thiết gắn trực tiếp với giá trị người dùng, thường là việc kỹ thuật hoặc vận hành. Ví dụ: "Tích hợp SDK của ngân hàng đối tác", "Cấu hình môi trường staging".
- Bug — một lỗi cần sửa. Ví dụ: "Màn hình thanh toán bị treo khi mạng yếu".
Mỗi issue có các trường thông tin quan trọng: Summary (tiêu đề), Description (mô tả chi tiết, thường chứa yêu cầu và tiêu chí chấp nhận), Assignee (người chịu trách nhiệm), Reporter (người tạo), Priority (độ ưu tiên), Status (trạng thái) và Story Points (ước lượng độ lớn — sẽ học kỹ ở bài Estimation).
Sprint — Đợt làm việc có giới hạn thời gian
Sprint là một lô issue được đóng gói để làm trong một khoảng thời gian cố định (time-boxed), thường là một hoặc hai tuần. Triết lý ở đây là: thay vì để công việc trôi nổi không kỳ hạn, đội chọn ra một nhóm việc vừa sức, cam kết hoàn thành trong sprint, rồi đánh giá kết quả ở cuối. Đầu sprint có buổi Sprint Planning để chọn việc, cuối sprint có Review và Retrospective.
Những issue chưa được đưa vào sprint nào nằm ở Backlog — danh sách chờ. Việc kéo issue từ Backlog vào Sprint chính là hành động "quyết định tuần này làm gì", và đây là nơi tư duy ưu tiên của PM thể hiện rõ nhất.
Board — Bức tranh trực quan
Board (bảng) là nơi bạn nhìn thấy toàn bộ công việc dưới dạng các cột trạng thái, mỗi issue là một tấm thẻ di chuyển từ trái sang phải. Một board điển hình có các cột: To Do → In Progress → In Review → Done. Có hai kiểu board phổ biến:
- Scrum board — gắn với sprint, chỉ hiển thị các issue trong sprint hiện tại. Hợp với đội làm theo chu kỳ sprint cố định.
- Kanban board — dòng chảy liên tục, không chia sprint, việc cứ đến thì kéo qua các cột. Hợp với đội vận hành, support, hoặc đội phát hành liên tục.
Tình huống thực tế
Ví dụ 1: Startup fintech Việt sắp xếp tính năng quét QR
Một startup ví điện tử ở TP.HCM (gọi tên giả định là "PayViet"), đội 6 developer và 1 PM, chuẩn bị làm tính năng thanh toán bằng mã QR cho dịp Tết. PM tạo một Epic tên PAY-100: Thanh toán QR tại cửa hàng. Bên dưới Epic này, cô chia thành các Story: PAY-101 quét QR tĩnh của cửa hàng, PAY-102 tạo QR động theo số tiền, PAY-103 lịch sử giao dịch QR, và một Task kỹ thuật PAY-104 tích hợp API của đối tác ngân hàng.
Trong buổi Sprint Planning đầu tháng 12, đội chỉ đủ sức làm 3 việc trong sprint hai tuần. PM quyết định kéo PAY-101, PAY-104 và một bug tồn PAY-088 vào sprint, để lại PAY-102 và PAY-103 ở Backlog cho sprint sau. Quyết định này không tùy hứng — PAY-104 phải xong trước thì PAY-101 mới chạy được, nên nó được ưu tiên.
Bài học: Epic giúp giữ bức tranh lớn không bị vỡ vụn, còn việc chọn issue vào sprint chính là nơi PM biến chiến lược "ra mắt QR trước Tết" thành hành động cụ thể của tuần này. Jira buộc bạn phải thành thật về năng lực đội: 6 người không làm được 8 việc trong 2 tuần, và board sẽ phơi bày điều đó.
Ví dụ 2: Công ty outsource và kỷ luật của trường Bug
Một team tại một công ty outsource ở Hà Nội làm dự án cho khách hàng Nhật. Khách hàng cực kỳ kỹ tính về chất lượng. Trong sprint, mỗi khi QA tìm ra lỗi, họ tạo một issue loại Bug, gắn Priority (Highest/High/Medium/Low), đính kèm ảnh chụp màn hình và các bước tái hiện lỗi vào Description.
Ban đầu đội gặp rắc rối: cột "In Review" trên board luôn dồn ứ 12-15 thẻ, trong khi cột "In Progress" vẫn đầy. Nhìn board, PM nhận ra developer cứ nhặt việc mới thay vì giúp review việc cũ, khiến nhiều tính năng "gần xong" mà không bao giờ thật sự Done. Anh đặt ra quy ước: mỗi sáng, nếu cột In Review có quá 5 thẻ, cả đội dừng nhận việc mới và review trước.
Bài học: Board không chỉ để theo dõi — nó là công cụ chẩn đoán. Một cột bị phình to là tín hiệu về nút thắt (bottleneck) trong quy trình. PM giỏi đọc board như bác sĩ đọc phim X-quang, thấy chỗ tắc nghẽn trước khi nó thành khủng hoảng tiến độ.
Ví dụ 3: Báo cáo cho sếp bằng dữ liệu thay vì cảm tính
PM của một app giao đồ ăn (giả định tên "FoodNow") bị Giám đốc sản phẩm hỏi mỗi tuần: "Tính năng đặt món theo nhóm đến đâu rồi?". Trước đây cô trả lời theo cảm giác: "Sắp xong rồi anh". Sau khi tổ chức công việc gọn trong Jira, cô gắn tất cả Story của tính năng này vào Epic FN-200, và Jira tự tổng hợp: 7/10 Story đã Done, 2 đang In Progress, 1 còn ở Backlog. Cô chỉ cần gửi link Epic, và cấp trên tự thấy bức tranh.
Cô còn dùng biểu đồ Burndown của sprint — biểu đồ cho thấy khối lượng việc còn lại giảm dần theo ngày. Khi đường burndown đi ngang (không giảm) ba ngày liền, cô biết sprint đang có vấn đề và chủ động cảnh báo trước thay vì để lỡ deadline.
Bài học: Khi công việc được tổ chức tốt trong Jira, việc báo cáo gần như miễn phí — dữ liệu tự nói. Đây là sự khác biệt giữa một PM "bận rộn cập nhật trạng thái" và một PM dùng hệ thống để trạng thái tự cập nhật chính nó.
Hướng dẫn từng bước
Đây là quy trình tối thiểu để một PM bắt đầu làm chủ Jira cho sản phẩm của mình:
- Xác định cấu trúc Epic của sản phẩm. Trước khi tạo bất cứ Story nào, liệt kê 4-8 khối lớn (Epic) tương ứng các tính năng/mục tiêu chính trong quý. Đây là xương sống — nó nên phản chiếu roadmap của bạn.
- Viết Story rõ ràng. Với mỗi Epic, chia thành các Story đủ nhỏ để xong trong một sprint. Mỗi Story cần có: tiêu đề ngắn gọn, mô tả theo công thức "Là... tôi muốn... để...", và quan trọng nhất là Acceptance Criteria (tiêu chí chấp nhận) — danh sách điều kiện rõ ràng để biết khi nào việc được coi là hoàn thành.
- Sắp xếp Backlog theo ưu tiên. Kéo những issue quan trọng nhất lên trên cùng. Backlog không phải bãi rác chứa mọi ý tưởng; nó là danh sách đã được xếp hạng. Việc gì ở dưới đáy mãi không nên ở đó thì hãy mạnh dạn đóng lại.
- Tham gia Sprint Planning. Cùng đội chọn issue từ đỉnh Backlog đưa vào sprint, dựa trên năng lực thực tế (velocity) của đội. Vai trò PM ở đây là bảo vệ thứ tự ưu tiên và làm rõ yêu cầu khi developer hỏi.
- Mở board mỗi ngày. Theo dõi luồng việc, để ý thẻ nào "đứng" quá lâu một chỗ, cột nào dồn ứ. Vào ticket bị kẹt để hỏi và gỡ vướng cho đội.
- Dùng comment thay vì chat riêng. Mọi quyết định, làm rõ yêu cầu, thay đổi phạm vi — hãy ghi vào phần comment của chính issue đó. Sau này bất cứ ai mở ticket lên đều thấy đầy đủ bối cảnh, không phải đi lục lại Slack hay Zalo.
- Đóng issue đúng cách. Một issue chỉ Done khi thỏa Acceptance Criteria. Là PM, hãy là người kiểm tra điều này, đừng để "Done" trở thành "developer nghĩ là xong".
Lỗi thường gặp & mẹo
Lỗi: Viết Story mơ hồ. Một ticket chỉ ghi "Làm màn hình thanh toán" sẽ khiến developer đoán mò và làm sai. Mẹo: Luôn kèm Acceptance Criteria cụ thể. Càng rõ ràng ở đầu, càng ít làm lại ở cuối.
Lỗi: Coi Jira là sổ ghi việc một chiều. PM tạo ticket xong rồi biến mất, để developer tự xoay. Mẹo: Jira là kênh giao tiếp hai chiều — hãy trả lời comment, làm rõ thắc mắc, cập nhật khi yêu cầu đổi.
Lỗi: Nhồi quá nhiều việc vào sprint. Vì "muốn nhanh", PM ép đội ôm 12 Story trong khi sức chỉ làm 8. Kết quả là cuối sprint dở dang, mất tinh thần. Mẹo: Tôn trọng velocity thực tế; làm xong ít việc tốt hơn dở dang nhiều việc.
Lỗi: Để Backlog phình to vô tận. Hàng trăm issue cũ không ai đụng tới làm loãng những việc thật sự quan trọng. Mẹo: Định kỳ dọn Backlog, đóng những issue đã hết liên quan.
Lỗi: Lạm dụng Priority "Highest". Khi cái gì cũng khẩn cấp thì chẳng cái gì khẩn cấp. Mẹo: Giữ kỷ luật cho nhãn ưu tiên cao nhất, chỉ dùng cho thứ thật sự chặn người dùng.
Mẹo nâng cao: Học cách dùng JQL (Jira Query Language) ở mức cơ bản, ví dụ gõ assignee = currentUser() AND status != Done để xem việc của riêng mình. Và đừng tự dựng workflow phức tạp — hãy nhờ Scrum Master/Admin; việc của bạn là nội dung và ưu tiên, không phải cấu hình.
Bài tập thực hành
- Dựng cấu trúc cho một sản phẩm giả định. Chọn một sản phẩm bạn quen (ví dụ tính năng "đặt lịch hẹn" cho một app phòng khám). Viết ra 3 Epic, và dưới mỗi Epic viết 3 Story theo công thức "Là... tôi muốn... để...".
- Viết Acceptance Criteria. Chọn một trong các Story trên, viết ít nhất 4 tiêu chí chấp nhận đủ rõ để developer biết chính xác khi nào việc hoàn thành.
- Lập kế hoạch một sprint. Giả sử đội bạn làm được khoảng 20 story point mỗi sprint hai tuần. Gán điểm ước lượng cho 6 Story bạn vừa viết, rồi chọn ra các Story đưa vào sprint sao cho không vượt 20 điểm. Giải thích vì sao bạn chọn thứ tự đó.
- Đọc board. Hình dung một board có cột In Review đang chứa 9 thẻ trong khi To Do còn 2 thẻ và In Progress có 1 thẻ. Viết 3 câu mô tả vấn đề bạn nhận ra và hành động bạn sẽ đề xuất.
Tóm tắt
Jira là công cụ biến tư duy sản phẩm của bạn thành công việc cụ thể mà đội có thể thực thi, và biến tiến độ thành dữ liệu đo được thay vì cảm tính. Bốn khái niệm nền tảng cần nắm chắc là: Project (chiếc hộp chứa toàn bộ công việc của một sản phẩm), Issue (đơn vị công việc — gồm Epic, Story, Task, Bug), Sprint (lô việc có giới hạn thời gian) và Board (bức tranh trực quan về luồng công việc).
Với tư cách PM, bạn không cần thành chuyên gia cấu hình Jira. Việc bạn cần làm chủ là: tổ chức công việc thành Epic và Story rõ ràng, viết Acceptance Criteria cụ thể, bảo vệ thứ tự ưu tiên ở Backlog, đọc board để phát hiện nút thắt, và dùng Jira như kênh giao tiếp chung thay vì sổ ghi việc một chiều. Khi làm tốt những điều này, việc báo cáo và phối hợp gần như tự diễn ra, và bạn có nhiều thời gian hơn cho thứ thật sự quan trọng: quyết định nên xây gì tiếp theo.