Mở đầu — vì sao bài này quan trọng
Nếu bạn đang làm Marketing và muốn chuyển sang BA, đây là bài học mà bạn sẽ thấy "đất diễn" của mình rõ ràng nhất. Lý do rất đơn giản: Requirements Gathering — thu thập và xác định yêu cầu — về bản chất chính là kỹ năng nghiên cứu (research) mà bạn đã làm mỗi ngày trong Marketing, chỉ khác đối tượng và mục đích cuối cùng.
Khi làm Marketing, bạn nghiên cứu thị trường để trả lời câu hỏi: "Khách hàng muốn gì, và làm sao để bán được nhiều hơn?". Khi làm BA, bạn nghiên cứu nghiệp vụ để trả lời câu hỏi: "Doanh nghiệp cần gì, và phần mềm/giải pháp nào sẽ giải quyết được vấn đề đó?". Cùng một bộ cơ bắp tư duy — quan sát, đặt câu hỏi, tổng hợp, ưu tiên — chỉ là tập luyện ở một sân chơi khác.
Vấn đề là rất nhiều người chuyển ngành bị kẹt ở chỗ: họ giỏi "đào" thông tin (market research), nhưng chưa biết cách biến mớ thông tin đó thành business requirements — những phát biểu yêu cầu đủ rõ ràng để lập trình viên xây dựng và để doanh nghiệp ký duyệt. Bài này chính là cây cầu nối giữa hai bờ đó. Học xong, bạn sẽ biết cách lấy đúng nguồn thông tin, phân biệt "mong muốn" với "yêu cầu thật", và viết requirement sao cho không bị hiểu nhầm.
Khái niệm cốt lõi
Requirements Gathering thực ra là gì?
Requirements Gathering (hay đầy đủ hơn là Requirements Elicitation — khơi gợi yêu cầu) là quá trình chủ động thu thập, làm rõ và xác nhận những gì các bên liên quan (stakeholder) thực sự cần ở một giải pháp. Từ "elicitation" — khơi gợi — rất quan trọng: yêu cầu hiếm khi nằm sẵn để bạn "nhặt" lên. Bạn phải khéo léo gợi nó ra, vì bản thân stakeholder nhiều khi cũng không nói rõ được điều họ muốn.
Điều này nghe quen không? Trong Marketing, khách hàng cũng không bao giờ nói thẳng "tôi cần một quảng cáo nhấn mạnh nỗi sợ bỏ lỡ (FOMO)". Họ chỉ nói "sản phẩm này hay nhưng tôi vẫn lăn tăn". Việc của bạn là đào sâu để hiểu insight phía sau. BA làm y hệt như vậy với nghiệp vụ.
Sự khác nhau cốt lõi: Market Research vs Business Requirements
Hãy nắm chắc bảng so sánh tư duy này, vì nó là trục xương sống của cả bài:
- Market research trả lời câu hỏi "Thị trường/khách hàng thế nào?" → đầu ra là insight, là xu hướng, là cơ hội. Tính chất: định hướng, gợi mở, chấp nhận mơ hồ.
- Business requirements trả lời câu hỏi "Hệ thống phải làm được gì để giải quyết vấn đề?" → đầu ra là phát biểu yêu cầu cụ thể, kiểm chứng được. Tính chất: chính xác, rõ ràng, không mâu thuẫn.
Ba tầng yêu cầu bạn cần phân biệt
Để không bị rối, hãy nhớ ba tầng (bài sau trong khóa sẽ đào sâu, ở đây ta chỉ cần nắm khung):
- Business Requirements — yêu cầu ở tầng mục tiêu kinh doanh. Ví dụ: "Giảm tỷ lệ bỏ giỏ hàng từ 70% xuống 55% trong 6 tháng."
- Stakeholder Requirements — yêu cầu của từng nhóm liên quan. Ví dụ: bộ phận vận hành cần "xem được lý do khách hủy đơn".
- Solution Requirements — yêu cầu cụ thể của giải pháp (chia thành functional và non-functional). Ví dụ: "Nút "Mua ngay" hiển thị ở đầu trang sản phẩm trên mobile."
Phân biệt "wants" và "needs"
Đây là kỹ năng then chốt. Stakeholder thường mang đến cho bạn một giải pháp họ tưởng tượng ("tôi cần thêm một nút màu đỏ to ở đây") thay vì vấn đề thật ("khách không tìm thấy chỗ đăng ký"). Nhiệm vụ của BA là bóc ngược từ giải pháp về vấn đề gốc. Trong Marketing bạn gọi đây là phân biệt giữa "feature" và "benefit" — cùng một logic.
Tình huống thực tế
Ví dụ 1 — Tiki: từ insight "khách bỏ giỏ" sang requirement cụ thể
Giả định bạn là BA mới tại một sàn thương mại điện tử kiểu Tiki. Đội Growth (Marketing) đưa cho bạn báo cáo: "Tỷ lệ bỏ giỏ hàng ở bước thanh toán là 68%, cao nhất ở nhóm khách dùng mobile, đặc biệt khách lần đầu mua."
Một người Marketing chưa quen tư duy BA sẽ vội kết luận: "Vậy mình cần làm trang thanh toán đẹp hơn." Nhưng đó là phỏng đoán giải pháp. BA giỏi sẽ làm Requirements Gathering: phỏng vấn 8 khách hàng đã bỏ giỏ, xem session recording, và phỏng vấn đội Chăm sóc khách hàng. Kết quả phát hiện ra ba vấn đề gốc khác nhau: (1) phí ship chỉ hiện ở bước cuối gây "sốc giá"; (2) bắt buộc tạo tài khoản mới được mua; (3) form nhập địa chỉ quá dài trên màn hình nhỏ.
Từ đó, requirement được viết ra rõ ràng, ví dụ: "Hệ thống phải hiển thị phí vận chuyển ước tính ngay tại trang giỏ hàng, trước khi khách bấm Thanh toán" và "Cho phép đặt hàng với vai trò khách (guest checkout), không bắt buộc tạo tài khoản."
Bài học: Market research cho bạn biết có vấn đề ở đâu (bỏ giỏ ở mobile). Requirements Gathering mới cho bạn biết vấn đề gốc là gì và hệ thống phải làm gì. Đừng nhảy thẳng từ số liệu sang giải pháp.
Ví dụ 2 — MoMo: khi stakeholder nói "wants" nhưng "needs" lại khác
Giả định tại một ví điện tử như MoMo, trưởng phòng Kinh doanh yêu cầu BA: "Làm cho tôi một dashboard hiển thị tất cả giao dịch theo thời gian thực, càng nhiều biểu đồ càng tốt." Đó là một "want" — một giải pháp đã được hình dung sẵn.
BA tiến hành elicitation bằng kỹ thuật "5 Whys" nhẹ nhàng: "Anh sẽ dùng dashboard này để quyết định điều gì?". Hóa ra nhu cầu thật là: trưởng phòng cần phát hiện sớm khi một chiến dịch khuyến mãi bị lạm dụng (gian lận hoàn tiền). Anh ấy không cần "nhiều biểu đồ" — anh ấy cần một cảnh báo tự động khi số giao dịch hoàn tiền của một mã khuyến mãi vượt ngưỡng bất thường.
Requirement cuối cùng vì thế đơn giản và đúng hơn rất nhiều: "Hệ thống gửi cảnh báo qua email/Telegram khi tỷ lệ hoàn tiền của một campaign vượt 15% trong vòng 1 giờ." Rẻ hơn, nhanh hơn, và giải quyết đúng nỗi đau.
Bài học: Đừng nhận yêu cầu theo nghĩa đen. Luôn hỏi "để làm gì?" cho đến khi chạm tới mục tiêu kinh doanh thật. Kỹ năng đào insight trong Marketing của bạn chính là vũ khí ở đây.
Ví dụ 3 — Một chuỗi F&B chuyển đổi số
Một chuỗi cà phê 30 chi nhánh ở TP.HCM muốn xây app tích điểm thành viên. Marketing đã có sẵn persona khách hàng và dữ liệu hành vi mua. BA tận dụng ngay: thay vì bắt đầu từ con số 0, BA dùng customer journey mà đội Marketing đã vẽ làm khung phỏng vấn stakeholder.
Khi gather requirements, BA phát hiện một mâu thuẫn kinh điển: bộ phận Marketing muốn "thu thập càng nhiều dữ liệu khách càng tốt" (số điện thoại, ngày sinh, sở thích), trong khi bộ phận Vận hành tại quầy phản đối vì "khách xếp hàng đông, nhân viên không có thời gian hỏi nhiều". Đây là xung đột yêu cầu giữa hai stakeholder.
BA giải quyết bằng cách viết requirement có ưu tiên: "Khi đăng ký tại quầy, chỉ bắt buộc số điện thoại. Các thông tin khác là tùy chọn, khách tự bổ sung sau qua app."
Bài học: Requirements Gathering không chỉ là thu thập, mà còn là dung hòa các yêu cầu mâu thuẫn giữa các bên. Và đừng quên: dữ liệu Marketing sẵn có (persona, journey) giúp bạn rút ngắn rất nhiều thời gian.
Hướng dẫn từng bước
Đây là quy trình Requirements Gathering bạn có thể áp dụng ngay cho dự án đầu tiên:
Bước 1 — Xác định stakeholder và mục tiêu kinh doanh. Trước khi hỏi bất cứ ai, hãy liệt kê: ai là người dùng cuối, ai trả tiền/ký duyệt, ai vận hành, ai bị ảnh hưởng. Viết một câu mục tiêu kinh doanh duy nhất (giống như viết "objective" cho một campaign). Ví dụ: "Tăng tỷ lệ khách quay lại trong 90 ngày từ 20% lên 35%."
Bước 2 — Chọn nguồn và kỹ thuật thu thập. Một số kỹ thuật phổ biến: phỏng vấn 1:1, workshop nhóm, quan sát người dùng (observation), khảo sát, phân tích tài liệu hiện có, và phân tích dữ liệu. Người Marketing có lợi thế lớn ở khảo sát và phân tích dữ liệu — hãy phối hợp cả định tính (phỏng vấn) lẫn định lượng (số liệu).
Bước 3 — Chuẩn bị câu hỏi mở. Tránh câu hỏi đóng (có/không). Dùng câu hỏi gợi mở như: "Anh/chị mô tả giúp em quy trình hiện tại đang làm thế nào?", "Điều gì khiến bước này mất nhiều thời gian nhất?", "Nếu có một cây đũa thần, anh/chị muốn thay đổi điều gì đầu tiên?".
Bước 4 — Đào tới vấn đề gốc. Với mỗi yêu cầu nghe được, hỏi "để làm gì?" và "vì sao quan trọng?" ít nhất 2–3 lần. Mục tiêu là tách want (giải pháp họ tưởng tượng) khỏi need (vấn đề thật).
Bước 5 — Ghi lại và phân loại. Gom thông tin thô vào ba nhóm: mục tiêu kinh doanh, yêu cầu của từng stakeholder, yêu cầu giải pháp. Ở giai đoạn này đừng vội viết đẹp, hãy viết đủ.
Bước 6 — Viết requirement rõ ràng, kiểm chứng được. Mỗi requirement nên: dùng một động từ hành động ("hệ thống phải cho phép…"), có tiêu chí đo được, không mâu thuẫn với requirement khác. Một mẹo: đọc xong, tự hỏi "Lập trình viên đọc câu này có hiểu giống tôi không? Tôi kiểm tra đúng/sai bằng cách nào?".
Bước 7 — Xác nhận lại với stakeholder (validation). Đây là bước người mới hay bỏ qua. Đọc lại danh sách requirement cho stakeholder nghe và xác nhận: "Em hiểu đúng ý anh chưa?". Bước này tránh việc xây xong mới phát hiện hiểu sai — cái giá đắt nhất trong cả dự án.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhảy thẳng từ số liệu sang giải pháp. Người Marketing quen ra quyết định nhanh, dễ bị cám dỗ "thấy số bỏ giỏ cao là sửa ngay trang thanh toán". Hãy chậm lại một nhịp để tìm vấn đề gốc.
Lỗi 2 — Chỉ nghe một stakeholder. Nếu bạn chỉ phỏng vấn sếp mà bỏ qua nhân viên vận hành hoặc khách hàng thật, requirement sẽ lệch. Luôn lấy thông tin từ nhiều phía và đối chiếu.
Lỗi 3 — Viết requirement mơ hồ. "Hệ thống phải thân thiện, dễ dùng, nhanh" là câu vô nghĩa với lập trình viên. Bao nhiêu giây là "nhanh"? Hãy luôn lượng hóa.
Lỗi 4 — Dùng giọng văn Marketing trong requirement. Văn Marketing thuyết phục, giàu cảm xúc. Requirement thì ngược lại: trung tính, chính xác, không hoa mỹ. Hãy chuyển công tắc giọng văn khi viết tài liệu BA.
Lỗi 5 — Không ghi nguồn và giả định. Mỗi yêu cầu nên ghi rõ "ai nói" và "dựa trên giả định nào". Khi tranh cãi xảy ra sau này, đây là bằng chứng vô giá.
Mẹo vàng: Tận dụng triệt để tài sản Marketing bạn đang có — persona, customer journey, dữ liệu hành vi, kết quả khảo sát. Chúng giúp bạn bước vào dự án BA với hiểu biết về khách hàng mà nhiều BA thuần kỹ thuật phải mất hàng tháng mới có.
Bài tập thực hành
Hãy chọn một sản phẩm số bạn dùng hàng ngày (ví dụ: app giao đồ ăn, ví điện tử, sàn TMĐT) và thực hiện:
- Viết 1 câu mục tiêu kinh doanh giả định cho một tính năng bạn nghĩ sản phẩm cần cải thiện (ví dụ: "giảm thời gian thanh toán xuống dưới 30 giây").
- Liệt kê 4 stakeholder có thể liên quan đến tính năng đó và mỗi người sẽ quan tâm điều gì khác nhau.
- Soạn 5 câu hỏi mở bạn sẽ dùng để phỏng vấn nếu được làm BA cho tính năng này. Đảm bảo không có câu hỏi đóng.
- Lấy một "want" và đào tới "need": Tự đặt một yêu cầu kiểu giải pháp (ví dụ "thêm nút chia sẻ"), rồi hỏi "để làm gì?" ba lần để tìm ra vấn đề gốc.
- Viết lại 3 requirement sao cho mỗi câu có động từ hành động + tiêu chí đo được. So sánh với cách bạn sẽ viết một dòng quảng cáo cho cùng tính năng đó, và cảm nhận sự khác biệt về giọng văn.
Tóm tắt
Requirements Gathering là cây cầu giúp bạn chuyển từ tư duy Marketing sang tư duy BA mà gần như không phải xây lại từ đầu — vì cốt lõi vẫn là kỹ năng research, đặt câu hỏi và đào insight mà bạn đã thành thạo. Điểm khác biệt cần luyện là: từ insight mơ hồ phải đi tới requirement chính xác, kiểm chứng được; phải phân biệt "want" (giải pháp tưởng tượng) với "need" (vấn đề gốc); phải lắng nghe nhiều stakeholder và dung hòa mâu thuẫn giữa họ.
Ba ví dụ Tiki, MoMo và chuỗi F&B cho thấy cùng một bài học lặp lại: đừng nhảy thẳng từ số liệu sang giải pháp, hãy đào tới gốc rồi mới viết yêu cầu. Quy trình 7 bước — từ xác định stakeholder, chọn kỹ thuật, đặt câu hỏi mở, đào vấn đề gốc, phân loại, viết requirement rõ ràng đến xác nhận lại — là bộ khung bạn có thể áp dụng ngay cho dự án đầu tiên. Và lợi thế lớn nhất của bạn — kho persona, customer journey và dữ liệu hành vi từ Marketing — chính là thứ giúp bạn xuất phát nhanh hơn nhiều BA khác. Hãy tận dụng nó.