Mở đầu — vì sao bài này quan trọng
Nếu bạn từng nhìn một board Jira và thấy một issue "kẹt" mãi ở trạng thái nào đó không rõ đang thuộc về ai, hoặc thấy cả team cãi nhau "cái này Done chưa?" — thì nguyên nhân gốc gần như luôn nằm ở workflow. Workflow chính là bộ khung xương của toàn bộ cách một công việc di chuyển từ lúc sinh ra cho đến lúc hoàn thành trong Jira. Nó quyết định một issue có thể ở những trạng thái (status) nào, được phép chuyển (transition) từ trạng thái này sang trạng thái nào, ai được phép chuyển, và điều gì tự động xảy ra khi chuyển.
Với vai trò PM, bạn không nhất thiết phải là người trực tiếp cấu hình workflow trên hệ thống (việc đó thường thuộc về Jira Admin — chúng ta sẽ nói kỹ ở Bài 54). Nhưng bạn phải là người hiểu và thiết kế workflow, bởi vì workflow chính là hiện thân của quy trình làm việc thật của team. Một workflow tốt giúp mọi người nhìn vào board là biết ngay công việc đang ở đâu, ai đang giữ, và cần gì để đẩy tiếp. Một workflow tồi thì ngược lại: nó khiến team gõ status cho có lệ, dữ liệu report sai lệch, và bạn — PM — mất khả năng nhìn thấy sự thật của dự án.
Bài này tập trung riêng vào việc thiết kế workflow và tùy biến status: từ workflow mặc định đơn giản, đến workflow thực chiến cho một team phát triển sản phẩm, và những nguyên tắc để không thiết kế quá tay.
Khái niệm cốt lõi
Ba thành phần của một workflow
Một workflow trong Jira được tạo bởi ba khối:
- Status (trạng thái): là "chỗ đứng" của một issue tại một thời điểm — ví dụ To Do, In Progress, Done. Mỗi status có một category (danh mục) là một trong ba nhóm: To Do (xám), In Progress (xanh dương), Done (xanh lá). Category rất quan trọng vì nhiều report và board của Jira dựa vào nó chứ không dựa vào tên status.
- Transition (chuyển tiếp): là "con đường" cho phép đi từ status này sang status khác. Nếu không có transition, issue không thể chuyển. Transition có thể một chiều hoặc hai chiều, và có thể được gắn điều kiện, người thực hiện, hành động tự động.
- Rule trên transition: gồm ba loại — Condition (ai được phép thực hiện transition này), Validator (điều kiện dữ liệu phải thỏa, ví dụ bắt buộc điền lý do khi Reject), và Post-function (việc tự động chạy sau khi chuyển, ví dụ tự gán assignee, tự set ngày resolved).
Workflow mặc định của Jira
Khi tạo một project mới, Jira cho bạn workflow đơn giản nhất:
To Do → In Progress → Done
Đây là workflow "sạch" và hoàn toàn ổn cho team nhỏ hoặc giai đoạn đầu. Đừng coi thường sự đơn giản này — rất nhiều team chạy hiệu quả cả năm chỉ với ba status.
Workflow thực chiến của một PM
Khi team lớn hơn và quy trình rõ ràng hơn, workflow điển hình cho một team phát triển sản phẩm thường trông như sau:
Backlog → Refined → To Do → In Progress → Code Review → In QA → Done
Diễn giải từng status:
- Backlog: ý tưởng/yêu cầu vừa được tạo, chưa được làm rõ. (Category: To Do)
- Refined: đã được refine trong buổi backlog refinement — có mô tả, acceptance criteria, story point. Sẵn sàng để đưa vào sprint. (Category: To Do)
- To Do: đã được kéo vào sprint, chờ ai đó bắt đầu. (Category: To Do)
- In Progress: đang được code. (Category: In Progress)
- Code Review: dev đã xong, đang chờ review pull request. (Category: In Progress)
- In QA: đã merge, đang được QA kiểm thử. (Category: In Progress)
- Done: đã pass QA, chấp nhận. (Category: Done)
Workflow scheme và chuyện dùng chung
Trong Jira, workflow không gắn trực tiếp vào project mà thông qua workflow scheme — một bảng ánh xạ "issue type nào dùng workflow nào". Nhờ đó, trong cùng một project, Bug có thể dùng workflow riêng (có thêm status Reopened), còn Story dùng workflow khác. Đây là lý do nên tách workflow theo bản chất công việc, đừng nhồi mọi thứ vào một workflow khổng lồ.
Tình huống thực tế
Ví dụ 1 — Tiki: khi thêm status "Code Review" cứu được chất lượng
Một team sản phẩm giả định tại Tiki (mảng thanh toán) ban đầu dùng workflow ba bước mặc định: To Do → In Progress → Done. Vấn đề: dev tự đẩy issue sang Done ngay khi code xong, trước cả khi ai review. Kết quả là trong một quý, có khoảng 18% số ticket bị reopen sau khi lên production vì lỗi mà lẽ ra review đã bắt được.
PM đã thiết kế lại: chèn thêm hai status Code Review và In QA vào giữa In Progress và Done. Đồng thời gắn một validator trên transition vào Done, bắt buộc phải có link tới pull request đã được approve. Sau hai sprint, tỉ lệ reopen giảm còn 6%.
Bài học: status không chỉ để "nhìn cho đẹp" — mỗi status mới nên gắn với một cổng chất lượng (quality gate) thật. Nếu chỉ thêm tên mà không có ràng buộc hoặc hành vi đi kèm, nó vô nghĩa.
Ví dụ 2 — Startup fintech 12 người: workflow 11 status và cái giá phải trả
Một startup fintech ở TP.HCM với đúng 12 người từng thuê một Jira consultant thiết kế workflow "chuẩn enterprise". Kết quả là một workflow 11 status: Backlog → Analysis → Ready for Dev → In Dev → Dev Done → In Code Review → Review Passed → In QA → QA Passed → UAT → Done.
Trên lý thuyết đẹp. Thực tế: dev thấy phiền, thường nhảy cóc hoặc bỏ mặc status không cập nhật. Ba tháng sau, PM mở Control Chart thì thấy dữ liệu cycle time vô nghĩa vì status không phản ánh thực tế. Team đã rút gọn xuống 6 status và gộp các cặp trùng lặp (ví dụ Dev Done và In Code Review thực chất là một pha).
Bài học: với team nhỏ, mỗi status thừa là một điểm ma sát. Quy tắc kinh nghiệm: số status nên xấp xỉ số lần "bàn giao" (handoff) thật giữa các vai trò, không hơn. 12 người mà 11 status là dấu hiệu over-engineering rõ ràng.
Ví dụ 3 — Team hỗ trợ nội bộ: workflow cho Bug khác workflow cho Story
Một team giả định tại một công ty logistics ở Singapore quản lý cả tính năng mới lẫn sửa lỗi trong cùng một project. Ban đầu họ dùng chung một workflow cho tất cả. Vấn đề: khi một Bug đã Done mà khách báo lỗi lại, họ không có cách nào đưa nó về trạng thái đang xử lý một cách sạch sẽ — phải tạo bug mới, làm loạn số liệu.
Giải pháp: tạo workflow scheme với hai workflow. Story dùng workflow phát triển bình thường. Bug dùng workflow riêng có thêm status Reopened và một transition từ Done → Reopened (kèm post-function tự gán lại cho dev cũ và tự tăng một custom field đếm số lần reopen).
Bài học: đừng ép mọi issue type vào một khuôn. Workflow scheme cho phép mỗi loại công việc có vòng đời phù hợp với bản chất của nó.
Hướng dẫn từng bước
Đây là quy trình thiết kế một workflow từ đầu — nên làm trên giấy/Miro trước, rồi mới cấu hình trong Jira.
- Vẽ dòng chảy công việc thật ngoài đời trước. Ngồi với team, hỏi: một yêu cầu đi qua tay những ai, theo thứ tự nào? Ghi ra từng pha thật. Đừng bắt đầu từ Jira, hãy bắt đầu từ thực tế.
- Gộp pha thành status theo nguyên tắc "chờ ai làm gì". Mỗi status phải là một điểm dừng có ý nghĩa: đang chờ một vai trò cụ thể hành động. Nếu hai pha luôn do cùng một người làm liên tục không có bàn giao, gộp lại.
- Gán category cho từng status. Mỗi status là To Do, In Progress, hay Done. Đây là bước hay bị bỏ quên nhưng cực quan trọng: board và report (velocity, burndown, cumulative flow) đọc theo category. Nếu bạn để Code Review nhầm vào category Done, burndown sẽ báo "xong" sớm sai bét.
- Vẽ các transition hợp lệ. Xác định đường đi được phép. Cân nhắc: có cần đường lùi không (ví dụ In QA → In Progress khi QA reject)? Có nên dùng transition "All" (global) để đưa mọi thứ về Backlog khi hủy không?
- Thêm rule vào những transition quan trọng.
- Cấu hình trong Jira. Vào Project settings → Workflows (hoặc Settings → Issues → Workflows ở cấp admin). Tạo/sửa workflow bằng chế độ Diagram cho trực quan. Sau đó gắn workflow vào issue type qua Workflow scheme, rồi Publish.
- Test với issue thật rồi mới rollout. Tạo vài issue nháp, đi qua hết vòng đời, kiểm tra transition, validator, post-function chạy đúng. Đặc biệt kiểm tra category hiển thị đúng trên board.
- Thông báo và đào tạo team. Workflow thay đổi là thay đổi thói quen. Giải thích tại sao mỗi status tồn tại, không chỉ cái gì.
Lỗi thường gặp & mẹo
- Over-engineering (quá nhiều status): như ví dụ startup fintech. Mẹo: nếu bạn không giải thích được một status trả lời "chờ ai làm gì", hãy xóa nó.
- Quên gán status category: khiến báo cáo sai. Rất khó phát hiện vì tên status vẫn đúng. Luôn kiểm tra category sau khi tạo status mới.
- Không có đường lùi: team chỉ vẽ đường tiến, đến khi QA reject thì không có cách nào đưa issue về In Progress một cách sạch, buộc phải chỉnh tay lằng nhằng. Luôn thiết kế ít nhất một đường quay lại cho các pha kiểm thử/review.
- Nhồi mọi issue type vào một workflow: Bug, Story, Task có vòng đời khác nhau. Dùng workflow scheme để tách.
- Lạm dụng resolution: một lỗi kinh điển là để một số status "Done" mà không set field Resolution. Kết quả: issue trông như đã đóng nhưng vẫn bị JQL
resolution = EMPTYbắt là "chưa xong". Mẹo: luôn dùng post-function set Resolution khi vào category Done, và clear Resolution khi Reopen.
- Đổi workflow giữa sprint: gây rối dữ liệu và làm team hoang mang. Mẹo: chỉ thay đổi workflow ở ranh giới sprint, và thông báo trước.
- Mẹo naming: đặt tên status ở dạng trạng thái chứ không phải hành động. Dùng "In Review" thay vì "Review it"; dùng "In QA" thay vì "Test". Status là nơi issue đang ở, không phải việc cần làm.
Bài tập thực hành
- Vẽ workflow thật của team bạn. Lấy một issue gần nhất đã hoàn thành, truy ngược nó đã đi qua tay những ai, theo thứ tự nào. Vẽ ra thành sơ đồ status. Đối chiếu với workflow đang cấu hình trong Jira — chúng có khớp không? Nếu lệch, đó chính là chỗ dữ liệu report của bạn đang nói dối.
- Thiết kế workflow riêng cho Bug. Bắt đầu từ workflow phát triển chuẩn, thêm status Reopened và transition Done → Reopened. Viết ra: transition này cần condition gì, post-function gì (gợi ý: tự gán lại dev, tăng biến đếm số lần reopen).
- Rà soát status thừa. Liệt kê tất cả status hiện có trong project của bạn. Với mỗi status, viết một câu trả lời cho "đang chờ ai làm gì". Status nào bạn không viết được câu đó — đánh dấu là ứng viên để xóa/gộp.
- Kiểm tra category. Mở từng status trong project và ghi lại category của nó. Có status In Progress nào bị gán nhầm sang To Do hoặc Done không? Ghi lại và đề xuất sửa.
Tóm tắt
Workflow là bộ khung xương biến quy trình làm việc thật của team thành thứ Jira có thể theo dõi. Ba thành phần cần nắm: status (issue đang ở đâu, mỗi status có một category To Do / In Progress / Done), transition (đường đi được phép), và rule trên transition (condition, validator, post-function).
Nguyên tắc thiết kế cốt lõi: mỗi status phải trả lời được "issue đang chờ ai làm gì"; số status nên xấp xỉ số lần bàn giao thật giữa các vai trò; luôn gán đúng category vì report đọc theo category; tách workflow theo issue type bằng workflow scheme; và mỗi status mới nên gắn một cổng chất lượng thật chứ không chỉ đổi tên. Bắt đầu đơn giản với To Do → In Progress → Done, chỉ thêm status khi có một handoff thật cần theo dõi. Ở các bài sau, khi bạn dùng JQL và các report như burndown hay cumulative flow, bạn sẽ thấy chất lượng của những phân tích đó phụ thuộc hoàn toàn vào việc workflow hôm nay được thiết kế đúng đến đâu.