Tư duy (Mindset) khi làm Leader Bài 4: Quản trị rủi ro & Ra quyết định

Khi làm Developer, bạn thường được giao một con đường đã vạch sẵn và nhiệm vụ của bạn là đi đến đích nhanh nhất, an toàn nhất [cite: x]. Nhưng khi làm Leader, bạn đứng trước ngã ba đường, không có biển chỉ dẫn, và bạn phải là người chọn đường cho cả đội đi [cite: x].

Đó chính là lúc bạn cần đến khả năng Quản trị rủi ro và Ra quyết định [cite: x].

1. Tư duy "Nếu... thì sao?" (Phòng bệnh hơn chữa bệnh)

• Developer thường lạc quan: "Code chạy ngon ở local rồi, deploy lên production chắc chắn ổn!" [cite: x]
• Leader bắt buộc phải bi quan một cách có tính toán: "Nếu tính năng này deploy lên mà server bị quá tải thì sao? Chúng ta có cơ chế rollback (hoàn tác) ngay lập tức không?" [cite: x]

Để rèn luyện tư duy này, bạn hãy nhìn vào mọi task, mọi hệ thống bằng con mắt tìm kiếm rủi ro [cite: x]:

• Rủi ro kỹ thuật: Thư viện bên thứ 3 (third-party) sập thì app của mình có chết theo không? Nếu database đầy thì sao? [cite: x]
• Rủi ro nhân sự: Nếu ngày mai bạn A (người duy nhất nắm core logic của module này) xin nghỉ ốm 1 tuần, team có bị đứng hình không? (Đây gọi là Bus Factor - rủi ro phụ thuộc vào một cá nhân) [cite: x].
• Rủi ro tiến độ: Nếu phần Frontend bị chậm 2 ngày, Backend có thể làm mock data để QA test trước được không? [cite: x]

2. Nghệ thuật của sự Đánh đổi (Trade-offs)

Trong thế giới công nghệ, không có giải pháp nào hoàn hảo 100% [cite: x]. Mọi quyết định đều là sự đánh đổi giữa: Tốc độ (Speed) - Chất lượng (Quality) - Nguồn lực (Cost) [cite: x].

Một Leader giỏi không phải là người luôn chọn giải pháp công nghệ "xịn" nhất, mà là người biết chọn giải pháp phù hợp nhất với bối cảnh hiện tại của dự án [cite: x].

Ví dụ thực tế: PO cần ra mắt tính năng gấp trong 3 ngày để chạy chiến dịch Marketing [cite: x].

• Tư duy Developer: "3 ngày không thể viết code sạch và setup kiến trúc microservices được. Em không làm." [cite: x]
• Tư duy Leader: "Chúng ta có thể làm xong trong 3 ngày với giải pháp tạm thời (workaround). Đánh đổi là hệ thống sẽ sinh ra Tech Debt (Nợ kỹ thuật) và khó bảo trì. Đề xuất: Cứ launch để kịp Marketing, nhưng Sprint sau PO phải cho team 2 ngày để refactor (viết lại) phần code này." [cite: x]

3. Quyết đoán và Dám chịu trách nhiệm

Một hiện tượng rất hay gặp ở các team Tech là "Analysis Paralysis" (Tê liệt vì phân tích) [cite: x]. Mọi người họp bàn cả buổi, cãi nhau xem dùng công cụ A hay công cụ B, cuối cùng không ai chốt lại được gì vì sợ chọn sai [cite: x].

• Leader là người dám chốt hạ: Khi có đủ khoảng 70-80% thông tin, hãy ra quyết định [cite: x]. Đừng đợi có 100% thông tin vì lúc đó cơ hội đã trôi qua [cite: x].
• Chấp nhận sai lầm và học hỏi: Quyết định sai tốt hơn là không có quyết định nào [cite: x]. Khi quyết định sai (ví dụ: chọn nhầm thư viện khiến app bị lỗi), Leader không đổ lỗi cho team [cite: x]. Họ đứng ra nhận trách nhiệm với cấp trên: "Đây là quyết định của em. Team đang khắc phục bằng cách X, và tụi em đã rút ra bài học Y để lần sau không lặp lại." [cite: x]

📝 Bài tập thực hành cho Bài 4 (Trong tuần này)

1. Nhận diện "Bus Factor" trong team: Hãy thử quan sát và ghi ra giấy xem trong team bạn hiện tại, có mảng kiến thức nào hoặc phần code nào đang chỉ có duy nhất một người nắm rõ không? Nếu có, hãy đề xuất team tổ chức một buổi chia sẻ (Knowledge Transfer) ngắn để ít nhất 1 người nữa cùng nắm được luồng logic đó [cite: x].
2. Áp dụng khung ADR (Architecture Decision Record): Lần tới khi bạn hoặc team tranh luận về việc chọn 2 cách code/giải pháp khác nhau, hãy làm người "phân xử" bằng cách ghi ra 3 gạch đầu dòng [cite: x]:
   • Bối cảnh (Tại sao phải chọn?) [cite: x]
   • Các lựa chọn và Điểm mạnh/Điểm yếu của từng cái (Đánh đổi) [cite: x].
   • Quyết định cuối cùng là gì và tại sao [cite: x].