👩‍💻 Một ngày làm BrSE kiêm BA

√ Sáng đến trưa: meeting, recap, confirm với khách

  • 「こちらのルールで問題ないかご確認いただけますでしょうか？」
    → Nhờ anh confirm giúp tôi rule này có ổn không ạ?

  • 「今朝のミーティングで共有されたケースXYZについて、改めて内容をご確認いただけますか？」
    → Về case XYZ đã trao đổi trong buổi họp sáng nay, anh confirm lại nội dung giúp team với ạ.

  • 「この設定は固定値ではなく、変更可能なものとして対応すればよろしいでしょうか？」
    → Phần setting này bên team sẽ xử lý theo hướng configurable chứ không phải fixed, như vậy có được không ạ?

 

√ Chiều đến tối: dev réo, QC hỏi, tồn 1 mớ nghiệp vụ cần phân tícha

Khi làm BRSE kiêm BA – thời gian để “deep thinking” gần như bằng 0

Bạn là người:

  • Họp với khách để hiểu nghiệp vụ

  • Ngồi chat cả ngày với khách để confirm qua lại những vấn đề chưa được clarify

  • Làm tài liệu mô tả yêu cầu

  • Trả lời câu hỏi từ dev/QA

  • Ngồi suy nghĩ những kịch bản ngoại lệ

  • Verify lại flow system trước khi gửi khách

➡︎ Kết quả thường thấy:
• Spec viết thiếu case, vì không đủ thời gian suy nghĩ sâu
• Cứ dev này tới dev kia, xoay mình lòng vòng giữa mớ QnA về nghiệp vụ hệ thống, trả lời xong xuôi cho từng người là quên cả note lại nội dung vào file spec.
• Đến lúc khách hỏi lại → “Ủa sao không có case ABC trong tài liệu?”
• Cảm giác đầu óc luôn bị ngắt mạch, không thể vào trạng thái deep work

 

Một lần vội vã - vạn lần nhớ sâu 

Một lần, khách hỏi:

「支払い時にクーポンの有効期限が切れていた場合、そのまま決済処理を進めるのではなく、ユーザーに期限切れであることを知らせる対応が必要でしょうか？」
(Trong trường hợp coupon đã hết hạn khi thanh toán, thay vì cứ tiếp tục xử lý payment, có cần hiển thị thông báo cho user biết là coupon đã hết hạn không ạ?)

Tôi nghe xong liền đề xuất:

「では、クーポンを自動的に無効化して、クーポンが未適用の状態で決済画面に進むようにしてはいかがでしょうか？」

　(Hay là mình làm cho hệ thống tự động disable coupon, rồi cho next sang màn hình payment trong trạng thái chưa áp dụng coupon?)

 

Khách trả lời:

「自動で無効にするのは難しいところですが、とはいえユーザー側で気付ける形になっていれば大丈夫ではないでしょうか。」
(Việc auto-disable thì hơi khó nói, nhưng nếu user có thể tự nhận ra được thì chắc cũng ổn nhỉ?)

Câu trả lời nghe rất kiểu "中途半端/ lở dở lương ương, không chốt rõ sẽ theo hướng nào". Nhưng vì lúc đó mình đang bận rộn bởi 1 issue khác, vậy nên thay vì đọc kỹ lại nội dung yêu cầu của khách hàng thì mình báo team dev là xử lý theo hướng disable luôn.

Kết quả là, dev làm đúng cái mình nói, nhưng lại sai với "expected" của khách hàng (thực ra khách muốn show alert khi submit). Dẫn đến team phải rework lại từ đầu, làm tốn gấp đôi effort của team cho một task không phải khó nhằn hay gì.

 

Tips giúp BrSE sống sót khi bị ngụp lặn trong “multi-tasking"

 

1. Chia block thời gian

  • Sáng: 2h deep work (tắt notification, tập trung viết spec, vẽ flow, define rule).

  • Chiều: slot dành cho họp, trả lời QA, xử lý bug, follow up dev.

👉 Thông báo rõ cho team để set expectation:
“Em sẽ xử lý hết câu hỏi từ 2–5h chiều nhé, để buổi sáng tập trung viết spec kỹ hơn.”

 

2. Áp dụng ma trận Urgent / Not urgent

  • Urgent & Important: Task blocking release, bug ảnh hưởng production → xử lý ngay.

  • Not urgent but Important: Clarify spec, define rule → xếp lịch deep work buổi sáng.

  • Urgent but Not important: Câu hỏi lặt vặt QA → gom lại thành block trả lời chiều.

  • Not urgent & Not important: Low-priority request → ghi nhận, follow up sau.

 

Ví dụ:
Hiện tại team có 5 dev, mỗi người đang ôm một task khác nhau. Mỗi task đều có spec cần làm rõ, nhưng mức độ khẩn cấp không giống nhau.

  • Task A (Dev1): spec chưa rõ, deadline release tuần này → Urgent & Important.

  • Task B (Dev2): tính năng mới, còn thời gian → Not urgent but Important.

  • Task C (Dev3): bug nhỏ, workaround được → Not urgent & Not important.

  • Task D (Dev4): câu hỏi QA lặt vặt → Urgent but Not important.

  • Task E (Dev5): rule phức tạp, cần define kỹ → Not urgent but Important.

👉 Cách xử lý:

  • Mình đánh độ ưu tiên dựa trên thời gian hoàn tất dự kiến + ma trận Urgent/Not urgent.

  • Block buổi sáng: xử lý Task A & E (deep work để viết rule, clarify spec).

  • Buổi chiều: trả lời Task D + follow up bug Task C.

  • Task B ghi nhận và hẹn slot clarify vào ngày hôm sau.

 

Bằng cách này, team thấy rõ vì sao có task được ưu tiên clarify ngay, task khác phải đợi. Dev cũng đỡ “hỏi tới đâu – trả lời tới đó” gây loãng thời gian, còn mình thì giữ được nhịp làm việc tập trung.

 

3. Tạo list Q&A tập trung

  • Thực tế: nếu để dev/QA hỏi qua chat rải rác thì rất dễ trôi mất thông tin. Mình từng bị hỏi cùng một câu 3 lần chỉ vì không log lại.

  • Cách làm:
    • Tạo 1 Notion board hoặc Google Sheet làm kho Q&A.
    • Cột gợi ý: Task ID / Người hỏi / Nội dung câu hỏi / Trạng thái (Pending, Answered, Need confirm khách) / Link liên quan.
    • Trả lời theo batch (ví dụ: gom lại 5–10 câu, xử lý 1 lượt từ 2–5h chiều).
    👉 Lợi ích: giảm context switching, có trace để tra lại, và reuse cho task tương tự.

Ví dụ:
Dev hỏi “Booking đã cancel thì có thể re-open lại không?” → log vào sheet, trả lời rõ kèm flow, lần sau QA test lại case này chỉ cần search là ra, khỏi hỏi lại.

 

4. Chuẩn hóa format tài liệu

  • Khi viết spec/answer, dùng template cố định để dev dễ follow, tránh sót.

  • Một doc nên có 5 block:

    1. Happy case: flow chuẩn, không lỗi.

    2. Exception case: lỗi thường gặp (ex: booking cancel rồi nhưng vẫn show trong lịch).

    3. Permission: ai được thao tác (admin, doctor, user…).

    4. Configurable/Fixed: cái nào set được, cái nào hardcode.

    5. Related logic: các rule liên quan (ex: thay đổi booking thì ảnh hưởng tới 問診票/medical questionnaire).

Nhờ format này, khi dev hỏi kiểu:
- Ở màn hình này, nếu cancel thì có cho phép bệnh nhân booking lại vào cùng 1 ngày được không?
→ Mình chỉ việc mở doc, kéo xuống Exception case là có sẵn rule để trả lời ngay.

 

5. Dám nói “em cần thêm thời gian”

Nhiều newbie thường vội confirm để “ghi điểm” trong mắt khách hàng → kết quả là dev code theo spec nửa vời, QA báo lỗi, rồi cả team phải họp lại.

Với vụ batch gửi mail reminder như dưới đây, nếu không confirm kỹ thì hậu quả rất cụ thể: user không nhận mail, support nổ inbox, release delay.

Ví dụ:

Khách yêu cầu: gửi mail reminder lúc 07:00 cho booking có thời gian khám rơi vào buổi sáng, và 12:00 cho booking có thời gian khám rơi vào buổi chiều.
Thực tế dev/ops chạy batch ở 06:55 và 11:55

=> Nếu booking rơi ngoài khoảng “được tính vào batch” (ví dụ booking được tạo vào 06:58 cho slot 07:00), nó có thể bị bỏ sót. Đây là chỗ dễ hiểu sai nếu không hỏi thêm.

 

Vì vậy: Nếu chưa rõ — hãy xin khách thêm thời gian để confirm.

Bạn có thể nói như sau:

「この部分は一見シンプルですが、バッチの起動時間や処理対象の定義次第で挙動が変わります。正確な仕様にしておかないとメールが届かないケースが発生するため、1日いただいてバッチ条件と例外ケースを整理してもよろしいでしょうか？」

(Phần này trông đơn giản nhưng phụ thuộc vào cron/batch time và điều kiện xử lý — nếu không làm rõ sẽ có booking bị lọt. Team xin 1 ngày để check kỹ từng case rồi confirm cách xử lý được không ạ?)

Nghe như vậy khách cũng sẽ hiểu và thông cảm cho mình — và thà chậm 1 nhịp còn hơn là để phát sinh những bug không đáng có gây mất lòng tin ở phía khách hàng.

 

✅ Những câu hỏi cần confirm trước khi chốt spec (để tránh hiểu nhầm)

  • Batch chạy vào chính xác mấy giờ? (ví dụ 06:55, 11:55) — ai chịu trách nhiệm ops?

  • Timezone dự án là gì? (UTC / Asia/Ho_Chi_Minh / server tz)

  • Tiêu chí đưa booking vào batch là gì? (ví dụ: booking.start_time nằm trong [07:00–07:30] hay start_time == 07:00?)

  • Khoảng “inclusion window” (ví dụ: batch gửi reminder cho booking có start_time trong 07:00 ± 5 phút hay chỉ chính xác 07:00?)

    • Inclusion window: Khoảng thời gian mà hệ thống xác định “booking nào sẽ được đưa vào batch để xử lý”. Nói cách khác, Batch không xử lý mọi booking tồn tại trong DB, mà chỉ lấy những booking thoả điều kiện thời gian nằm trong window đó.

      Ví dụ trực quan hơn:

      • Batch chạy lúc 06:55 sáng.

      • Inclusion window được định nghĩa là: tất cả booking có start_time từ 07:00 → 11:59 (tức là các booking buổi sáng).

      ==> Như vậy, batch sẽ query:

       
      SELECT * FROM booking
      WHERE start_time BETWEEN '07:00' AND '11:59'
      AND status = 'CONFIRMED'
      AND created_at < '06:55'; 
       

  • Nếu booking được tạo/đổi giờ sau lần chạy batch (ví dụ tạo 06:58 cho slot 07:00) → có retry hay re-run không? Có job lần thứ 2 không?

  • Nếu coupon/permission/blacklist ảnh hưởng (ví dụ user unsubscribed) → xử lý thế nào?

  • Yêu cầu UX: show log/trace cho support? show trong UI? show failed attempts?

  • Acceptance criteria cho QA (test cases) là gì?

Dưới đây là nội dung mẫu dùng để phản hồi KH về hướng xử lý của team:

 

項目: リマインダーメールのバッチ処理
概要: 以下のルールでバッチを実行する。

  • Batch A: 06:55（サーバー時刻）に実行 ⇒ 午前枠（07:00〜11:59）の予約へ送信。

  • Batch B: 11:55（サーバー時刻）に実行 ⇒ 午後枠（12:00〜17:59）の予約へ送信。
    対象条件: バッチ実行時点で status = CONFIRMED の予約のみ対象。実行後に作成/更新された予約は当該実行で送信されない。
    補償処理: 必要あれば、実行直前の追加チェックや再実行（例: 06:58/11:58 のサブ実行）を設計する。
    ログ: 処理対象リスト・成功/失敗を必ずログ出力し、サポートが参照できるようにする。
    QA項目: 実行前に作成された予約は送信されるか、直前作成は送信されないか、タイムゾーンケース、ユーザー配信停止ケースなど。

     

    Mục: Batch Mail Reminder
    Mô tả: Hệ thống sẽ gửi mail nhắc trước cho booking theo quy tắc:

    • Batch 1 chạy 06:55 (server tz): gửi reminder cho các booking có start_time thuộc buổi sáng (ví dụ: 07:00–11:59).

    • Batch 2 chạy 11:55 (server tz): gửi reminder cho các booking có start_time thuộc buổi chiều (ví dụ: 12:00–17:59).
      Inclusion window: booking phải tồn tại trước thời điểm batch chạy và có status = CONFIRMED. Nếu booking được tạo/hoặc thay đổi sau thời điểm batch chạy, sẽ không được gửi reminder trong lần chạy đó.

    • Retry / compensating job: Nếu cần đảm bảo không bỏ sót booking tạo sát giờ, cần thêm secondary job (ví dụ re-run tại 06:58 cho morning, 11:58 cho afternoon) hoặc trigger real-time khi booking created/updated trong window X phút trước start_time.

    • Logging / Visibility: Mỗi lần batch phải log list booking processed, success/fail, lý do fail; hiển thị link logs cho support.

    • QA Acceptance: test cases bao gồm booking created trước 06:55 (should get mail), created at 06:58 (should NOT get mail unless compensating job), updated from 06:50→07:10 (should follow updated logic), user unsubscribed (no mail), timezone edge-case.

     

✅ Acceptance criteria / Test cases (tối thiểu)

  • TC1: Booking tạo 07:00 slot, tạo lúc 06:00 → nhận mail (pass).

  • TC2: Booking tạo 07:00 slot, tạo lúc 06:58 → không nhận mail (pass) — nếu theo spec hiện tại; nếu muốn khác thì spec phải nói rõ.

  • TC3: Booking thay đổi start_time từ 08:00 → 07:00 lúc 06:59 → có/không nhận mail? (xác định theo spec)

  • TC4: User unsubscribed → không gửi.

  • TC5: Timezone khác server → kiểm tra mapping.

  • TC6: Fail delivery → log/alert có rõ lý do không.

✅ Checklist nhanh trước khi chốt

◻︎Batch cron time đã confirm (HH:MM) và timezone.

◻︎Đã định nghĩa inclusion window rõ ràng.

◻︎Quy tắc cho booking tạo/ cập nhật sát giờ đã nêu (compensating job hay realtime trigger).

◻︎Acceptance tests đã liệt kê.

◻︎Log & visibility cho support OK.

 

📝 Checklist confirm rule (JP–VN)

  • 「このルールは全てのケースに適用されますか？」
    → Rule này áp dụng cho tất cả case hay chỉ một số?

  • 「更新は上書き処理ですか？それとも追記処理ですか？」
    → Update là overwrite hay append thêm dữ liệu?

  • 「キャンセル時のデータは保持しますか？削除しますか？」
    → Cancel thì giữ hay xóa dữ liệu?

  • 「例外ケースとして想定しているものはありますか？」
    → Có ngoại lệ nào cần tính đến không?

  • 「私の理解をまとめると、◯◯です。間違いないでしょうか？」
    → Tôi tóm lại hiểu biết: ◯◯. Có đúng không ạ?

📚 Checklist “BrSE kiêm BA”

  • Bảo vệ thời gian deep work

  • Ghi lại mọi câu hỏi để không bị quên

  • Chuẩn hóa tài liệu bằng template

  • Confirm rule bằng checklist Nhật–Việt

  • Dám xin thêm thời gian để define đúng

🌱 Kết

Làm BrSE kiêm BA không mệt vì việc khó, mà mệt vì bị ngắt mạch suy nghĩ liên tục. Nhưng chỉ cần biết cách quản lý thời gian, lưu trace và confirm rule cẩn thận, bạn sẽ thấy mình “chat cả ngày” mà vẫn define đủ sâu.

Hãy nhớ: mỗi lần clarify kỹ lưỡng, bạn không chỉ cứu spec mà còn cứu cả team khỏi một bug.