Mở đầu: câu chuyện có thật
Một công ty bán lẻ mỹ phẩm ở TP.HCM thuê đội phát triển làm app đặt hàng cho cộng tác viên (CTV). Giám đốc kinh doanh nói một câu: "Làm cho tôi cái app để CTV đặt hàng nhanh hơn." Đội dev nghe xong về code đúng 3 tháng. Đến ngày demo, chị giám đốc lắc đầu: CTV không cần đặt hàng nhanh hơn — họ cần theo dõi hoa hồng theo thời gian thực vì đó mới là lý do họ rời bỏ hệ thống cũ. Ba tháng công sức đổ sông đổ biển.
Đây chính là lý do elicitation (thu thập yêu cầu) tồn tại. Vấn đề không nằm ở chỗ dev code dở, mà ở chỗ không ai đào sâu để hiểu nhu cầu thật.
Elicitation không phải là "ghi lại yêu cầu"
Rất nhiều BA mới hiểu nhầm rằng công việc của mình là ngồi họp, ghi lại những gì stakeholder nói, rồi chuyển cho dev. Đó là thư ký, không phải BA.
Elicitation trong tiếng Anh có gốc từ elicit — nghĩa là "khơi gợi, moi ra". BA phải chủ động khơi gợi những thứ mà chính stakeholder cũng chưa nói ra hoặc chưa ý thức được. Có ba tầng nhu cầu:
- Điều họ nói ra (stated needs) — "Tôi muốn app đặt hàng nhanh."
- Điều họ thật sự muốn (real needs) — "Tôi muốn CTV không bỏ đi."
- Điều họ chưa biết mình cần (unstated needs) — "CTV cần thấy hoa hồng minh bạch để tin tưởng."
Vì sao stakeholder không nói hết?
- Họ cho là hiển nhiên: "Ai chả biết đơn hàng phải có mã số thuế" — nhưng dev không phải dân kế toán.
- Họ không biết cách diễn đạt: nghiệp vụ trong đầu họ, không thành lời được.
- Họ mâu thuẫn nhau: phòng kinh doanh muốn duyệt đơn nhanh, phòng kế toán muốn kiểm soát chặt.
- Họ sợ lộ vấn đề nội bộ: quy trình hiện tại đang "lách" nên ngại nói thật.
Sáu kỹ thuật elicitation cốt lõi (bản đồ toàn khóa)
Khóa học này sẽ đi qua 6 kỹ thuật, mỗi kỹ thuật hợp với một tình huống:
| Kỹ thuật | Dùng khi | Bài |
|---|---|---|
| Phỏng vấn stakeholder | Cần hiểu sâu 1 người | Bài 2 |
| Workshop | Cần nhiều bên thống nhất | Bài 3 |
| Quan sát (observation) | Nghiệp vụ khó mô tả bằng lời | Bài 4 |
| Khảo sát (survey) | Cần ý kiến số đông | Bài 4 |
| Phân tích tài liệu | Có sẵn quy trình, biểu mẫu | Bài 5 |
| Prototyping | Yêu cầu mơ hồ, cần "thấy mới biết" | Bài 5 |
Ba nguyên tắc vàng trước khi đi đào
- Xác định đúng người (stakeholder): đừng chỉ hỏi sếp. Người dùng cuối, người vận hành, người bị ảnh hưởng đều là nguồn yêu cầu.
- Chuẩn bị trước khi gặp: đọc tài liệu, hiểu bối cảnh, chuẩn bị câu hỏi. Đi tay không là lãng phí thời gian của cả hai bên.
- Yêu cầu chưa xác thực chỉ là giả thuyết: cái bạn thu được cần được ghi nhận → xác thực → ưu tiên (Bài 6).
Ví dụ thực tế Việt Nam
Một ngân hàng số muốn làm tính năng "mở tài khoản online". BA mới chỉ hỏi phòng sản phẩm và viết ra 20 màn hình. BA có kinh nghiệm thì: phỏng vấn nhân viên chi nhánh (Bài 2), quan sát khách quầy điền form giấy (Bài 4), đọc quy định eKYC của NHNN (Bài 5), rồi làm prototype cho 5 khách thử (Bài 5). Kết quả: phát hiện ra khâu chụp CCCD là điểm khách bỏ cuộc nhiều nhất — thứ mà không cuộc họp nào nói ra.
Checklist trước mỗi buổi elicitation
- [ ] Tôi đã liệt kê đầy đủ stakeholder liên quan (không chỉ người ra quyết định)?
- [ ] Tôi hiểu bối cảnh nghiệp vụ và mục tiêu dự án chưa?
- [ ] Tôi đã chọn kỹ thuật phù hợp với tình huống?
- [ ] Tôi có mục tiêu rõ ràng cho buổi này (muốn biết được gì)?
- [ ] Tôi có kế hoạch ghi nhận (ghi âm/ghi chú/mẫu template)?
- [ ] Tôi phân biệt được "điều họ nói" và "điều họ thật sự cần"?
Tổng kết
Elicitation là hoạt động chủ động khơi gợi và đào sâu nhu cầu thật của stakeholder — không phải chép chính tả. Đây là kỹ năng nền tảng quyết định 80% chất lượng của mọi dự án. Bài tiếp theo, chúng ta bắt đầu với kỹ thuật được dùng nhiều nhất: phỏng vấn stakeholder.