🧩 “Hỏi cho đủ câu chứ chưa chắc đã đủ hiểu” – cú lầm tưởng của năm đầu làm BRSE

 

Chào mọi người

Hôm nay mình lại tiếp tục lên cho mọi người bài viết nằm trong chuỗi những câu chuyện dở khóc dở cười mình gặp phải trong quá trình làm việc trong ngành IT. Mình cũng chỉ là một newbie trong ngành, thích viết và thích chia sẻ về những gì mình vấp phải , hy vọng nó hữu ích với những bạn mới vào nghề giống như mình.

 

❌ Cú lầm tưởng: hỏi nhiều câu = hiểu đủ
Mình vẫn nhớ như in buổi họp kick-off đầu tiên mình tham gia với vai trò BRSE. Mình hăng hái chuẩn bị hẳn checklist gần 20 câu hỏi gửi khách:

  • 「現在の業務フローはどうなっていますか？」
    (Luồng nghiệp vụ hiện tại ra sao?)

  • 「特別なユーザーロールは存在しますか？」
    (Có user role nào đặc biệt không?)

  • 「処理ルールのドキュメントはありますか？」
    (Có tài liệu rule xử lý không ạ?)

Khách trả lời rất nhiệt tình. Mình cũng cố gắng take note đầy đủ các câu trả lời, lúc đó mình còn trộm nghĩ là “Chắc cũng cũng ổn rồi, mình đã hỏi hết những thứ cần hỏi.”

Khách hàng trả lời rất nhiệt tình không thiếu câu nào.

… Cho đến khi bắt tay viết tài liệu.
Mình mới thấy có những chỗ chưa rõ ràng một chút nào:

  • “Phòng ban X duyệt trước, rồi đến phòng Y” → Nhưng theo tiêu chí gì để duyệt?

  • “Một user có thể có nhiều role” → Nhưng hệ thống xử lý thế nào khi role xung đột?

  • “Người duyệt đang nghỉ phép” → Thì flow có dừng lại không, hay auto-forward?

Lúc đó mình mới hiểu:
・Mình đã hỏi rất nhiều, nhưng chưa hỏi đúng trọng tâm.
・Mình nghe được câu trả lời, nhưng không chạm đến insight nghiệp vụ.

 

Bài học: Hỏi nghiệp vụ ≠ thu thập thông tin

Hỏi nghiệp vụ là để đào sâu logic ngầm, phát hiện rủi ro và chốt rõ kỳ vọng.

Một câu hỏi “cho có” thì chỉ như thủ tục hành chính.
Nhưng một câu hỏi đúng trọng tâm có thể “móc ra” cả những thứ khách hàng chưa từng để ý.

Hỏi giỏi = biến buổi họp thành nơi bóc tách “bản đồ thật sự” của doanh nghiệp, chứ không chỉ là nơi thu thập keyword.

 

Vậy làm sao để đào insight từ khách hàng?

Đây là những tips thực tế mình rút ra sau nhiều lần “ngã đau”.

 

1. Đặt câu hỏi “tại sao” thay vì chỉ “cái gì”

Khách thường mô tả họ đang làm gì, nhưng insight nằm ở vì sao họ làm vậy.

Ví dụ:

  • Khách nói: “Phòng A duyệt trước rồi mới đến phòng B.”

  • Nếu chỉ ghi lại như thế, bạn chỉ có “thông tin”.

👉 Nhưng khi hỏi thêm:
“Quy trình này để kiểm soát ngân sách hay chỉ để thông báo?”
thì bạn mới tìm ra mục đích thật sự.

 

2. Scenario hóa – kéo khách hàng “diễn thử” tình huống

Đừng đặt những câu hỏi chung chung, vì khi đưa ra câu hỏi chung chung thì người nghe cũng sẽ trả lời một cách chung chung.

Còn nếu đưa ra câu hỏi có mục đích rõ ràng, bạn sẽ nhận lại câu trả lời trực quan hơn.

 

★ Ví dụ trong hệ thống booking phòng khám 🏥:

Khách nói: “Bệnh nhân đặt lịch xong thì phía admin sẽ thực hiện assign bác sĩ. Thế thôi.”

Nếu chỉ nghe vậy mà bạn nghĩ rằng mình đã nằm lòng hệ thống thì bạn "sai" rồi.
Khi bạn bóc tách yêu cầu trên thành từng scenario chi tiết thì sao nhỉ ???

  • Nếu 2 bệnh nhân đặt cùng slot → ai được ưu tiên book thành công ?

  • Nếu chỉ có một bác sĩ available trong khoảng thời gian user đã book → hệ thống có cần xử lý auto-assign không?

  • Nếu có nhiều bác sĩ available trong khoảng thời gian user đã book → Hiển thị list bác sĩ theo thứ tự random? hay có cần gán điều kiện đặc biệt gì ở đây không?

  • Nếu clinic đóng cửa nhưng bác sĩ vẫn đăng ký lịch làm việc → hệ thống sẽ xử lý hiển thị calendar theo lịch làm việc của clinic, hay của bác sĩ?

  • Nếu bệnh nhân hủy booking vào phút chót → hệ thống có cho phép cancel vào phút chót không? Có quy định ràng buộc nào liên quan đến việc cho phép cancel hay không?

  • ....... còn 1001 câu QnA nữa

 

👉 Chính nhờ “scenario hóa” như vậy, bạn sẽ kéo khách hàng cùng diễn thử tình huống, từ đó lộ ra những lỗ hổng define nghiệp vụ mà ban đầu khách chưa nghĩ tới.

 

3. Xác nhận ngược bằng cách recap trong họp

Khi nghe mong muốn của khách hàng trong buổi meeting, nhưng bạn thấy cấn cấn hoặc cảm thấy chưa hiểu lắm → Thay vì chờ đến lúc viết spec chi tiết rồi mới confirm thì hãy confirm trực tiếp trong cuộc họp.
Mẫu câu mình hay dùng để recap lại nội dung từ phía KH ↓↓↓

  • 「〇〇について、△△と理解しておりますが、よろしいでしょうか。」
    (Về 〇〇, tôi đang hiểu là △△, không biết có đúng không ạ?)

  • 「先ほどの説明をもとに内容をまとめました。ご認識に誤りがないか、ご確認お願いいたします。」
    (Tôi đã tóm tắt lại nội dung theo giải thích vừa rồi, nhờ an xác nhận giúp xem tôi có đang hiểu sai chỗ nào không? )

 

4. Đừng tin ngay khi khách nói “không có case khác”

Khách hàng thường chỉ nghĩ tới happy path (happy case). Ngoại lệ thì hoặc họ quên, hoặc họ cho rằng “chắc không xảy ra đâu”.

👉 Khi đó, đừng chỉ hỏi kiểu chung chung như “Có case nào khác không?”, mà hãy gợi mở bằng chính scenario đã hình dung trước đó.

 

★ Ví dụ với hệ thống booking mà mình đã đề cập ở mục 2:

  • Trong tuần trước hoặc tháng trước, có ca nào mà bệnh nhân claim/than phiền về việc đặt lịch không thành công không?

  • Có lần nào admin phải sửa lại lịch hẹn vì hệ thống xử lý khác với mong muốn không?

  • Nếu 2 bệnh nhân cùng chọn một khung giờ nhưng chỉ còn 1 bác sĩ trống, trong thực tế clinic đã xử lý thế nào?

  • Có từng tình huống nào bác sĩ bận đột xuất (họp, ca cấp cứu) khiến booking phải huỷ hoặc đổi gấp không? Khi đó hệ thống hiện nay hỗ trợ được tới đâu, còn chỗ nào admin phải can thiệp tay?

  • Trong lịch sử vận hành, đã có trường hợp nào bệnh nhân đặt được slot nhưng đến nơi lại không có bác sĩ tiếp nhận không?

➡︎ Những câu hỏi này gợi cho khách nhớ lại các sự cố thực tế thay vì chỉ trả lời trên giấy. Và chính các sự cố này mới thường là nguyên nhân gây bug khi hệ thống đi vào production.

 

5. Biết khi nào nên hỏi “vòng ngoài”

Đừng chỉ phụ thuộc vào SME, vì họ thường mô tả quy trình lý tưởng. Trong khi đó, những “lệ làng” và ngoại lệ phát sinh lại nằm trong tay end-user, QA, hoặc team vận hành.

★ Ví dụ booking phòng khám 🏥:
SME nói: “Admin assign bác sĩ cho bệnh nhân là xong.”
Nhưng khi đặt những câu hỏi sắc sâu về mặt nghiệp vụ hơn ↓ ↓ ↓

  • QA → phát hiện bug: bệnh nhân chọn slot trống, nhưng bác sĩ đó cùng lúc có ca ở bệnh viện khác.

  • End-user (admin) → kể rằng họ thường phải gọi điện cho bác sĩ trước khi xác nhận, vì hệ thống không hiển thị lịch bận ngoài.

👉 Nếu chỉ nghe SME, ta tưởng flow “trơn tru”. Nhưng nhờ hỏi “vòng ngoài”, mới thấy những case thủ công ảnh hưởng nhiều nhất.

 

📚 Checklist hỏi nghiệp vụ để ra insight

  • Xác định mục tiêu thật sự → Nếu bỏ bước này thì nó có ảnh hưởng gì đến flow đặt lịch hay không?

  • Đào bới các case ngoại lệ → Có tình huống nào từng khiến quy trình bị gián đoạn không?

  • Gỡ logic ngầm → Nếu A fail, hệ thống sẽ làm gì tiếp theo?

  • Kiểm tra hiểu đúng → Em xin phép recap lại… có đúng không ạ?

 

🌱 Đúc kết lại

Một người hỏi cho có sẽ chỉ thu được keyword.
Một người hỏi giỏi sẽ khiến khách cũng bất ngờ ^^.

Và lúc đó, bạn – một BRSE non-tech – không chỉ là người phiên dịch, mà trở thành người cùng khách hàng cải tiến luồng nghiệp vụ, tạo ra sản phẩm chất lượng tốt cả về mặt interface lẫn mặt business.
Đó mới chính là giá trị lớn nhất của kỹ năng đặt câu hỏi thông minh, hẹ hẹ.