Chào mọi người,
Hôm nay là Day 14 trong series "IT Storytelling – chuyện ngành IT". Thú thật, mình từng nghĩ công việc BrSE chủ yếu là họp và confirm rule với khách. Nhưng rồi có những ngày, không chỉ họp, mà còn phải lao vào dập bug cháy nhà.

Một trong những kỷ niệm nhớ đời là vụ bug đặt sân tennis trùng giờ.

 

★ Bối cảnh câu chuyện

Dự án hôm đó đang chạy hệ thống đặt sân tennis. Rule khách đưa ra ban đầu nghe thì đơn giản:

  • Cho phép booking trùng đầu.

  • Cho phép booking trùng đuôi.

  • Không cho phép một booking nằm trọn vẹn bên trong booking khác.

  • Và có thêm rule “Overlap" cho phép chồng lấn tối đa 10 phút.

 

Nghe thì đơn giản, dev cũng code đúng rule. Nhưng bug lại nổ ngay trong production.
Một khách hàng báo rằng họ đặt sân thành công, nhưng khi đến nơi thì… lại bị trùng giờ với người khác 😓.

Nguyên nhân đến từ việc vi phạm case NG trong rule thứ 3 đề cập phía trên.

  • User A book: 12:20–12:30

  • User B book: 12:10–12:40

  • Hệ thống chỉ check overlap = 10 phút (12:20–12:30) và cho là hợp lệ.

  • Nhưng thực tế, booking của User B bao trùm toàn bộ booking của User A, dẫn đến cả hai người cùng bị confirm.

Trong buổi họp khẩn với KH:
💬 Khách: 「なぜこのような二重予約が発生したのですか？」
(Tại sao lại xảy ra double booking như thế này?)
💬 Tuôi (với vẻ mặt căng như dây đàn): 「仕様では10分までOKと書いてあったので、その通りに実装しました。」
(Trong spec ghi rõ là cho phép overlap đến 10 phút, nên bọn tôi code y nguyên.)

 

Sau đó khách có giải thích lại cụ thể cho tôi về rule "Không cho phép một booking nằm trọn vẹn bên trong booking khác" bằng sơ đồ như dưới đây.

Xem hình minh họa case OK và case NG thì mới hiểu ra là vấn đề không nằm ở code, mà nằm ở cách diễn giải business rule ^^.

 

 

 

⁉️ Điều tra nguyên nhân
Sau khi dive vào log + test lại, mới thấy logic “booking trùng” không hề đơn giản như lúc đầu tưởng.

Ví dụ thực tế từ production:

  • Booking A: 12:20 – 12:30

  • Booking B: 12:10 – 12:40

  • Rule: cho phép overlap tối đa 10 phút, nhưng không cho phép một booking bị bao trùm toàn bộ bởi booking khác.

👉 Khi check theo logic code, hệ thống lại xử lý như sau:

  • C1: Booking A bắt đầu = 12:20 (nằm trong khoảng overlap của B) → ✅ cho phép.

  • Nhưng thực tế: A bị B bao trùm toàn bộ → đúng rule thì phải ❌ NG.

👉 Chính sự “hiểu nhầm” giữa rule overlap ≤ 10 phút và rule không bao trùm toàn bộ đã dẫn tới bug double booking trong production.

 

🌱 Bài học mình rút ra

1. Rule nghiệp vụ tưởng đơn giản nhưng thực chất là một logic tree

Khách nói: “cho phép trùng đầu/đuôi, không cho phép nằm trọn” → nghe ngắn gọn, nhưng dev không thể code chuẩn nếu chỉ vậy.
BrSE/BA cần bẻ nhỏ thành scenario cụ thể, highlight cái nào ✅ OK/ ❌ NG.

 

2. Phải phân tích logic nghiệp vụ thành tất cả pattern có thể xảy ra

Rule khách đưa: “cho phép trùng đầu, trùng đuôi, không cho phép nằm trọn vẹn trong nhau” → chưa đủ để dev code chuẩn.
Cần đưa về logic đầy đủ hơn:

  • Trường hợp đúng giờ bắt đầu hoặc kết thúc → OK.

  • Trường hợp có bất kỳ khoảng overlap nào ngoài head/tail → NG.

  • Trường hợp nằm trọn vẹn trong nhau → NG.

👉 Tức là: chỉ cho phép “chạm biên”, không cho phép “chồng lấn”.

 

3. Business case: Booking overlap

Từ ví dụ A & B, mình học được rằng confirm rule phải:

  • Liệt kê tất cả case có thể xảy ra.

  • Phân loại rõ case nào ✅ OK, case nào ❌ NG.

  • Chuyển thành bảng/diagram cho cả bên internal và external dễ hiểu → tránh việc mỗi người hiểu một kiểu.

 

4. Vai trò BrSE trong “bug cháy nhà”

  • Khách kỳ vọng: không để bất kỳ overlap ngoài rule xảy ra.

  • Dev code đúng theo spec mơ hồ.

  • Người gánh ở giữa chính là BrSE: phải translate rule thành test case đủ chi tiết.

👉 Nếu không làm rõ ngay từ đầu, production sẽ thay bạn “test” miễn phí.

 

5. Checklist khi confirm rule booking trùng

  • Xác định rõ Overlap rule: bao nhiêu phút được phép trùng?

  • Vẽ timeline với 2 booking mẫu → liệt kê toàn bộ scenario (C1 → Cn).

  • Confirm với khách từng case: ✅ OK / ❌ NG.

  • Document lại logic + test case cho dev.

  • Sau bug: bổ sung vào business rule guideline để tránh repeat.

 

🥀 Đúc kết

Một ngày làm BrSE không chỉ có meeting, mà có thể phải lao vào xử lý bug cháy nhà từ production. Nhưng chính những lúc ấy, mình hiểu thêm:

  • Rule nghiệp vụ cần breakdown đến mức test case cụ thể.

  • BrSE không chỉ relay rule, mà phải lường trước edge case.

  • Bug production, nếu nhìn tích cực, là cơ hội để refine nghiệp vụ và trưởng thành hơn.

Thế nên, đừng coi bug chỉ là “cháy nhà” – hãy xem nó như một cuộc diễn tập thực chiến để nâng cấp bản thân.

 

#Taiyangsharing #ITtopci #BrSEstorytelling #chuyệnngànhIT #BrSEnontech