Một danh sách use case đã xếp hạng chưa phải roadmap. Roadmap là trình tự theo thời gian cân bằng giữa thắng nhanh (tạo động lực, chứng minh giá trị) và xây nền tảng (dữ liệu, hạ tầng agent, quản trị) để đi xa.
Nguyên tắc "70/20/10" theo giai đoạn
- Giai đoạn 1 (0–3 tháng) — Chứng minh: 100% dồn vào 1 quick win. Mục tiêu là một chiến thắng đo được và một bài học vận hành.
- Giai đoạn 2 (3–9 tháng) — Mở rộng: ~70% cho 2–3 use case tiếp, ~30% bắt đầu xây nền tảng dùng chung (cổng dữ liệu, registry công cụ, lớp giám sát).
- Giai đoạn 3 (9–18 tháng) — Nhân rộng: nền tảng đủ mạnh để mỗi use case mới rẻ và nhanh hơn cái trước.
Nền tảng gồm những gì
1. Data access layer: cách agent đọc dữ liệu sạch (RAG/kho tri thức).
2. Tool/action registry: danh mục API agent được phép gọi + phân quyền.
3. Observability: log mọi bước agent, chi phí token, tỷ lệ thành công.
4. Guardrails: giới hạn hành động, human-in-the-loop, kiểm duyệt output.
5. Eval harness: bộ test đo chất lượng agent trước khi lên production.
Sai lầm chiến lược là xây hết nền tảng trước rồi mới làm use case — tốn 6 tháng không có kết quả. Đúng hơn: quick win đầu tiên tự "kéo" ra những mảnh nền tảng tối thiểu cần thiết, rồi tái sử dụng.
Ví dụ roadmap 12 tháng
| Quý | Use case | Nền tảng phát sinh |
|---|---|---|
| Q1 | Agent trả ticket cấp 1 | Observability cơ bản, guardrail escalate |
| Q2 | Agent đối chiếu hóa đơn | Data layer tài chính, tool registry |
| Q3 | Agent soạn báo giá | Tái dùng registry + eval harness |
| Q4 | Mở 2 use case tự phục vụ | Nền tảng dùng chung ổn định |
Cũng chú ý cột "nền tảng phát sinh": nó cho thấy nền tảng không phải một dự án riêng khổng lồ, mà là những mảnh nhỏ được sinh ra đúng lúc use case cần, rồi được chuẩn hóa để tái dùng. Đây là cách xây nền tảng "vừa đủ, đúng lúc" (just-in-time) thay vì "làm hết trước" (big design up front).
Khung quyết định "quick win hay nền tảng?"
Nếu chưa có chiến thắng nào được lãnh đạo công nhận
-> ưu tiên QUICK WIN, dù nền tảng còn thô.
Nếu quick win thứ 3 đang phải "đẽo lại" cùng một thứ (vd: cùng tích hợp CRM)
-> đã đến lúc trích ra thành NỀN TẢNG dùng chung.
Nếu use case tiếp theo bị chặn bởi dữ liệu bẩn/thiếu API
-> đó là đầu tư nền tảng bắt buộc, không né được.
Các bước làm
- Đặt quick win (bài 3) vào Quý 1, mục tiêu số đo rõ ràng.
- Với mỗi use case ở các quý sau, liệt kê "mảnh nền tảng" nó cần.
- Gộp các mảnh lặp lại → đưa vào backlog nền tảng dùng chung.
- Phân bổ nguồn lực theo 70/20/10.
- Đặt 2–3 cột mốc có thể trình lãnh đạo (demo, số tiết kiệm, tỷ lệ tự động).
- Rà soát roadmap mỗi quý — nó là bản sống, không phải đá khắc.
Sai lầm thường gặp
- "Đại dự án nền tảng" 6 tháng không kết quả: đốt ngân sách và niềm tin trước khi có giá trị.
- Chỉ chạy quick win, không bao giờ trích nền tảng: use case thứ 5 vẫn đắt như cái đầu tiên.
- Roadmap khóa cứng 18 tháng: agentic AI thay đổi nhanh, cần rà soát theo quý.
- Không gắn cột mốc với số đo lãnh đạo hiểu: mất tài trợ giữa chừng.
- Không rà soát roadmap theo quý: agentic AI và năng lực mô hình thay đổi nhanh; một quyết định 6 tháng trước có thể đã lỗi thời.
Tóm tắt
Roadmap tốt cân bằng ba thứ: chứng minh giá trị sớm (quick win), tích lũy nền tảng đúng lúc (mỗi use case sau rẻ hơn), và giữ được tài trợ nhờ cột mốc bằng số. Nó là một bản sống, rà soát theo quý, chứ không phải đá khắc. Nếu bạn chỉ nhớ một điều: đừng bao giờ đốt 6 tháng xây nền tảng trước khi có chiến thắng đầu tiên.
Bài 5 sẽ trả lời câu hỏi lớn tiếp theo cho từng thành phần trong roadmap: nên mua giải pháp có sẵn hay tự xây?