Các cấp độ dùng AI của một Senior BA

✍️ Hana · 🗓️ Tháng 11/2026 📚 Series: Bước đầu trở thành BA thời AI 🔢 Order: 1

Bốn cột tăng dần ghi cấp I đến IV, tương ứng AI là trợ lý, reviewer, người làm và cả team

---

Dùng AI nhiều chưa chắc đã dùng AI giỏi

Một BA mở ChatGPT 50 lần mỗi ngày vẫn có thể đang ở cấp độ thấp nhất. Cấp độ không đo bằng số lần hỏi AI. Nó đo bằng việc ai khởi động công việc, ai review, và tài liệu đi qua hệ thống của team như thế nào.

Mình mượn khung từ Build the Churches, Phần I của playbook The Agentic Awakening do Bessemer Venture Partners viết. Bài gốc viết cho engineering. Ý chính của họ: niềm tin thôi chưa đủ, phải "xây nhà thờ". Tức là xây hạ tầng, quy trình và người chịu trách nhiệm, để thói quen mới trở thành thực hành chung của tổ chức.

Bài này dịch khung đó sang công việc của BA. Mình dùng bối cảnh quen thuộc ở nhiều team outsource Việt Nam: tài liệu BA nằm trên GitLab, task và tiến độ nằm trên Redmine hoặc Jira.

---

Khung gốc: 4 cấp độ và 2 bước nhảy

Bài gốc chia mức độ tự chủ của AI thành 4 cấp, giống xe tự lái. Mỗi cấp trả lời một câu hỏi: AI đóng vai gì?

1. Driver assist - AI là trợ lý. Người cầm lái sát sao. Con người là nút thắt cổ chai.
2. Safety systems - AI là người review. AI gắn vào pipeline để kiểm tra. Dễ áp dụng vì không đổi cách làm việc.
3. Destination-led - AI là người làm. Agent chạy dài, tự viết và tự mở merge request. Một người chạy nhiều agent.
4. Fleet autonomy - AI là cả team. Việc tự được kích hoạt từ bug, sự cố, cuộc hội thoại. Con người chỉ duyệt những thay đổi có hệ quả.

Hai bước nhảy quan trọng nhất: từ trợ lý lên người làm là lúc bạn thôi đọc từng dòng. Từ người làm lên cả team là lúc hệ thống tự bắt đầu việc mà không cần bạn giao.

Nền móng phải có trước

Bài gốc nhấn mạnh: nền móng có 4 trụ, trụ nào yếu sẽ thành trần cho các trụ còn lại. Với BA, mình dịch như sau:

Theo khảo sát trong bài gốc, đo lường và bảo mật là hai trụ yếu nhất. Team BA cũng vậy: ai cũng dùng AI, nhưng ít ai trả lời được "nhanh hơn bao nhiêu" và "đã đưa dữ liệu khách hàng đi đâu".

---

Bối cảnh: GitLab giữ sự thật, Redmine/Jira giữ việc

Nguyên tắc mình dùng: GitLab là nơi duy nhất chứa nội dung yêu cầu. Redmine/Jira chỉ chứa việc cần làm và trạng thái. Ticket không copy nội dung spec, chỉ link tới file và merge request trên GitLab. Nhờ vậy, AI ở cấp nào cũng biết phải đọc ở đâu và ghi vào đâu.

Một repo tài liệu BA đơn giản:

ba-docs/
├── README.md            # quy ước, cách đặt tên, luồng review
├── glossary.md          # thuật ngữ nghiệp vụ
├── templates/           # user story, use case, BRD, SRS
├── features/
│   └── FEAT-012-refund/
│       ├── spec.md      # yêu cầu, business rule, AC
│       ├── flows.md     # sơ đồ Mermaid
│       └── open-questions.md
├── decisions/           # quyết định nghiệp vụ đã chốt với khách
└── CHANGELOG.md

Quy ước liên kết giữa hai hệ thống:

• Branch đặt theo ticket: ba/1234-refund-rule (Redmine) hoặc ba/SHOP-123-refund-rule (Jira).
• Commit ghi mã ticket: refs #1234 cho Redmine khi Redmine đã được nối với repository, hoặc SHOP-123 cho Jira qua tích hợp GitLab - Jira.
• Merge request là cổng duyệt: PO, tech lead và QA là reviewer. Merge vào main nghĩa là spec đã thành baseline.
• Ticket chuyển trạng thái theo MR: mở MR → In review, merge → Ready for dev.

Vòng đời một yêu cầu đi qua GitLab và Redmine/Jira: ticket chỉ giữ trạng thái, spec sống trên GitLab

Ticket chỉ đổi trạng thái theo merge request; mọi nội dung yêu cầu được viết, review và chốt trên GitLab. Các cấp độ bên dưới chỉ khác nhau ở chỗ: ai đi vòng này, BA hay agent.

Từ cấp II trở lên, AI cần quyền đọc và ghi vào cả hai hệ thống. Cách phổ biến hiện nay là MCP server: Atlassian có MCP server chính thức cho Jira, Redmine có các bản cộng đồng như redmine-mcp-server, GitLab cũng có nhiều bản MCP. Nếu chưa dùng MCP, REST API của cả ba công cụ đều đủ dùng.

---

Flow của BA ở từng cấp độ

Cùng một ví dụ xuyên suốt: khách muốn thêm tính năng hoàn tiền cho đơn hàng. Ticket là #1234 trên Redmine hoặc SHOP-123 trên Jira, tài liệu nằm ở features/FEAT-012-refund/.

Cấp I - AI là trợ lý: BA làm, AI gợi ý

AI không chạm vào GitLab hay Redmine/Jira. Mọi thứ đi qua copy-paste.

1. BA nhận ticket trên Redmine/Jira, đọc yêu cầu và biên bản họp.
2. BA dán bối cảnh vào cửa sổ chat. AI gợi ý câu hỏi làm rõ, nháp user story và acceptance criteria.
3. BA chỉnh sửa, tự tạo branch, commit spec.md, mở merge request.
4. BA tự cập nhật ticket, tự nhắc reviewer.

Dấu hiệu nhận biết: mỗi lần hỏi AI phải giải thích lại dự án từ đầu. Chất lượng phụ thuộc hoàn toàn vào kỹ năng prompt của từng người. Rủi ro lớn nhất: dán tài liệu khách hàng vào tài khoản AI cá nhân.

Cấp II - AI là người review: BA viết, AI soi

BA vẫn viết như cũ. Điểm khác là AI được gắn vào quy trình, chạy tự động mỗi khi có thay đổi.

1. BA mở merge request cho FEAT-012 trên GitLab.
2. GitLab CI gọi AI review spec và đăng comment vào MR:
   • thiếu mục so với template, AC chưa theo Given/When/Then;
   • thuật ngữ lệch với glossary.md;
   • mâu thuẫn với spec khác hoặc với decisions/;
   • câu mơ hồ kiểu "xử lý nhanh", thiếu edge case như hoàn tiền một phần.
3. BA sửa theo góp ý, người review thật chỉ còn tập trung vào nghiệp vụ.
4. Khi ticket có comment mới từ khách, AI tóm tắt "điều gì đã đổi so với spec".
5. Khi dev mở MR code, AI đối chiếu với AC trong spec và báo lệch.

Vì sao dễ bắt đầu: giống bài gốc nói, cấp này không bắt ai đổi cách làm việc. Với team BA, đây thường là bước có lợi nhuận cao nhất trên công sức bỏ ra.

Cấp III - AI là người làm: BA giao đích đến, agent ra bản nháp

BA không viết từng dòng nữa. BA mô tả đích đến, agent tự đi qua cả hai hệ thống.

1. BA giao ticket #1234 cho agent, kèm mục tiêu và phạm vi.
2. Agent đọc ticket, biên bản họp, spec liên quan, glossary và các quyết định đã chốt trên GitLab.
3. Agent tạo branch ba/1234-refund-rule, viết spec.md, flows.md dạng Mermaid và open-questions.md.
4. Agent mở MR, link về ticket, đề xuất tách story con ở dạng nháp trên Redmine/Jira.
5. BA review MR ở mức quyết định nghiệp vụ, mang open-questions.md đi chốt với khách.
6. Trong lúc đó, agent thứ hai phân tích tác động tới module thanh toán, agent thứ ba viết kịch bản kiểm thử cho QA.

Bước nhảy thật sự nằm ở đây: BA thôi đọc từng dòng, chuyển sang duyệt quyết định. Điều kiện cần là nền móng: template, glossary, decisions/ phải đủ tốt để agent có ngữ cảnh. Quyền ghi của agent phải bị giới hạn: được mở MR và tạo ticket nháp, không được merge hay đóng ticket.

Cấp IV - AI là cả team: hệ thống tự khởi động việc

Không ai cần giao việc. Sự kiện trong hệ thống tự kích hoạt agent.

1. Nguồn kích hoạt: change request mới từ khách, bug gắn nhãn requirement-gap, dev hỏi trên ticket, MR code thay đổi hành vi không có trong spec, biên bản họp mới.
2. Agent phân tích tác động, cập nhật spec trên branch mới và mở MR.
3. Agent tạo hoặc cập nhật ticket con, ghi CHANGELOG.md và bản nháp release note.
4. Nếu câu hỏi của dev đã có câu trả lời trong spec, agent trả lời trên ticket kèm link và tự đóng vòng.
5. Con người duyệt theo mức rủi ro:
   • sửa chính tả, định dạng, glossary: tự merge sau khi qua review AI;
   • thay đổi business rule hoặc phạm vi: BA và PO duyệt;
   • ảnh hưởng tới estimate, hợp đồng, pháp lý: PM và khách hàng ký duyệt.

Ở cấp này, BA không còn là người viết tài liệu. BA là người thiết kế hệ thống viết tài liệu: viết skill, rule, bộ kiểm tra chất lượng, và giữ các quyết định mà chỉ con người được ra.

---

So sánh nhanh 4 cấp độ

---

Lộ trình leo cấp và những cái bẫy

Bài gốc khuyên: xây nền móng, nhưng đừng chờ xây xong mới đổi cách làm việc. Chính lúc làm việc với agent sẽ lộ ra chỗ thiếu. Với team BA, mình đề xuất thứ tự sau:

1. Chốt chính sách dữ liệu trước tiên. Dùng tài khoản AI của công ty, tắt dùng dữ liệu để huấn luyện, ghi rõ tài liệu khách nào được đưa vào AI.
2. Đưa tài liệu về GitLab dạng Markdown. Word và Excel rải rác trên Drive là rào cản lớn nhất cho cấp III.
3. Viết template, glossary và thư mục decisions/. Đây là ngữ cảnh mà agent sẽ đọc. Context mới là lợi thế bền vững, công cụ thì thay đổi liên tục.
4. Bật AI review trong merge request. Đây là cấp II, không ai phải đổi thói quen.
5. Chỉ định một người sở hữu "hạ tầng AI" của team BA. Người này giữ bộ skill, prompt, kết nối MCP và cập nhật khi công cụ thay đổi.
6. Thí điểm cấp III trên một feature. Cho agent quyền mở MR và tạo ticket nháp, chưa cho merge.
7. Đo trước khi mở rộng. Chỉ lên cấp IV khi số liệu cho thấy cấp III ổn định.

Những chỉ số mình thấy có ích cho BA, chuyển thể từ nhóm chỉ số chất lượng trong bài gốc:

• thời gian từ lúc tạo ticket tới lúc spec được merge;
• tỷ lệ MR của agent được duyệt ngay lần review đầu;
• số lần spec bị sửa lại trong 2 tuần sau khi merge;
• số bug có nguyên nhân là hiểu sai yêu cầu;
• số câu hỏi dev đặt trên ticket cho mỗi feature.

Và những cái bẫy mình hay gặp:

• Đo số lượng thay vì chất lượng. Spec dài gấp đôi không có nghĩa là tốt gấp đôi. Bài gốc cũng cảnh báo dùng nhiều token chưa chắc đã hiệu quả.
• Để nội dung spec nằm ở cả ticket và GitLab. Hai nguồn sự thật thì agent sẽ đọc nhầm bản cũ.
• Review cho có. Duyệt mọi MR như nhau khiến người review mệt và bấm duyệt cho xong. Hãy phân loại theo rủi ro.
• Cho agent quyền quá rộng quá sớm. Agent đọc comment của khách cũng là đọc dữ liệu từ bên ngoài, nên có thể bị prompt injection. Agent đọc dữ liệu ngoài không nên có quyền merge.
• Nhảy cấp khi nền móng chưa có. Agent cấp III trên một đống file Word không template chỉ tạo ra nhiều bản nháp sai hơn, nhanh hơn.

---

Kết: BA không biến mất, BA đổi vai

Càng lên cấp cao, BA càng viết ít hơn và quyết định nhiều hơn. Những việc vẫn thuộc về con người: hiểu khách thật sự cần gì, đàm phán phạm vi, chịu trách nhiệm cho một business rule đã chốt.

Nhưng cấp độ của một BA không tách rời cấp độ của team. Một BA giỏi AI đến đâu cũng khó lên cấp III nếu tài liệu vẫn nằm trong file Word gửi qua email. Đó là lý do bài gốc gọi là "xây nhà thờ": thói quen cá nhân chỉ bền khi có nơi để nó trở thành thực hành chung.

Về phần mình: mình đang ở cấp II, và đang cùng team xây cấp III. Nên phần cấp III và IV ở trên là hướng mình đang đi dựa trên khung của bài gốc, chưa phải thứ đã chạy xong.

Bạn đang ở cấp nào? Và viên gạch nền móng nào team bạn đang thiếu?

---

Nguồn: Build the Churches - The Agentic Awakening (Bessemer Venture Partners). Các bài liên quan: Cách mình chạy workflow bằng skill cho AI · Cách mình viết PRD cùng với AI.