Bạn làm gì để team không phụ thuộc quá nhiều vào một người duy nhất?

Question

Accepted Answer

**Bus factor thấp là một rủi ro tôi quản lý có chủ đích, giống như cách tôi quản lý bất kỳ điểm lỗi đơn (single point of failure) nào.** Nếu chỉ một người có thể deploy, debug dịch vụ thanh toán, hoặc đụng vào module legacy, thì team chỉ cách một lá đơn xin nghỉ hoặc một kỳ nghỉ phép là tới khủng hoảng. Mục tiêu là lan tỏa kiến thức mà không làm chậm tất cả mọi người tới mức ì ạch.

## Các cơ chế thực tế

- **Code review có chủ đích.** Review không chỉ là gác cổng; nó là chuyển giao kiến thức. Tôi đảm bảo không vùng nào chỉ được review bởi chính người viết ra nó.
- **Pair và luân phiên trên các hệ thống quan trọng.** Tôi cố ý giao việc ở những vùng rủi ro cao cho một người thứ hai, ngay cả khi chuyên gia có thể làm nhanh hơn. Chi phí ngắn hạn, bảo hiểm dài hạn.
- **Tài liệu xứng đáng với công sức bỏ ra.** Không phải những wiki đồ sộ chẳng ai đọc, mà là những thứ chịu lực: runbook, các quyết định kiến trúc, "cách deploy," "làm gì khi X hỏng."
- **Luân phiên on-call.** Không gì lan tỏa kiến thức vận hành nhanh bằng việc mọi người thay phiên nhau chịu trách nhiệm cho production.
- **Các buổi chia sẻ nội bộ / brown bag.** Người sở hữu một hệ thống con hóc búa dẫn cả team đi qua nó.

## Cách tôi tìm ra rủi ro

- Vẽ bản đồ quyền sở hữu một cách trung thực: với mỗi hệ thống quan trọng, hỏi "ai khác có thể xử lý được nếu X nghỉ hai tuần?" Nếu câu trả lời là "không ai cả," đó là một rủi ro được gắn cờ.
- Để ý **hero pattern** — người luôn là người bị page, luôn là câu trả lời. Đó là dấu hiệu cảnh báo, không phải điểm mạnh.

## Những cạm bẫy

- **Tích trữ kiến thức như một sự bảo đảm công việc.** Một số kỹ sư (và một số quản lý) thích cảm giác không thể thay thế. Tôi diễn giải lại: làm nút thắt cổ chai sẽ chặn chính cơ hội promotion và ngày nghỉ của bạn.
- Sửa quá đà thành "ai cũng làm mọi thứ," làm phá hủy chiều sâu. Mục tiêu là không có điểm lỗi đơn, không phải là không có chuyên môn hóa.
- Viết tài liệu một lần rồi để nó mục nát; tài liệu lỗi thời còn tệ hơn không có.

## Tại sao điều này quan trọng

Giảm bus factor bảo vệ tiến độ giao hàng trước ốm đau, nghỉ phép và nghỉ việc, đồng thời giải phóng những người giỏi nhất của bạn để họ phát triển thay vì bị mắc kẹt bảo trì thứ mà chỉ mình họ hiểu. Nó cũng làm team khỏe mạnh hơn: quyền sở hữu chung thắng những màn anh hùng mong manh.