Chào mọi người, lại là Taiyang với những câu chuyện dở khóc trong ngành IT đây...

Chủ đề hôm nay mình muốn chia sẻ là một “bài học xương máu” mang tên:

Khi BRSE phải làm "thầy bói" – Và hành trình thoát mù nhờ giao tiếp đa chiều

 

Một ngày đẹp trời nọ, khách hàng lon ton chạy lên môi trường Staging để kiểm tra hệ thống, ngay sau khi nhận được thông báo quen thuộc từ mình:

「ステージング環境へのリリースが無事に終わりました。ご検証のほどよろしくお願いいたします。」
(Bản release lên Staging đã hoàn tất, nhờ anh test lại ạ.)

Dev code đúng theo requirement,
Tester test pass không một lỗi.
Mọi thứ tưởng như xuôi chèo mát mái, cho đến khi...

Khách hàng phán một câu:


「最初の要件と違います。」
(Không đúng như yêu cầu ban đầu.)

Lúc đó mình chỉ biết ngớ người kiểu:
“Ủa? Không đúng là... không đúng cái gì mới được?”

Mà trớ trêu thay – chính mình, người trực tiếp nắm hết mọi trao đổi với khách, cũng… không biết mình sai chỗ nào.
Và thế là buổi họp incident mở ra như một vở cải lương dài tập, còn mình thì chính thức đóng vai "thầy bói mù sờ voi".

 

Và từ khoảnh khắc đó, mình nhận về một bài học cực kỳ đắt giá...

❌ Nguy hiểm không nằm ở “không hiểu yêu cầu”, mà nằm ở “tưởng là mình đã hiểu”.

(危険なのは「要件を理解していないこと」ではなく、
「理解できているつもりになっていること」です。)

 

💥 Những sai lầm kinh điển của BRSE (đặc biệt là BRSE non-tech)

  • Tự suy diễn yêu cầu khách từ logic của mình

  • Không xác nhận lại assumption

  • Những phần khách nói miệng trong họp… nghe xong để đó

  • Quá tin vào khả năng "nghe là hiểu", không confirm ngược lại

  • Dịch tài liệu một chiều mà không hỏi lại về ý định thật sự

Kết quả là:
Một chức năng nhìn thì “ngon lành” về mặt kỹ thuật → Nhưng lại hoàn toàn vô lý với nghiệp vụ thực tế.

💡 Bài học mình rút ra – Để không phải làm "thầy bói mù" lần nữa

✅ Ghi lại mọi giả định

"Mình hiểu là A → B, nếu có gì sai mong được confirm lại."
「A → Bと理解しましたが、認識違いがあればご指摘いただけますと幸いです。」

Mình khuyên thật với các bạn là nếu nghe - hiểu nhưng không chắc chắn nội dung, đừng có ngại mà hãy chai mặt đi confirm lại. Thà bị nghĩ là "có vậy mà cũng không hiểu", còn tốt hơn hiểu sai rồi truyền đạt cho team ở nhà sai là lại "ăn cám" ^^.

✅ Tổ chức session confirm intent trước khi đi vào chi tiết

Thay vì nhào vô hỏi luôn về button, layout, API...
Hãy bắt đầu bằng:

Anh kỳ vọng chức năng này sẽ giải quyết vấn đề nghiệp vụ nào ạ?
「この機能で、どのような業務課題を解決したいとお考えでしょうか？」

Mục đích của việc đặt câu hỏi này là:

  • Mở ra bức tranh toàn cảnh nghiệp vụ, trước khi sa vào chi tiết kỹ thuật.

  • Giúp BRSE hiểu rõ vấn đề cốt lõi khách hàng đang đối mặt, từ đó đề xuất giải pháp phù hợp (thay vì chỉ “build theo mô tả”).

  • Tránh hiểu sai mục tiêu → tránh làm ra chức năng “đúng về kỹ thuật, sai về nghiệp vụ”.

✅ Recap ngay sau buổi họp

Sau mỗi buổi họp, hãy recap lại nội dung đã hiểu và gửi cho khách xác nhận.

“Em hiểu nội dung buổi hôm nay như sau…”
「本日の打ち合わせ内容は、以下の通りと理解しております。」

→ Có recap, mới thấy mình hiểu sót chỗ nào.

Nhưng chỉ recap thôi là chưa đủ.
Hãy đính kèm cả meeting minute (議事録) như một dạng evidence – ghi lại chi tiết toàn bộ nội dung trao đổi, bao gồm cả những phần nói miệng hay phát sinh trong họp.

Ví dụ:

“Chi tiết buổi họp đã được ghi trong biên bản sau, nhờ anh/chị cùng xác nhận giúp ạ.”
「詳細については以下の議事録にも記載しておりますので、ご確認いただけますと幸いです。」

→ Vừa làm rõ ý hiểu, vừa có căn cứ phòng trường hợp sau này có bất đồng.

Kết hợp recap + meeting note là bộ đôi “cứu cánh” giúp BRSE sống sót qua mọi pha “ai đúng – ai sai – ai không nhớ đã nói gì”. 😅

✅ Vì vậy, một recap đầy đủ và chuyên nghiệp nên có:

  1. Tóm tắt nội dung đã thảo luận (theo từng gạch đầu dòng)

  2. Nội dung cần xác nhận lại (Assumptions + Confirmation Points)

  3. Next actions / Ai làm gì, deadline cụ thể cho từng bên

  4. Link đến Meeting minute

✅ Hỏi lại dev/QA trước khi dịch tài liệu

Vì có những đoạn, nếu chỉ dịch literal (dịch word by word theo kiểu máy móc, không phân tích sâu mục đích hoặc logic nghiệp vụ) thì dev và QC sẽ hiểu... sai liền.

Ví dụ:

Ví dụ:

Khách nói:
「予約の確認画面で、患者情報を表示してください。」
(Hãy cho hiển thị thông tin bệnh nhân trên màn hình xác nhận booking.)

Nếu chỉ dịch literal là:

“Hiển thị thông tin bệnh nhân ở màn hình xác nhận.”
→ Thì dev sẽ không biết:

  • Là hiển thị trước khi chốt booking hay sau khi đã book thành công?

  • Hiển thị toàn bộ thông tin hay chỉ một phần?

Trong những tình huống như vậy, mình thường sẽ nhắn trực tiếp cho dev như thế nà

“Khách muốn hiển thị thông tin bệnh nhân trên màn hình xác nhận booking, nhưng chưa rõ thời điểm và mức độ hiển thị. Em đề xuất như sau… Mọi người thấy sao ạ?”

📚 Mình bắt đầu lập checklist “Giao tiếp đa chiều” chuyên dụng cho BrSE

 

Tình huống

Câu hỏi tự vấn

Hành động cụ thể

Yêu cầu mơ hồ

"Mình có đang suy diễn không?"

Gửi mail confirm với assumption

Họp xong chưa rõ

"Đã recap lại chưa nhỉ?"

Gửi note + confirm sau họp

Giao tài liệu cho dev

"Dev có hiểu giống mình không?"

Gặp riêng dev walkthrough

Khách nói miệng

"Mình có ghi lại không?"

Ghi log ngay trong meeting note

Giao tiếp không chỉ là "nói đúng", mà là đảm bảo "hiểu giống nhau"

Là BRSE – nhất là BRSE non-tech – phải luyện kỹ năng giao tiếp như radar:
Nghe – Xác nhận – Nghi ngờ – Lặp lại – Và không assume bất kỳ điều gì.

Vì chỉ một lần “nghe nhầm” hay “hiểu lệch” là đủ kéo theo công sức cả team đổ sông.

Nhưng nếu bạn biết biến mỗi lần hiểu nhầm thành một bài học, thì dần dần, bạn sẽ tự build cho mình một checklist giao tiếp còn đỉnh hơn cả technical spec.

Bạn thì sao?

Lần gần nhất bạn assume sai ý khách – chuyện gì đã xảy ra?
Có tip giao tiếp nào bạn rút ra từ một pha “đi vào lòng đất” không?

Hãy chia sẻ nhé. Biết đâu kinh nghiệm của bạn lại cứu được một BRSE non-tech nào đó đang ngụp lặn giữa những hiểu nhầm... như mình ngày xưa.

Nếu bạn thấy bài viết này quen quen thì đúng rồi đấy…
Vì những vết xước của nghề, ai làm BRSE rồi cũng có vài vết na ná nhau cả thôi 😅
Chúc mọi người "nghe hiểu" luôn chuẩn, và không bao giờ phải làm “thầy bói” nữa nha.


Taiyang – người kể chuyện ngành IT phiên bản không ngầu nhưng thật thà ✌️