Dạo gần đây mình đang học thêm kiến thức về quản lý dự án (Project Management), đặc biệt là từ PMP. Mình thấy những concept quản lý này không chỉ áp dụng trong lý thuyết mà còn cực kỳ thực tế trong công việc BrSE hằng ngày. Thế nên hôm nay mình muốn chia sẻ một case study cũ, nhưng lồng ghép thêm góc nhìn quản lý để bài viết thêm thú vị. Mời mọi người cùng tham khảo bài viết nhé ^^.

 

1. Case study – Batch update bị fail trong hệ thống Booking

 

Trong một dự án cũ, team mình có tạo 1 con batch chạy hằng đêm theo flow dưới đây :

  1. Lấy data booking từ DB
  2. Update trạng thái booking
  3. Gửi notification API cho user

👉 Vấn đề: batch bị fail ở bước 2 (update).

  • Nguyên nhân: table lock do process khác (API booking/job khác/batch khác) cùng ghi dữ liệu vào bảng.
  • Hậu quả:
    • User sáng hôm sau login → trạng thái không đổi.
    • CS team bị khách hàng phàn nàn.
    • PM lo ngại hệ thống không ổn định.
    • Nội bộ thì “đùn đẩy trách nhiệm”:
      • BE → blame infra (do DB lock, không phải bug code).
      • Infra → blame BE (query chưa tối ưu).
      • QA → “batch chạy ban đêm nên không test được”.

Kết quả: ai cũng có lý, nhưng không ai đứng ra nhận trách nhiệm.

 

2. Vai trò của BrSE trong tình huống này 👩‍💻

 

Nếu chỉ “dịch qua dịch lại” thì BrSE chẳng khác nào người đưa tin. Nhưng với vai trò quản lý trung gian, BrSE cần làm hơn thế:

  • Step 1: Nhìn issue như một business case
    Batch này ảnh hưởng trực tiếp đến trải nghiệm khách → không chỉ technical issue mà còn là business impact.
  • Step 2: Phân tích trách nhiệm theo góc quản lý dự án
    Mình lập mini RACI chart cho batch:
    • BE: Responsible – viết query batch.
    • Infra: Consulted – confirm DB index/lock.
    • QA: Informed – cần biết cách test batch.
    • PM: Accountable – đảm bảo batch không fail production.
  • Step 3: Bắc cầu trách nhiệm
    Mình tổ chức quick huddle → giải thích batch này là critical path, fail ở đây tức là fail toàn bộ business flow. Kết quả: BE + Infra + QA cùng debug và thống nhất rule mới: luôn dry-run ở staging với volume data lớn trước khi go-live.

 

(※) Know-how sharing

Dry-run = chạy thử / mô phỏng/ rehearsal ==> Hệ thống sẽ thực thi đầy đủ logic xử lý (query, batch, API flow,...) nhưng không commit dữ liệu thật vào database hoặc không thực hiện hành động có ảnh hưởng thật.

Mục đích: kiểm tra logic, performance, và bug trướck hi chạy "real run".

🔹 Ví dụ về bactch gửi mail

√ Dry-run: batch sẽ lấy danh sách bệnh nhân, log ra xem “sẽ gửi mail cho ai, lúc nào” nhưng không gửi mail thật.

√ Real run: batch sẽ gửi mail thật đến bệnh nhân.

 

3. Bài học rút ra – Teamwork = Task + Responsibility

 

Từ case này, mình nhận ra:

  • Chia task thôi chưa đủ → khi có sự cố, ai cũng chỉ nhìn task của mình, không ai nhìn “system chạy ổn chưa”.
  • BrSE chính là người kéo team lại với nhau, nhắc rằng một batch không chỉ là code, mà là trải nghiệm khách hàng.
  • Áp dụng RACI matrix giúp tránh “đá bóng trách nhiệm” và định rõ ai chủ động alert, ai join consult, ai chịu trách nhiệm cuối cùng.

 

4. Mini Checklist để teamwork không chỉ là chia task

  • Clarify rõ R/A/C/I cho các process quan trọng.
  • Đưa batch/API critical vào risk log từ sớm.
  • Confirm có plan “dry-run” trước khi go-live.
  • Khi issue xảy ra, report theo business impact, không chỉ technical.

 

5. Sharing know-how từ kiến thức PMP

 

Theo PMP, teamwork gắn liền với:

  • Responsibility Assignment Matrix (RAM) → phân rõ R/A/C/I để tránh “ai cũng nghĩ người khác lo”.
  • Risk Management → batch fail chính là một risk, cần đưa vào risk log, assign owner và có mitigation plan.

Với góc nhìn này, BrSE giống như “người cảnh báo”:

  • Giúp PM thấy risk từ sớm.
  • Giúp dev team có plan phòng ngừa.
  • Giúp khách hàng thấy team chủ động quản lý, không đợi “sập rồi mới chữa cháy”.

 

🥀 Đúc kết

Teamwork trong IT, đặc biệt ở những hệ thống phức tạp, không bao giờ chỉ là chia task. Nó là cách cả team cùng chia sẻ trách nhiệm để bảo vệ mục tiêu chung.

 

Và ở giữa dòng chảy đó, BrSE nhiều khi chính là “người bắc cầu”: không chỉ dịch ngôn ngữ, mà dịch cả trách nhiệm, dịch cả góc nhìn business. Nhờ vậy, team tránh cảnh “ai cũng đúng nhưng kết quả thì sai”.

 

Vì cuối cùng, khách hàng chẳng quan tâm BE hay Infra, họ chỉ quan tâm hệ thống có chạy đúng hay không. Và BrSE chính là người đảm bảo mọi cây cầu teamwork đều đủ vững, để cả team bước qua an toàn.

 

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