Một dự án ngân hàng số triển khai tính năng "mở tài khoản trực tuyến eKYC" có tới 11 stakeholder khác nhau: phòng tuân thủ (compliance), phòng rủi ro, đội vận hành chi nhánh, đội kỹ thuật bảo mật, đối tác định danh điện tử bên thứ ba, phòng marketing, và dĩ nhiên là khách hàng cuối. Mỗi nhóm có một tập yêu cầu khác nhau, đôi khi mâu thuẫn nhau ngay từ gốc — phòng compliance muốn thêm bước xác minh thủ công để giảm rủi ro gian lận, trong khi phòng marketing muốn luồng đăng ký dưới 90 giây để tối đa tỷ lệ chuyển đổi. Đây chính là công việc cốt lõi hàng ngày của một Business Analyst (BA): xác định đúng ai cần được lắng nghe, hỏi đúng câu hỏi, rồi tổng hợp hàng chục trang ghi chú phỏng vấn thành một bộ requirement mạch lạc mà cả team kỹ thuật lẫn ban lãnh đạo đều hiểu giống nhau. Công việc này tốn rất nhiều thời gian thủ công — soạn stakeholder map, viết interview guide, ngồi nghe lại transcript hàng giờ, rồi phát hiện ra hai stakeholder vừa nói hai điều trái ngược nhau nhưng không ai để ý.
AI không thay thế được năng lực đọc-hiểu-con-người của một BA giỏi, nhưng nó có thể rút ngắn đáng kể phần việc cơ học: dựng nháp stakeholder map trong vài phút, sinh ra bộ câu hỏi phỏng vấn bám sát mục tiêu dự án, tóm tắt transcript hàng chục trang thành bảng requirement có cấu trúc, và đặc biệt hữu ích ở việc phát hiện những mâu thuẫn tinh vi giữa các stakeholder mà con người dễ bỏ sót khi phải xử lý quá nhiều thông tin cùng lúc. Bài học này sẽ đi qua bốn kỹ năng thực chiến: dùng AI để lập power/interest grid (ma trận quyền lực/mối quan tâm) và kế hoạch giao tiếp, sinh interview guide theo từng nhóm stakeholder, tổng hợp output elicitation thành requirement có cấu trúc và có traceability, và cuối cùng là phát hiện xung đột nhu cầu giữa các bên để đưa ra phương án hòa giải.
Lập Bản Đồ Stakeholder Với AI — Quyền Lực, Mối Quan Tâm Và Nhu Cầu Giao Tiếp
Trước khi hỏi bất kỳ ai bất kỳ câu gì, một BA giỏi luôn dừng lại để trả lời câu hỏi nền tảng: "Ai thực sự cần tham gia vào quá trình elicitation (thu thập, khơi gợi yêu cầu) này, và họ cần được đối xử như thế nào?" Đây chính là mục đích của power/interest grid — công cụ kinh điển chia stakeholder thành bốn nhóm dựa trên hai trục: mức độ quyền lực (khả năng ảnh hưởng đến quyết định dự án) và mức độ quan tâm (mức độ dự án tác động trực tiếp đến công việc của họ). Bốn nhóm điển hình là: Quản lý chặt (quyền lực cao, quan tâm cao — cần tương tác thường xuyên, sâu), Giữ hài lòng (quyền lực cao, quan tâm thấp — cần cập nhật định kỳ nhưng không cần chi tiết), Giữ thông tin (quyền lực thấp, quan tâm cao — cần được lắng nghe kỹ dù không có quyền quyết), và Theo dõi tối thiểu (quyền lực thấp, quan tâm thấp — chỉ cần thông báo khi có thay đổi lớn).
Vấn đề thực tế là: xây một power/interest grid chính xác đòi hỏi BA phải hiểu cả cấu trúc tổ chức lẫn động lực chính trị nội bộ — thứ không nằm sẵn trong bất kỳ tài liệu nào. Với một hệ thống quản lý bán hàng đa kênh (omnichannel retail), danh sách stakeholder ban đầu có thể chỉ là "phòng kinh doanh, phòng IT, phòng kho vận" — nhưng khi đào sâu, còn có trưởng nhóm vận hành từng chi nhánh, đội chăm sóc khách hàng, đối tác vận chuyển thứ ba, và cả phòng tài chính (vì liên quan đến đối soát công nợ). AI rất giỏi trong việc mở rộng danh sách này từ một mô tả dự án ban đầu — nó đọc ra các actor tiềm ẩn mà một BA mới vào dự án dễ bỏ sót vì chưa nắm hết bức tranh tổ chức.
Điều AI không làm thay được là gán đúng mức độ quyền lực thực tế — quyền lực trên sơ đồ tổ chức (organizational chart) đôi khi khác xa quyền lực thực tế trong quyết định dự án. Một Trưởng phòng Vận hành có thể có chức danh thấp hơn Giám đốc Kinh doanh trên giấy tờ, nhưng lại là người thực sự quyết định liệu tính năng có được vận hành viên chấp nhận sử dụng hay không. BA vẫn phải là người xác nhận cuối cùng dựa trên quan sát thực tế và kinh nghiệm làm việc với tổ chức đó.
Các Bước Thực Hành
- Viết một đoạn mô tả ngắn (200-400 từ) về dự án — mục tiêu, phạm vi, các phòng ban liên quan đã biết — đưa vào AI để sinh danh sách stakeholder mở rộng, bao gồm cả những actor gián tiếp (đối tác bên ngoài, cơ quan quản lý, đội hỗ trợ vận hành).
- Đối chiếu danh sách AI sinh ra với sơ đồ tổ chức thực tế và kinh nghiệm cá nhân, gạch bỏ actor không liên quan, bổ sung actor AI bỏ sót (đặc biệt là các cá nhân có ảnh hưởng ngầm không xuất hiện trên tổ chức đồ).
- Với mỗi stakeholder còn lại, tự đánh giá sơ bộ mức quyền lực và mối quan tâm (Cao/Trung/Thấp) dựa trên hiểu biết thực tế, sau đó nhờ AI phản biện lại đánh giá đó bằng cách hỏi "vì sao stakeholder X lại được xếp quyền lực thấp trong khi họ ký duyệt ngân sách".
- Dựng bảng power/interest grid hoàn chỉnh, đặt lên Miro hoặc Confluence để cả team dự án cùng xem và góp ý — đây là bước bắt buộc, không nên giữ bản nháp AI làm bản chính thức mà không qua review nhóm.
- Với mỗi stakeholder, gắn kèm chiến lược giao tiếp cụ thể (tần suất, kênh, mức độ chi tiết thông tin) và nhập vào bảng RACI (Responsible/Accountable/Consulted/Informed) cho từng giai đoạn của dự án.
Ví Dụ Prompt
Bạn là một Business Analyst cấp cao, có kinh nghiệm phân tích stakeholder
cho các dự án ngân hàng số và fintech.
Dưới đây là mô tả dự án:
"Xây dựng tính năng mở tài khoản trực tuyến bằng eKYC (định danh điện tử)
cho một ngân hàng số. Mục tiêu giảm thời gian mở tài khoản từ 3 ngày
xuống dưới 5 phút. Các phòng ban đã biết liên quan: Sản phẩm số, Công
nghệ, Tuân thủ (Compliance), Rủi ro (Risk), Vận hành chi nhánh."
Hãy:
1. Liệt kê đầy đủ các stakeholder có thể liên quan, bao gồm cả những
actor gián tiếp dễ bị bỏ sót (đối tác định danh điện tử bên thứ ba,
cơ quan quản lý nhà nước, đội chăm sóc khách hàng, đội pháp chế,
đội marketing, đội bảo mật thông tin).
2. Với mỗi stakeholder, ước lượng sơ bộ mức độ quyền lực (Cao/Trung/
Thấp) và mối quan tâm (Cao/Trung/Thấp), kèm lý do ngắn gọn.
3. Xếp mỗi stakeholder vào một trong bốn nhóm của power/interest grid
(Quản lý chặt / Giữ hài lòng / Giữ thông tin / Theo dõi tối thiểu).
4. Đề xuất tần suất và kênh giao tiếp phù hợp cho từng nhóm (ví dụ:
họp tuần, báo cáo email hai tuần một lần, chỉ thông báo khi có
thay đổi lớn).
5. Xuất kết quả dưới dạng bảng Markdown: Stakeholder | Quyền lực |
Mối quan tâm | Nhóm | Tần suất giao tiếp | Kênh | Ghi chú.
Trả lời bằng tiếng Việt, giữ nguyên các thuật ngữ chuyên môn tiếng Anh
(stakeholder, eKYC, compliance, RACI).
Sau khi có bảng nháp, một prompt tiếp theo hữu ích là yêu cầu AI đóng vai "phản biện" để kiểm tra độ hợp lý của đánh giá:
Xem lại bảng power/interest grid dưới đây. Đóng vai một Project Sponsor
khó tính, hãy chỉ ra 3 điểm bất hợp lý hoặc thiếu logic trong cách xếp
loại (ví dụ: một phòng ban có quyền ký duyệt ngân sách nhưng lại bị xếp
quyền lực Thấp), và đề xuất điều chỉnh.
[PASTE BẢNG POWER/INTEREST GRID]
Mẹo: Đừng dừng lại ở bảng tĩnh một lần đầu dự án. Power/interest grid thay đổi theo giai đoạn — một đối tác định danh điện tử có thể ở nhóm "Theo dõi tối thiểu" lúc khảo sát yêu cầu, nhưng chuyển sang "Quản lý chặt" khi bước vào giai đoạn tích hợp kỹ thuật. Hãy nhờ AI dựng lại grid ở đầu mỗi giai đoạn lớn của dự án (discovery, thiết kế, triển khai, go-live), thay vì coi bảng đầu tiên là cố định suốt vòng đời dự án.
Sinh Bộ Câu Hỏi Và Interview Guide Cho Từng Nhóm Stakeholder Bằng AI
Một trong những sai lầm phổ biến nhất của BA khi mới vào nghề là dùng chung một bộ câu hỏi cho mọi buổi phỏng vấn, bất kể đối tượng là ai. Hỏi phòng compliance câu hỏi giống hệt câu hỏi hỏi đội vận hành chi nhánh sẽ khiến buổi phỏng vấn hời hợt với cả hai bên — compliance cần câu hỏi đào sâu về quy định, rủi ro pháp lý, còn vận hành chi nhánh cần câu hỏi về quy trình thực tế hàng ngày, các ngoại lệ họ phải xử lý thủ công. Interview guide (bộ hướng dẫn phỏng vấn) tốt phải được thiết kế riêng theo vai trò, mục tiêu buổi elicitation, và loại thông tin cần thu thập — functional requirement, non-functional requirement, pain point hiện tại, hay kỳ vọng về trải nghiệm.
AI đặc biệt mạnh ở việc sinh nhanh bộ câu hỏi có cấu trúc theo kỹ thuật phỏng vấn kinh điển như 5 Whys (hỏi "tại sao" liên tiếp để đào tới gốc rễ vấn đề), câu hỏi mở kiểu funnel (từ rộng đến hẹp dần), hoặc câu hỏi theo kịch bản (scenario-based) để khơi gợi ra các edge case mà stakeholder không tự nhớ ra khi được hỏi trực tiếp. Với một app đặt xe đang muốn thêm tính năng "đặt xe hộ người khác", một buổi phỏng vấn với đội vận hành tài xế cần câu hỏi khác hẳn buổi phỏng vấn với đội chăm sóc khách hàng — dù cả hai đều liên quan cùng một tính năng.
Một điểm cần lưu ý: AI sinh câu hỏi dựa trên pattern chung của ngành, nó không biết những chi tiết đặc thù nội bộ công ty bạn — ví dụ quy trình xử lý khiếu nại hiện tại đã có bước nào, hệ thống cũ tên gì, thuật ngữ nội bộ nào đang được dùng. BA cần đưa các thông tin này vào context của prompt, và luôn rà lại bộ câu hỏi trước khi gửi cho stakeholder, tránh hỏi những câu ngây ngô cho thấy chưa tìm hiểu gì về nghiệp vụ trước buổi phỏng vấn — điều này làm giảm uy tín của BA ngay từ câu hỏi đầu tiên.
Các Bước Thực Hành
- Xác định rõ mục tiêu của từng buổi elicitation trước khi soạn câu hỏi: đây là buổi khám phá pain point, buổi xác nhận requirement đã viết, hay buổi thu thập chi tiết acceptance criteria?
- Cung cấp cho AI vai trò cụ thể của stakeholder sắp phỏng vấn, bối cảnh dự án, và 2-3 câu hỏi "bắt buộc phải hỏi" mà bạn đã biết trước (business context), để AI mở rộng thêm câu hỏi bổ trợ đúng hướng.
- Yêu cầu AI phân loại câu hỏi theo từng giai đoạn buổi phỏng vấn: mở đầu (warm-up, xây dựng rapport), khai thác chính (core), và câu hỏi đóng (wrap-up, xác nhận hiểu đúng).
- Rà soát bộ câu hỏi AI sinh ra, loại bỏ câu hỏi mang tính dẫn dắt (leading question) hoặc câu hỏi đóng quá sớm (chỉ trả lời được có/không) ở phần khai thác chính — đây là lỗi AI hay mắc nếu không được nhắc rõ.
- Chuẩn bị sẵn bản ghi âm (Otter.ai hoặc Fireflies.ai) trước buổi phỏng vấn để không phải vừa hỏi vừa ghi chép tay, giúp BA tập trung lắng nghe và đặt câu hỏi đào sâu (follow-up) ngay tại chỗ khi cần.
Ví Dụ Prompt
Bạn là một Business Analyst chuẩn bị phỏng vấn elicitation yêu cầu cho
dự án sau:
Dự án: Hệ thống HRM nội bộ, module mới "Quản lý nghỉ phép tự động"
Đối tượng phỏng vấn: Trưởng phòng Nhân sự (HR Manager)
Mục tiêu buổi phỏng vấn: Hiểu quy trình duyệt nghỉ phép hiện tại,
các ngoại lệ đang xử lý thủ công, và kỳ vọng về tự động hóa.
Bối cảnh đã biết: hiện công ty duyệt nghỉ phép qua email và Excel,
có khoảng 5 loại nghỉ phép khác nhau (phép năm, ốm, không lương,
thai sản, việc riêng).
Hãy soạn một interview guide gồm:
1. 3 câu hỏi mở đầu (warm-up) để xây dựng rapport và hiểu bối cảnh
chung vai trò của người được phỏng vấn.
2. 8-10 câu hỏi khai thác chính, dùng kỹ thuật 5 Whys và câu hỏi theo
kịch bản (scenario-based) để đào sâu pain point và edge case (ví dụ:
nghỉ phép gấp không báo trước, xin nghỉ chồng lịch với người khác
trong team, nghỉ phép vượt quá số ngày còn lại).
3. 3 câu hỏi đóng để xác nhận lại hiểu biết và hỏi xem còn ai khác
nên được phỏng vấn thêm (stakeholder snowballing).
4. Với mỗi câu hỏi, ghi chú ngắn gọn mục đích thu thập thông tin gì
(functional requirement, non-functional, pain point, hay kỳ vọng
UX).
Tránh câu hỏi dẫn dắt (leading question) và câu hỏi đóng quá sớm ở
phần khai thác chính. Trả lời bằng tiếng Việt.
Với các buổi workshop nhóm hoặc JAD session (Joint Application Development session — buổi làm việc chung giữa nhiều stakeholder để thống nhất yêu cầu), prompt cần điều chỉnh để tính đến động lực nhóm:
Tôi sắp chủ trì một buổi JAD session với 6 người tham gia: 2 người
phòng Vận hành chi nhánh, 2 người phòng Compliance, 1 người phòng IT,
1 Product Owner. Mục tiêu: thống nhất luồng xử lý ngoại lệ khi khách
hàng mở tài khoản eKYC bị từ chối tự động nhưng có giấy tờ hợp lệ.
Hãy thiết kế agenda buổi workshop 90 phút gồm:
1. Cấu trúc thời gian từng phần (mở đầu, trình bày vấn đề, thảo luận
nhóm, chốt quyết định).
2. Bộ câu hỏi dẫn dắt thảo luận để đảm bảo cả nhóm ít tiếng nói (ví dụ
phòng Compliance) không bị lấn át bởi nhóm nói nhiều hơn.
3. Kỹ thuật xử lý nếu hai bên đưa ra yêu cầu mâu thuẫn ngay tại chỗ,
để không làm buổi workshop bế tắc.
4. Checklist đầu ra cần đạt được cuối buổi (ví dụ: sơ đồ luồng xử lý
ngoại lệ đã được cả 6 người đồng thuận, danh sách vấn đề còn tồn
đọng cần follow-up sau).
Mẹo: Luôn dành 5-10 phút cuối interview guide cho câu hỏi "Ai khác nên được tôi phỏng vấn về việc này mà tôi có thể đang bỏ sót?" — kỹ thuật này gọi là stakeholder snowballing, và nó thường xuyên phát hiện ra những actor quan trọng mà cả AI lẫn power/interest grid ban đầu đều không liệt kê, vì chỉ người trong cuộc mới biết ai thực sự nắm giữ thông tin then chốt.
Tổng Hợp Output Buổi Elicitation Thành Requirement Có Cấu Trúc
Đây là công đoạn tốn thời gian nhất trong quy trình elicitation truyền thống: sau một loạt buổi phỏng vấn và workshop, BA có trong tay hàng chục trang ghi chú, transcript được ghi âm, hoặc slide trình bày rời rạc — và phải biến tất cả thành một bộ requirement mạch lạc, có cấu trúc, sẵn sàng đưa vào backlog dưới dạng user story và acceptance criteria. Nhiều BA junior mất cả một ngày làm việc chỉ để nghe lại transcript và gạch chân ý chính, một công việc cơ học mà AI có thể rút xuống còn 30-45 phút nếu được hướng dẫn đúng.
Sức mạnh thực sự của AI ở bước này không chỉ là tóm tắt — mà là khả năng phân loại thông tin thô thành các nhóm có ý nghĩa nghiệp vụ: đâu là functional requirement (yêu cầu chức năng), đâu là non-functional requirement (yêu cầu phi chức năng như hiệu năng, bảo mật), đâu chỉ là ý kiến cá nhân chưa được xác nhận, đâu là pain point hiện tại cần giải quyết, và đâu là câu nói mơ hồ cần làm rõ thêm ở vòng phỏng vấn sau. Với một dự án hệ thống quản lý bán hàng đa kênh, một câu nói của trưởng phòng kho vận như "chúng tôi hay bị lệch tồn kho giữa kênh online và cửa hàng, nhất là dịp khuyến mãi" chứa đựng ít nhất ba tầng thông tin: một pain point cụ thể, một điều kiện xảy ra (dịp khuyến mãi — tức tải cao), và một gợi ý ngầm về yêu cầu đồng bộ tồn kho theo thời gian thực. AI có thể giúp tách các tầng này ra rõ ràng nếu được yêu cầu đúng cách.
Một nguyên tắc quan trọng cần giữ vững: mọi requirement được tổng hợp phải giữ được traceability (khả năng truy vết) ngược lại về nguồn gốc — ai đã nói câu đó, trong buổi nào, ngày nào. Đây không phải thủ tục hành chính thừa thãi; nó là công cụ sống còn khi sau này có tranh cãi về việc "ai yêu cầu tính năng này" hoặc khi cần quay lại xác nhận với đúng người đã phát biểu ý đó ban đầu. AI dễ đánh mất traceability nếu bạn chỉ yêu cầu nó "tóm tắt" mà không yêu cầu rõ ràng phải giữ trích dẫn nguồn.
Các Bước Thực Hành
- Ngay sau mỗi buổi phỏng vấn/workshop, xuất transcript từ Otter.ai hoặc Fireflies.ai (hoặc ghi chú tay đã đánh máy lại), đừng để dồn nhiều buổi rồi mới xử lý cùng lúc — thông tin dễ lẫn lộn nguồn gốc.
- Đưa transcript vào AI kèm yêu cầu phân loại rõ ràng theo loại thông tin (functional/non-functional/pain point/ý kiến chưa xác nhận), luôn giữ trích dẫn câu gốc và người nói.
- Chuyển các mục đã phân loại là functional requirement thành nháp user story theo cấu trúc chuẩn ("Là [vai trò], tôi muốn [chức năng], để [giá trị đạt được]"), kèm acceptance criteria sơ bộ.
- Đánh dấu rõ những điểm còn mơ hồ hoặc thiếu thông tin ("Cần làm rõ với ai, về việc gì") thay vì để AI tự suy đoán và điền vào chỗ trống — đây là lỗi nguy hiểm nhất khi dùng AI tổng hợp requirement.
- Đưa bản requirement nháp lên Confluence hoặc Jira, gắn link ngược về transcript gốc (traceability), rồi gửi lại đúng stakeholder đã phát biểu để họ xác nhận đã hiểu đúng ý (validation loop) trước khi đưa vào backlog chính thức.
Ví Dụ Prompt
Dưới đây là transcript buổi phỏng vấn với Trưởng phòng Kho vận về
tính năng đồng bộ tồn kho đa kênh (dự án: hệ thống quản lý bán hàng
đa kênh, kênh online + cửa hàng vật lý).
[PASTE TRANSCRIPT TỪ OTTER.AI/FIREFLIES.AI]
Hãy phân tích và xuất kết quả theo cấu trúc sau:
1. Danh sách Functional Requirement — mỗi mục kèm trích dẫn nguyên
văn câu nói gốc và mốc thời gian (timestamp) trong transcript.
2. Danh sách Non-Functional Requirement (hiệu năng, độ trễ đồng bộ,
độ tin cậy) nếu có đề cập, dù chỉ ngầm ý.
3. Danh sách Pain Point hiện tại — vấn đề người được phỏng vấn đang
gặp phải với quy trình/hệ thống cũ.
4. Danh sách các điểm CẦN LÀM RÕ THÊM — những câu nói mơ hồ, thiếu
số liệu cụ thể, hoặc có thể hiểu theo nhiều cách khác nhau. Không
tự suy đoán ý nghĩa, chỉ liệt kê rõ cần hỏi lại điều gì.
5. Với mỗi Functional Requirement, nháp một user story theo cấu trúc
"Là [vai trò], tôi muốn [chức năng], để [giá trị]" kèm 2-3 acceptance
criteria sơ bộ dạng Given/When/Then.
Giữ nguyên trích dẫn nguồn cho từng mục để đảm bảo traceability.
Trả lời bằng tiếng Việt, giữ thuật ngữ kỹ thuật tiếng Anh.
Khi có nhiều buổi phỏng vấn từ nhiều stakeholder khác nhau cùng chủ đề, một prompt tổng hợp chéo (cross-synthesis) sẽ giúp phát hiện điểm chung và điểm khác biệt:
Dưới đây là bản tóm tắt requirement đã trích xuất từ 4 buổi phỏng vấn
riêng biệt, cùng chủ đề "đồng bộ tồn kho đa kênh":
- Buổi 1: Trưởng phòng Kho vận
- Buổi 2: Trưởng phòng Kinh doanh Online
- Buổi 3: Quản lý cửa hàng khu vực miền Nam
- Buổi 4: Đội kỹ thuật (Tech Lead)
[PASTE 4 BẢN TÓM TẮT]
Hãy:
1. Liệt kê các requirement được TẤT CẢ hoặc ĐA SỐ stakeholder đồng
thuận (độ tin cậy cao, có thể đưa thẳng vào backlog).
2. Liệt kê các requirement chỉ xuất hiện ở MỘT stakeholder duy nhất
(cần xác nhận thêm xem có phải nhu cầu chung hay chỉ là ý kiến
cá nhân).
3. Chỉ ra bất kỳ mâu thuẫn nào giữa các stakeholder về cùng một chủ đề
(sẽ phân tích sâu hơn ở bước xử lý xung đột).
Mẹo: Đừng bao giờ để bản tổng hợp của AI đi thẳng vào backlog mà không qua bước "gửi lại xác nhận" với chính stakeholder đã phát biểu. AI diễn giải ngôn ngữ tự nhiên rất tốt, nhưng nó không có ngữ cảnh văn hóa tổ chức và không thể phân biệt được khi ai đó nói "chắc cũng nên có" (ý kiến nhẹ) với "bắt buộc phải có" (yêu cầu cứng) nếu giọng điệu không rõ ràng trong transcript — chỉ con người trực tiếp tham gia buổi phỏng vấn mới cảm nhận được sắc thái đó.
Phát Hiện Nhu Cầu Mâu Thuẫn Giữa Các Stakeholder Và Sinh Phương Án Giải Quyết
Mâu thuẫn giữa yêu cầu của các stakeholder không phải là điều bất thường — nó gần như chắc chắn xảy ra ở bất kỳ dự án nào có từ ba nhóm liên quan trở lên, vì mỗi nhóm tối ưu hóa cho mục tiêu khác nhau. Quay lại ví dụ ngân hàng số: phòng Compliance muốn thêm bước xác minh thủ công cho mọi hồ sơ có điểm rủi ro gian lận trên ngưỡng nhất định, trong khi phòng Marketing muốn luồng đăng ký hoàn toàn tự động dưới 90 giây để tối ưu tỷ lệ chuyển đổi. Cả hai yêu cầu đều hợp lý trong phạm vi trách nhiệm của từng phòng, nhưng chúng không thể cùng tồn tại nguyên vẹn trong một thiết kế duy nhất.
Vấn đề thực tế là những mâu thuẫn này thường không lộ rõ ngay khi phỏng vấn từng nhóm riêng lẻ — chúng chỉ hiện ra khi đặt các bản ghi yêu cầu cạnh nhau và so sánh. Một BA làm việc với 8-10 stakeholder qua nhiều tuần dễ bị "chìm" trong khối lượng thông tin và không tự phát hiện ra rằng yêu cầu của tuần thứ hai đang mâu thuẫn trực tiếp với ghi chú từ tuần đầu tiên. Đây chính là chỗ AI phát huy giá trị rõ rệt nhất trong toàn bộ quy trình elicitation: khả năng giữ toàn bộ context của nhiều buổi phỏng vấn cùng lúc và đối chiếu chéo, việc mà trí nhớ con người khó làm tốt khi khối lượng thông tin lớn.
Tuy nhiên, phát hiện mâu thuẫn chỉ là bước một. Bước quan trọng hơn — và cũng là bước đòi hỏi kỹ năng con người nhiều nhất — là đưa ra phương án giải quyết khả thi, thường dưới dạng đánh đổi (trade-off) có chủ đích thay vì chọn hẳn một bên và bỏ hoàn toàn bên còn lại. Với ví dụ eKYC ở trên, phương án dung hòa thực tế có thể là: chỉ áp dụng xác minh thủ công cho hồ sơ có điểm rủi ro trên ngưỡng cao (ví dụ 5% hồ sơ có rủi ro cao nhất), còn 95% hồ sơ còn lại vẫn được xử lý tự động dưới 90 giây — vừa giữ được mục tiêu tốc độ của Marketing, vừa đáp ứng yêu cầu kiểm soát rủi ro của Compliance. AI có thể giúp sinh ra nhiều phương án dung hòa như vậy để BA và các bên liên quan cùng thảo luận, nhưng quyết định cuối cùng — và việc thuyết phục các bên chấp nhận đánh đổi — vẫn thuộc về con người, vì nó đòi hỏi hiểu biết chính trị nội bộ và kỹ năng đàm phán mà AI không có.
Các Bước Thực Hành
- Sau khi tổng hợp requirement từ tất cả các buổi elicitation, gom toàn bộ vào một tài liệu duy nhất (hoặc một Confluence page tổng hợp) trước khi đưa vào AI phân tích chéo — đừng phân tích rời rạc từng buổi một.
- Yêu cầu AI quét toàn bộ requirement đã tổng hợp để tìm các cặp yêu cầu có khả năng mâu thuẫn trực tiếp (loại trừ lẫn nhau) hoặc mâu thuẫn gián tiếp (một yêu cầu làm giảm hiệu quả của yêu cầu khác).
- Với mỗi mâu thuẫn được phát hiện, xác nhận lại bằng cách đọc lại đúng trích dẫn nguồn (traceability) từ cả hai phía, tránh trường hợp AI hiểu sai ngữ cảnh và tạo ra mâu thuẫn giả (false positive).
- Với mâu thuẫn xác nhận là thật, nhờ AI sinh 2-3 phương án dung hòa khả thi, mỗi phương án nêu rõ ai được lợi, ai phải nhượng bộ, và mức độ nhượng bộ cụ thể (định lượng nếu có thể, ví dụ "5% hồ sơ" thay vì "một số hồ sơ").
- Tổ chức một buổi thảo luận ngắn (hoặc đưa vào JAD session tiếp theo) với đại diện các bên mâu thuẫn để chọn phương án cuối cùng, ghi lại quyết định và lý do vào requirement document — đây là bước bắt buộc có con người, không thể để AI tự chọn thay.
Ví Dụ Prompt
Dưới đây là bảng tổng hợp requirement đã thu thập từ 5 nhóm stakeholder
cho dự án "Mở tài khoản trực tuyến eKYC":
[PASTE BẢNG REQUIREMENT, mỗi dòng gồm: Requirement | Nguồn (stakeholder)
| Trích dẫn gốc]
Hãy phân tích và tìm các mâu thuẫn:
1. Liệt kê các cặp requirement mâu thuẫn TRỰC TIẾP (không thể cùng
tồn tại nguyên vẹn), nêu rõ requirement nào, từ stakeholder nào,
và bản chất mâu thuẫn là gì.
2. Liệt kê các cặp requirement mâu thuẫn GIÁN TIẾP (không loại trừ
nhau hoàn toàn nhưng một yêu cầu làm giảm hiệu quả/khó thực hiện
yêu cầu kia).
3. Với mỗi mâu thuẫn, đánh giá mức độ nghiêm trọng (Cao/Trung/Thấp)
dựa trên: có ảnh hưởng đến go-live date không, có liên quan đến
compliance/pháp lý không, có ảnh hưởng trải nghiệm khách hàng
trực tiếp không.
4. Với 3 mâu thuẫn nghiêm trọng nhất, đề xuất 2-3 phương án dung hòa
cho mỗi mâu thuẫn, mỗi phương án nêu rõ: bên nào được lợi, bên nào
phải nhượng bộ, mức độ nhượng bộ cụ thể (định lượng nếu có thể),
và rủi ro còn lại nếu chọn phương án đó.
Trả lời bằng tiếng Việt, trình bày dưới dạng bảng Markdown cho phần 1-3
và dạng danh sách có cấu trúc cho phần 4.
Khi cần chuẩn bị nội dung cho buổi họp hòa giải giữa các bên, một prompt hỗ trợ chuẩn bị kịch bản thảo luận cũng rất hữu ích:
Tôi sắp chủ trì buổi họp giữa phòng Compliance và phòng Marketing để
giải quyết mâu thuẫn: Compliance muốn xác minh thủ công mọi hồ sơ có
điểm rủi ro gian lận trên 70 điểm, Marketing muốn luồng đăng ký hoàn
toàn tự động dưới 90 giây cho mọi hồ sơ.
Hãy giúp tôi chuẩn bị:
1. Một đoạn mở đầu trung lập, không thiên vị bên nào, nêu rõ cả hai
mục tiêu đều chính đáng và mục đích buổi họp là tìm phương án
cùng thắng (win-win), không phải để một bên áp đảo bên kia.
2. 3 câu hỏi để hỏi phòng Compliance nhằm hiểu rõ ngưỡng rủi ro 70
điểm có phải con số cứng hay có thể điều chỉnh (ví dụ dựa trên dữ
liệu thực tế bao nhiêu % hồ sơ rơi vào ngưỡng này).
3. 3 câu hỏi để hỏi phòng Marketing nhằm hiểu rõ mục tiêu 90 giây có
áp dụng cho 100% hồ sơ hay có thể chấp nhận một tỷ lệ nhỏ hồ sơ
xử lý chậm hơn nếu tỷ lệ đó đủ nhỏ.
4. Một bảng so sánh 2 phương án dung hòa để trình bày trực quan tại
buổi họp.
Mẹo: Khi trình bày mâu thuẫn cho các bên liên quan, không bao giờ đóng khung nó bằng ngôn ngữ "phòng A sai, phòng B đúng" — luôn dùng ngôn ngữ trung lập kiểu "hai mục tiêu chính đáng đang cạnh tranh về cùng một nguồn lực". Cách đóng khung này (framing), tuy nhỏ, quyết định rất lớn đến việc buổi họp hòa giải có đi vào phòng thủ cá nhân hay tập trung tìm giải pháp — AI có thể giúp bạn soạn ngôn ngữ trung lập này rất tốt nếu bạn nhắc rõ yêu cầu "không thiên vị bên nào" ngay trong prompt.
Những Điểm Chính Cần Nhớ
AI có thể rút ngắn đáng kể phần việc cơ học trong stakeholder analysis và requirements elicitation — từ vài giờ xuống vài phút cho việc lập danh sách stakeholder, soạn interview guide, hay tóm tắt transcript hàng chục trang. Nhưng giá trị cốt lõi của một BA giỏi không nằm ở tốc độ xử lý thông tin, mà ở khả năng đọc hiểu con người, hiểu chính trị tổ chức, và đưa ra quyết định đánh đổi khi các bên có nhu cầu xung đột — những việc AI không thể làm thay.
Bốn nguyên tắc cần khắc sâu: thứ nhất, luôn coi output của AI là bản nháp cần review, không phải kết quả cuối — đặc biệt với power/interest grid, vì quyền lực thực tế trong tổ chức thường khác quyền lực trên giấy tờ. Thứ hai, interview guide phải được thiết kế riêng theo từng nhóm stakeholder và mục tiêu buổi phỏng vấn, tránh dùng một bộ câu hỏi chung chung cho mọi đối tượng. Thứ ba, mọi requirement tổng hợp từ AI phải giữ được traceability về đúng nguồn gốc (ai nói, buổi nào, ngày nào) và phải được gửi lại xác nhận với chính stakeholder trước khi đưa vào backlog chính thức. Thứ tư, phát hiện mâu thuẫn giữa các stakeholder là nơi AI mang lại giá trị rõ rệt nhất nhờ khả năng đối chiếu chéo nhiều nguồn cùng lúc, nhưng việc chọn phương án dung hòa và thuyết phục các bên chấp nhận đánh đổi vẫn luôn là công việc của con người.
Cuối cùng, hãy nhớ rằng công cụ — dù là ChatGPT, Claude, Notion AI, hay bất kỳ trợ lý AI nào khác — chỉ tốt bằng chất lượng context bạn đưa vào. Một prompt mơ hồ cho ra kết quả mơ hồ; một prompt có bối cảnh dự án cụ thể, vai trò rõ ràng, và yêu cầu định dạng đầu ra tường minh sẽ cho ra bản nháp chất lượng cao mà BA chỉ cần tinh chỉnh thay vì viết lại từ đầu.