Chào mọi người 👋

Làm BrSE/BA, có một “đặc sản” mà chắc ai cũng từng trải qua: deadline dí.
Deadline dí mà chỉ team mình thì còn đỡ. Khổ cái, deadline dí xuyên biên giới: từ khách hàng Nhật → PM JP → BrSE VN → Dev VN. Và mình đứng đâu? Đúng rồi, ngay ở giữa. Một chiếc cầu nối mỏng manh, gió thổi cái là lung lay 🌪️.

Có những hôm, deadline dí tận gáy, khách Nhật sốt ruột hỏi:


「この機能はいつリリースできますか？」
(Chức năng này bao giờ release được vậy?)

 

Trong khi bên dev VN thì rối:
“Task dính critical path, BE delay một ngày là cả chuỗi FE → Test bị chậm theo. Giờ commit thì chắc chắn trễ.”

Ở giữa hai bên, mình phải đứng ra làm “cầu nối mỏng manh”: vừa giải thích rõ rủi ro với khách để họ không nghĩ team VN thiếu trách nhiệm, vừa giữ tinh thần cho dev để họ không cảm thấy bị ép đến ngộp thở.

Nghe thì giống trò đu dây, nhưng đúng là vậy 😅.

 

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

1. Luôn nắm rõ tiến độ thực tế

Không chỉ nghe từ PM hay Dev lead, mà phải đi sâu vào task cụ thể để biết tiến độ thực sự đang ở đâu.
Ví dụ với tính năng Assign bác sĩ (auto/manual), dev estimate 5 ngày nhưng khi breakdown thì:

  1. DB design + viết API assign → 12h

  2. Xử lý logic BE (auto/manual assign) → 16h (critical path)

  3. FE: màn hình chọn bác sĩ (manual) + gọi API → 12h

  4. FE: auto assign + hiển thị kết quả → 8h

  5. UT + IT → 12h

👉 Tổng 60h ~ 7.5 ngày.
Trong đó, BE xử lý logic là critical path. Nếu BE chậm thì cả chuỗi (FE + Test) đều bị trễ.

 

 


Thực tế, dev estimate sai phần BE vì chỉ nghĩ “check lịch trống của bác sĩ”, nhưng sau phát hiện phải xử lý thêm rule check thời gian mở cửa của store, ca làm việc của bác sĩ, bác sĩ có phụ trách course user đã chỉ định không, check ưu tiên assign theo value "degree", ... → phát sinh thêm ~8h.

⚠︎ Trong bối cảnh này, bắt buộc BrSE phải nắm chi tiết “task nào đang stuck? BE, FE hay API bên ngoài?” để đi giải thích/tường trình cụ thể với phía Khách hàng.
➡︎ Nếu không quản critical path thì mọi nỗ lực OT sau đó cũng chỉ là chữa cháy 🚒.

 

2. Dùng ngôn ngữ trung hòa

Làm cầu nối nghĩa là không đổ lỗi trực diện.

  • Với khách: thay vì “Dev chưa làm kịp”, hãy nói:
    「現在、技術的な課題の切り分けを行っており、リリース時期を調整中です。」
    (Hiện tại team đang phân tích technical issue, và thời gian release đang được điều chỉnh.)
    → Giữ sự chuyên nghiệp, tránh mất niềm tin.

  • Với dev: thay vì “Khách hối ỉ ôi kìa mọi người ơi”, hãy nói:
    “Khách đang cần timeline rõ hơn để báo cáo lên manager bên trên của họ, nên nhờ các anh share thêm thông tin cụ thể để em discuss lại với khách ạ.”
    → Giữ tinh thần đồng đội, không tạo áp lực mù quáng.

Ngôn ngữ trung hòa giúp cả hai bên cảm thấy bạn đứng về phía họ, thay vì trở thành “người truyền áp lực”.

 

3. Biết khi nào nên escalate

Nếu task nằm trên critical path và delay nghiêm trọng, không nên ôm một mình.
Ví dụ với case assign bác sĩ, khi BE bị trễ → ảnh hưởng toàn bộ timeline. Lúc này cần escalate lên PM sớm để có phương án:

  • Nới deadline (xin phép khách hàng).

  • Hoặc OT để bù.

➡︎ Cầu nối giỏi không phải là người “chịu đựng” mà là người biết khi nào cần thêm dầm chống để cây cầu không sập 😆.

 

4. Ví dụ report đến phía khách hàng

Trong case ví dụ đề cập ở mục 1, team đã estimate sai phần BE – vốn nằm trong critical path. Theo nguyên lý quản lý dự án, thời gian thực tế tuyệt đối không được vượt quá critical path vì sẽ ảnh hưởng trực tiếp đến deadline tổng.
Khi escalated lên PM thì sự việc đã vượt ngoài tầm kiểm soát, lúc đó chỉ còn cách phải đi cúi đầu xin lỗi khách hàng một cách chân thành và khẩn cầu.

 

📑 Mẫu report tiếng Nhật

 

件名：【重要】医師アサイン機能のリリース遅延について

[お客様名] 様

いつも大変お世話になっております。

この度は、医師アサイン機能（自動アサイン・手動アサイン）の開発において、弊社の見積もり不足により、バックエンド処理（クリティカルパス上のタスク）の工数が想定以上に膨らんでしまい、当初予定していたリリース日に間に合わない状況となっております。
本件につきましては、弊社の不手際によりご迷惑をお掛けすることとなり、心よりお詫び申し上げます。

現在、以下の二つの対応案を検討しております。

  1. リリース日を延長させていただく案
    　→ 追加で必要となる工数（約8時間）を反映し、[新しいリリース日] を目標とする。

  2. リリース日は据え置き、弊社側で残業対応する案
    　→ チーム内で追加工数を吸収し、当初のリリース日を維持する。

大変恐縮ではございますが、どちらの方針で進めるべきかご判断をいただけますでしょうか。
本件、弊社の見積もり誤りによる影響であることを重ねてお詫び申し上げます。

引き続き誠心誠意対応させていただきますので、何卒よろしくお願い申し上げます。


[署名]

 

👉 Mẫu này vừa nhận lỗi chân thành, vừa đưa ra giải pháp cụ thể để khách chọn. Quan trọng: ngữ điệu phải khiêm nhường, “hạ mình” tối đa để thể hiện trách nhiệm.

 

📌 Mini Checklist khi deadline dí

  • Luôn confirm task status với dev → không nói chung chung.

  • Giữ giọng điệu trung lập khi trả lời khách.

  • Ghi chú lại issue + thời gian ảnh hưởng để có bằng chứng.

  • Báo sớm khi có risk → tránh để thành sự đã rồi.

 

Deadline dí là chuyện thường, nhưng qua mỗi lần “đu dây” như vậy, mình học được cách giữ cân bằng.
Vì chiếc cầu nối chỉ mỏng manh nếu mình để nó mỏng manh. Còn nếu mình chịu khó “gia cố” từng chút một – bằng sự minh bạch, ngôn ngữ trung hòa, và tinh thần teamwork – thì cầu nối đó sẽ đủ vững để cả team đi qua.