Phân biệt: Roadmap, timeline, release plan và backlog

Vì sao chủ đề quan trọng

Trong một tuần, một PM có thể nghe bốn câu hỏi nghe rất giống nhau: giám đốc hỏi "quý này mình đi về đâu", sales hỏi "khi nào bán được tính năng đặt cọc", kỹ thuật hỏi "sprint sau làm gì", còn chăm sóc khách hàng hỏi "bản cập nhật tháng sau có gì". Nếu bạn trả lời cả bốn câu bằng cùng một tài liệu, kết quả gần như chắc chắn là một bảng tính khổng lồ mà không ai đọc hết, hoặc tệ hơn, một roadmap bị nhồi đầy ngày tháng và trở thành lời hứa mà đội không giữ được.

Bốn câu hỏi đó cần bốn tài liệu: roadmap, timeline, release plan và backlog. Chúng liên quan chặt với nhau nhưng trả lời bốn câu hỏi khác nhau, cho bốn nhóm người đọc khác nhau, với bốn mức độ chắc chắn khác nhau. Phần lớn rắc rối về roadmap mà PM gặp, từ "sếp bắt ghi ngày lên roadmap" tới "sales hứa với khách một thứ chưa chắc làm", đều bắt đầu từ việc trộn các tài liệu này vào nhau.

Bài này là nền cho cả khóa. Các bài sau dạy cách dựng từng tài liệu; bài này dạy cách nhận ra mình đang cần tài liệu nào.

Bức tranh lớn

Hãy nghĩ về bốn tài liệu như bốn tầng, đi từ "vì sao" xuống "làm gì cụ thể":

• Roadmap trả lời vì sao và theo thứ tự nào. Nó nói đội đang theo đuổi những kết quả (outcome) nào, ưu tiên cái nào trước. Đơn vị là vấn đề và kết quả, không phải tính năng. Thời gian chỉ ở mức thô: Now, Next, Later, hoặc theo quý.
• Timeline trả lời khi nào. Nó lấy phần "Now" của roadmap và biến thành các mốc có ngày hoặc khoảng ngày, kèm phụ thuộc và nhãn cam kết hay dự báo.
• Release plan trả lời bản phát hành nào chứa gì. Nó gom công việc thành từng đợt ra mắt mà người dùng nhìn thấy: phiên bản 3.2 ngày nào, có những thay đổi gì, ai cần chuẩn bị gì.
• Backlog trả lời làm gì tiếp theo, chính xác là gì. Nó là danh sách user story và task đã sắp xếp, đủ chi tiết để đội kỹ thuật nhận việc trong sprint.

Mỗi tầng được suy ra từ tầng trên. Timeline không được đặt ra độc lập, nó là roadmap cộng thêm ước lượng, phụ thuộc và năng lực của đội. Khi roadmap đổi, timeline phải được suy ra lại, không phải ngược lại.

flowchart TD
    A[Chiến lược sản phẩm] --> B[Roadmap - vì sao, theo thứ tự nào]
    B --> C[Timeline - khi nào, cam kết hay dự báo]
    B --> D[Release plan - bản nào chứa gì]
    C --> E[Backlog - làm gì tiếp, chi tiết]
    D --> E
    E --> F[Sprint và giao hàng]
    F -->|Dữ liệu thực tế| B

Mũi tên cuối cùng quan trọng không kém: dữ liệu từ những gì đã giao, kết quả có đạt hay không, quay ngược lên để cập nhật roadmap. Một đội chỉ có mũi tên đi xuống là đội đang thực thi một kế hoạch cũ.

Ví dụ chi tiết

Một chuỗi phòng khám nha khoa ở TP.HCM có app đặt lịch. Vấn đề lớn nhất quý này: 22% lịch hẹn bị bỏ mà không báo trước, ghế trống, bác sĩ ngồi chờ. Cùng một mục tiêu đó được viết thành bốn tài liệu như sau.

Roadmap (cho ban giám đốc, đội product):

Timeline (cho sales, marketing, vận hành):

Release plan (cho chăm sóc khách hàng, đội vận hành chi nhánh):

Backlog (cho đội kỹ thuật, ở dạng user story):

• Là khách hàng, tôi muốn nhận tin nhắc qua Zalo 24 giờ trước giờ hẹn, để tôi không quên.
• Là lễ tân, tôi muốn thấy khách nào đã bấm xác nhận, để tôi gọi những người chưa xác nhận.
• Kỹ thuật: tích hợp API gửi tin Zalo ZNS, xử lý khi gửi thất bại.

Để ý rằng cả bốn tài liệu nói về cùng một việc, nhưng không tài liệu nào thay được tài liệu nào. Giám đốc không cần đọc user story. Đội kỹ thuật không cần biết "Later" là gì để làm sprint này. Sales cần ngày, nhưng chỉ ngày của những thứ đã đủ chắc.

So sánh trực tiếp

Đây là bảng nên in ra và dán cạnh bàn trong tháng đầu làm PM:

Hàng "người đọc chính" là hàng quan trọng nhất. Khi không chắc mình cần tài liệu nào, hãy hỏi: người này sẽ dùng câu trả lời để làm gì? Giám đốc dùng để phân bổ người và tiền, nên cần roadmap. Sales dùng để hứa với khách, nên cần timeline có nhãn. Lễ tân dùng để trả lời khách ngày ra mắt, nên cần release plan.

Lộ trình từng bước

Khi nhận một yêu cầu kiểu "gửi anh cái roadmap", làm theo năm bước:

• Hỏi người yêu cầu sẽ dùng nó để làm gì. "Anh cần để trình hội đồng quản trị hay để chốt lịch chiến dịch marketing?" Câu trả lời cho biết họ thực sự cần tài liệu nào.
• Xác định câu hỏi chính. Vì sao, khi nào, bản nào, hay làm gì.
• Chọn đúng tài liệu và đúng mức chi tiết. Đừng gửi backlog 200 dòng cho người cần một trang roadmap.
• Kiểm tra tài liệu được suy ra từ tầng trên. Timeline phải lấy từ roadmap hiện tại, không phải từ một bảng tính cũ ai đó giữ riêng.
• Ghi rõ ngày cập nhật và độ chắc chắn ở đầu tài liệu, để người đọc biết họ đang cầm phiên bản nào.

flowchart TD
    Q[Có người hỏi về kế hoạch] --> W{Họ dùng câu trả lời để làm gì}
    W -->|Phân bổ người và tiền| R[Gửi roadmap]
    W -->|Hứa với khách, lên chiến dịch| T[Gửi timeline có nhãn]
    W -->|Chuẩn bị cho ngày ra mắt| P[Gửi release plan]
    W -->|Nhận việc trong sprint| B[Mở backlog]

Thói quen & kỷ luật

Cần luyện tập

Drill một: lấy roadmap hoặc kế hoạch hiện tại của đội bạn. Gạch chân mọi chỗ có ngày cụ thể. Với từng chỗ, hỏi: đây là roadmap hay đang là timeline trá hình?

Drill hai: chọn một mục tiêu trong quý này và viết nó thành bốn dạng như ví dụ phòng khám: một dòng roadmap, một mốc timeline, một dòng release plan, ba user story.

Drill ba: nhớ lại lần gần nhất có người hiểu sai kế hoạch của bạn. Họ cần tài liệu nào, và bạn đã gửi tài liệu nào?

Checklist hành động tuần này

• [ ] Liệt kê các tài liệu kế hoạch đội đang có và gắn mỗi cái vào một trong bốn loại
• [ ] Tìm tài liệu nào đang làm hai việc cùng lúc, ví dụ roadmap có ngày cụ thể
• [ ] Thêm dòng "cập nhật ngày" và "độ chắc chắn" ở đầu mỗi tài liệu
• [ ] Hỏi sales và vận hành họ cần biết gì về thời gian, rồi ghi lại
• [ ] Thống nhất với tech lead ai sở hữu timeline

Chỉ số & North Star

Dấu hiệu bạn đã thành thạo

Bạn thành thạo khi không còn ai gọi mọi thứ là "roadmap" trong đội bạn. Khi sales hỏi ngày, bạn gửi timeline có nhãn thay vì sửa roadmap. Khi giám đốc hỏi hướng đi, bạn nói bằng outcome thay vì liệt kê tính năng. Và khi roadmap đổi, bạn tự động suy ra lại timeline và báo cho những người đang dựa vào nó.

Cạm bẫy thường gặp

Chốt lại

Roadmap, timeline, release plan và backlog không phải bốn tên gọi cho cùng một thứ. Chúng là bốn câu trả lời cho bốn câu hỏi: vì sao, khi nào, bản nào, làm gì. Tầng dưới luôn được suy ra từ tầng trên, và dữ liệu thực tế luôn quay ngược lên để sửa tầng trên. Phần còn lại của khóa học dạy cách dựng từng tầng, bắt đầu với roadmap và kết thúc bằng một dự án bạn tự dựng cả roadmap lẫn timeline.