Product Roadmap
Bản trình bày hướng đi của sản phẩm trong vài tháng tới, theo mục tiêu cần đạt thay vì danh sách tính năng kèm ngày giao. Công cụ để thống nhất kỳ vọng, không phải bản cam kết.
Định nghĩa
Thứ mà ban giám đốc muốn xem không phải backlog. Họ muốn một trang giấy trả lời được: sáu tháng tới sản phẩm này đi về đâu, và vì sao lại là hướng đó chứ không phải hướng kia. Roadmap được viết ở mức vừa đủ để mọi người thống nhất hướng đi mà không phải hứa những thứ chưa ai biết.
Vấn đề là phần lớn roadmap ngoài thực tế được vẽ dưới dạng bảng Gantt: mười lăm tính năng, mỗi cái một ô, gắn ngày cụ thể tới tận tháng thứ chín. Loại roadmap đó chỉ chính xác trong hai tuần đầu, sau đó thành nguồn cơn của mọi cuộc họp giải trình.
Roadmap trả lời "chúng ta đang cố đạt điều gì", không phải "ngày nào giao cái gì". Cái thứ hai là việc của release plan.
Roadmap theo mục tiêu
Cách viết bền hơn là bám vào kết quả cần đạt. Mỗi mục trên roadmap gồm ba phần: vấn đề đang giải, chỉ số kỳ vọng thay đổi, và vài hướng giải pháp đang cân nhắc.
Ví dụ, thay vì ghi "Q3: Ví trả trước, tích điểm, đặt bàn", ghi:
Quý 3 — Giảm thời gian chờ tại quầy giờ cao điểm. Hiện trung bình 7 phút, mục tiêu dưới 4 phút. Hướng đang cân nhắc: đặt trước qua app, hiển thị hàng chờ theo thời gian thực, thanh toán trước.
Viết kiểu này thì khi hướng giải pháp đổi, roadmap vẫn đúng. Còn viết theo danh sách tính năng thì đổi cái nào cũng thành thất hứa.
Định dạng Now, Next, Later
Cách trình bày dễ dùng nhất cho team vừa và nhỏ, chia làm ba cột:
| Cột | Khoảng thời gian | Mức chi tiết |
|---|---|---|
| Now | Đang làm, 1 đến 2 tháng | Rõ, đã có story trong backlog |
| Next | 2 đến 4 tháng tới | Biết mục tiêu, chưa chốt giải pháp |
| Later | Xa hơn | Chỉ là ý tưởng và vấn đề cần giải |
Không ghi ngày cho cột Next và Later. Ai hỏi thì trả lời bằng khoảng, kèm điều kiện. Cách này giữ được sự trung thực mà vẫn cho stakeholder thấy hướng đi.
Phân biệt Roadmap, Release Plan và Backlog
| Tiêu chí | Product Roadmap | Release Plan | Product Backlog |
|---|---|---|---|
| Tầm nhìn | 3 đến 12 tháng | 1 đến 3 tháng | Hiện tại tới vài sprint |
| Đơn vị | Mục tiêu, chủ đề | Feature, mốc phát hành | Story, bug, việc kỹ thuật |
| Độ chắc chắn | Thấp, sẽ đổi | Trung bình | Cao ở phần đầu danh sách |
| Người đọc chính | Ban lãnh đạo, khách hàng | PO, team, bên vận hành | Scrum Team |
Ví dụ thực tế
Đến tháng thứ tư thì bảng Gantt 14 tính năng cho 9 tháng đã lệch hẳn: 6 tính năng bị đẩy lùi, và cuộc họp giao ban nào cũng mất nửa tiếng giải thích vì sao trễ. Sản phẩm là nền tảng học trực tuyến cho học sinh cấp hai, gần 34 nghìn người dùng hoạt động mỗi tháng.
PO viết lại theo Now, Next, Later với ba mục tiêu:
- Now: giảm tỉ lệ bỏ dở bài học giữa chừng, hiện 46%, mục tiêu dưới 30%.
- Next: giúp phụ huynh thấy được tiến độ con mình mà không cần gọi điện hỏi trung tâm.
- Later: mở rộng sang môn tiếng Anh.
Số liệu velocity của team được dùng để đưa khoảng thời gian, không phải ngày cố định: mục tiêu Now ước chừng 4 đến 6 sprint. Sau ba tháng, phần lớn giải pháp ban đầu bị thay bằng hướng khác — hoá ra học sinh bỏ dở vì bài học dài 25 phút, chia thành các đoạn 7 phút thì tỉ lệ bỏ dở xuống còn 31%. Roadmap vẫn đúng suốt thời gian đó vì nó cam kết vào mục tiêu.
Khi sếp vẫn đòi ngày chính xác
Chuyện này sẽ xảy ra, đặc biệt khi có hợp đồng hoặc chiến dịch marketing gắn kèm. Ba đường lùi, xếp theo thứ tự nên thử:
- Đưa ngày kèm mức tin cậy: "80% khả năng xong trong 6 tuần, 95% trong 9 tuần". Dựa trên dải velocity thật, không phải cảm tính.
- Cam kết ngày cho phần lõi, để phần mở rộng ở dạng khoảng.
- Nêu rõ giả định đi kèm: đội hình không đổi, không có việc chen ngang từ production quá 20% dung lượng. Khi giả định vỡ, bạn có cơ sở để bàn lại thay vì bị hỏi vì sao trễ.
Điều nên tránh là gật đại cho xong buổi họp. Cái giá của việc đó luôn được trả sau, với lãi.
