Mở đầu — vì sao bài này quan trọng
Nếu tôi phải chọn ra một khoảnh khắc mà tôi thấy nhiều BA fresher "vỡ mộng" nhất, thì đó là buổi họp requirement đầu tiên. Bạn ngồi đó, cầm cuốn sổ, chờ đợi khách hàng "đọc cho bạn chép" những gì họ muốn. Nhưng thực tế phũ phàng hơn: khách hàng nói lan man, mâu thuẫn, nói cái họ nghĩ họ muốn (chứ không phải cái họ thực sự cần), rồi ba tuần sau lại đổi ý. Và khi hệ thống làm ra sai, người bị hỏi đầu tiên chính là bạn — người BA.
Đây là lý do bài học này quan trọng. Elicitation là kỹ năng cốt lõi phân biệt một BA thật sự với một người chỉ biết "ghi biên bản". Nếu bạn không chủ động moi được yêu cầu đúng, thì mọi kỹ năng viết User Story, vẽ BPMN, làm data model ở các bài sau đều vô nghĩa — vì bạn đang xây nhà trên nền móng sai.
Trong bài này, tôi sẽ không dạy bạn cách viết tài liệu (đó là việc của Bài 32) hay cách vẽ user journey (Bài 39). Tôi tập trung đúng một thứ: 8 kỹ thuật để bạn lấy được yêu cầu từ đầu người khác ra giấy của bạn, và làm sao chọn đúng kỹ thuật cho đúng tình huống. Đây là thứ mà nhà tuyển dụng BA fresher rất hay hỏi trong phỏng vấn, và cũng là thứ giúp bạn "sống sót" trong 90 ngày đầu đi làm.
Khái niệm cốt lõi
Elicitation là gì — và không phải là gì
Trong tiếng Anh, động từ "elicit" nghĩa là khơi ra, moi ra, gợi ra một thứ gì đó đang tiềm ẩn. Người ta cố tình không dùng từ "collect" (thu thập) hay "gather" (gom góp), vì hai từ đó ngụ ý yêu cầu đã nằm sẵn ở đâu đó, bạn chỉ việc nhặt lên. Sự thật thì ngược lại: phần lớn yêu cầu chưa tồn tại ở dạng lời nói rõ ràng trong đầu stakeholder. Chúng nằm ở dạng thói quen, giả định ngầm, nỗi đau chưa gọi tên, hoặc mâu thuẫn giữa các phòng ban.
Vì vậy hãy ghi nhớ định nghĩa này:
> Elicitation = quá trình BA chủ động moi (elicit) yêu cầu từ stakeholder và các nguồn khác, chứ không thụ động ghi nhận những gì được nói ra.
Sự khác biệt "chủ động" ở đây là điểm mấu chốt. BA thụ động hỏi: "Anh/chị muốn hệ thống làm gì?". BA chủ động hỏi: "Hiện tại quy trình duyệt đơn của anh mất bao lâu? Khâu nào hay bị kẹt? Nếu tôi bỏ được bước ký tay, anh có gặp rủi ro gì về kiểm toán không?". Câu hỏi đầu cho ra một danh sách chức năng mờ nhạt. Câu hỏi sau cho ra yêu cầu thật, có bối cảnh, có ràng buộc.
Vì sao stakeholder không tự nói ra yêu cầu đúng
Có ba lý do kinh điển, và bạn nên thuộc lòng vì phỏng vấn hay hỏi:
- Tri thức ngầm (tacit knowledge): Người làm nghiệp vụ lâu năm coi nhiều thứ là "hiển nhiên" nên họ quên không nói. Ví dụ kế toán không nói "hóa đơn phải làm tròn đến đồng" vì với họ đó là chuyện đương nhiên — nhưng lập trình viên thì không biết.
- Không biết cái mình chưa biết: Stakeholder không phải chuyên gia công nghệ, nên họ không hình dung được hệ thống có thể làm gì. Họ chỉ mô tả cái đang làm thủ công.
- Xung đột lợi ích ngầm: Phòng Sale muốn tạo đơn nhanh, phòng Kế toán muốn kiểm soát chặt. Không ai nói ra mâu thuẫn này; BA phải phát hiện.
8 kỹ thuật elicitation cho BA fresher
Dưới đây là 8 kỹ thuật phổ biến nhất, kèm khi nào nên dùng. Bạn không cần giỏi cả 8 ngay, nhưng phải biết chúng tồn tại và biết chọn.
| # | Kỹ thuật | Bản chất | Dùng tốt nhất khi |
|---|---|---|---|
| 1 | Interview (Phỏng vấn) | Hỏi trực tiếp 1-1 hoặc nhóm nhỏ | Cần hiểu sâu, có ít stakeholder, chủ đề nhạy cảm |
| 2 | Workshop | Họp có điều phối, nhiều bên cùng lúc | Cần thống nhất giữa nhiều phòng ban, gỡ mâu thuẫn nhanh |
| 3 | Observation (Quan sát) | Xem người dùng làm việc thật | Có tri thức ngầm, quy trình thủ công phức tạp |
| 4 | Document Analysis | Đọc tài liệu, quy trình, hệ thống cũ | Có sẵn tài liệu, thay thế hệ thống legacy |
| 5 | Survey / Questionnaire | Bảng hỏi gửi số đông | Nhiều người dùng ở xa, cần dữ liệu định lượng |
| 6 | Prototyping | Đưa bản nháp giao diện để lấy phản hồi | Stakeholder khó diễn đạt, cần "thấy mới biết" |
| 7 | Brainstorming | Nghĩ ý tưởng tự do rồi lọc | Giai đoạn đầu, cần nhiều lựa chọn giải pháp |
| 8 | Focus Group | Nhóm người dùng đại diện thảo luận | Muốn hiểu cảm nhận, ưu tiên của nhóm khách hàng |
Nguyên tắc vàng: không có kỹ thuật "tốt nhất", chỉ có kỹ thuật "phù hợp"
Một sai lầm của fresher là học được một kỹ thuật rồi dùng nó cho mọi thứ. Người giỏi luôn phối hợp: đọc tài liệu trước để có nền (Document Analysis), phỏng vấn để đào sâu (Interview), quan sát để kiểm chứng lời nói có khớp thực tế không (Observation), rồi làm workshop để chốt với nhiều bên (Workshop). Elicitation là một chuỗi, không phải một hành động đơn lẻ.
Tình huống thực tế
Tình huống 1 — Fresher hỏi sai câu, khách hàng "vẽ lại quy trình cũ"
Minh, một BA mới ra trường vào làm tại một công ty phần mềm ở Quận 7 (TP.HCM), được giao phỏng vấn chị trưởng phòng kho của một khách hàng bán lẻ để làm hệ thống quản lý tồn kho mới. Minh mở đầu: "Chị muốn hệ thống mới làm được gì ạ?". Chị kho trả lời trong 40 phút, mô tả y hệt phần mềm Excel cũ chị đang dùng — kể cả những thao tác thủ công thừa thãi như copy dữ liệu qua 3 sheet.
Kết quả: bản requirement đầu tiên của Minh chỉ là "số hóa cái Excel", không tạo ra giá trị gì. Sếp trả lại, bảo làm lại.
Diễn giải: Minh đã hỏi câu "muốn hệ thống làm gì" — câu này khiến stakeholder mô tả giải pháp cũ thay vì vấn đề thật. Lần thứ hai, Minh đổi hướng, dùng phối hợp Observation + Interview: anh xin xuống kho ngồi xem chị làm việc nửa buổi. Anh phát hiện chị mất 2 tiếng mỗi sáng chỉ để đối chiếu số tồn thực tế với sổ, vì hàng bị lệch mã. Đây mới là nỗi đau thật — thứ chị không hề nhắc trong buổi phỏng vấn vì chị coi việc lệch mã là "chuyện thường ngày".
Bài học: Hỏi về vấn đề và quy trình hiện tại, đừng hỏi về giải pháp mong muốn. Và khi có tri thức ngầm (thao tác quen tay), Observation mạnh hơn Interview.
Tình huống 2 — Workshop cứu vãn dự án mắc kẹt vì mâu thuẫn phòng ban
Một fintech tại Hà Nội xây app cho vay tiêu dùng. Suốt hai tuần, BA phỏng vấn riêng từng phòng: phòng Rủi ro muốn thêm 5 bước kiểm tra trước khi duyệt khoản vay; phòng Kinh doanh muốn khách vay được tiền trong dưới 3 phút. Mỗi lần phỏng vấn riêng, mỗi phòng đều "đúng" theo góc của họ, và tài liệu requirement mâu thuẫn nhau chan chát. Dự án đứng im.
BA lead quyết định tổ chức một workshop 2 tiếng, mời cả hai phòng cùng ngồi, có một người điều phối (facilitator) trung lập và một người ghi chép. Trên bảng, họ vẽ luồng duyệt vay và đánh dấu từng điểm mâu thuẫn. Khi ngồi chung, phòng Rủi ro nhận ra 3 trong 5 bước kiểm tra có thể tự động hóa bằng gọi API tới trung tâm thông tin tín dụng, không cần con người. Mâu thuẫn "nhanh vs an toàn" được giải trong một buổi — điều mà 2 tuần phỏng vấn riêng lẻ không làm được.
Bài học: Khi mâu thuẫn nằm giữa các stakeholder, phỏng vấn riêng chỉ khuếch đại mâu thuẫn. Workshop đưa họ vào cùng một phòng để tự thấy và tự chốt. Vai trò facilitator trung lập là chìa khóa — BA không phán ai đúng ai sai, mà dẫn dắt để họ tự thỏa thuận.
Tình huống 3 — Prototype nói thay ngàn lời
Một startup giáo dục ở Đà Nẵng muốn làm tính năng "báo cáo tiến độ học tập" cho phụ huynh. BA phỏng vấn phụ huynh, ai cũng nói "tôi muốn xem con học thế nào". Nhưng hỏi cụ thể muốn thấy gì, họ ú ớ. Yêu cầu quá mơ hồ, không thể viết User Story.
BA bèn dùng prototyping: dùng Figma phác nhanh 2 phiên bản màn hình báo cáo — một bản thiên về biểu đồ điểm số, một bản thiên về nhận xét bằng chữ của giáo viên. Khi đưa cho 8 phụ huynh xem, 7 người lập tức chỉ vào bản nhận xét bằng chữ và nói "tôi cần cái này, điểm số thì tôi xem trên sổ liên lạc rồi". Một phản hồi mà trăm câu phỏng vấn không moi ra được.
Bài học: Khi stakeholder không diễn đạt được bằng lời ("tôi cần thấy mới biết"), prototype biến yêu cầu trừu tượng thành thứ cụ thể để họ phản ứng. Với fresher, bạn không cần thiết kế đẹp — một wireframe giấy hoặc Figma thô là đủ.
Hướng dẫn từng bước
Đây là quy trình elicitation gọn gàng bạn có thể áp dụng ngay cho một buổi làm việc với stakeholder.
Bước 1 — Chuẩn bị trước (chiếm 50% thành công). Trước khi gặp bất kỳ ai, làm Document Analysis: đọc tài liệu dự án, quy trình cũ, hệ thống hiện có. Liệt kê những gì bạn đã biết và những khoảng trống cần hỏi. Đừng bao giờ đi phỏng vấn với đầu óc trống rỗng — đó là dấu hiệu của fresher thiếu chuyên nghiệp.
Bước 2 — Chọn kỹ thuật theo tình huống. Dùng bảng 8 kỹ thuật ở trên. Hỏi bản thân: Có bao nhiêu stakeholder? Có mâu thuẫn không? Có tri thức ngầm không? Họ có diễn đạt được bằng lời không? Câu trả lời sẽ chỉ cho bạn nên Interview, Workshop, Observation hay Prototype.
Bước 3 — Soạn câu hỏi mở, tập trung vào vấn đề. Chuẩn bị 5–8 câu hỏi mở (bắt đầu bằng "Anh/chị thường làm gì khi...", "Điều gì khiến...", "Kể cho tôi nghe về..."). Tránh câu hỏi đóng có/không và câu hỏi dẫn dắt về giải pháp.
Bước 4 — Trong buổi làm việc, dùng kỹ thuật "5 Whys" và diễn giải lại. Khi stakeholder nêu một yêu cầu, hỏi "tại sao" vài lần để chạm tới nguyên nhân gốc. Sau đó diễn giải lại ("Ý anh là..., tôi hiểu đúng chứ?") để xác nhận. Đây là kỹ thuật active listening cực kỳ quan trọng.
Bước 5 — Ghi chép và ghi âm (có xin phép). Ghi lại nguyên văn từ ngữ nghiệp vụ họ dùng. Đừng vội "dịch" sang ngôn ngữ kỹ thuật ngay tại chỗ, kẻo bạn hiểu sai mà không biết.
Bước 6 — Tổng hợp và gửi lại xác nhận trong 24 giờ. Sau buổi, viết bản tóm tắt yêu cầu và gửi lại stakeholder trong ngày để họ confirm. Trí nhớ phai rất nhanh; xác nhận sớm giúp bắt lỗi hiểu sai khi còn kịp.
Bước 7 — Lặp và phối hợp. Elicitation hiếm khi xong trong một buổi. Sau khi tổng hợp, bạn sẽ thấy khoảng trống mới — lại chọn kỹ thuật phù hợp và lặp lại.
Lỗi thường gặp & mẹo
Lỗi 1 — Hỏi câu dẫn dắt về giải pháp. "Chị có muốn thêm nút xuất Excel không?" khiến chị gật đầu dù chưa chắc cần. Hãy hỏi vấn đề: "Sau khi xem báo cáo, chị thường làm gì tiếp theo với số liệu đó?".
Lỗi 2 — Tin 100% vào lời nói. Điều người ta nói họ làm và điều họ thực sự làm thường khác nhau. Mẹo: luôn kiểm chứng lời nói bằng Observation hoặc bằng dữ liệu thật.
Lỗi 3 — Bỏ qua stakeholder "im lặng". Trong workshop, người nói to nhất không phải người có yêu cầu quan trọng nhất. Người dùng cuối (end user) thường ngồi im. Chủ động hỏi họ.
Lỗi 4 — Không chuẩn bị, hỏi lan man. Fresher hay sợ "chuẩn bị nhiều thành cứng nhắc". Ngược lại: chuẩn bị kỹ giúp bạn tự tin và linh hoạt hơn.
Lỗi 5 — Quên ghi lại thuật ngữ nghiệp vụ. Mỗi domain có tiếng lóng riêng ("đơn treo", "bill lỗi", "hàng âm kho"). Ghi lại và làm một glossary — nó cứu bạn rất nhiều lần sau này.
Mẹo vàng: Sau mỗi buổi, tự chấm điểm: "Mình đã moi ra được vấn đề gốc hay chỉ ghi lại mong muốn bề mặt?". Nếu chỉ có mong muốn bề mặt, bạn chưa elicit — bạn mới chỉ chép.
Bài tập thực hành
Bài 1 — Chọn kỹ thuật. Với mỗi tình huống sau, hãy chọn 1–2 kỹ thuật phù hợp nhất và giải thích lý do (2–3 câu mỗi câu):
- (a) Bạn cần hiểu vì sao nhân viên thu ngân hay bấm sai nút hoàn tiền.
- (b) Ba phòng ban đang cãi nhau về ai được quyền duyệt đơn giảm giá.
- (c) Bạn thay thế một hệ thống ERP cũ 10 năm, không còn tài liệu.
- (d) 2.000 người dùng ở khắp cả nước, bạn cần biết tính năng nào họ dùng nhiều nhất.
- "Chị có muốn hệ thống gửi email tự động không?"
- "Anh thấy giao diện này đẹp chứ?"
- "Bên mình cần tính năng lọc theo ngày đúng không?"
Tóm tắt
Elicitation là kỹ năng chủ động moi yêu cầu, không phải thụ động ghi biên bản. Stakeholder thường không tự nói ra yêu cầu đúng vì tri thức ngầm, vì không biết cái mình chưa biết, và vì mâu thuẫn lợi ích ẩn. Nhiệm vụ của bạn là xuyên qua các lớp đó.
Bạn có 8 kỹ thuật trong tay: Interview, Workshop, Observation, Document Analysis, Survey, Prototyping, Brainstorming và Focus Group. Không kỹ thuật nào "tốt nhất" — chỉ có kỹ thuật phù hợp với tình huống, và người giỏi luôn phối hợp nhiều kỹ thuật thành một chuỗi. Với fresher, hãy thành thạo Interview và Document Analysis trước.
Nhớ ba điều cốt lõi: (1) hỏi về vấn đề và quy trình hiện tại, không hỏi về giải pháp mong muốn; (2) luôn kiểm chứng lời nói bằng quan sát hoặc dữ liệu; (3) tổng hợp và gửi xác nhận sớm. Làm được ba điều này, bạn đã đứng trên nền móng vững để bước sang các bài tiếp theo về viết tài liệu và mô hình hóa yêu cầu.