⏰ Sáng thứ 7, 6h30. Chuông báo thức chưa kêu mà mình đã bị đánh thức bởi tiếng ting ting dồn dập từ Chatwork. Trong cơn ngái ngủ, mình chỉ kịp thấy cái title liên quan được khách highlight: “[至急][本番環境で不具合発生]// Urgent – Bug Production”.
Nếu ai từng làm BrSE chắc hẳn sẽ hiểu cảm giác “tim rơi xuống dạ dày” lúc đó. Ban đầu, mình nghĩ chắc là bug hiển thị đơn giản. Nhưng khi mở log và check ticket thì thấy bug cũng căng đét phết.

Bug Bác sĩ và bệnh nhân đã vào phòng khám online, nhưng không thể nhìn thấy nhau - một con bọ siêu to liên quan đến core function của hệ thống.

 

🔹 Bối cảnh

Lấy bối cảnh là hệ thống làm về khám bệnh online. Flow hoạt động của hệ thống được 想定/dự kiến như dưới đây:

Bệnh nhân thực hiện booking trên user site → Gửi thông báo booking đến admin site → Gửi mail thông báo đến bệnh nhân và bác sĩ chỉ định khám ※ Trong mail có cấp URL meeting dùng để truy cập vào phòng khám bệnh online.

Cụ thể hơn:

  1. Bệnh nhân booking lịch khám trên web.

  2. Hệ thống gửi email cho cả bệnh nhân và bác sĩ, trong đó có URL riêng để vào phòng video call.

    • URL bác sĩ chứa param c (clinic).

    • URL bệnh nhân chứa param u (user).
      Ví dụ:

    https://onlinetreatment.com/meeting/c?booking_id=1224 https://onlinetreatment.com/meeting/u?booking_id=1224

  3. Khi cả hai cùng truy cập đúng link, hệ thống sẽ kết nối camera/mic → hai bên thấy và nghe được nhau.

🚨 Issue phát sinh

Khi bệnh nhân và bác sĩ đều join vào phòng video call đúng theo giờ booking, nhưng hai bên không nhìn thấy nhau, timer không chạy, và session coi như “chết đứng”.

Phía End-user liên tục réo phía middle, phía Middle thì thúc hối team offshore, tình huống cực kỳ căng thẳng.

 

🔹 Điều tra nguyên nhân

Sau khi trace log và so sánh URL, phát hiện:

  • Param trong URL được gắn sai.

  • Nguyên nhân: phía công ty đồng phát triển (cùng tham gia dự án) khi bổ sung tính năng test mic/camera trước khi vào phòng đã chỉnh sửa xử lý param trong link meeting.

  • Họ vô tình thay đổi cấu trúc URL chung mà không thông báo cho công ty mình → dẫn đến link bị lỗi, khiến hệ thống không thể kết nối đúng role giữa bác sĩ và bệnh nhân.

🔹 Cách mình trình bày issue với khách

Ngay khi nhận thông báo “Không vào được phòng meeting”, bài toán đầu tiên mình đối diện không phải là code, mà là communication.
Khách nói “không vào được” – nhưng thực tế có thể có đến hàng chục nguyên nhân:

  • Do đường truyền của bác sĩ/bệnh nhân yếu.

  • Do thao tác nhầm link.

  • Do account chưa được active.

  • Hoặc nghiêm trọng hơn: lỗi hệ thống.

Trong vài phút ngắn ngủi, mình vừa phải cùng dev trace log, vừa tự hỏi: “Nếu khách gọi ngay bây giờ, mình nên trả lời thế nào?”

Nếu báo quá mơ hồ:

“Hiện chưa rõ nguyên nhân, chỉ biết là không kết nối được.”
→ Khách sẽ càng hoang mang và nghi ngờ năng lực của team.

Nếu đi sâu quá technical:

“Do param URL bị phía công ty đồng phát triển sửa nhầm trong function test mic/camera.”
→ Khách có thể không hiểu, hoặc tệ hơn, suy diễn rằng “team không kiểm soát nổi phía vendor thuê ngoài”.

Ở vai trò BrSE, đây chính là tình huống “đi trên dây”: phải vừa nói thật – vừa chọn lọc. Nói ít quá thì bị coi là giấu giếm, nói nhiều quá thì gây mất niềm tin.

Cuối cùng, mình đã chọn trình bày theo cấu trúc 4 tầng:

  1. Hiện trạng (Fact)
    「患者様と医師の両方がビデオ通話用URLから入室しても、互いに映像が表示されない事象が発生しています。」
    (Bác sĩ và bệnh nhân đều vào đúng link, nhưng không nhìn thấy nhau.)

  2. Nguyên nhân sơ bộ (Why)
    「案内メールに添付されるURLパラメータが誤っており、患者用・医師用の識別が正しくできない状態でした。」
    (URL param bị sai, không phân biệt được role bác sĩ/bệnh nhân.)

  3. Mức độ ảnh hưởng (Impact)
    「診察自体が成立しないため、ビジネスに直結する重大な不具合です。」
    (Buổi khám không thể tiến hành, ảnh hưởng trực tiếp business.)

  4. Hướng xử lý (Action)
    「至急URL修正対応を行い、さらに今後は共通機能の変更時に必ず事前連絡・確認を行うプロセスを追加します。」
    (Fix ngay URL, đồng thời bổ sung quy trình confirm khi cty đồng phát triển thực hiện chỉnh sửa trên common function.)

 

🔹 Bài học rút ra

  1. Đặt khách vào trung tâm khi trình bày issue
    Không phải lúc nào khách cũng quan tâm đến lỗi code cụ thể. Điều họ muốn nghe là: tình trạng hiện tại ảnh hưởng ra sao, nguyên nhân là gì, và bao lâu thì có thể fix.

  2. Ngắn gọn nhưng đủ ý
    Khi explain, chỉ cần 4 yếu tố: hiện trạng – nguyên nhân – ảnh hưởng – hướng xử lý. Tránh lan man, nhưng cũng không được bỏ sót thông tin quan trọng.

  3. Chuyển vấn đề thành cơ hội cải thiện
    Bug lần này do công ty đồng phát triển vô tình sửa param chung mà không báo.

    Bài học rút ra: phải thiết lập quy trình liên lạc – bất kỳ thay đổi nào liên quan đến chức năng dùng chung giữa hai bên đều cần notify + confirm phạm vi ảnh hưởng trước khi release.

  4. Lesson learned cho BA/BrSE

    • Đừng chỉ dừng lại ở việc report bug. Hãy nhìn issue như một cơ hội để refine lại requirement, process và communication.

    • Một issue production nếu được xử lý minh bạch, nhanh gọn, có thể biến thành điểm cộng: khách sẽ tin tưởng team hơn vì khả năng kiểm soát và quản lý rủi ro.

 

✅ Checklist khi trình bày issue cho khách

  • Hiện trạng: Mô tả đúng sự cố đang xảy ra.

  • Nguyên nhân: Giải thích ngắn gọn, dễ hiểu, tránh quá technical.

  • Ảnh hưởng: Chỉ rõ mức độ tác động đến enduser/business.

  • Hướng xử lý: Nêu plan fix, ước lượng timeline.

  • Quy trình phòng ngừa: Đề xuất cải thiện để tránh tái diễn.

 

🥀 Đúc kết

Làm BrSE, khi đối diện với bug production, chúng ta không chỉ là người “truyền đạt sự cố” mà còn là người quản lý thông tin: phải biến vấn đề phức tạp thành thông tin ngắn gọn, đủ ý và dễ hiểu cho khách.
Một câu nói mơ hồ có thể khiến khách mất niềm tin, nhưng một báo cáo rõ ràng, đi kèm kế hoạch xử lý, sẽ biến “khủng hoảng” thành “cơ hội khẳng định năng lực”.
Nói ngắn gọn nhưng đủ – đó chính là kỹ năng quan trọng để xây dựng sự tin cậy lâu dài với khách hàng.