Mở đầu — vì sao bài này quan trọng
Khi còn làm QA/Tester, công việc lấy thông tin của bạn thường khá đơn giản: tài liệu đã có sẵn (test plan, spec), bug thì tự nó "lộ ra" khi bạn chạy test, và nếu thiếu thông tin thì bạn ping dev hoặc BA một câu trên Slack là xong. Bạn là người nhận requirement, không phải người moi requirement.
Khi chuyển sang BA, mọi thứ đảo ngược. Bây giờ bạn là người phải đi tìm, đào, gợi mở và làm rõ requirement — từ những con người bận rộn, đôi khi không biết chính xác họ muốn gì, đôi khi mâu thuẫn với nhau, đôi khi giấu thông tin. Hoạt động này trong nghề BA có một tên riêng: Elicitation (khơi gợi/thu thập yêu cầu). Lưu ý đây không phải là "gathering" (thu nhặt) — vì requirement hiếm khi nằm sẵn đó để bạn nhặt. Phần lớn nó nằm trong đầu stakeholder dưới dạng ngầm ẩn (tacit), và việc của BA là khơi nó ra.
BABOK v3 — bộ khung kiến thức chuẩn của ngành BA (sẽ được nói sâu ở Bài 13) — dành hẳn một Knowledge Area cho "Elicitation and Collaboration". Trong đó liệt kê một bộ kỹ thuật mà BA chuyên nghiệp dùng để lấy thông tin. Bài này tập trung trọn vẹn vào 9 kỹ thuật elicitation cốt lõi: hiểu mỗi kỹ thuật là gì, khi nào dùng, và — quan trọng với người từ QA — kỹ thuật nào bạn đã vô tình dùng giỏi từ thời làm tester mà chưa biết tên gọi của nó.
Tin vui: nền QA cho bạn lợi thế lớn ở ít nhất ba kỹ thuật (document analysis, observation, interview kiểu điều tra). Tin cần lưu ý: có vài kỹ thuật bạn sẽ thấy "lạ" vì QA hiếm khi chạm tới (workshop điều phối, focus group). Hết bài này bạn sẽ có một bộ công cụ rõ ràng để chọn đúng kỹ thuật cho từng tình huống thay vì lúc nào cũng chỉ biết... gửi email hỏi.
Khái niệm cốt lõi
Elicitation không phải một hành động đơn lẻ mà là một nhóm hoạt động. BABOK chia thành ba bước lớn: chuẩn bị (prepare) → tiến hành (conduct) → xác nhận kết quả (confirm). Nhưng linh hồn của nó nằm ở việc chọn đúng kỹ thuật để conduct. Dưới đây là 9 kỹ thuật bạn phải nắm.
1. Interview (Phỏng vấn)
Hỏi trực tiếp một hoặc một nhóm nhỏ stakeholder. Có hai dạng: structured (câu hỏi soạn sẵn) và unstructured (trò chuyện mở, đào sâu theo câu trả lời). Đây là kỹ thuật phổ biến nhất và là kỹ thuật người-từ-QA dễ làm tốt, vì bản chất việc điều tra một bug ("tái hiện thế nào? bước nào fail? môi trường gì?") chính là phỏng vấn có cấu trúc.2. Workshop (Hội thảo điều phối)
Tập hợp nhiều stakeholder vào một phòng (thật hoặc online) để cùng đào và chốt requirement trong thời gian ngắn. BA đóng vai facilitator — người điều phối, không phải người phát biểu nhiều nhất. Hiệu quả cao vì giải quyết mâu thuẫn ngay tại chỗ, nhưng đòi hỏi kỹ năng dẫn dắt mà QA ít có cơ hội rèn.3. Observation (Quan sát / Shadowing)
Ngồi cạnh và quan sát người dùng thật làm việc trong môi trường thật. Có passive (chỉ nhìn, không can thiệp) và active (vừa nhìn vừa hỏi). Cực mạnh để phát hiện những bước người dùng làm theo thói quen mà họ không kể trong phỏng vấn. QA quen "shadow" hệ thống; giờ bạn shadow con người.4. Document Analysis (Phân tích tài liệu)
Đọc và rút requirement từ tài liệu sẵn có: quy trình cũ, hợp đồng, spec hệ thống legacy, báo cáo. Đây là siêu năng lực bẩm sinh của người từ QA — bạn đã quen đọc spec dày, soi mâu thuẫn giữa các phần, phát hiện chỗ thiếu logic.5. Survey/Questionnaire (Khảo sát)
Gửi bộ câu hỏi cho số đông để thu thập dữ liệu định lượng hoặc định tính ở quy mô lớn. Dùng khi cần ý kiến của hàng trăm người mà phỏng vấn từng người là bất khả thi. Mấu chốt là thiết kế câu hỏi tốt (closed-ended để đếm, open-ended để hiểu).6. Brainstorming (Động não)
Tạo ra càng nhiều ý tưởng càng tốt trong thời gian ngắn, không phán xét trong lúc nghĩ. Dùng khi cần khám phá giải pháp, tìm rủi ro tiềm ẩn, hoặc liệt kê các trường hợp. Người QA giỏi brainstorm... edge case — kỹ năng đó chuyển thẳng sang đây.7. Focus Group (Nhóm tập trung)
Một nhóm 6–12 người đại diện cho người dùng/khách hàng được mời thảo luận có dẫn dắt về một sản phẩm/ý tưởng. Khác workshop ở chỗ: focus group nhằm thu quan điểm và cảm nhận của người dùng, không nhằm chốt requirement nội bộ.8. Prototyping (Tạo mẫu)
Dựng bản mẫu (wireframe, mockup, clickable prototype) để stakeholder nhìn và phản hồi. "Trăm nghe không bằng một thấy" — nhiều requirement chỉ lộ ra khi người ta nhìn thấy thứ gì đó cụ thể để chê. Rất hợp với người tư duy chi tiết như QA.9. Interface Analysis (Phân tích giao tiếp hệ thống)
Xác định và làm rõ các điểm tương tác giữa hệ thống với hệ thống khác, hoặc giữa các thành phần (API, file trao đổi, màn hình bàn giao giữa các phòng ban). Đây là chỗ kinh nghiệm API testing / integration testing của bạn tỏa sáng — bạn vốn đã hiểu input/output, contract, error handling ở các interface.> Mẹo ghi nhớ: 9 kỹ thuật rơi vào 3 nhóm theo "nguồn thông tin". Từ con người (Interview, Workshop, Observation, Survey, Focus Group). Từ tài liệu/hệ thống (Document Analysis, Interface Analysis). Từ sự sáng tạo/trực quan (Brainstorming, Prototyping). Nhớ theo nhóm dễ hơn nhớ rời.
Không có kỹ thuật nào "tốt nhất". BA chuyên nghiệp luôn phối hợp nhiều kỹ thuật: ví dụ document analysis để nắm bối cảnh trước → interview để đào sâu → workshop để chốt → prototyping để xác nhận. Việc chọn kỹ thuật phụ thuộc vào: thời gian, số lượng stakeholder, mức độ rõ ràng của vấn đề, và văn hóa tổ chức.
Tình huống thực tế
Ví dụ 1 — Document Analysis cứu dự án ngân hàng (lợi thế của người từ QA)
Chị Lan, từng là QA 4 năm tại một công ty fintech ở TP.HCM, mới chuyển sang vai trò BA cho dự án số hóa quy trình mở thẻ tín dụng của một ngân hàng. Stakeholder phía ngân hàng cực kỳ bận, mỗi tuần chỉ cho họp 30 phút. Nếu lao vào phỏng vấn ngay, chị sẽ phí thời gian quý giá để hỏi những thứ đã nằm trong tài liệu.Chị Lan làm theo bản năng QA: trước cuộc họp đầu tiên, chị xin và đọc kỹ 3 tài liệu — quy trình mở thẻ hiện hành (bản Word 40 trang), thông tư của Ngân hàng Nhà nước về điều kiện cấp thẻ, và spec hệ thống core cũ. Đọc xong, chị phát hiện mâu thuẫn: tài liệu quy trình ghi "duyệt thủ công bởi 2 cấp" nhưng thông tư cho phép duyệt tự động với hạn mức dưới 50 triệu. Chị ghi lại thành danh sách 12 câu hỏi sắc bén.
Kết quả: cuộc họp 30 phút đầu tiên, thay vì hỏi lan man, chị đặt thẳng 12 câu hỏi đó. Trưởng phòng tín dụng bất ngờ: "BA mới mà đã đọc cả thông tư à?". Niềm tin được thiết lập ngay lập tức.
Bài học: Document Analysis nên là kỹ thuật đầu tiên khi vào dự án có sẵn tài liệu. Người từ QA có lợi thế tự nhiên vì đã quen đọc tài liệu dày và soi mâu thuẫn. Đừng phỏng vấn để hỏi những gì tài liệu đã trả lời — hãy phỏng vấn để hỏi những gì tài liệu bỏ trống hoặc mâu thuẫn.
Ví dụ 2 — Observation phát hiện thứ phỏng vấn không thấy (sàn TMĐT)
Anh Huy chuyển từ QA sang BA tại một công ty thương mại điện tử ở Hà Nội, phụ trách dự án cải tiến công cụ xử lý đơn hàng cho nhân viên kho. Qua phỏng vấn, các nhân viên kho đều nói: "Phần mềm ổn, không có vấn đề gì lớn". Nhưng số liệu cho thấy thời gian xử lý mỗi đơn vẫn cao bất thường — trung bình 4 phút/đơn, trong khi mục tiêu là 2 phút.Phỏng vấn không ra vấn đề, nên anh Huy đổi sang Observation. Anh xuống kho ngồi cạnh một nhân viên trong 2 tiếng, chỉ quan sát (passive). Anh thấy: cứ mỗi đơn, nhân viên phải mở phần mềm, copy mã đơn, mở thêm một file Excel riêng để tra vị trí kệ hàng, rồi quay lại phần mềm nhập tay. Cái file Excel "bên lề" đó chưa ai từng nhắc trong phỏng vấn — vì với họ nó là "chuyện đương nhiên", một thói quen ngầm.
Anh hỏi: "Sao mình không tra vị trí kệ ngay trong phần mềm?". Nhân viên đáp: "Phần mềm có chỗ đó nhưng dữ liệu sai từ năm ngoái nên tụi em tự làm file riêng cho chắc". Đó chính là requirement bị giấu: cần đồng bộ và làm sạch dữ liệu vị trí kệ trong hệ thống.
Bài học: Người dùng thường không kể những gì họ coi là hiển nhiên, hoặc những "workaround" họ tự nghĩ ra. Observation lôi ra được requirement ngầm (tacit) mà Interview bỏ sót. Đây cũng là cú "đổi đối tượng shadow": QA shadow hệ thống, BA shadow con người.
Ví dụ 3 — Workshop chốt mâu thuẫn mà email mãi không xong (outsource)
Chị Trang, BA chuyển từ QA tại một công ty outsource ở Đà Nẵng, làm dự án cho khách hàng Singapore. Yêu cầu về tính năng "hoàn tiền" (refund) cứ qua lại trên email suốt 3 tuần mà không chốt được: team Sales muốn hoàn tiền nhanh để giữ khách, team Finance muốn nhiều bước duyệt để chống gian lận, team Kỹ thuật phía khách lo về khả năng tích hợp cổng thanh toán. Mỗi email một người trả lời một kiểu, mâu thuẫn chồng chất.Theo phản xạ cũ, chị Trang định gửi thêm một email tổng hợp. Nhưng mentor khuyên dùng Workshop. Chị tổ chức một buổi online 90 phút, mời cả ba bên, chuẩn bị sẵn một bảng trên Miro với cột "đề xuất của từng bên" và "ràng buộc". Vai trò của chị là điều phối: đặt câu hỏi, ghi lại, ép ra quyết định, không phát biểu ý kiến cá nhân. Trong 90 phút, ba bên nhìn thẳng nhau và thống nhất: hoàn tiền dưới 1 triệu VND duyệt tự động, trên ngưỡng đó cần Finance duyệt — giải được cả tốc độ lẫn chống gian lận.
Bài học: Khi mâu thuẫn giữa nhiều stakeholder, email kéo dài vô tận vì không ai bị "ép" phản hồi đồng thời. Workshop nén thời gian, buộc đối thoại trực tiếp và ra quyết định tại chỗ. Đây là kỹ thuật người-từ-QA cần luyện nhất, vì nó đòi kỹ năng điều phối — thứ QA ít khi phải làm.
Hướng dẫn từng bước
Một quy trình elicitation tốt cho mọi kỹ thuật đi qua 5 bước:
- Xác định mục tiêu và đối tượng. Bạn cần làm rõ điều gì? Thông tin đó nằm trong đầu ai, hay trong tài liệu/hệ thống nào? Trả lời được câu này sẽ gợi ý kỹ thuật phù hợp.
- Chọn kỹ thuật theo bối cảnh. Dùng la bàn nhanh:
- Chuẩn bị (Prepare). Soạn câu hỏi (interview/survey), chuẩn bị bảng/agenda (workshop), in tài liệu cần đọc, dựng mock (prototyping). Bước này quyết định 70% chất lượng. QA giỏi test case = bạn giỏi chuẩn bị câu hỏi có hệ thống.
- Tiến hành (Conduct). Thực thi kỹ thuật. Luôn ghi chép (notes, recording nếu được phép). Trong interview/workshop, lắng nghe nhiều hơn nói, dùng câu hỏi mở "tại sao", "kể cho tôi nghe về...".
- Xác nhận (Confirm). Tổng hợp lại những gì thu được và gửi cho stakeholder xác nhận: "Tôi hiểu đúng không?". Bước này tránh việc bạn hiểu sai mà cứ tưởng đúng — chính là tư duy "verify" mà QA đã thấm.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ dùng một kỹ thuật cho mọi việc. Người mới từ QA hay mặc định "gửi email hỏi" hoặc "đọc tài liệu" cho mọi tình huống. Hậu quả: bỏ sót requirement ngầm. Mẹo: mỗi dự án cố tình dùng ít nhất 2–3 kỹ thuật khác nhau để chéo kiểm thông tin (triangulation).
Lỗi 2 — Phỏng vấn để hỏi thứ tài liệu đã trả lời. Phí thời gian quý của stakeholder và làm bạn mất uy tín. Mẹo: luôn Document Analysis trước, vào phỏng vấn chỉ hỏi phần tài liệu bỏ trống/mâu thuẫn.
Lỗi 3 — Tin 100% lời người dùng nói trong phỏng vấn. Người dùng kể "quy trình lý tưởng", không kể workaround thực tế. Mẹo: khi nghi ngờ, bổ sung Observation để thấy họ làm gì thay vì nói gì.
Lỗi 4 — Trong Workshop, BA nói nhiều hơn điều phối. Người từ QA thường rất am hiểu chi tiết nên dễ "nhảy vào giải" thay vì để stakeholder tự chốt. Mẹo: vai facilitator = đặt câu hỏi và ghi lại, giữ kỷ luật thời gian, không áp đặt ý kiến.
Lỗi 5 — Brainstorming bị phán xét sớm. Vừa có ý tưởng đã bị chê "không khả thi" khiến mọi người im lặng. Mẹo: tách rõ hai pha — pha tạo ý tưởng (cấm phán xét) và pha đánh giá (lọc, xếp hạng) làm sau.
Lỗi 6 — Survey với câu hỏi dẫn dắt (leading question). Hỏi "Bạn có thấy tính năng X tuyệt vời không?" sẽ ra kết quả vô giá trị. Mẹo: câu hỏi trung lập, tránh gợi ý câu trả lời; test thử survey với vài người trước khi gửi đại trà — đúng tinh thần "test trước khi release" của QA.
Mẹo tận dụng nền QA: Với Interface Analysis, hãy lôi hết kiến thức API testing ra — bạn vốn hiểu request/response, status code, error case, contract. Với Brainstorming các trường hợp, kỹ năng nghĩ edge case của bạn giúp liệt kê được những tình huống mà BA "thuần" hay bỏ sót (đây cũng là chủ đề riêng của Bài 16).
Bài tập thực hành
- Lập ma trận chọn kỹ thuật. Cho 5 tình huống sau, chọn kỹ thuật elicitation phù hợp nhất và giải thích trong 1–2 câu mỗi tình huống:
- Soạn bộ câu hỏi phỏng vấn. Chọn một quy trình bạn biết rõ (ví dụ: đặt đồ ăn qua app). Viết 8 câu hỏi phỏng vấn structured để khơi requirement, trong đó ít nhất 3 câu là câu hỏi mở (bắt đầu bằng "Tại sao", "Kể cho tôi...").
- Phân biệt Workshop vs Focus Group. Viết một đoạn 100–150 từ giải thích sự khác nhau, kèm một ví dụ tình huống cho mỗi loại.
- Tự soi nền QA. Liệt kê 3 kỹ thuật trong số 9 kỹ thuật mà bạn cho rằng kinh nghiệm QA của mình hỗ trợ tốt nhất, và 2 kỹ thuật bạn thấy yếu nhất. Với 2 kỹ thuật yếu, ghi một hành động cụ thể để luyện tập.
Tóm tắt
- Elicitation là hoạt động khơi gợi requirement — khác hẳn việc thụ động nhận spec thời QA. Phần lớn requirement nằm ngầm trong đầu stakeholder.
- BABOK v3 nêu 9 kỹ thuật cốt lõi: Interview, Workshop, Observation, Document Analysis, Survey, Brainstorming, Focus Group, Prototyping, Interface Analysis. Nhớ theo 3 nhóm nguồn: con người / tài liệu-hệ thống / sáng tạo-trực quan.
- Không có kỹ thuật "tốt nhất" — BA giỏi phối hợp nhiều kỹ thuật và chọn theo bối cảnh (thời gian, số stakeholder, độ rõ của vấn đề).
- Người từ QA có lợi thế tự nhiên ở Document Analysis, Interface Analysis (nhờ API testing) và brainstorm edge case; cần luyện thêm Workshop (điều phối) và Focus Group.
- Quy trình 5 bước: xác định mục tiêu → chọn kỹ thuật → chuẩn bị → tiến hành → xác nhận. Bước chuẩn bị và bước xác nhận đúng tinh thần "test có hệ thống" và "verify" mà bạn đã thấm từ QA.
- Sai lầm phổ biến nhất: chỉ dùng một kỹ thuật, và tin 100% lời người dùng nói thay vì quan sát họ làm.