AI đổi gì trong công việc của BA?

Nói cách khác: quãng từ đặc tả rõ tới phần mềm chạy được ngắn lại. Quãng từ mớ mong muốn lộn xộn tới đặc tả rõ vẫn là của người — và thường là của BA.

2. Vì sao SDD và AI-DLC làm tăng giá trị nghề BA

Ở bài trước bạn gặp spec-driven development (SDD) và AI-DLC: đặc tả (specification) là nguồn sự thật; code là đầu ra. Agent (chương trình AI được giao việc) làm đúng những gì bạn viết — không hơn, không kém theo nghĩa “đoán ý sếp giúp bạn”.

Trước đây, spec viết ẩu vẫn chạy được, vì dev sẽ hỏi lại trong standup (họp ngắn hằng ngày), tự suy từ kinh nghiệm dự án trước, hoặc lấp chỗ trống bằng “chắc khách muốn vậy”.

Agent thì không đi uống cà phê hỏi lại theo cách đó. Viết mơ hồ → nó sinh ra thứ trông chỉn chu nhưng sai — và sai nhanh, nhiều hơn trước. Sửa muộn còn đắt vì cả chuỗi test và review đã chạy theo hướng sai.

Vì vậy mấy kỹ năng BA cổ điển bỗng thành nút thắt sản xuất: đặt đúng vấn đề (problem framing), khơi gợi yêu cầu (elicitation), phát hiện mâu thuẫn giữa các bên, viết tiêu chí chấp nhận (acceptance criteria) kiểm chứng được, hiểu nghiệp vụ ngành (domain).

Không phải “AI thay BA”. Là đội cần BA giỏi hơn khi máy đọc spec để sinh code.

3. Dùng AI cho việc của mình thì kiểm lại kiểu gì

AI viết trôi chảy. Đó vừa là cái lợi vừa là cái bẫy: một đoạn mô tả nghiệp vụ do máy sinh ra đọc rất mượt, câu nào cũng đúng ngữ pháp, thuật ngữ nào cũng có vẻ đúng chỗ — nên bạn khó nhận ra chỗ nó bịa.

Mình dính vài lần rồi mới rút ra được một thói quen: cái gì AI không thể biết thì phải tự kiểm.

Nó không biết công ty bạn quy định số dư tối thiểu bao nhiêu. Không biết phòng kế toán đang chốt sổ ngày mấy. Không biết hai tháng trước sếp đã bác một phương án y hệt. Những chỗ đó nó sẽ điền bằng một câu nghe rất hợp lý — và bạn là người ký tên dưới tài liệu.

Vài cách kiểm thực tế, làm được ngay cả khi bạn chưa đi làm:

• Đọc ngược từ dưới lên. Đọc xuôi thì não trôi theo mạch văn; đọc từng câu rời từ cuối lên đầu dễ bắt được câu nghe hay mà rỗng.
• Với mỗi con số, mỗi quy tắc nghiệp vụ trong bản nháp, tự hỏi mình lấy nó ở đâu. Không chỉ ra được nguồn thì đánh dấu lại rồi đi hỏi người thật.
• Đừng dán dữ liệu thật của khách vào công cụ AI công cộng.
• Tự viết bản nháp đầu tiên rồi mới đưa AI phản biện. Ngược lại thứ tự đó thì bạn đang học cách sửa bài của máy, chứ không phải học cách phân tích.

Ranh giới thì đơn giản: dùng AI để nháp, đừng dùng AI để chốt.

4. Số liệu nói gì

Nói trước cho sòng phẳng: gần như chưa có nghiên cứu nghiêm túc nào đo tác động của AI lên riêng nghề BA. Những thí nghiệm lớn nhất tới giờ đều đo lập trình viên. Ai bảo bạn "AI làm BA nhanh hơn X%" thì nhiều khả năng họ đang suy từ số của dev sang.

Thứ gần nhất có được là khảo sát nội bộ ngành: Global State of Business Analysis 2025 của IIBA hỏi hơn 2.380 người ở 171 quốc gia, khoảng 74% kỳ vọng AI tác động tích cực tới nghề. Đọc đúng bản chất: đây là kỳ vọng của người trong nghề, không phải thống kê việc làm hay lương. Người trong cuộc lạc quan là chuyện thường.

Còn hai thí nghiệm bên phía dev thì đáng biết vì một lý do khác. Một thử nghiệm trên 4.867 lập trình viên ở Microsoft và Accenture cho thấy nhóm dùng trợ lý AI hoàn thành nhiều việc hơn khoảng 26%, rõ nhất ở người ít kinh nghiệm. Ngược lại, METR cho 16 lập trình viên kỳ cựu làm việc trên kho mã họ đã thuộc lòng, kết quả là chậm hơn 19%.

Chi tiết đáng nhớ nhất không nằm ở hai con số đó, mà ở chỗ: nhóm của METR tự đánh giá là mình nhanh hơn 20%, trong khi đồng hồ nói ngược lại.

Đó mới là phần liên quan tới bạn. Sớm muộn sẽ có ngày công ty triển khai một công cụ AI rồi hỏi "có hiệu quả không". Nếu bạn trả lời bằng cảm nhận của đội, bạn có thể sai tới bốn mươi điểm phần trăm. Đo đi — thời gian làm rõ một yêu cầu, số lần phải làm lại, số lỗi lọt sau khi bàn giao. Đúng cái nghề này vẫn làm với mọi giải pháp khác.

5. Ai thực sự có nguy cơ

Rủi ro cao hơn ở BA (hoặc “BA trên giấy”) chỉ làm khâu chép lại: ghi biên bản họp rồi đổi tên file thành “BRD”, chuyển lời khách thành ticket Jira không thêm phân tích, copy-paste requirement giữa Confluence và slide, không bao giờ hỏi “vì sao”, không chỉ ra mâu thuẫn, không đề xuất cắt phạm vi.

Phần soạn thảo máy làm được ngày càng ổn. Phần quyết định và làm rõ thì không.

Ít rủi ro hơn — thậm chí đắt giá hơn — khi bạn ngồi được với người dùng thật và khơi đúng nỗi đau, tách “khách muốn” khỏi “khách cần”, viết acceptance criteria mà QA và agent đều kiểm được, đọc được số liệu và thiết kế experiment nhỏ để đo giải pháp, nói được tiếng domain: bảo hiểm, ngân hàng, logistics, giáo dục…

6. Kỹ năng nào tăng giá — và vài lời cho người mới

Tăng giá thì không phải list chứng chỉ. Mấy thứ này đang đắt thật:

1. Đặt đúng vấn đề — trước khi ai đó nhảy vào giải pháp (kể cả giải pháp AI).
2. Elicitation — hỏi, quan sát, prototype sớm để stakeholder phản ứng trên thứ sờ được.
3. Phát hiện mâu thuẫn — giữa phòng ban, giữa quy trình và hệ thống, giữa OKR và backlog.
4. Viết tiêu chí chấp nhận kiểm chứng được — theo mẫu Given/When/Then (cho trước tình huống gì, khi người dùng làm gì, thì hệ thống phải ra kết quả gì), kèm ví dụ số và các trường hợp biên.
5. Hiểu nghiệp vụ ngành — AI generic không thay được context công ty bạn.
6. Đo lường — metric, baseline, experiment; nhớ METR ở trên.

Còn nếu bạn chưa đi làm, mấy việc nhỏ này hữu ích hơn “học tool cho đủ bộ”:

Học một domain nhỏ đến mức kể được quy trình end-to-end (ví dụ: đặt hàng → thanh toán → hoàn tiền). Mỗi lần viết requirement, hỏi thử: “Agent đọc câu này sẽ làm đúng ý mình không?” Nếu không, câu đó còn mơ hồ. Dùng AI để nháp, không dùng AI để chốt — bạn chịu trách nhiệm từng dòng gửi stakeholder. Tập review: lấy một PR hoặc một đoạn spec AI sinh, viết ra 5 chỗ sai nghiệp vụ hoặc thiếu điều kiện biên. Tool thì học được; cái nguy hiểm hơn là không đo. Portfolio (hồ sơ việc làm) nên có case “tôi làm rõ X, cắt Y, acceptance criteria Z”, không chỉ “tôi biết vẽ user story”.

7. Lo hay mừng?

Mừng nếu bạn đang học đúng lõi BA: làm rõ, kết nối người, viết được thứ máy và người cùng hiểu, đo được kết quả.

Lo nếu kế hoạch nghề nghiệp của bạn là “ngồi ghi chép và chuyển ticket”.

AI rút ngắn đường từ spec tốt tới code chạy. Nó không rút ngắn đường từ hỗn loạn tới spec tốt — đoạn đó đang đắt hơn, và là chỗ bạn kiếm sống.

Khoá này còn bài riêng về công cụ AI cho BA ở phần sau. Trước khi mở tool, giữ một thói quen: đo, đừng chỉ hỏi cảm nhận.