--- title: "AI đổi gì trong công việc của BA?" url: "https://bahub.vn/khoa-hoc/ba-foundation/ai-doi-gi-trong-cong-viec-cua-ba" author: "Phan Minh Hoàng" published: "2026-08-16" updated: "2026-08-16" source: "bahub.vn" license: "Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc." --- # AI đổi gì trong công việc của BA? > Khâu nào trong việc của BA rẻ đi, khâu nào đắt lên, cách kiểm lại thứ AI làm hộ, và số liệu thật sự nói được gì về nghề. - Nguồn: https://bahub.vn/khoa-hoc/ba-foundation/ai-doi-gi-trong-cong-viec-cua-ba - Tác giả: Phan Minh Hoàng - Khoá học: BA Foundation (mục lục: https://bahub.vn/khoa-hoc/ba-foundation.md) - Chương: Quy trình và môi trường làm việc Bạn học BA giữa lúc tin tức bảo AI viết code được cả app. Câu hỏi thẳng: nghề bạn sắp học — **Business Analyst** — nên lo hay nên mừng? Câu trả lời ngắn của mình: **mừng nếu bạn làm phân tích thật; lo nếu bạn chỉ làm khâu chép lại.** Phần còn lại giải thích vì sao, bằng số liệu chứ không bằng khẩu hiệu. ## 1. Giai đoạn nào rẻ đi, giai đoạn nào đắt lên AI không xoá quy trình. Nó **đổi giá** từng khâu. | Giai đoạn | Xu hướng chi phí / công sức | Vì sao | | --------------------------------------------------------- | ---------------------------- | -------------------------------------------------------- | | Viết code nháp, dựng prototype (bản chạy thử) | **Rẻ đi** rõ | Công cụ sinh code, gợi ý hoàn thành hàm | | Soạn thảo tài liệu lần đầu, diễn đạt lại cho gọn | **Rẻ đi** | AI giỏi viết lại và liệt kê trường hợp “có thể sót” | | Làm rõ yêu cầu, chốt phạm vi, xử lý mâu thuẫn stakeholder | **Đắt lên** (tương đối) | Đây là nút thắt: máy không ngồi họp thay bạn | | Review (rà soát) code và hành vi nghiệp vụ | **Đắt lên** | Nhiều code hơn / nhanh hơn → cần mắt người hiểu ngữ cảnh | | Kiểm thử tính năng có AI trong sản phẩm | **Đắt lên và khác bản chất** | Không còn đúng/sai một dòng; cần bộ đánh giá | | Quyết định “làm gì / không làm gì” | **Vẫn đắt** | AI không chịu trách nhiệm business | ![Cán cân công sức dịch từ viết code sang làm rõ và rà soát](https://bahub.vn/uploads/2026/08/1786859612539-asjrvn-ai-doi-gi-trong-cong-viec-cua-ba-1.webp "Cán cân công sức dịch từ viết code sang làm rõ và rà soát") 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. ![Cùng một câu hỏi, mô hình có thể trả lời hai kiểu khác nhau](https://bahub.vn/uploads/2026/08/1786859664518-wspgc2-ai-doi-gi-trong-cong-viec-cua-ba-2.webp "Cùng một câu hỏi, mô hình có thể trả lời hai kiểu khác nhau") 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](https://www.iiba.org/career-resources/the-global-state-of-business-analysis/the-global-state-of-business-analysis-reports-and-surveys/the-global-state-of-business-analysis-2025/) 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](https://www.microsoft.com/en-us/research/publication/the-effects-of-generative-ai-on-high-skilled-work-evidence-from-three-field-experiments-with-software-developers/) ở 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](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) 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… ![Hai lối đi của nghề BA](https://bahub.vn/uploads/2026/08/1786859710100-2jq3lm-ai-doi-gi-trong-cong-viec-cua-ba-3.webp "Hai lối đi của nghề BA") ## 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.** --- Nguồn: https://bahub.vn/khoa-hoc/ba-foundation/ai-doi-gi-trong-cong-viec-cua-ba — Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc.