Mở đầu — vì sao bài này quan trọng
Sau 48 bài học, bạn đã nắm rất nhiều mảnh ghép rời rạc: issue types, workflows, JQL, dashboards, automation... Nhưng trong thực tế, kiến thức rời rạc không giúp bạn ghi điểm với sếp hay với team. Cái team cần ở một BA giỏi công cụ là khả năng dựng một dự án JIRA từ con số 0 sao cho cả team dùng được, dùng đúng, và dùng lâu dài mà không phải đập đi xây lại sau ba tháng.
Đây chính là kỹ năng phân biệt một người "biết bấm JIRA" với một người "thiết kế được không gian làm việc trên JIRA". Trong nhiều công ty Việt Nam mình từng làm việc, người được giao setup JIRA cho team BA thường không phải dev, không phải PM, mà chính là BA senior — bởi BA hiểu rõ nhất quy trình tài liệu, luồng phê duyệt, và cách công việc phân tích nghiệp vụ trôi từ ý tưởng đến bàn giao.
Bài này là một hands-on lab trọn vẹn. Chúng ta sẽ không nói lý thuyết chung chung nữa. Bạn sẽ đóng vai một BA Lead vừa được tuyển vào một startup, được giao đúng một nhiệm vụ: mở JIRA lên và biến nó thành nơi làm việc thực sự cho cả nhóm BA. Cuối bài bạn sẽ có một checklist setup hoàn chỉnh có thể bê thẳng vào công ty thật.
Khái niệm cốt lõi
Trước khi bấm nút, cần hiểu một dự án JIRA "dùng được cho BA" gồm những lớp cấu hình nào. Hãy hình dung như xây nhà: phải có móng, có khung, rồi mới đến nội thất.
1. Project type — Team-managed hay Company-managed?
Đây là quyết định đầu tiên và quan trọng nhất.
- Team-managed project (trước đây gọi là Next-gen): mỗi project tự quản cấu hình riêng. BA Lead có thể tự tay sửa workflow, tạo custom field, đổi issue type mà không cần admin toàn hệ thống. Phù hợp với team nhỏ, muốn linh hoạt, tự chủ.
- Company-managed project (trước là Classic): dùng chung schema, workflow, field với các project khác trong tổ chức. Cấu hình nhất quán nhưng muốn đổi gì cũng phải qua JIRA Admin. Phù hợp công ty lớn, nhiều team, cần chuẩn hóa.
2. Các lớp cấu hình cần dựng
Một project hoàn chỉnh cho BA cần đủ các lớp sau, theo thứ tự ưu tiên:
- Project metadata: tên, key (mã viết tắt), avatar, lead.
- Issue types: BA cần gì trong các loại Epic / Story / Task / Bug / Sub-task đã học ở Bài 4. Thường BA thêm loại riêng như "BA Task" hoặc "Requirement".
- Workflow: các trạng thái mà một yêu cầu (requirement) đi qua. BA thường cần thêm bước "Đang phân tích" và "Chờ phê duyệt".
- Custom fields: trường thông tin riêng của BA như "Stakeholder", "Mức độ ưu tiên nghiệp vụ", "Link BRD".
- Board: Scrum hay Kanban, tùy cách team chạy.
- Components & Versions: phân loại công việc theo module sản phẩm.
- People & Permissions: ai vào được, ai sửa được gì.
Tình huống thực tế
Ví dụ 1 — FastBite: startup giao đồ ăn dựng JIRA từ con số 0
Bạn vừa gia nhập FastBite, một startup giao đồ ăn ở TP.HCM, vốn series A, đội ngũ 35 người trong đó có 4 BA. Trước đó team viết requirement bằng Google Docs rải rác, không ai biết yêu cầu nào đang ở giai đoạn nào. CTO giao bạn: "Tuần này dựng cho anh JIRA để team BA và team Dev nói chung một ngôn ngữ."
Bạn quyết định tạo một project Team-managed tên "FastBite Product", key là FBP. Bạn thêm issue type "BA Task" cho công việc phân tích thuần (ví dụ: "Phỏng vấn 5 nhà hàng về quy trình huỷ đơn"), và giữ Story cho yêu cầu sẽ chuyển cho dev. Bạn dựng custom field "Stakeholder" để ghi rõ ai là người đặt yêu cầu — vì ở FastBite, yêu cầu đến từ cả team Vận hành, team Marketing lẫn các nhà hàng đối tác.
Bài học: BA setup JIRA không sao chép template Scrum mặc định, mà điều chỉnh theo nguồn yêu cầu thực tế của doanh nghiệp. Custom field "Stakeholder" sau này giúp BA Lead lọc được "tất cả yêu cầu từ team Vận hành đang chờ phân tích" chỉ bằng một câu JQL.
Ví dụ 2 — Ngân hàng số Timo: khi linh hoạt phải nhường chỗ cho chuẩn hóa
Một BA tại Timo (ngân hàng số) được giao dựng project cho mảng tính năng thanh toán. Bạn này, vì mê sự linh hoạt, chọn Team-managed và tự chế workflow riêng. Ba tháng sau, bộ phận compliance yêu cầu mọi requirement phải đi qua đúng các bước phê duyệt chuẩn giống các project khác — vì lý do kiểm toán. Lúc này workflow tự chế của bạn không khớp, và việc di chuyển 200 issue sang Company-managed project tốn cả tuần.
Bài học: Trong môi trường có yêu cầu tuân thủ (compliance) như ngân hàng, bảo hiểm, fintech, hãy hỏi trước: "Tổ chức có chuẩn workflow bắt buộc không?" Nếu có, chọn Company-managed ngay từ đầu, dù mất chút linh hoạt. Chọn sai project type là cái giá đắt nhất khi setup.
Ví dụ 3 — Agency phần mềm Tiki Partner: một project, nhiều khách hàng
Một BA ở agency outsourcing dựng JIRA phục vụ ba khách hàng cùng lúc. Cô ấy ban đầu định tạo ba project riêng, nhưng nhận ra team BA chỉ có 3 người, nhảy qua lại ba project rất mệt. Giải pháp: dùng một project duy nhất, tách khách hàng bằng Components (Component "KH-A", "KH-B", "KH-C") và bằng custom field "Client". Board được lọc theo component để mỗi khách hàng có swimlane riêng.
Bài học: Số lượng project không nên nhiều hơn mức team có thể quản lý. Với team nhỏ, Components + custom field thường gọn gàng hơn việc đẻ ra nhiều project. Càng ít project, càng dễ báo cáo tổng hợp.
Hướng dẫn từng bước
Bây giờ vào việc thật. Chúng ta dựng project "FastBite Product" (key: FBP) cho team BA của FastBite. Bạn nên mở JIRA của mình lên và làm song song.
Bước 1 — Tạo project và đặt key chuẩn
Vào Projects → Create project. Chọn template Kanban (FastBite team BA chạy luồng liên tục, chưa cố định sprint). Chọn Team-managed.
- Project name:
FastBite Product - Key:
FBP— key này xuất hiện trong mọi issue (FBP-1, FBP-2...). Đặt ngắn 3 ký tự, viết hoa, dễ đọc khi nói chuyện. Tránh key dài nhưFASTBITEPROD. - Project lead: chính bạn (BA Lead).
Bước 2 — Cấu hình Issue Types cho BA
Vào Project settings → Issue types. Mặc định Kanban có Epic, Story, Task, Bug, Sub-task (đã học ở Bài 4). Với team BA, bổ sung:
- Đổi tên hoặc thêm type "BA Task" cho công việc phân tích (research, phỏng vấn, viết tài liệu) không phải code.
- Giữ Story cho yêu cầu sẽ bàn giao cho dev.
- Giữ Epic để gom các yêu cầu lớn theo tính năng (ví dụ Epic "Tính năng huỷ đơn").
Bước 3 — Tinh chỉnh Workflow
Vào Project settings → Workflows. Workflow Kanban mặc định thường là: To Do → In Progress → Done. Với BA, nên bổ sung trạng thái phản ánh đúng vòng đời requirement:
Backlog → Đang phân tích (Analyzing) → Chờ phê duyệt (Pending Review) → Sẵn sàng cho Dev (Ready for Dev) → Done
Thêm trạng thái "Chờ phê duyệt" cực kỳ quan trọng với BA, vì requirement luôn cần stakeholder ký duyệt trước khi dev bắt đầu. Đây là điểm khác biệt giữa board của BA và board của dev.
Bước 4 — Tạo Custom Fields
Vào Project settings → Fields (hoặc khi mở một issue, dùng tính năng tạo field nhanh trong Team-managed). Tạo:
- Stakeholder (User Picker hoặc Text): ai đặt yêu cầu.
- Mức độ ưu tiên nghiệp vụ (Select): Cao / Trung bình / Thấp — khác với Priority kỹ thuật.
- Link BRD (Text/URL): dán link tài liệu Confluence của yêu cầu (chúng ta sẽ liên kết JIRA–Confluence ở Bài 16 và 50).
Bước 5 — Cấu hình Board và Columns
Vào Board → cấu hình cột sao cho mỗi cột map đúng một trạng thái workflow ở Bước 3. Bật swimlane theo Epic hoặc theo Assignee để nhìn rõ ai đang ôm gì. Đặt WIP limit (giới hạn số việc đang làm) cho cột "Đang phân tích" — ví dụ tối đa 3 — để BA không ôm 10 requirement cùng lúc.
Bước 6 — Thêm Components
Vào Project settings → Components. Với FastBite, tạo các component theo module: Đặt hàng, Thanh toán, Giao vận, Nhà hàng đối tác. Component giúp lọc nhanh "tất cả yêu cầu mảng Thanh toán" và gán mặc định người phụ trách (component lead).
Bước 7 — Mời người và phân quyền
Vào Project settings → Access. Mời 4 BA và một vài dev lead. Trong Team-managed, có 3 vai trò sẵn: Admin / Member / Viewer. Cho BA Lead là Admin, các BA khác là Member, stakeholder bên Vận hành là Viewer (xem nhưng không sửa lung tung). Chi tiết phân quyền sâu hơn sẽ học ở Bài 20.
Bước 8 — Tạo vài issue mẫu và một filter
Tạo 5-7 issue thật để team thấy mẫu chuẩn: 1 Epic, 3 Story, 2 BA Task. Điền đầy đủ Stakeholder, Component, mô tả theo template. Sau đó lưu một filter kiểu project = FBP AND status = "Chờ phê duyệt" để BA Lead theo dõi việc cần duyệt (filter sẽ học kỹ ở Bài 35).
Bước 9 — Viết một trang "Quy ước dùng JIRA"
Đây là bước hay bị bỏ qua nhưng quyết định project sống hay chết. Viết ngắn gọn (trong Confluence, hoặc ngay description của project): khi nào dùng Story vs BA Task, trạng thái nào nghĩa là gì, ai được chuyển sang "Ready for Dev". Không có quy ước, mỗi người dùng một kiểu, và sau một tháng dữ liệu thành mớ hỗn độn.
Lỗi thường gặp & mẹo
Lỗi 1 — Setup quá phức tạp ngay từ đầu. Người mới hay tạo 8 issue type, 12 custom field, workflow 9 trạng thái. Kết quả: không ai dùng nổi. Mẹo: bắt đầu tối giản, thêm dần khi team thực sự kêu thiếu. "Bạn có thể thêm field bất cứ lúc nào, nhưng gỡ field đã có dữ liệu thì rất đau."
Lỗi 2 — Chọn nhầm project type. Chọn Team-managed rồi ba tháng sau bị buộc chuẩn hóa (như Timo ở trên). Mẹo: hỏi rõ về yêu cầu compliance và nhu cầu báo cáo tổng hợp đa team trước khi tạo project.
Lỗi 3 — Đặt key cẩu thả. Key quá dài hoặc trùng ý nghĩa. Mẹo: 2-4 ký tự, viết tắt tên sản phẩm, dễ đọc khi nói qua điện thoại.
Lỗi 4 — Quên phân quyền, để mọi người là Admin. Sau đó có người vô tình xoá workflow. Mẹo: nguyên tắc đặc quyền tối thiểu — chỉ BA Lead và admin là Admin, còn lại Member hoặc Viewer.
Lỗi 5 — Không có dữ liệu mẫu và không có quy ước. Team mở project trống trơn, không biết bắt đầu từ đâu. Mẹo: luôn tạo issue mẫu chuẩn + trang quy ước trước khi mời team vào.
Mẹo vàng: Sau khi dựng xong, hãy đóng vai một BA mới và thử tạo một issue từ đầu. Nếu bạn phải dừng lại tự hỏi "field này điền gì?" thì team của bạn cũng sẽ vấp đúng chỗ đó. Setup tốt là setup mà người mới dùng được trong 5 phút không cần hỏi.
Bài tập thực hành
Hãy tự tay dựng một project hoàn chỉnh theo kịch bản sau (dùng JIRA free tier nếu chưa có tài khoản công ty):
Kịch bản: Bạn là BA Lead của "GreenMart" — chuỗi siêu thị mini đang số hoá, team BA 3 người, chạy theo luồng Kanban. Yêu cầu đến từ team Vận hành cửa hàng và team Marketing.
- Tạo project Team-managed, đặt key hợp lý (gợi ý: GM). Giải thích vì sao bạn chọn Team-managed hay Company-managed.
- Cấu hình tối thiểu 4 issue type, trong đó có ít nhất 1 type riêng cho BA. Giải thích lựa chọn.
- Tinh chỉnh workflow có ít nhất một trạng thái "Chờ phê duyệt".
- Tạo đúng 3 custom field, mỗi field giải thích sẽ dùng để lọc hay báo cáo gì.
- Tạo 4 component theo module siêu thị (gợi ý: Bán hàng, Kho, Khách hàng thân thiết, Khuyến mãi).
- Tạo 6 issue mẫu điền đầy đủ thông tin.
- Lưu một filter giúp BA Lead theo dõi việc đang chờ duyệt.
- Viết trang "Quy ước dùng JIRA" dài tối đa 200 từ.
Tóm tắt
Setup một project JIRA cho team BA không phải là bấm nút "Create project" rồi xong. Nó là một bài thiết kế không gian làm việc, đòi hỏi bạn hiểu nguồn yêu cầu, vòng đời requirement và cách team sẽ báo cáo.
Những điểm cốt lõi cần nhớ:
- Chọn đúng project type trước tiên: Team-managed cho linh hoạt, Company-managed khi cần chuẩn hóa và compliance. Chọn sai là cái giá đắt nhất.
- Dựng theo lớp: metadata → issue types → workflow → custom fields → board → components → permissions. Mỗi lớp phục vụ một mục đích rõ ràng.
- Tối giản trước, tinh chỉnh sau: thêm field dễ, gỡ field có dữ liệu thì đau.
- Workflow của BA khác workflow của dev: luôn có bước "Đang phân tích" và "Chờ phê duyệt".
- Mỗi custom field phải phục vụ việc lọc hoặc báo cáo, nếu không thì đừng tạo.
- Issue mẫu + trang quy ước là thứ quyết định project sống hay chết, đừng bỏ qua.