Mở đầu — vì sao bài này quan trọng
Có một câu hỏi mà bất kỳ ai làm trong lĩnh vực Operations, quản lý sản phẩm hay điều hành team kỹ thuật đều sẽ bị hỏi ít nhất một lần mỗi tuần: "Bao giờ xong?". Câu hỏi đó nghe đơn giản, nhưng cách bạn trả lời — và quan trọng hơn, cách bạn trình bày kế hoạch dài hạn — sẽ quyết định team của bạn được tin tưởng hay bị nghi ngờ, được trao quyền hay bị vi mô quản lý.
Roadmap (lộ trình) chính là công cụ trả lời câu hỏi đó ở tầm vĩ mô. Nó là bản đồ cho biết đội của bạn sẽ đi đâu trong 3, 6 hay 12 tháng tới. Nhưng ở đây có một cái bẫy rất phổ biến, đặc biệt với các công ty Việt Nam vốn quen với tư duy "hợp đồng có deadline cụ thể": nhiều người mặc định roadmap phải là một bảng Gantt chi tiết với ngày tháng chính xác cho từng đầu việc. Khi thực tế không diễn ra đúng như bảng đó — điều gần như luôn xảy ra với phần mềm — cả team và cả sếp đều mất niềm tin vào việc lập kế hoạch.
Bài học này giúp bạn phân biệt hai trường phái roadmap: Gantt-style (theo mốc thời gian cứng) và Now/Next/Later (theo mức độ ưu tiên và độ chắc chắn). Quan trọng hơn phân biệt, bạn sẽ học được khi nào dùng cái nào, và làm sao để chọn đúng công cụ cho đúng bối cảnh. Đây không phải tranh luận "cái nào tốt hơn" — mà là câu chuyện "cái nào phù hợp với loại công việc và mức độ bất định mà bạn đang đối mặt".
Khái niệm cốt lõi
Roadmap là gì và không phải là gì
Trước hết cần làm rõ: roadmap không phải là danh sách công việc (backlog), cũng không phải là lịch chạy sprint. Roadmap là một tài liệu giao tiếp (communication artifact) thể hiện hướng đi và các mục tiêu lớn của sản phẩm hoặc tổ chức trong một khoảng thời gian. Đối tượng đọc roadmap thường là ban lãnh đạo, các phòng ban khác (sales, marketing, customer support), và chính team.
Vì là công cụ giao tiếp, roadmap phải cân bằng giữa hai nhu cầu đối lập: người đọc muốn có sự chắc chắn ("khi nào tôi có tính năng này để đi bán?"), còn thực tế công việc lại đầy bất định. Cách bạn cân bằng hai nhu cầu này chính là điểm khác biệt giữa hai trường phái.
Gantt-style roadmap: lộ trình theo thời gian
Gantt chart là dạng biểu đồ thanh ngang, mỗi thanh là một công việc, độ dài thanh biểu thị thời lượng, vị trí thanh biểu thị ngày bắt đầu và kết thúc. Roadmap kiểu Gantt gắn từng hạng mục với một khoảng thời gian cụ thể: "Tính năng thanh toán QR sẽ ra mắt tuần 15/7", "Module báo cáo hoàn thành ngày 30/9".
Ưu điểm của Gantt là rất rõ ràng và dễ hiểu với người ngoài team. Nó thể hiện được sự phụ thuộc (dependency) giữa các công việc — việc B chỉ bắt đầu khi việc A xong. Nó phù hợp tuyệt vời với các bối cảnh mà phạm vi công việc đã cố định và có thể ước lượng đáng tin cậy:
- Agency / công ty làm dự án theo hợp đồng: khách hàng ký hợp đồng fixed-scope (phạm vi cố định), có điều khoản phạt nếu trễ hạn. Bạn bắt buộc phải cam kết ngày.
- Dự án có nhiều bên phụ thuộc thời gian: ví dụ ra mắt tính năng phải trùng với một chiến dịch marketing đã đặt lịch quảng cáo, hoặc phải xong trước một sự kiện lớn như mùa mua sắm 11/11, Tết.
- Công việc mang tính triển khai hơn là khám phá: di dời hệ thống (migration), tuân thủ pháp lý có deadline luật định, tích hợp với đối tác đã hẹn ngày go-live.
Now/Next/Later: lộ trình theo mức độ ưu tiên
Cách tiếp cận Now/Next/Later, được phổ biến bởi Janna Bastow (đồng sáng lập ProdPad), thay trục thời gian cứng bằng ba "làn" thể hiện mức độ ưu tiên và độ chắc chắn giảm dần:
- Now (Bây giờ): những gì team đang làm hoặc sẽ làm ngay. Độ chắc chắn cao, đã hiểu rõ vấn đề và giải pháp.
- Next (Kế tiếp): những gì sẽ làm sau khi xong Now. Đã xác định vấn đề nhưng giải pháp còn linh hoạt.
- Later (Về sau): những ý tưởng, hướng đi tiềm năng. Độ chắc chắn thấp, có thể thay đổi hoàn toàn.
Now/Next/Later phù hợp với: sản phẩm nội bộ (in-house product), startup, môi trường Agile nơi ưu tiên thay đổi liên tục dựa trên dữ liệu và phản hồi thị trường. Nhược điểm: những người quen tư duy hợp đồng có thể thấy nó "mơ hồ", "không cam kết". Bạn cần giáo dục người đọc rằng sự mơ hồ đó là cố ý và trung thực, không phải do team lười lập kế hoạch.
Bảng so sánh nhanh
| Tiêu chí | Gantt-style | Now/Next/Later |
|---|---|---|
| Trục chính | Thời gian (ngày cụ thể) | Ưu tiên & độ chắc chắn |
| Phù hợp với | Fixed-scope, agency, có dependency thời gian | In-house, Agile, khám phá |
| Rủi ro | False precision, cứng nhắc | Bị hiểu là thiếu cam kết |
| Đơn vị | Tính năng / task | Vấn đề / outcome |
Tình huống thực tế
Tình huống 1 — Agency phần mềm ở TP.HCM và hợp đồng ngân hàng
Một công ty gia công phần mềm khoảng 120 người ở Quận 1 nhận hợp đồng xây dựng cổng thanh toán cho một ngân hàng. Hợp đồng ghi rõ: 6 tháng, tổng giá trị 4,2 tỷ đồng, có điều khoản phạt 0,5% giá trị hợp đồng cho mỗi tuần trễ, và ngày go-live phải trùng với chiến dịch ra mắt thẻ mới của ngân hàng vào 1/10.
Ở bối cảnh này, PM của agency bắt buộc dùng Gantt. Phạm vi đã được đặc tả chi tiết trong hợp đồng (fixed-scope), có mốc pháp lý và mốc marketing cứng, và có sự phụ thuộc rõ ràng: tích hợp core-banking phải xong trước khi test bảo mật, test bảo mật phải xong trước UAT. PM chia thành các milestone: hoàn thành API tích hợp (15/7), pass pen-test (20/8), UAT với ngân hàng (15/9), go-live (1/10). Mỗi thanh trên Gantt có người chịu trách nhiệm và buffer 10% cho rủi ro.
Bài học rút ra: khi bạn ở thế bị ràng buộc bởi hợp đồng và dependency thời gian thực từ bên ngoài, Now/Next/Later sẽ là thảm họa — khách hàng cần con số để lập kế hoạch của họ. Gantt là công cụ đúng. Điều quan trọng là phải có buffer và cập nhật Gantt hàng tuần khi thực tế thay đổi, thay vì để nó thành một tài liệu chết.
Tình huống 2 — Startup fintech Đông Nam Á chuyển từ Gantt sang Now/Next/Later
Một startup ví điện tử tại khu vực Đông Nam Á, giai đoạn Series A, khoảng 40 kỹ sư. Ban đầu CEO yêu cầu team làm roadmap Gantt cho cả năm với hơn 30 tính năng có ngày cụ thể. Kết quả sau quý đầu: chỉ 40% tính năng đúng hạn, và tệ hơn, có 8 tính năng team đã lỡ làm nhưng người dùng gần như không dùng — vì thị trường đã thay đổi (một đối thủ ra mắt tính năng tương tự, một quy định mới của ngân hàng trung ương buộc phải ưu tiên việc khác).
Head of Product quyết định chuyển sang Now/Next/Later. Roadmap mới không còn ghi ngày, mà ghi theo outcome: Now — "tăng tỷ lệ hoàn tất KYC từ 60% lên 80%"; Next — "mở rộng số điểm nạp tiền offline"; Later — "khám phá tính năng đầu tư vi mô". Mỗi 6 tuần team review lại và dịch chuyển các mục giữa ba làn dựa trên dữ liệu.
Sau hai quý: tỷ lệ tính năng "được dùng thật" tăng rõ rệt, và điều bất ngờ là ban lãnh đạo hài lòng hơn — vì các cuộc họp không còn xoay quanh "sao trễ deadline" mà xoay quanh "chúng ta có đang giải đúng vấn đề không".
Bài học rút ra: với sản phẩm in-house trong thị trường biến động nhanh, việc bám vào ngày tháng cứng khiến team tối ưu sai thứ (đúng lịch nhưng sai giá trị). Now/Next/Later giải phóng team để tối ưu theo kết quả. Nhưng lưu ý: việc chuyển đổi đòi hỏi giáo dục lãnh đạo — nếu không, họ sẽ tưởng bạn đang trốn tránh cam kết.
Tình huống 3 — Mô hình lai (hybrid) tại một công ty SaaS
Một công ty SaaS quản lý bán hàng cho các cửa hàng bán lẻ, khoảng 200 nhân sự, gặp tình huống trung gian. Đội sản phẩm cốt lõi làm việc theo Agile và muốn Now/Next/Later. Nhưng đội sales lại cần con số để cam kết với khách hàng lớn, và đội infra phải hoàn thành việc chuyển đổi hạ tầng cloud trước khi hợp đồng với nhà cung cấp cũ hết hạn vào 31/12 — một deadline cứng.
Giải pháp của VP Engineering là dùng cả hai, cho hai loại công việc khác nhau. Các sáng kiến khám phá (discovery-driven) trên roadmap sản phẩm dùng Now/Next/Later. Các công việc có mốc cứng bắt buộc (migration hạ tầng, tuân thủ pháp lý, cam kết hợp đồng đã ký) được tách ra một "committed track" theo Gantt với ngày rõ ràng. Trong buổi họp roadmap hàng quý, hai phần được trình bày song song và ghi chú rõ đâu là "cam kết cứng" đâu là "định hướng".
Bài học rút ra: hai trường phái không loại trừ nhau. Một tổ chức trưởng thành phân loại công việc theo mức độ bất định, rồi áp dụng công cụ phù hợp cho từng loại. Sai lầm là ép toàn bộ tổ chức dùng một khuôn.
Hướng dẫn từng bước
Đây là quy trình để chọn và xây dựng roadmap phù hợp:
Bước 1 — Phân loại công việc theo độ bất định. Với mỗi hạng mục lớn, tự hỏi: "Ta đã hiểu rõ vấn đề và giải pháp chưa? Có ràng buộc thời gian từ bên ngoài không?". Việc rõ ràng + có deadline cứng thì nghiêng về Gantt. Việc còn phải khám phá thì nghiêng về Now/Next/Later.
Bước 2 — Xác định đối tượng đọc và nhu cầu của họ. Roadmap cho khách hàng ngoài hay cho ban lãnh đạo cần cam kết → cần yếu tố thời gian rõ hơn. Roadmap nội bộ cho team làm sản phẩm → có thể thuần Now/Next/Later.
Bước 3 — Chọn khung (framework) chủ đạo. Đa số sản phẩm in-house nên lấy Now/Next/Later làm khung chính, rồi bổ sung mốc cứng cho những mục thực sự cần. Ngược lại với agency.
Bước 4 — Diễn đạt theo outcome, không theo tính năng. Kể cả khi dùng Gantt, hãy gắn mỗi milestone với một kết quả kinh doanh, không chỉ là "hoàn thành module X".
Bước 5 — Thêm buffer và ghi rõ độ tin cậy. Với Gantt, luôn có 10-20% buffer. Với Now/Next/Later, ghi chú rõ "Later là định hướng, không phải cam kết".
Bước 6 — Thiết lập nhịp cập nhật. Roadmap là tài liệu sống. Định kỳ (2-6 tuần) review và dịch chuyển các mục, cập nhật ngày. Một roadmap không được cập nhật sẽ nhanh chóng trở thành lời nói dối.
Bước 7 — Giao tiếp và giáo dục người đọc. Nói rõ với các bên: roadmap này thể hiện điều gì, cái gì là cam kết cứng, cái gì là định hướng có thể đổi. Đây là bước quan trọng nhất và thường bị bỏ qua.
Lỗi thường gặp & mẹo
Lỗi 1 — Ép mọi thứ vào Gantt vì lãnh đạo thích nhìn ngày. Đây là lỗi phổ biến nhất ở Việt Nam. Kết quả là false precision, team bị áp lực sai, và roadmap thành công cụ đổ lỗi. Mẹo: giáo dục lãnh đạo bằng dữ liệu — cho họ thấy tỷ lệ trễ hạn của các dự báo ngày trong quá khứ.
Lỗi 2 — Nhầm Now/Next/Later là cái cớ để không cam kết gì. Now/Next/Later vẫn đòi hỏi kỷ luật: mục ở làn Now phải rõ ràng và có thể bắt đầu ngay. Nếu Now của bạn cũng mơ hồ thì đó là vấn đề, không phải đặc tính của framework.
Lỗi 3 — Roadmap liệt kê tính năng thay vì vấn đề. "Làm chatbot" không nói lên giá trị. "Giảm khối lượng ticket support" thì có. Roadmap theo outcome giúp team tự do chọn giải pháp tốt nhất.
Lỗi 4 — Không cập nhật roadmap. Một roadmap cũ 3 tháng còn tệ hơn không có roadmap, vì nó tạo kỳ vọng sai. Mẹo: đặt lịch review cố định vào cuối mỗi chu kỳ.
Lỗi 5 — Coi đây là cuộc chiến tôn giáo. Người theo Agile chê Gantt lỗi thời, người truyền thống chê Now/Next/Later vô kỷ luật. Cả hai đều sai. Mẹo: nhớ nguyên tắc — công cụ phục vụ bối cảnh, không phải ngược lại.
Mẹo bổ sung: dùng màu sắc và nhãn "độ tin cậy" (cao/trung bình/thấp) trên bất kỳ roadmap nào để trực quan hóa sự bất định — điều này ngăn người đọc hiểu nhầm phỏng đoán thành cam kết.
Bài tập thực hành
- Phân loại: Lấy danh sách 8-10 sáng kiến lớn mà team bạn (hoặc một công ty bạn biết) đang có. Với mỗi sáng kiến, đánh dấu: (a) độ chắc chắn về vấn đề/giải pháp cao hay thấp, (b) có deadline cứng từ bên ngoài không. Dựa vào đó, phân chúng vào "Gantt track" hay "Now/Next/Later track".
- Chuyển đổi diễn đạt: Lấy 5 mục đang được viết dạng tính năng (ví dụ "làm tính năng X") và viết lại thành dạng outcome (kết quả cần đạt). So sánh xem cách viết mới có mở ra giải pháp nào khác không.
- Dựng roadmap lai: Cho một tình huống giả định — startup 30 người vừa có một hợp đồng lớn với khách hàng doanh nghiệp yêu cầu 3 tính năng go-live vào một ngày cố định, đồng thời vẫn phát triển sản phẩm cốt lõi. Hãy phác một roadmap kết hợp: phần committed track theo Gantt, phần khám phá theo Now/Next/Later, kèm ghi chú độ tin cậy.
- Kịch bản giao tiếp: Viết một đoạn 4-5 câu bạn sẽ nói với CEO để giải thích vì sao team chuyển từ roadmap Gantt cả năm sang Now/Next/Later, xử lý được lo ngại "vậy là không cam kết gì à?".
Tóm tắt
Roadmap là công cụ giao tiếp về hướng đi, không phải lịch chạy việc chi tiết. Có hai trường phái chính. Gantt-style gắn công việc với ngày cụ thể, rõ ràng và mạnh về dependency, phù hợp với agency, hợp đồng fixed-scope, và các mốc cứng từ bên ngoài — nhưng dễ rơi vào bẫy false precision với công việc mang tính khám phá. Now/Next/Later sắp xếp theo mức độ ưu tiên và độ chắc chắn giảm dần, trung thực về sự bất định, tập trung vào outcome, phù hợp với sản phẩm in-house và môi trường Agile — nhưng cần giáo dục người đọc để không bị hiểu là thiếu cam kết.
Chìa khóa không phải chọn phe, mà là phân loại công việc theo độ bất định rồi áp dụng đúng công cụ — thậm chí kết hợp cả hai trong một tổ chức. Dù chọn cách nào, hãy diễn đạt theo kết quả, thêm buffer, đánh dấu độ tin cậy, cập nhật định kỳ, và luôn giao tiếp rõ ràng đâu là cam kết cứng, đâu là định hướng. Làm được vậy, roadmap của bạn sẽ là công cụ tạo niềm tin thay vì công cụ đổ lỗi.