Câu trả lời được chấp nhận
Bạn đang đối mặt với một hệ số xe buýt (bus factor) bằng 1 — tức chỉ cần một người rời đi là dự án có thể đình trệ. Rủi ro này lẽ ra đã phải nằm trong sổ đăng ký rủi ro từ trước; giờ nó đã thành vấn đề (issue), nên phải xử lý như vấn đề.
Ưu tiên trong 30 ngày (theo thứ tự):
- Lập danh mục tri thức quan trọng cùng tech lead ngay tuần đầu: các thành phần, luồng dữ liệu, điểm tích hợp với phần mềm kế toán, tài khoản/hạ tầng, "những chỗ hay hỏng". Xếp hạng theo mức độ rủi ro, không cố tài liệu hoá mọi thứ.
- Ghép cặp chuyển giao (pairing): chỉ định 1–2 người trong đội làm cùng tech lead trên chính các phần rủi ro nhất. Tri thức ngầm truyền qua làm cùng tốt hơn nhiều so với đọc tài liệu.
- Ghi lại quyết định kiến trúc dưới dạng ngắn (bối cảnh – quyết định – hệ quả) và quay video các buổi giải thích.
- Giảm tải cho người nhận chuyển giao: tạm hoãn một số hạng mục ít giá trị trong backlog, cập nhật kế hoạch tiến độ cho trung thực.
- Thương lượng phương án dự phòng: hỏi tech lead có sẵn sàng hỗ trợ tư vấn theo giờ sau khi nghỉ không (qua thoả thuận chính thức với công ty).
Về việc tuyển gấp 2 người: cần thận trọng. Định luật Brooks (The Mythical Man-Month, 1975) cảnh báo rằng thêm người vào dự án phần mềm đang trễ thường làm nó trễ hơn, vì chi phí đào tạo và giao tiếp. Tuyển là đúng cho dài hạn, nhưng đừng coi đó là lời giải cho 30 ngày tới — người mới chính là người cần chuyển giao, sẽ chiếm thêm thời gian của tech lead.
Báo cáo lên sponsor: đừng giấu, cũng đừng kịch tính hoá. Trình bày như một vấn đề có kế hoạch: tác động dự kiến lên tiến độ (khoảng ước lượng, không phải con số đẹp), các hành động đang làm, quyết định bạn cần từ sponsor (ví dụ duyệt ngân sách tư vấn, chấp nhận hoãn hạng mục X). Đây là cách áp dụng nguyên tắc stewardship và minh bạch trong PMBOK 7.
Bài học lâu dài: đưa "phân bố tri thức" thành tiêu chí của Định nghĩa hoàn thành nội bộ — ví dụ mỗi thành phần quan trọng phải có ít nhất hai người hiểu và đã từng sửa.
Nguồn: