Làm thế nào để thiết kế cơ cấu tổ chức và đội nhóm?

Question

Accepted Answer

Thiết kế tổ chức (org design) là về việc **vạch ranh giới đội sao cho những phần công việc thay đổi cùng nhau thì sống cùng nhau** — giảm thiểu phụ thuộc liên đội cho những thứ cần dịch chuyển nhanh. Cấu trúc nên đi theo chiến lược và hệ thống, không phải ngược lại.

## Nguyên tắc

```text
1. ĐỘI SỞ HỮU KẾT QUẢ, không phải các lớp (một đội sở hữu một product/domain từ đầu đến cuối)
2. GIẢM THIỂU PHỤ THUỘC — các đội tự chủ ship nhanh hơn
3. ĐỊNH LUẬT CONWAY — kiến trúc sẽ phản chiếu tổ chức của bạn; thiết kế cả hai cùng nhau
4. QUYỀN SỞ HỮU RÕ RÀNG — mỗi mảng trọng yếu có MỘT đội sở hữu
5. KÍCH THƯỚC ĐÚNG — ~5–9 người; đội cỡ "two-pizza"
6. TẢI NHẬN THỨC — đừng giao cho một đội nhiều domain hơn mức nó có thể gánh
```

## Tư duy stream-aligned

Ưu tiên các đội stream-aligned tồn tại lâu dài, sở hữu một luồng công việc, được hỗ trợ bởi các platform team giúp giảm tải nhận thức cho các đội khác. Tái cơ cấu khi cấu trúc bắt đầu chống lại công việc — không phải theo ngẫu hứng.

## Những cạm bẫy

- **Silo theo chức năng** (một "đội QA", một "đội frontend") buộc mọi feature phải băng qua nhiều lần bàn giao.
- **Phớt lờ Định luật Conway** rồi ngạc nhiên khi kiến trúc phản chiếu sơ đồ tổ chức.
- **Tái cơ cấu liên tục**, làm reset niềm tin và quyền sở hữu mỗi lần.
- **Quyền sở hữu mập mờ**, mọi thứ đều "chung" và do đó chẳng ai sở hữu.

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

Cấu trúc âm thầm quyết định tốc độ.

Ranh giới tồi tạo ra vô số cuộc họp điều phối và trách nhiệm mờ nhòe; ranh giới tốt cho phép các đội dịch chuyển độc lập.

Vì Định luật Conway, org design *chính là* thiết kế kiến trúc.

Vạch sai ranh giới đội thì không lượng heroics kỹ thuật nào làm cho hệ thống sạch sẽ được.