3 NGUYÊN TẮC “SỐNG CÒN” ĐỂ LẤY YÊU CẦU HIỆU QUẢ#
Nguồn: Quân làm BA | Ngày: 15/12/2025
Thể loại: Nghề BA | Tags: #BusinessAnalyst #KinhNghiemThucChien #LayYeuCau #RequirementElicitation #ChuyenDoiSo
Bài viết chia sẻ 3 nguyên tắc cốt lõi để tránh biến việc lấy yêu cầu thành “cơn ác mộng”, đúc kết từ thực tế dự án ERP/MES.
PHẦN 1: HAI TRỞ NGẠI LỚN KHI LẤY YÊU CẦU#
1.1. Cái bẫy của “Kinh nghiệm”#
- Thiếu kinh nghiệm → chỉ khai thác được 30% tảng băng nổi.
- 70% còn lại nằm ở:
- Trường hợp ngoại lệ (Business cases) khách hàng quên kể.
- Rủi ro kỹ thuật tiềm tàng (tích hợp hệ thống, chuyển đổi dữ liệu).
- Yếu tố con người – phức tạp nhất.
- Giải quyết: phải “trầy vi tróc vảy” qua ít nhất một dự án trọn vẹn mới mong thuần thục.
“Nếu không có kinh nghiệm, mình chỉ biết cầm cái bảng câu hỏi mẫu đi hỏi, và thứ mình nhận được chỉ là 30% tảng băng nổi.”
1.2. Sự bất lực trong diễn đạt#
- Truyền đạt kém, lời nói không khớp ý nghĩ → đối tác hiểu sai.
- Giải pháp cá nhân: VẼ – mọi lúc mọi nơi, trên mọi công cụ (bảng trắng, giấy nháp, PowerPoint, Excel).
- Hỗ trợ làm rõ vấn đề khi “lời nói bất lực”.
PHẦN 2: 3 NGUYÊN TẮC “BẤT DI BẤT DỊCH”#
2.1. Nguyên tắc 1: LUÔN CHUẨN BỊ (Fail to prepare = Prepare to fail)#
a. Bảng câu hỏi (Questionnaire) “xương máu”#
- Tùy biến cho từng khách hàng, tuyệt đối không dùng template chung.
- Dựa trên RFP (Hồ sơ mời thầu) hoặc UR (Yêu cầu người dùng) – đây là những mô tả ban đầu thường mông lung → cần câu hỏi làm rõ.
- Nếu không có RFP, phải làm việc với Sales/PM để nắm Pain point (nỗi đau) của khách hàng.
- Cấu trúc bảng câu hỏi khuyên dùng:
- Cột 1: Số thứ tự
- Cột 2: Câu hỏi
- Cột 3: Câu trả lời ghi nhận
- Cột 4: Người/Bộ phận chịu trách nhiệm trả lời
- Review với Senior trong team để lấp lỗ hổng kiến thức.
b. Sàng lọc đối tượng (Đúng người – Đúng việc)#
- Workshop nên tối giản, chỉ mời người liên quan trực tiếp:
- Kho → Thủ kho
- Sản xuất → Quản đốc
- Lên lịch trình chi tiết gửi khách hàng: ngày, giờ, cần gặp ai.
- Mục đích: tránh làm khách hàng mệt mỏi, trả lời qua loa → requirement tệ → dự án fail.
c. Xác định mục tiêu rõ ràng#
- Trước khi vào họp, phải biết rõ mình muốn mang gì về:
- Quy trình Sales?
- Cách làm hợp đồng?
- Sơ đồ tổ chức?
- Có mục tiêu mới chọn đúng phương pháp “moi tin”.
- Lưu ý: Giai đoạn này là moi tin, đừng sa đà vào tư vấn quá sớm. Mình đến để nghe, không phải để dạy.
“Bám sát mục tiêu là ‘Moi tin’, chứ đừng sa đà vào ‘Tư vấn’ quá sớm. Mình đến để nghe họ nói, chứ không phải để dạy họ làm.”
2.2. Nguyên tắc 2: TRỰC QUAN HÓA – KHI CẦN LÀ PHẢI “SHOW”#
“Nói anh không hiểu thì tôi show hình cho anh xem.”
- Sử dụng màn hình phần mềm, mockup, sơ đồ, diagram.
- Lợi ích:
- Đỡ buồn ngủ – mắt có cái để nhìn.
- Gom về một góc nhìn chung – tránh ông nói gà bà hiểu vịt.
- Dễ thảo luận, chỉ thẳng vào ký hiệu/quy trình.
- Thực hành: Đứng dậy, cầm bút lông, phác thảo lên bảng, vừa vẽ vừa nói. “Hàng về thì ông Kho nhận, rồi đẩy sang ông Kế toán…”
- Khách hàng xác nhận đúng/sai chỉ trong 5 giây, hiệu quả gấp trăm lần nói suông.
2.3. Nguyên tắc 3: TỈNH TÁO KHI LẮNG NGHE#
- BA không phải máy ghi âm hay thư ký. Khi nghe, đầu phải nhảy số liên tục để:
- Kiểm tra chéo: cùng một câu hỏi, hỏi ông A và ông B có ra cùng đáp án không? Nếu lệch → có vấn đề.
- Phát hiện mâu thuẫn: câu trả lời cho vấn đề A có ý Y mâu thuẫn với quy trình B đã nghe trước đó → cần đào sâu.
- Quy trình tư duy: HỎI → PHÂN TÍCH → TỔNG HỢP → vẽ bức tranh tổng quan chính xác.
- Đừng quên kiểm tra chéo với team nhà (Dev/Tech lead) để đảm bảo giải pháp khả thi.
“Sơ suất vớ nhầm thông tin sai là ’tèo’ ngay.”
Lời kết#
Tác giả thừa nhận từng mắc nhiều sai lầm do thiếu chuẩn bị, nhưng những “vết sẹo” đó giúp đúc kết nên các nguyên tắc trên. Họp lấy yêu cầu không đáng sợ nếu nắm vững nguyên tắc, và luôn sẵn sàng sửa sai.
