Tư Duy Nhận Task "Chuẩn Chỉnh" Cho Fresher Tập 2: "Chia Để Trị" (Kỹ năng băm nhỏ vấn đề).

Nếu Tập 1 là để hiểu đúng việc, thì Tập 2 là để làm đúng cách. Bệnh chung của Fresher khi nhận một task phức tạp là thường nhìn nó như một "cục tảng" khổng lồ, dẫn đến hai thái cực: một là hoang mang không biết bắt đầu từ đâu, hai là lạc quan tếu và đưa ra estimate (ước lượng thời gian) ảo tưởng.

Đây là cách hướng dẫn Fresher băm nhỏ task chuẩn tư duy của một kỹ sư hệ thống.

1. Phân rã cấu trúc (Work Breakdown Structure)

Đừng để Fresher vừa nhận task xong đã lao ngay vào gõ code. Hãy bắt các bạn ấy vẽ ra giấy hoặc lên một checklist cụ thể các bước thực thi.

• Tư duy cốt lõi: Một task lớn thực chất là tập hợp của nhiều task nhỏ (Sub-tasks). Băm càng nhỏ, tỉ lệ rủi ro càng thấp.
• Ví dụ thực chiến: Khi giao task "Xây dựng API đặt chỗ và thanh toán vé", Fresher không được phép ghi vào To-do list một dòng chung chung là "Code tính năng đặt vé". Hãy yêu cầu họ băm nhỏ thành các phase:
  • Thiết kế Dữ liệu: Phân tích schema database, xác định các bảng cần thiết, thiết lập Index.
  • Xử lý Logic Lõi: Viết logic check số lượng vé (chỗ này phải nhắc nhở tự đặt câu hỏi: có cần dùng Row-level locking để tránh tình trạng race condition khi nhiều người cùng đặt không?).
  • Tích hợp Cache/Queue: Có cần lưu tạm dữ liệu vào Redis để tối ưu tốc độ đọc không? Có đẩy event vào Message Queue (RabbitMQ/Kafka) để xử lý bất đồng bộ bước gửi email không?
  • Viết Unit Test & Load Test: Chuẩn bị các script test để giả lập hàng trăm request đập vào cùng lúc.
  • Tối ưu & Dọn dẹp: Refactor code theo Clean Architecture trước khi push.

2. Quản lý Sự phụ thuộc (Dependencies) & Nhận diện Blocker

Sau khi băm nhỏ task, Fresher cần nhìn vào danh sách đó và xác định xem bước nào mình có thể tự làm, bước nào phải phụ thuộc vào người khác (hoặc hệ thống khác).

• Chỉ ra các Blocker (Vật cản):
  • Cần quyền truy cập: "Em chưa có quyền truy cập vào server Staging để test, em cần xin anh DevOps cấp quyền ngay bây giờ."
  • Chờ API từ bên thứ 3: "Logic thanh toán cần chờ API của bên ngân hàng trả về."
• Chiến thuật "Switch Context" (Linh hoạt chuyển đổi): Dạy Fresher không bao giờ lấy lý do "Em đang chờ anh A cấp quyền nên hôm nay em ngồi chơi". Nếu Sub-task 1 bị block, phải tự động nhảy sang làm Sub-task 3 (Ví dụ: Chờ API thực tế thì tự viết dữ liệu giả - Mock data - để code phần hiển thị trước).

3. Nghệ thuật Ước lượng (Estimation) không "ảo tưởng"

Từ danh sách các Sub-tasks đã băm nhỏ, việc đưa ra thời gian hoàn thành sẽ trở nên thực tế và có cơ sở hơn rất nhiều.

• Quy tắc vàng: Không có một Sub-task nào được phép kéo dài quá 1 ngày làm việc (4-8 tiếng). Nếu một bước mất nhiều hơn 1 ngày, tức là nó vẫn còn quá to, phải băm nhỏ tiếp.
• Nguyên tắc "Buffer Time" (Thời gian dự phòng): Fresher thường tính thời gian code bằng thời gian hoàn thành. Phải nhắc nhở rằng: Thời gian hoàn thành = Thời gian Code + Thời gian Debug + Thời gian chờ Review + Thời gian Fix lỗi sau Review. Cần cộng thêm ít nhất 20-30% thời gian dự phòng cho những rủi ro bất ngờ (lỗi môi trường, server sập, v.v.).

Red Flags (Dấu hiệu cảnh báo nguy hiểm) cần chấn chỉnh ngay:

• Checklist "có như không": Viết To-do list nhưng các đầu mục quá lớn, không đo lường được tiến độ (Ví dụ: "Làm Frontend", "Làm Backend").
• Giấu nhẹm Blocker: Bị kẹt ở một bước cấu hình môi trường mất cả buổi sáng nhưng không la lên, tự ngồi mò mẫm làm cháy toàn bộ timeline của các bước phía sau.