Chào mọi người,

Nếu như ở Day 14 mình kể về bug cháy nhà thì sang Day 15, mình muốn chia sẻ một pha “đi vào lòng đất” – lần đầu bị khách phản dame ngay trong buổi họp.

🎾 Bối cảnh

Khách muốn thêm tính năng quản lý thời gian kinh doanh cho sân tennis.

  • Có business date (ngày hoạt động).

  • Có business hour (giờ hoạt động).

Nghe qua tưởng chỉ là “add setting mới” → dễ thôi. Nhưng mình đã chủ quan.

 

💥 Pha phản dame trong họp (hội thoại vòng vo)

 

💬 Khách:
「テニスコートの営業時間ですが、単純に1つの時間を設定してずっと使うのではなく、“いつからその設定を有効にするか”を管理したいんです。」
(Về giờ kinh doanh của sân tennis, không chỉ đơn giản là setting 1 lần và dùng mãi, mà tôi muốn quản lý cả “từ khi nào setting đó bắt đầu có hiệu lực”.)

 

💬 Mình (hiểu 1 chiều):
「はい、理解しました。つまり、一度設定した営業時間を編集すれば、常に最新の時間に更新されるということですね。」
(Vâng, em hiểu rồi. Tức là chỉ cần edit lại thì giờ kinh doanh sẽ luôn được update thành giờ mới nhất đúng không ạ?)

 

💬 Khách:
「いえ、そうではなくて、“設定を上書きする”のではなく、“期間ごとに異なる設定を保持したい”んです。つまり、過去に設定した内容も残しつつ、未来に向けて新しい設定を追加するイメージです。」
(Không, không phải overwrite, mà là muốn giữ lại setting theo từng giai đoạn. Tức là vừa giữ được setting trong quá khứ, vừa thêm setting mới cho tương lai.)

 

💬 Mình (bắt đầu loạn):
「えっと…つまり、編集ではなく履歴を残すという感じでしょうか？それとも全ての設定を一つのテーブルに積み重ねるイメージですか？」
(À… tức là không phải edit mà sẽ lưu lại như history ạ? Hay là dồn tất cả setting vào chung một bảng?)

 

💬 Khách (càng nói càng vòng):
「履歴というより、“適用開始日”を持つレコードを複数作れるようにしたいんです。例えば…ある日付を境にして自動的に次の設定に切り替わる、そういう仕組みです。」
(Không hẳn là history, mà là muốn tạo được nhiều record, mỗi record có ngày bắt đầu áp dụng. Ví dụ: đến một ngày nào đó thì hệ thống tự động chuyển sang setting tiếp theo.)

 

💬 Mình (mặt đơ):
「……つまり、編集機能で切り替えるのではなく、自動的に反映されるということでしょうか？」
(…Nghĩa là không dùng chức năng edit để đổi, mà muốn hệ thống tự động phản ánh ạ?)

 

💬 Khách (vẫn kiên nhẫn):
「はい。例えば、2025年5月5日からはこの営業時間、2026年1月1日からは別の営業時間、といった具合です。システムは現在日付を見て、自動的にどの設定を使うか判断する必要があります。」
(Vâng. Ví dụ: từ ngày 2025/05/05 thì dùng giờ kinh doanh A, từ 2026/01/01 thì dùng giờ kinh doanh B. Hệ thống phải dựa vào ngày hiện tại để tự động lấy setting đúng.)

 

💬 Mình (ngộ ra muộn màng):
「あ…つまり“有効期間を持った設定のテーブル”を作るということですね！」
(À… tức là phải có bảng setting với các mốc effective date để quản lý đúng không ạ!)

 

👉 Và kết quả là: khách quá bực vì mình mãi không chịu hiểu, Thậm chí khách còn phải dùng Google Translate bồi thêm cú smash cuối cùng vào Slack.

“Tôi muốn quản lý những ngày mà bảng được áp dụng. Bảng 1 kết thúc từ tháng 1 đến tháng 3 năm 2025. Chúng tôi muốn bắt đầu Bảng 2 từ tháng 4 năm 2025. Nói cách khác, tôi muốn có thể tạo một bảng có thời hạn nộp đơn.”

 

📚 Đào sâu vào issue

Cái khó của mình trong meeting này không nằm ở từ vựng hay nghe hiểu tiếng Nhật, mà là… không phân biệt được “current state” và “history state” trong nghiệp vụ.

  • Suy nghĩ ban đầu của mình: business hour chỉ là một record duy nhất, muốn thay đổi thì edit → overwrite record cũ.

  • Mong muốn thật sự của khách: business hour có tính “phiên bản” (version). Nghĩa là hệ thống phải giữ lại tất cả lịch sử setting và tự động áp dụng mốc mới khi đến thời điểm.

Ví dụ thực tế khách đưa ra (sau khi vòng vo mãi rồi gửi thẳng Google Translate lên Slack 😂):

  • 2025/01 → 8:00 – 20:00

  • 2025/03 → đổi thành 9:00 – 21:00

  • 2026/01 → đổi tiếp thành 10:00 – 22:00

👉 Điều khách cần:

  • Nếu admin check dữ liệu ở 2025/01, phải thấy 8:00 – 20:00, không bị overwrite thành setting mới hơn.

  • Hệ thống phải hiểu: tại “current time” → lấy business hour mới nhất không vượt quá ngày hiện tại. Khi sang mốc mới (ví dụ 2026/01), hệ thống auto switch.

Mình thì cứ loanh quanh nghĩ: “Ủa, business hour đâu cần nhiều version, chỉ cần edit là xong mà?”. Chính vì sự không nhận ra chiều “time dimension” này mà mình bị khách “phản dame” liên tục trong meeting.

 

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

  • Không được assume
    Nghe “add business date/hour” thì tưởng đơn giản là add trường ngày + giờ. Nhưng thực tế requirement còn có “ngầm định” (giữ history, auto switch).

  • Luôn confirm bằng ví dụ timeline
    Thay vì hỏi mơ hồ, mình phải confirm cụ thể:

    “Ví dụ: Từ 2025/01 set 8:00–20:00, rồi 2025/03 đổi 9:00–21:00. Khi admin check lại tháng 1 thì có cần thấy setting cũ (8:00–20:00) không, hay chỉ cần thấy setting mới nhất?”


    → Với dạng requirement có chiều thời gian, timeline/diagram dễ giúp cả hai bên hình dung cùng một khung.

  • BrSE/BA cần phát hiện “time dimension” trong requirement
    Đây là key. Đừng chỉ nghĩ theo trạng thái hiện tại. Hãy luôn tự hỏi:

    • Quá khứ có cần giữ không?

    • Tương lai có thể pre-setting không?

    • Current state sẽ được xác định theo rule nào?

  • Khi không hiểu, cứ mạnh dạn nhờ khách vẽ bảng/diagram
    Nhiều khi requirement phức tạp đến mức diễn đạt bằng lời rất vòng vo. Nếu mình không hình dung ra thì confirm bằng bảng hoặc timeline sẽ nhanh và đỡ gây hiểu lầm hơn.

✅ Checklist chống phản dame

  • Khi nghe yêu cầu mới, hãy tự hỏi: có liên quan đến quá khứ – hiện tại – tương lai không?

  • Confirm bằng timeline example: Past → Now → Future.

  • Paraphrase lại bằng lời mình → xin khách check.

  • Sau họp, gửi meeting note để double-confirm.

  • Nếu thấy requirement hơi mơ hồ, đừng ngại confirm sớm. Im lặng gật đầu là con đường nhanh nhất dẫn tới ‘phản dame’.

✨ Đúc kết

Lần đầu bị khách phản dame ngay trong họp khiến mình vừa ngại, vừa nhớ lâu.
Nó giống như đang đánh tennis, mình tưởng quả bóng sắp ra ngoài nên thở phào, ai ngờ khách tung cú xoáy vào góc sân khiến mình đứng hình.

Nhưng cũng nhờ vậy mà mình rút ra:
👉 Làm BrSE/BA không chỉ “nghe và ghi”, mà phải nghĩ thêm một bước để bao quát cả những chiều thời gian, edge case mà khách chưa nói rõ.

Mỗi lần bị “phản dame” là một lần học cách đứng vững hơn trước những pha bóng bất ngờ của dự án 🎾.