Hệ thống mang hình dạng của tổ chức đã xây nó
Có một quan sát cũ nhưng vẫn đúng trong ngành phần mềm: cấu trúc hệ thống có xu hướng phản chiếu cấu trúc giao tiếp của tổ chức xây ra nó. Ba đội ít nói chuyện với nhau sẽ xây ra ba phần hệ thống nối với nhau bằng những điểm giao mỏng. Một đội lớn ngồi chung sẽ xây ra một khối lớn dính chặt.
Điều này quan trọng với người làm sản phẩm vì chiều ngược lại cũng đúng: khi ranh giới hệ thống không khớp ranh giới đội, mỗi thay đổi phải đi qua nhiều đội, và tốc độ của cả công ty bị quyết định bởi lịch họp phối hợp chứ không phải tốc độ viết code.
Triệu chứng ở ChởNhanh
ChởNhanh (giả định) có 60 kỹ sư chia thành 8 đội:
| Đội | Số kỹ sư | Sở hữu về mặt sản phẩm |
|---|---|---|
| Đặt đơn | 9 | App và web đặt đơn của shop |
| Điều phối | 10 | Ghép đơn, sắp tuyến, giao việc cho tài xế |
| App tài xế | 8 | Ứng dụng của 3.500 tài xế |
| Đối soát COD | 7 | Thu hộ, trả tiền cho shop |
| Tính phí và hoá đơn | 6 | Bảng giá, hoá đơn |
| Công cụ vận hành | 8 | Công cụ nội bộ cho kho và chăm sóc khách |
| Dữ liệu | 7 | Báo cáo, mô hình dự báo |
| Nền tảng | 5 | Dịch vụ dùng chung |
| Tổng | 60 | 8 mảng sản phẩm |
- 40% thay đổi phải sửa code thuộc từ hai đội trở lên.
- Thời gian từ lúc bắt đầu đến lúc lên production trung bình 3 tuần, dù phần viết code chỉ khoảng 4 ngày.
- Một lần phát hành chung mỗi tuần cho cả 8 đội. Một lỗi của đội này chặn phát hành của bảy đội còn lại.
Ranh giới theo nghiệp vụ, không theo tầng kỹ thuật
Một sai lầm hay gặp khi tái tổ chức là chia đội theo tầng: đội giao diện, đội backend, đội cơ sở dữ liệu. Cách này đảm bảo rằng mọi tính năng đều cần ba đội.
Ranh giới tốt đi theo nghiệp vụ: một đội sở hữu trọn một mảng — giao diện, logic và dữ liệu của mảng đó — và nói chuyện với đội khác qua một giao diện rõ ràng (API hoặc sự kiện). Câu hỏi thử: một tính năng điển hình của đội này có làm xong được mà không phải chờ đội khác không?
flowchart TD
A[Đặt đơn] --> E[Dịch vụ trạng thái đơn]
B[Điều phối] --> E
C[App tài xế] --> E
E --> D[Đối soát COD]
E --> F[Công cụ vận hành]
G[Tính phí] --> A
G --> DSơ đồ trên là hướng ChởNhanh muốn đi: mỗi đội có hệ thống riêng, nói chuyện qua dịch vụ trạng thái đơn (bài 5) và dịch vụ tính phí (bài 2), không ai đọc thẳng cơ sở dữ liệu của ai.
Thiết kế đội cho kiến trúc mình muốn
Nếu hệ thống phản chiếu tổ chức, thì muốn có kiến trúc nào, hãy xếp đội theo kiến trúc đó trước, rồi để hệ thống đi theo. Ở ChởNhanh, việc tách đối soát COD khỏi lõi cũ (bài 7) chỉ khả thi vì đã có một đội Đối soát COD 7 người sở hữu trọn nghiệp vụ đó. Nếu nghiệp vụ đối soát rải rác ở ba đội, sẽ không ai đủ thẩm quyền để tách.
Nhưng đừng xếp lại đội quá thường xuyên. Mỗi lần tổ chức lại, đội mất vài tháng để hiểu mảng mới. Nguyên tắc của Mai và anh Đạt: chỉ đổi ranh giới đội khi có dữ liệu cho thấy ranh giới hiện tại gây chậm, và không quá một lần mỗi năm. Xem Org Design for Product cho các mô hình tổ chức đội sản phẩm.
Bốn loại đội và vai trò của chúng
| Loại đội | Làm gì | Ví dụ ở ChởNhanh |
|---|---|---|
| Đội theo dòng giá trị | Giao giá trị trực tiếp cho một nhóm người dùng | Đặt đơn, App tài xế, Đối soát COD |
| Đội nền tảng | Cung cấp dịch vụ dùng chung để đội khác nhanh hơn | Nền tảng |
| Đội hỗ trợ năng lực | Giúp đội khác học một kỹ năng rồi rút ra | Hai kỹ sư Dữ liệu hỗ trợ các đội tự làm báo cáo |
| Đội phân hệ phức tạp | Sở hữu một phần cần chuyên môn sâu | Điều phối, với thuật toán sắp tuyến |
Đo xem có tiến bộ không
Mai và anh Đạt đặt bốn chỉ số, xem mỗi tháng:
| Chỉ số | Hiện tại | Mục tiêu sau 4 quý |
|---|---|---|
| Thay đổi phải sửa code của từ hai đội | 40% | 15% |
| Thời gian từ bắt đầu đến production | 3 tuần | 1 tuần |
| Tần suất phát hành | 1 lần/tuần chung | Mỗi đội tự phát hành hằng ngày |
| Sự cố do thay đổi của đội khác | 4/quý | 1/quý |
Vai trò của người làm sản phẩm
- Đừng thiết kế tính năng chẻ đôi quyền sở hữu. Một tính năng mà nửa logic ở Đặt đơn, nửa ở Điều phối sẽ tạo thêm phụ thuộc. Hỏi kỹ sư: "nên đặt phần này ở đội nào?" trước khi viết spec.
- Giữ ranh giới sản phẩm khớp ranh giới hệ thống. Khi chia trách nhiệm giữa các PM, nhìn sơ đồ hệ thống. Hai PM cùng sở hữu một dịch vụ là công thức cho tranh chấp.
- Dành chỗ trên roadmap cho việc tách. Ranh giới không tự nhiên tốt lên. Xem System Architecture Basics để nói chuyện về dịch vụ, cơ sở dữ liệu và phụ thuộc mà không bị lạc.
Làm ngay
Lấy năm tính năng gần nhất đội bạn đã làm. Với mỗi tính năng, đếm số đội phải sửa code và số ngày chờ đội khác. Nếu hơn một nửa cần từ hai đội, vẽ sơ đồ đơn giản: các đội, hệ thống họ sở hữu, và những chỗ họ chạm vào hệ thống của nhau. Đánh dấu chỗ chạm nhiều nhất — đó là ứng viên đầu tiên cho một ranh giới mới, và là chủ đề cho buổi nói chuyện tiếp theo với Engineering Manager.