Roadmap nền tảng khác gì roadmap thường
Roadmap sản phẩm cuối chạy theo nhu cầu người dùng và thị trường. Roadmap nền tảng chạy theo đòn bẩy dùng chung và rủi ro hệ thống. Câu hỏi trung tâm không phải 'khách hàng muốn gì' mà là 'năng lực nào, khi xây một lần, sẽ mở khóa giá trị cho nhiều đội nhất và giảm rủi ro chung nhiều nhất'.
Ba loại việc luôn có trong roadmap nền tảng
- Năng lực mới (capabilities) — thêm model, thêm API, mở tính năng mới cho nhiều đội.
- Nâng cấp nền (foundations) — cải thiện độ trễ, giảm chi phí, tăng độ tin cậy gateway. Ít 'lấp lánh' nhưng là thứ giữ khách hàng nội bộ ở lại.
- Trả nợ & hợp nhất (consolidation) — gỡ model trùng lặp, migrate đội khỏi version cũ, dẹp shadow model. Đây là công việc chống phân mảnh, thường bị bỏ quên đến khi quá muộn.
Khung ưu tiên: Reach × Leverage × Risk-reduction / Effort
Biến thể của RICE cho nền tảng:
- Reach: bao nhiêu đội được lợi (không phải bao nhiêu người dùng cuối).
- Leverage: mức độ mỗi đội tiết kiệm được nếu dùng chung thay vì tự làm.
- Risk-reduction: giảm rủi ro chung bao nhiêu (an toàn, chi phí, phân mảnh).
- Effort: công sức đội nền tảng bỏ ra.
Ví dụ cụ thể
Có hai đề xuất: (A) làm tính năng re-ranking riêng cho đội Search — Reach 1, Effort cao. (B) chuẩn hóa eval harness dùng chung cho mọi đội — Reach 8, giảm rủi ro nâng cấp cho cả nền tảng. Đội Search hối thúc A mỗi ngày. Nhưng B mới là việc platform. Cách xử lý khéo: đưa B lên trước, đồng thời cho đội Search một đường tự mở rộng (extension point) để họ tự làm re-ranking trên nền chung.
Chống 'roadmap bị bắt cóc'
Nền tảng luôn bị đội mạnh nhất kéo về phục vụ riêng họ. Ba lá chắn:
- Nguyên tắc Reach tối thiểu: chỉ nhận vào roadmap nền tảng việc phục vụ từ 2 đội trở lên. Việc 1 đội → họ tự làm trên extension point.
- Extension point: thiết kế nền tảng để đội tự mở rộng, giảm áp lực dồn lên bạn.
- Ngân sách hợp nhất cố định: dành sẵn ~20% năng lực mỗi quý cho consolidation, không thương lượng.
Sai lầm thường gặp
- Roadmap toàn năng lực mới, không có consolidation → phân mảnh tích lũy, một ngày sập.
- Ưu tiên theo ai la to nhất thay vì theo Reach × Leverage.
- Hứa lộ trình cứng theo quý cho hạ tầng vốn nhiều bất định — nên dùng 'now / next / later' thay vì ngày cứng.
Checklist roadmap
- [ ] Mỗi hạng mục có ước lượng Reach (số đội) rõ ràng.
- [ ] Có ít nhất một hạng mục consolidation trong quý này.
- [ ] Việc chỉ phục vụ 1 đội được đẩy sang extension point, không chiếm chỗ platform.
- [ ] Roadmap phân theo now/next/later, có nêu giả định và rủi ro.
<!--les-append-->
Ngân sách consolidation: vì sao phải cố định, không thương lượng
Bài trên nói dành ~20% cho hợp nhất. Lý do nó phải cố định thay vì "làm khi rảnh": nợ phân mảnh không gây đau ở hiện tại, nên nó luôn thua mọi việc có người đang chờ. Kết quả là nó không bao giờ được làm, cho tới lúc nó gây sự cố.
Cách bảo vệ khoản này trong thực tế:
- Đặt nó thành một hạng mục có tên trong roadmap, không phải một phần trăm ẩn.
- Báo cáo nó như một kết quả, không như một chi phí: "quý này gỡ 3 model trùng lặp, giảm 18 triệu/tháng chi phí suy luận".
- Nêu con số nợ hiện tại mỗi quý: bao nhiêu đội còn ở version cũ, bao nhiêu model trùng chức năng, bao nhiêu shadow model. Một con số tăng dần là thứ duy nhất khiến người ta chú ý.
Migration là một sản phẩm, và nó cần đặc tả
Bài trên nói "migration là sản phẩm". Cụ thể nghĩa là một bản nâng cấp phải có bốn thứ trước khi ra mắt:
| Thành phần | Nội dung |
|---|---|
| Đường song song | Version cũ và mới chạy cùng lúc, tối thiểu một quý |
| Công cụ so sánh | Đội chạy được cùng đầu vào qua hai version và thấy khác biệt |
| Ngày tắt công bố trước | Có ngày cụ thể, thông báo trước tối thiểu 60 ngày |
| Người hỗ trợ có tên | Ai đội nội bộ hỏi khi migration gặp vấn đề |
Dấu hiệu roadmap đang bị bắt cóc
Ba dấu hiệu kiểm được trong năm phút:
- Trên 60% hạng mục quý này có Reach = 1.
- Không có hạng mục consolidation nào.
- Bạn nhớ tên một đội cụ thể khi đọc phần lớn hạng mục.