title: "Xây dựng lộ trình (Roadmap) dài hạn: Tư vấn cho khách hàng những gì họ nên làm trong 6-12 tháng tới"
series: "Thư viện Kỹ năng BA·PO·EA: 45 Bài học Thực chiến"
part: "Phần 3 — Tư duy Chiến lược & Tầm nhìn"
skill_number: 36
audience: "BA, PO, EA & vai trò làm việc trực tiếp với khách hàng"
reading_time: "11 phút"
tags: ["roadmap", "Now-Next-Later", "lộ trình dài hạn", "tư vấn chiến lược", "BA", "PO", "EA"]

Xây dựng lộ trình (Roadmap) dài hạn: Tư vấn cho khách hàng những gì họ nên làm trong 6-12 tháng tới

Dự án sắp nghiệm thu, khách hàng hài lòng, và rồi họ hỏi một câu tưởng như đơn giản: "Sau cái này thì bên em nên làm gì tiếp theo?" Nếu bạn trả lời bằng cách liệt kê vài tính năng còn thiếu trong hợp đồng hiện tại, bạn đang bỏ lỡ cơ hội lớn nhất để trở thành người khách hàng gọi trước tiên cho lần sau. Câu hỏi đó không cần một danh sách việc — nó cần một lộ trình, và lộ trình thì không thể cam kết chắc chắn cho những thứ còn cách 10 tháng nữa.

🎯 Kỹ thuật cốt lõi

Now-Next-Later là cách tổ chức roadmap theo mức độ chắc chắn giảm dần theo thời gian, thay vì theo một trục thời gian tuyệt đối (tháng 1, tháng 2, tháng 3...). Ý tưởng cốt lõi: càng xa trong tương lai, thông tin bạn có càng ít chính xác, nên cam kết cũng phải lỏng dần tương ứng — nói cứng những gì bạn chắc, nói mở những gì bạn chưa chắc, thay vì giả vờ chắc chắn với mọi thứ để trông "chuyên nghiệp".

Ba nhóm, ba mức cam kết khác nhau:

• Now (0-3 tháng) — đang làm hoặc sắp làm ngay, có phạm vi rõ, có ước lượng effort cụ thể, có thể cam kết deadline. Đây là phần gần với một kế hoạch dự án thông thường.
• Next (3-6 tháng) — đã xác định là ưu tiên, có hướng giải pháp sơ bộ, nhưng phạm vi chi tiết và effort chính xác chưa chốt. Cam kết ở mức "sẽ làm", không cam kết ở mức "ngày nào xong".
• Later (6-12 tháng) — mới là ý tưởng/định hướng lớn, có thể thay đổi thứ tự hoặc bị loại bỏ khi có thông tin mới (thị trường đổi, ngân sách đổi, ưu tiên kinh doanh đổi). Mục đích của cột này không phải để hứa, mà để cho khách hàng thấy bạn đang nghĩ xa hơn hợp đồng hiện tại.

Nguyên tắc vận hành quan trọng nhất: roadmap không phải bản kế hoạch tĩnh vẽ một lần rồi để đó — nó phải được review định kỳ (thường mỗi quý), lúc đó việc gì đang ở Later có thể được "thăng hạng" lên Next nếu đủ thông tin, và việc gì ở Next có thể bị đẩy lùi hoặc rút khỏi roadmap nếu bối cảnh đổi. Sai lầm phổ biến nhất khi dùng khung này là gắn ngày tháng cụ thể vào cột Later ("tháng 11 sẽ triển khai module X") — làm vậy là đánh mất toàn bộ giá trị của khung, vì bạn lại quay về cam kết cứng cho thứ chưa đủ dữ kiện để cam kết, và khi thực tế lệch (gần như chắc chắn sẽ lệch), uy tín bị ảnh hưởng oan uổng.

Bối cảnh (Situation)

(Tình huống dưới đây là minh hoạ tổng hợp từ các dự án tư vấn CNTT phổ biến tại Việt Nam, không phải case cụ thể của một công ty có thật.)

Anh T., PO của một đội tư vấn triển khai hệ thống quản lý kho và bán hàng cho một chuỗi cửa hàng vật liệu xây dựng, đang ở tuần cuối cùng của dự án phase 1 — dự án kéo dài 5 tháng, phạm vi hợp đồng chỉ gói gọn trong module quản lý tồn kho và bán hàng tại quầy. Dự án chạy suôn sẻ, nghiệm thu đúng hẹn, và trong buổi họp tổng kết, Giám đốc vận hành của khách hàng — người trực tiếp ký hợp đồng và theo sát dự án — bất ngờ hỏi: "Đội các anh làm việc với tụi tôi 5 tháng nay, chắc cũng hiểu rõ hệ thống và cách vận hành của tụi tôi rồi. Vậy sau cái này thì tụi tôi nên đầu tư tiếp cái gì? Có nên làm app cho khách hàng đặt hàng online không, hay tích hợp với kế toán trước?"

Đây là kiểu câu hỏi mà nhiều BA/PO dễ trả lời hời hợt vì nó nằm ngoài phạm vi hợp đồng đã ký — trả lời qua loa "để em về suy nghĩ thêm rồi báo lại" hoặc né tránh vì sợ nói sai lại bị hiểu là cam kết ngoài hợp đồng. Anh T. nhận ra đây chính là khoảnh khắc quyết định liệu đội tư vấn có được mời tiếp cho phase 2, hay khách hàng sẽ tự tìm đối tác khác — hoặc tệ hơn, tự làm nội bộ theo cách rời rạc không có định hướng.

Thách thức (Task)

Cái khó của anh T. nằm ở ba lớp. Một, anh cần trả lời một câu hỏi chiến lược (6-12 tháng tới nên làm gì) trong khi hợp đồng hiện tại chỉ cho phép anh nhìn rõ 5 tháng vừa qua — vượt ra ngoài phạm vi này là anh đang tư vấn miễn phí, không phải nghĩa vụ hợp đồng, nhưng nếu từ chối thẳng thừng thì mất cơ hội thể hiện giá trị vượt ngoài "người thực thi đúng scope".

Hai, nếu anh trả lời bằng một danh sách các việc cần làm kèm mốc thời gian cụ thể ("tháng 8 làm app, tháng 10 tích hợp kế toán, tháng 12 làm báo cáo BI"), anh đang tự đặt bẫy cho chính mình — vì tại thời điểm này anh chưa hề khảo sát nhu cầu thực tế của khách hàng cuối, chưa biết ngân sách phase 2 là bao nhiêu, chưa biết đội kế toán của khách có sẵn sàng tích hợp hay không. Nếu 3 tháng sau tình huống thay đổi (điều gần như chắc chắn xảy ra) và các mốc anh đưa ra bị trễ, khách hàng sẽ nhớ anh là người "hứa nhưng không giữ lời" — dù bản chất đó chỉ là một gợi ý sơ bộ bị hiểu nhầm thành cam kết.

Ba, nếu anh chỉ nói chung chung kiểu "cái gì cũng có thể làm được, tuỳ nhu cầu anh/chị" thì không giải quyết được gì — khách hàng sẽ cảm thấy đội tư vấn không thực sự hiểu bối cảnh kinh doanh của họ, chỉ biết làm đúng những gì được giao. Anh T. cần một cách trả lời vừa đủ cụ thể để chứng minh mình đã suy nghĩ nghiêm túc, vừa đủ linh hoạt để không tự trói mình vào những cam kết chưa có cơ sở.

Hành động (Action)

Anh T. không trả lời ngay trong buổi họp đó. Anh xin phép trình bày một đề xuất lộ trình sơ bộ trong vòng một tuần, và triển khai theo các bước sau.

Bước 1 — Thu thập tín hiệu thay vì đoán mò. Trước khi vẽ bất kỳ roadmap nào, anh T. dành 3 ngày phỏng vấn nhanh ba nhóm: (1) Giám đốc vận hành — về mục tiêu kinh doanh 12 tháng tới của chuỗi cửa hàng (mở rộng thêm bao nhiêu điểm bán, có kế hoạch bán online không); (2) đội kế toán — hiện đang dùng phần mềm gì, có đau ở đâu trong việc đối soát dữ liệu bán hàng; (3) chính đội vận hành tại quầy — trong 5 tháng dùng hệ thống mới, họ gặp khó khăn gì mà module hiện tại chưa xử lý. Đây là bước quan trọng nhất vì roadmap tư vấn chỉ có giá trị khi dựa trên nhu cầu thật, không phải suy đoán từ góc nhìn của đội dev.

Bước 2 — Phân loại các sáng kiến thu được vào ba cột Now/Next/Later theo mức độ chắc chắn, không theo mức độ quan trọng. Anh T. liệt kê được 9 sáng kiến tiềm năng (app đặt hàng online, tích hợp kế toán, báo cáo BI, quản lý nhiều chi nhánh, chương trình khách hàng thân thiết...). Thay vì xếp theo "cái nào hay nhất", anh xếp theo "cái nào đã đủ rõ để lên kế hoạch":

• Now: hai lỗi/thiếu sót nhỏ trong module tồn kho mà đội vận hành phản ánh trong phỏng vấn — phạm vi rõ, effort ước tính được ngay, có thể đưa vào một gói bảo trì/hỗ trợ ngắn hạn 4 tuần.
• Next: tích hợp dữ liệu bán hàng với phần mềm kế toán hiện có — hướng giải pháp đã rõ (API đồng bộ hoá đơn), nhưng cần khảo sát kỹ hơn về phần mềm kế toán cụ thể khách đang dùng trước khi báo effort chính xác.
• Later: app đặt hàng online cho khách hàng cuối, chương trình khách hàng thân thiết, mở rộng multi-chi nhánh — đây đều là các sáng kiến lớn, phụ thuộc vào quyết định kinh doanh (có mở rộng điểm bán không, có chiến lược bán online không) mà bản thân Giám đốc vận hành cũng chưa chốt.

Bước 3 — Gắn lý do kinh doanh cho từng mục, không chỉ liệt kê tên tính năng. Với mỗi mục trong ba cột, anh T. viết kèm một câu "vì sao" ngắn gọn nối với mục tiêu kinh doanh đã nghe được ở bước 1 — ví dụ mục Next ghi rõ: "Tích hợp kế toán — giảm thời gian đối soát cuối ngày hiện đang mất khoảng 1-2 giờ/chi nhánh, theo phản ánh của đội kế toán." Cách viết này biến roadmap từ một danh sách tính năng khô khan thành một câu chuyện gắn với bài toán thật của khách hàng, giúp người đọc roadmap (kể cả người không rành kỹ thuật) hiểu ngay vì sao mục đó đáng làm.

Bước 4 — Trình bày rõ mức độ cam kết khác nhau giữa ba cột khi thuyết trình, tránh gây hiểu lầm. Khi trình bày roadmap trong buổi họp tiếp theo, anh T. nói rõ ràng ngay từ đầu: "Cột Now là những gì em cam kết làm được trong 4 tuần tới với effort cụ thể. Cột Next là hướng đi em tin là đúng, nhưng em cần thêm 2-3 tuần khảo sát kỹ phần mềm kế toán bên mình trước khi báo giá và thời gian chính xác. Cột Later là những định hướng lớn, phụ thuộc vào quyết định kinh doanh của anh/chị — ví dụ có mở rộng thêm chi nhánh trong năm sau không — nên em chưa đưa ra effort hay mốc thời gian, mà chỉ nêu để anh/chị thấy hướng đi dài hạn." Việc nói rõ sự khác biệt về mức cam kết này giúp khách hàng không đặt kỳ vọng sai — họ không mong cột Later phải "đúng hẹn" như cột Now.

Bước 5 — Đề xuất mốc review roadmap, không để nó thành tài liệu chết. Anh T. đề nghị mỗi quý ngồi lại 1 buổi 60 phút để cập nhật roadmap: xem mục nào ở Later đã đủ thông tin để chuyển lên Next, mục nào ở Next cần rút lại vì ưu tiên kinh doanh đổi. Việc chủ động đề xuất cơ chế review này là điểm khiến khách hàng thấy đây không phải một bản slide trình bày một lần để gây ấn tượng, mà là một công cụ họ có thể dùng thật.

Kết quả (Result)

Giám đốc vận hành đánh giá cao cách trình bày vì lần đầu tiên họ thấy một roadmap không hứa suông — anh T. minh bạch chỗ nào chắc, chỗ nào chưa chắc, thay vì báo cáo kiểu "tháng nào làm gì" như các bên tư vấn trước từng làm rồi trễ hẹn. Kết quả cụ thể: khách hàng ký ngay gói bảo trì 4 tuần cho các mục Now, và đồng ý cho đội anh T. làm khảo sát chi tiết (một hợp đồng nhỏ riêng) cho mục tích hợp kế toán ở cột Next trong tháng kế tiếp — tức là roadmap không chỉ là tư vấn suông, nó trực tiếp tạo ra hai hợp đồng tiếp theo.

Điều chưa hoàn hảo: ba tháng sau, khi review lại roadmap theo đúng lịch đã hẹn, mục "app đặt hàng online" ở cột Later bị chính khách hàng yêu cầu gác lại vô thời hạn vì công ty mẹ thay đổi chiến lược, chuyển trọng tâm sang mở thêm điểm bán vật lý thay vì bán online — một quyết định kinh doanh nằm ngoài tầm kiểm soát của anh T. và đội tư vấn. Nếu ba tháng trước anh T. lỡ cam kết cứng thời gian cho mục này (thay vì để nó ở Later không kèm mốc), đây sẽ là một lần "trễ hẹn" gây mất uy tín oan uổng. Vì đã đặt đúng chỗ ngay từ đầu, việc gác lại này chỉ đơn giản là một điều chỉnh bình thường trong buổi review, không ai cảm thấy có gì sai.

Bài học anh T. rút ra: giá trị của một roadmap tư vấn không nằm ở việc nó dự đoán đúng tương lai — hầu như không ai làm được điều đó với hạn 12 tháng — mà nằm ở việc nó thành thật về mức độ chắc chắn của từng phần, để khi thực tế thay đổi (luôn luôn thay đổi), không bên nào cảm thấy bị lừa hay thất hứa.

📋 Áp dụng ngay

• Khi khách hàng hỏi "sau dự án này nên làm gì", đừng trả lời ngay trong buổi họp — xin thời gian khảo sát tín hiệu thật (mục tiêu kinh doanh, điểm đau vận hành) trước khi vẽ roadmap.
• Xếp các sáng kiến vào Now/Next/Later theo mức độ chắc chắn về thông tin, không phải theo mức độ mong muốn hay độ "hot" của ý tưởng.
• Không bao giờ gắn ngày tháng cụ thể cho mục ở cột Later — chỉ nêu định hướng, để tránh cam kết oan cho thứ chưa đủ dữ kiện.
• Khi trình bày, luôn nói rõ bằng lời sự khác biệt mức cam kết giữa ba cột, đừng để khách hàng tự suy diễn cả roadmap đều chắc như nhau.
• Chủ động đề xuất lịch review roadmap định kỳ (theo quý) — đây vừa là cách giữ roadmap sống, vừa là lý do chính đáng để duy trì quan hệ tư vấn sau khi hợp đồng hiện tại kết thúc.

💡 Bài học đúc rút (Key Takeaway): Một roadmap tốt không phải là bản dự đoán chính xác 12 tháng tới — đó là điều không ai làm được. Nó là một cách trung thực để nói "đây là điều tôi chắc, đây là điều tôi tin nhưng chưa chắc, đây là hướng đi tôi thấy nhưng còn phụ thuộc quyết định của anh/chị" — và chính sự trung thực về mức độ chắc chắn đó, chứ không phải độ chính xác của lời hứa, mới là thứ khiến khách hàng tin tưởng mời bạn quay lại.

🔗 Kỹ năng liên quan

• Quản trị kỳ vọng về thời gian — nguyên tắc không cam kết cứng cho thứ chưa chắc trong Now-Next-Later cũng chính là kỹ năng quản trị kỳ vọng thời gian ở quy mô dài hạn hơn.
• Tư duy ROI — sau khi có roadmap, bước tiếp theo là giúp khách hàng định lượng lợi ích từng mục để quyết định đầu tư cái nào trước.
• Dự báo rủi ro — mỗi mục ở cột Next/Later trong roadmap nên đi kèm đánh giá rủi ro phụ thuộc, để khách hàng hiểu vì sao chưa thể cam kết chắc.

Bài trước: Tư duy "Đơn giản hóa" · Bài tiếp theo: Tư duy ROI