BA là ai trong kỷ nguyên AI? — Định nghĩa lại vai trò từ "người ghi chép" thành"người kiến tạo giải pháp"

9 giờ sáng thứ Hai, Minh mở email và thấy một dòng ngắn gọn từ chị Lan Anh — Giám đốc Vận hành (COO) của Serene Hotels, chuỗi 5 khách sạn boutique tại Đà Nẵng, Hội An, Đà Lạt:

"Tôi muốn một app để khách đặt phòng online, giống mấy khách sạn lớn có."

Không có tài liệu đính kèm. Không có ngân sách. Không có deadline. Chỉ một câu, đúng 20 chữ, đủ để bắt đầu — hoặc đủ để phá hỏng — cả một dự án.

Minh là BA được giao phụ trách dự án này. Anh gọi nó là "Reso". Và trong 30 phút tiếp theo, Minh sẽ phải đưa ra một quyết định mà phần lớn BA mới vào nghề không nhận ra là mình đang phải đưa ra: forward email này cho Huy — Tech Lead của đội kỹ thuật — để anh ước lượng effort làm app, hay là gõ lại một email trả lời chị Lan Anh với đúng một câu hỏi?

Đây không phải là câu chuyện về kỹ năng viết tài liệu. Đây là câu chuyện về việc bạn chọn làm gì trong chính khoảnh khắc đầu tiên đó.

Sự thật cơ bản (First Principle)

Bóc hết các lớp vỏ về quy trình, template, chứng chỉ — chỉ còn lại một sự thật không thể chối cãi:

Mục đích của bất kỳ phần mềm hay dự án nào luôn là giải quyết một vấn đề kinh doanh thật — không phải để "có công nghệ mới".

Không ai trả tiền để có một cái app. Người ta trả tiền để có kết quả: bán được nhiều hơn, tốn ít chi phí hơn, mất ít khách hàng hơn, ra quyết định nhanh hơn. "App" chỉ là phương tiện — một trong nhiều phương tiện có thể — để đạt kết quả đó. Nếu Minh không biết chính xác vấn đề kinh doanh nào của Serene Hotels đang cần được giải quyết, thì dù đội của Huy có build ra một app đẹp, mượt, đúng scope tới từng pixel, dự án vẫn có thể là một thất bại hoàn toàn về mặt kinh doanh.

Đây là lý do một tài liệu yêu cầu (requirement document) "đẹp" không đồng nghĩa với "đúng". Một BA có thể viết ra 40 trang đặc tả chi tiết, được stakeholder ký duyệt, được đội dev triển khai đúng 100% — và toàn bộ nỗ lực đó vẫn vô giá trị, nếu ngay từ đầu nó được xây trên một hiểu lầm về vấn đề thật. Tài liệu đẹp không cứu được một giải pháp sai. First principle này là nền tảng cho mọi thứ sẽ được bàn trong series này.

Phân tích

Quay lại email của chị Lan Anh. Nếu Minh đóng vai "BA ghi chép" (order-taker), quy trình xử lý sẽ trông như thế này:

1. Đọc email → hiểu là "khách hàng muốn app đặt phòng".
2. Forward cho Huy kèm ghi chú: "Anh Huy ước lượng giúp em effort làm app đặt phòng online nhé."
3. Huy và đội dev bắt đầu phác thảo kiến trúc, chọn stack, break sprint.
4. Vài tuần sau, có một bản demo app đặt phòng — đúng như yêu cầu.

Nhìn thoáng qua, quy trình này không sai ở bất kỳ bước nào. Vấn đề là nó bỏ qua hoàn toàn một câu hỏi: "Tại sao chị Lan Anh cần cái này, và cần vào lúc này?"

Một câu yêu cầu ngắn gọn như "tôi muốn một app" gần như luôn luôn là phần nổi của một tảng băng. Nó là cách một người không chuyên về công nghệ diễn đạt một nhu cầu kinh doanh bằng ngôn ngữ giải pháp — vì đó là cách dễ nói nhất. Chị Lan Anh không phải là kỹ sư phần mềm; chị không có nghĩa vụ phải diễn đạt vấn đề của mình dưới dạng "chúng tôi cần cải thiện chỉ số X". Chị chỉ biết: "khách sạn lớn có app, chúng tôi thì chưa, và có gì đó đang không ổn." Việc dịch câu nói bề mặt đó thành vấn đề kinh doanh thật — đó chính xác là công việc mà một BA được trả lương để làm, chứ không phải công việc của khách hàng.

Ở đây, series Reso sẽ không tiết lộ ngay điều gì thực sự đứng sau yêu cầu của chị Lan Anh — các bài sau sẽ đào sâu dần bằng những kỹ thuật cụ thể (đặt câu hỏi, phân tích quy trình, phân tích dữ liệu...). Nhưng ngay tại thời điểm này, trước khi biết bất kỳ chi tiết nào, Minh — nếu là một BA kiến tạo giải pháp — đã có đủ căn cứ để KHÔNG hành động ngay theo yêu cầu bề mặt. Không phải vì anh nghi ngờ chị Lan Anh nói dối hay giấu thông tin, mà vì kinh nghiệm cho anh biết: yêu cầu ở dạng giải pháp ("tôi muốn X") gần như không bao giờ là điểm bắt đầu tốt để BA hành động — nó là điểm bắt đầu tốt để BA đặt câu hỏi.

Đây chính là ranh giới phân biệt hai vai trò tưởng như giống nhau nhưng khác nhau về bản chất.

Giải pháp

Sự khác biệt giữa hai kiểu BA không nằm ở kỹ năng viết tài liệu, mà nằm ở thời điểm họ dừng lại để hỏi "tại sao".

BA ghi chép (Order-Taker)

• Nhận yêu cầu → chuyển tiếp yêu cầu (cho dev, cho PM) gần như nguyên văn.
• Câu hỏi mặc định: "Làm cái này như thế nào?" (How)
• Thước đo thành công: tài liệu khớp với những gì khách hàng nói.
• Rủi ro: xây đúng thứ khách hàng nói, nhưng sai thứ khách hàng cần.
• Vai trò trong chuỗi giá trị: một trạm chuyển tiếp thông tin (relay station).

BA kiến tạo giải pháp (Solution Shaper)

• Nhận yêu cầu → dừng lại, đặt câu hỏi "vì sao" trước khi hỏi "như thế nào".
• Câu hỏi mặc định: "Vấn đề kinh doanh thật đằng sau yêu cầu này là gì?" (Why)
• Thước đo thành công: giải pháp cuối cùng tạo ra kết quả kinh doanh đo lường được, dù nó có thể không giống 100% những gì khách hàng mô tả ban đầu.
• Rủi ro được kiểm soát: có thể phải đề xuất một giải pháp khác với những gì khách hàng hình dung — đòi hỏi kỹ năng giao tiếp/thuyết phục (sẽ bàn ở bài 9) để không biến thành đối đầu.
• Vai trò trong chuỗi giá trị: cầu nối (bridge) giữa tư duy kinh doanh của khách hàng và tư duy giải pháp của kỹ sư.

Với case Reso, một BA kiến tạo giải pháp sẽ không trả lời email của chị Lan Anh bằng một bản kế hoạch dự án. Anh sẽ trả lời bằng một cuộc hẹn 30 phút, mang theo một bộ câu hỏi mở: "Điều gì khiến chị nghĩ đến việc này vào lúc này?", "Nếu có app rồi, điều gì sẽ khác đi trong công việc vận hành hằng ngày của chị?", "Ban giám đốc có đang đặt ra áp lực hay mục tiêu cụ thể nào liên quan đến việc này không?". Đây chưa phải là kỹ thuật đặt câu hỏi chi tiết (bài 3 sẽ đi sâu vào kỹ thuật "5 Whys" và nghệ thuật hỏi), mà là một quyết định về tư thế: chọn dừng lại thay vì chuyển tiếp.

Điều quan trọng cần nói rõ: BA kiến tạo giải pháp không phải là BA "làm khó" khách hàng bằng cách hỏi vặn vẹo. Ngược lại, đặt đúng câu hỏi ngay từ đầu là cách nhanh nhất để tránh lãng phí hàng tuần, hàng tháng công sức của cả đội — của chính Huy và các kỹ sư — vào một giải pháp không giải quyết được vấn đề thật.

Vì sao dịch chuyển này càng cấp thiết trong kỷ nguyên AI?

Trước đây, phần lớn thời gian của một BA đổ vào việc ghi chép: phỏng vấn stakeholder, chép lại từng câu, soạn tài liệu, format bảng biểu, làm workflow diagram. Đây là công việc tốn thời gian nhất, nhưng cũng là công việc AI ngày càng làm tốt và nhanh hơn con người — từ việc chuyển ghi âm cuộc họp thành bản nháp yêu cầu, đến việc gợi ý cấu trúc user story (chi tiết về cách khai thác AI cho việc này sẽ được bàn kỹ ở bài 12 của series).

Khi phần việc "chép lại" bị nén thời gian gần về 0, phần việc còn lại — phần AI chưa và khó có thể thay thế — chính là: hiểu đúng bối cảnh con người, phát hiện mâu thuẫn giữa lời nói và nhu cầu thật, và chịu trách nhiệm cho một đề xuất giải pháp. Đó là lý do định nghĩa vai trò BA buộc phải dịch chuyển: không phải vì "ghi chép" đã hết giá trị, mà vì nó không còn là phần khan hiếm nhất trong chuỗi giá trị của một BA nữa. Phần khan hiếm — và vì thế phần đáng đầu tư nhất — là năng lực đặt câu hỏi đúng và kiến tạo giải pháp.

📎 Actionable Template

Bạn đang là BA ghi chép hay BA kiến tạo giải pháp? — Bảng tự đánh giá nhanh

Áp dụng ngay cho tình huống của Minh với email của chị Lan Anh:

Cách đọc kết quả: nếu phần lớn câu trả lời của bạn là "Chưa" ở cột hành động cụ thể (không phải tư thế), đó là tín hiệu bạn đang trôi về phía "BA ghi chép" — cần dừng lại trước khi viết dòng tài liệu tiếp theo. Với Minh ở thời điểm này, câu trả lời đúng cho mọi cột "Chưa" không phải là hoảng loạn, mà là: đặt lịch hẹn, chuẩn bị câu hỏi, và chưa chốt bất kỳ giải pháp nào.

🧠 Tư duy phản biện
Khi khách hàng nói "tôi muốn X", câu hỏi không phải là "làm sao để có X nhanh nhất", mà là: nếu tôi xây đúng X như họ mô tả, và nó không giải quyết được vấn đề thật của họ — ai sẽ là người chịu trách nhiệm cho thất bại đó?

🔗 Case Study & Bài viết liên quan

Đây là chương mở đầu của hành trình Reso — case study xuyên suốt 12 bài của series "BA 4.0: Từ Phân tích đến Giải pháp", theo chân Minh từ email đầu tiên của chị Lan Anh cho đến khi dự án đi vào vận hành thật. Các lát cắt tiếp theo sẽ dần bóc tách vấn đề kinh doanh thật đứng sau yêu cầu "làm app" này.

Đọc tiếp: First Principles Thinking cho BA — nơi Minh áp dụng cụ thể tư duy "sự thật cơ bản" để chuẩn bị cho buổi hẹn với chị Lan Anh.

Kết

Minh chưa biết chính xác vấn đề thật của Serene Hotels là gì — và đó là điều bình thường ở ngày đầu tiên của bất kỳ dự án nào. Điều không bình thường là nếu anh giả vờ như mình đã biết, chỉ để tiết kiệm 30 phút đặt lịch hẹn.

Anh đóng email, mở lịch, và gõ một dòng mời họp gửi chị Lan Anh. Chưa có bản đặc tả nào được viết ra. Chưa có sprint nào được lên kế hoạch. Nhưng quyết định quan trọng nhất của cả dự án Reso — có lẽ là quyết định quan trọng nhất Minh sẽ đưa ra trong toàn bộ series này — vừa mới được đưa ra: dừng lại, và hỏi "vì sao" trước khi hỏi "như thế nào". Bài tiếp theo sẽ đi vào chi tiết cách Minh trang bị cho mình một công cụ tư duy cụ thể để chuẩn bị cho buổi hẹn đó.

Bài tiếp theo: First Principles Thinking cho BA