Mở đầu — vì sao bài này quan trọng
Nếu bạn từng làm Designer, gần như chắc chắn bạn đã ngồi cùng người dùng, quan sát họ dùng sản phẩm, hỏi họ "vì sao anh/chị lại làm thế này?" và ghi lại từng phản ứng. Đó chính là User Research — và đây là một trong những tài sản quý giá nhất bạn mang theo khi chuyển sang nghề BA.
Nhưng có một sự thật hơi phũ: hiểu người dùng muốn gì không đồng nghĩa với việc doanh nghiệp cần làm gì. Một Designer giỏi có thể phát hiện "người dùng bực bội vì bước thanh toán quá dài". Một BA giỏi phải biến insight đó thành một Business Requirement rõ ràng, đo lường được, có thể bàn giao cho đội phát triển, và quan trọng nhất — thuyết phục được người nắm ngân sách rằng việc sửa nó đáng để đầu tư.
Bài 3 tập trung đúng vào cây cầu đó: làm sao đi từ tiếng nói của người dùng (user insight) sang yêu cầu nghiệp vụ (business requirement). Đây là kỹ năng bản lề. Nếu bạn qua được cây cầu này một cách vững vàng, phần lớn công việc BA sau này sẽ trở nên tự nhiên. Còn nếu bạn kẹt lại ở tư duy "người dùng muốn gì thì ta làm nấy", bạn sẽ mãi bị coi là một Designer biết viết tài liệu, chứ không phải một BA thực thụ.
Khái niệm cốt lõi
User Research và Business Requirement khác nhau chỗ nào?
Hãy phân biệt rõ ba tầng thông tin mà bạn sẽ làm việc:
- User Insight (phát hiện từ người dùng): những gì bạn quan sát, nghe được, đo được từ hành vi và cảm xúc của người dùng. Ví dụ: "70% người dùng bỏ giỏ hàng ở bước nhập địa chỉ."
- User Need (nhu cầu người dùng): vấn đề thực sự đằng sau insight đó. Ví dụ: "Người dùng muốn nhập địa chỉ nhanh, không phải gõ lại thông tin đã có."
- Business Requirement (yêu cầu nghiệp vụ): điều doanh nghiệp quyết định làm để giải quyết nhu cầu đó, gắn với mục tiêu kinh doanh. Ví dụ: "Hệ thống phải cho phép người dùng chọn địa chỉ đã lưu hoặc tự động điền địa chỉ từ số điện thoại, nhằm giảm tỷ lệ bỏ giỏ hàng ở bước địa chỉ từ 70% xuống dưới 40% trong quý tới."
Ba câu hỏi biến insight thành requirement
Mỗi khi có một phát hiện từ người dùng, hãy tự hỏi ba câu:
- "Vấn đề gốc là gì?" — Đằng sau hành vi kia, người dùng đang cố đạt điều gì? (Đây là kỹ năng empathy bạn đã có sẵn từ Design.)
- "Doanh nghiệp được gì nếu giải quyết?" — Nếu sửa việc này, công ty tăng doanh thu, giảm chi phí, giữ chân khách, hay giảm rủi ro? Nếu không trả lời được, có thể đây không phải requirement đáng ưu tiên.
- "Làm sao biết ta đã giải quyết xong?" — Tiêu chí đo lường cụ thể là gì? Con số, ngưỡng, thời hạn.
Requirement tốt trông như thế nào?
Một business requirement chất lượng thường đạt các tiêu chí (nhiều nơi gọi là chuẩn INVEST hoặc SMART):
- Cụ thể và không mơ hồ: tránh từ như "dễ dùng hơn", "nhanh hơn" mà không có ngưỡng.
- Đo lường được: gắn với metric rõ ràng.
- Gắn mục tiêu kinh doanh: trả lời được câu "so what?".
- Khả thi và có ưu tiên: biết cái nào Must-have, cái nào Nice-to-have.
- Truy vết được (traceable): biết requirement này sinh ra từ insight nào của người dùng.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT: từ "bực bội khi thanh toán" sang requirement có ROI
Bối cảnh: Bạn là Designer vừa chuyển sang BA tại một sàn thương mại điện tử Việt Nam tầm trung (giả định, quy mô ~200.000 đơn/tháng). Đội UX của bạn làm usability test và phát hiện: nhiều người dùng lớn tuổi loay hoay ở bước nhập mã giảm giá, không tìm thấy ô nhập, và bỏ đơn.
Nếu còn tư duy Designer, bạn sẽ đề xuất: "Thiết kế lại ô nhập mã cho nổi bật hơn." Đúng, nhưng chưa đủ để thuyết phục sếp bỏ tiền.
Với tư duy BA, bạn làm thêm mấy bước: kéo số liệu từ analytics và thấy 12% người dùng chạm vào khu vực mã giảm giá rồi thoát; giá trị đơn trung bình là 350.000đ; ước tính khoảng 3.000 đơn/tháng bị rơi ở bước này. Bạn viết lại thành business requirement:
> "Trang thanh toán phải hiển thị ô nhập mã giảm giá rõ ràng và cho phép áp mã trong tối đa 2 thao tác, nhằm giảm tỷ lệ thoát tại bước mã giảm giá từ 12% xuống dưới 6%, ước tính thu hồi ~1.500 đơn/tháng, tương đương ~525 triệu đồng doanh thu/tháng."
Bài học: Cùng một insight, nhưng cách BA trình bày gắn liền với con số kinh doanh khiến đề xuất được duyệt. Designer thấy vấn đề trải nghiệm; BA định lượng vấn đề đó thành tiền.
Ví dụ 2 — Ứng dụng đặt xe/giao đồ ăn: khi người dùng "muốn" nhưng doanh nghiệp không nên làm
Bối cảnh (giả định gần với các super-app Đông Nam Á như Grab, Gojek): Trong phỏng vấn người dùng, rất nhiều tài xế nói họ muốn "được tự chọn đơn nào để nhận, xem trước điểm đến và số tiền trước khi bấm nhận". Về mặt trải nghiệm tài xế, đây là mong muốn hoàn toàn chính đáng.
Một BA non tay sẽ vội biến mong muốn này thành requirement "cho phép tài xế xem điểm đến trước khi nhận đơn". Nhưng khi soi qua ba câu hỏi lọc, bạn phát hiện: nếu cho xem trước, tài xế sẽ chỉ chọn đơn ngon, bỏ đơn xa/khó, khiến khách ở khu vực xa bị hủy đơn nhiều, giảm trải nghiệm khách hàng và doanh thu tổng thể. Nhu cầu người dùng (tài xế) xung đột với mục tiêu kinh doanh và với một nhóm người dùng khác (khách hàng).
Kết quả, requirement được viết lại khôn ngoan hơn: "Hệ thống hiển thị ước lượng thu nhập theo khung giờ và tuyến đường, giúp tài xế cảm thấy minh bạch, nhưng không cho phép từ chối chọn lọc từng đơn dựa trên điểm đến."
Bài học: BA không phải người ghi lại mong muốn của người dùng rồi chuyển thẳng cho dev. BA phải cân bằng lợi ích nhiều bên (tài xế, khách hàng, doanh nghiệp). Đây là khác biệt tư duy lớn nhất so với Design — nơi bạn thường chỉ tối ưu cho một nhóm người dùng chính.
Ví dụ 3 — Ngân hàng số: từ than phiền định tính sang requirement có tiêu chí nghiệm thu
Bối cảnh (giả định gần với các ngân hàng số như TPBank, Techcombank): Đội nghiên cứu nhận được nhiều phản hồi "app mở khoản tiết kiệm rối, không hiểu lãi suất tính thế nào". Đây là insight định tính, rất mơ hồ.
Là BA, bạn tổ chức thêm vài buổi phỏng vấn ngắn để đào sâu và nhận ra vấn đề gốc: người dùng không phân biệt được kỳ hạn nào cho lãi suất bao nhiêu, và không thấy trước số tiền lãi ước tính. Bạn chuyển thành requirement kèm tiêu chí nghiệm thu rõ ràng:
> "Màn hình mở tiết kiệm phải hiển thị bảng lãi suất theo từng kỳ hạn và tính toán tự động số tiền lãi dự kiến ngay khi người dùng nhập số tiền và chọn kỳ hạn. Tiêu chí nghiệm thu: khi người dùng nhập 100 triệu, kỳ hạn 6 tháng, hệ thống hiển thị đúng số lãi dự kiến theo lãi suất hiện hành trong vòng 1 giây."
Bài học: Insight mơ hồ ("app rối") không thể giao cho dev. BA có nhiệm vụ đào sâu tới vấn đề gốc, rồi đóng gói thành requirement có tiêu chí nghiệm thu (acceptance criteria) mà đội phát triển và QA đều hiểu giống nhau.
Hướng dẫn từng bước
Đây là quy trình 6 bước bạn có thể áp dụng ngay để chuyển từ user research sang business requirement:
Bước 1 — Thu thập và gom nhóm insight. Tập hợp mọi phát hiện từ phỏng vấn, khảo sát, usability test, ticket hỗ trợ, dữ liệu analytics. Gom các phát hiện tương tự vào cùng một nhóm chủ đề (affinity mapping — kỹ thuật bạn đã quen từ Design).
Bước 2 — Đào tới vấn đề gốc. Với mỗi nhóm, dùng kỹ thuật "5 Whys" (hỏi "vì sao?" liên tục) để đi từ triệu chứng bề mặt xuống nguyên nhân thật. "Người dùng bỏ giỏ hàng" là triệu chứng; "họ không tin sản phẩm giao đúng hẹn" mới là gốc.
Bước 3 — Kiểm tra giá trị kinh doanh. Với mỗi vấn đề gốc, hỏi: giải quyết nó thì doanh nghiệp được gì? Nếu không nối được với doanh thu, chi phí, giữ chân khách hay rủi ro, hãy đánh dấu là ưu tiên thấp.
Bước 4 — Viết requirement dạng chuẩn. Dùng khung câu: "Hệ thống phải [làm gì] để [đạt mục tiêu kinh doanh nào], đo bằng [metric cụ thể]." Tránh mô tả giải pháp thiết kế chi tiết ở tầng này — BA nói "cái gì và vì sao", chưa vội nói "trông ra sao".
Bước 5 — Gắn tiêu chí nghiệm thu và độ ưu tiên. Mỗi requirement cần có acceptance criteria (làm sao biết đã xong) và mức ưu tiên (Must / Should / Could — bạn sẽ học kỹ MoSCoW ở bài sau).
Bước 6 — Ghi lại truy vết. Lập một bảng đơn giản: Insight gốc → Vấn đề gốc → Requirement → Metric. Bảng này giúp bạn luôn giải thích được "vì sao ta làm cái này" khi bị chất vấn.
Lỗi thường gặp & mẹo
Lỗi 1 — Chép nguyên lời người dùng thành requirement. Người dùng nói "tôi muốn nút to hơn" không có nghĩa requirement là "làm nút to hơn". Nhu cầu gốc có thể là "tôi không thấy nút ở đâu". Mẹo: luôn tách lời nói khỏi nhu cầu.
Lỗi 2 — Viết requirement mà quên metric. "Cải thiện trải nghiệm thanh toán" không phải requirement, đó là ước muốn. Mẹo: nếu không gắn được con số, hãy tự hỏi "sáu tháng sau tôi chứng minh thành công bằng gì?".
Lỗi 3 — Nhảy thẳng vào giải pháp thiết kế. Đây là bẫy phổ biến nhất với Designer chuyển BA. Bạn quen vẽ giải pháp, nên vừa nghe vấn đề đã muốn thiết kế màn hình. Mẹo: ở tầng requirement, cố ý mô tả "cái gì cần đạt" thay vì "màn hình trông thế nào", để dev và stakeholder không bị bó vào một giải pháp duy nhất.
Lỗi 4 — Bỏ qua stakeholder không phải người dùng cuối. Requirement còn phải phục vụ bộ phận vận hành, pháp chế, tài chính. Người dùng muốn "đăng ký trong 10 giây" nhưng bộ phận rủi ro cần định danh eKYC đầy đủ. BA phải cân bằng. Mẹo: với mỗi requirement, liệt kê xem còn ai bị ảnh hưởng ngoài người dùng cuối.
Mẹo tận dụng lợi thế Designer: Bạn giỏi kể chuyện bằng hình ảnh. Hãy dùng journey map và persona (những thứ bạn đã có) làm bằng chứng trực quan khi trình bày requirement cho stakeholder. Một requirement kèm một journey map minh họa "chỗ đau" sẽ thuyết phục hơn nhiều so với một trang chữ khô khan.
Bài tập thực hành
Hãy chọn một sản phẩm bạn dùng hàng ngày (app ngân hàng, ví điện tử như MoMo/ZaloPay, hay một sàn TMĐT) và làm bài tập sau:
- Thu thập: Viết ra 5 insight bạn tự quan sát hoặc từng nghe người khác than phiền về sản phẩm đó.
- Đào gốc: Với mỗi insight, áp dụng "5 Whys" để tìm ít nhất một vấn đề gốc.
- Lọc giá trị: Đánh dấu insight nào nếu giải quyết sẽ mang lại giá trị kinh doanh rõ ràng, và giải thích ngắn giá trị đó là gì.
- Viết requirement: Chọn 2 vấn đề gốc có giá trị cao nhất, viết chúng thành business requirement theo khung "Hệ thống phải [làm gì] để [mục tiêu] đo bằng [metric]".
- Lập bảng truy vết: Vẽ bảng 4 cột (Insight → Vấn đề gốc → Requirement → Metric) cho 2 requirement vừa viết.
Tóm tắt
- User Research cho bạn insight và nhu cầu người dùng; công việc của BA là biến chúng thành business requirement gắn với giá trị kinh doanh.
- Ba câu hỏi lọc bản lề: Vấn đề gốc là gì? Doanh nghiệp được gì? Làm sao biết đã xong?
- Một requirement tốt phải cụ thể, đo lường được, gắn mục tiêu kinh doanh, có tiêu chí nghiệm thu và truy vết được về insight gốc.
- Đừng chép nguyên lời người dùng, đừng quên metric, đừng nhảy thẳng vào giải pháp thiết kế, và đừng bỏ quên các stakeholder ngoài người dùng cuối.
- Lợi thế lớn nhất của bạn từ nền Design là khả năng empathy và kể chuyện bằng hình ảnh — hãy dùng nó để đào sâu nhu cầu và thuyết phục stakeholder, nhưng luôn kết thúc bằng một requirement có con số.