Mở đầu — vì sao bài này quan trọng
Có một cảnh tượng bạn sẽ gặp đi gặp lại trong sự nghiệp làm technical leadership: đội engineering thì rên rỉ vì hệ thống cũ kỹ, deploy mãi vẫn hay lỗi, muốn nâng cấp hạ tầng nhưng "không có thời gian"; còn bên business thì chỉ nhìn thấy một dòng thời gian toàn feature mới, và mỗi khi bạn xin hai tuần để trả nợ kỹ thuật, họ hỏi lại: "Cái đó khách hàng có nhìn thấy không?".
Nút thắt nằm ở chỗ đội của bạn không có một engineering roadmap — một bản kế hoạch riêng cho các khoản đầu tư vào nền tảng, hạ tầng, độ tin cậy và năng suất kỹ sư. Khi thiếu nó, mọi công việc kỹ thuật chỉ tồn tại dưới dạng những mẩu vụn lén lút giấu trong product roadmap, hoặc tệ hơn, chỉ nằm trong đầu vài kỹ sư senior. Không ai ngoài đội biết bạn đang đầu tư vào đâu, tại sao, và khi nào có kết quả.
Bài này dạy bạn cách xây và truyền đạt một engineering roadmap: phân biệt nó với product roadmap, cấu trúc nó thành các theme có thể bảo vệ được trước business, và trình bày nó sao cho cả CTO lẫn CEO đều gật đầu. Đây là kỹ năng biến bạn từ "người xin thời gian trả nợ" thành "người dẫn dắt chiến lược kỹ thuật".
Khái niệm cốt lõi
Engineering roadmap khác gì product roadmap
Product roadmap trả lời câu hỏi: chúng ta ship gì cho người dùng? Nó nói về tính năng, trải nghiệm, giá trị khách hàng nhìn thấy được — trang thanh toán mới, tính năng chat, mở rộng thị trường.
Engineering roadmap trả lời một câu hỏi khác: chúng ta đầu tư vào đâu để làm nền tảng cho việc ship đó nhanh, an toàn và bền vững? Nó nói về những thứ người dùng cuối không trực tiếp thấy nhưng luôn cảm nhận được hậu quả nếu bỏ bê:
- Platform và infrastructure: migrate từ monolith sang service tách biệt, chuyển sang Kubernetes, nâng cấp database, xây CI/CD pipeline.
- Technical debt: refactor module thanh toán chằng chịt, thay thư viện đã hết vòng đời hỗ trợ, dọn dẹp các nhánh code chết.
- Reliability và operability: cải thiện observability, giảm thời gian phục hồi sự cố, xây hệ thống alerting.
- Developer experience (DevEx): giảm thời gian build từ 40 phút xuống 8 phút, tự động hóa provisioning môi trường test.
Bốn nhóm đầu tư trên engineering roadmap
Tôi thường khuyên học viên cấu trúc engineering roadmap theo bốn nhóm để dễ cân đối và dễ giải thích:
- Keep the lights on (KTLO): những việc bắt buộc để hệ thống không sập — vá lỗ hổng bảo mật, nâng cấp phiên bản sắp hết hạn hỗ trợ, xử lý scaling khi lượng người dùng tăng.
- Reduce friction: giảm ma sát nội bộ — tăng tốc pipeline, cải thiện DevEx, dọn tech debt gây chậm mọi feature.
- Enable the future: nền tảng cho tham vọng sắp tới — nếu năm sau ra thị trường mới cần multi-region, phần nền tảng đó phải bắt đầu từ bây giờ.
- Bets / R&D: những đặt cược mang tính khám phá — thử nghiệm một kiến trúc mới, đánh giá một công nghệ mới có thể thay đổi cuộc chơi.
Roadmap là theme, không phải task list
Sai lầm phổ biến nhất là biến engineering roadmap thành danh sách Jira ticket. Roadmap ở tầm leadership phải là các theme có outcome rõ ràng, không phải danh sách công việc chi tiết.
So sánh hai cách viết cho cùng một việc:
- Cách sai (task): "Tách service authentication ra khỏi monolith. Viết migration script. Setup API gateway."
- Cách đúng (theme + outcome): "Chủ đề Q3: Giảm bán kính ảnh hưởng của sự cố — mục tiêu là một lỗi ở module A không kéo sập toàn hệ thống. Kết quả đo được: giảm số sự cố toàn hệ thống từ 4/quý xuống dưới 1/quý, thời gian phục hồi trung bình dưới 15 phút."
Ngôn ngữ chung: gắn mỗi theme với một outcome kinh doanh
Mọi theme trên engineering roadmap phải dịch được sang ngôn ngữ business. Đây là bảng dịch mà tôi luôn bắt học viên tự làm trước mỗi lần trình bày:
| Theme kỹ thuật | Outcome kinh doanh |
|---|---|
| Giảm thời gian build/deploy | Ship feature nhanh hơn, time-to-market ngắn hơn |
| Cải thiện độ tin cậy | Giảm downtime, giữ chân khách hàng, tránh mất doanh thu |
| Refactor module cốt lõi | Feature tương lai làm nhanh hơn, ít bug hơn |
| Nâng cấp bảo mật/compliance | Đủ điều kiện bán cho khách hàng enterprise |
Tình huống thực tế
Ví dụ 1 — Sàn thương mại điện tử Việt Nam và "tuần lễ vàng" bị bỏ quên
Một sàn thương mại điện tử tại TP.HCM (khoảng 90 kỹ sư) chỉ có duy nhất một product roadmap. Suốt cả năm, mọi sprint đều là feature: voucher, livestream shopping, ví điện tử. Đội infra liên tục cảnh báo hệ thống chưa được kiểm tra tải cho các đợt cao điểm, nhưng vì không có chỗ nào trên roadmap ghi nhận, cảnh báo này bị trôi.
Đến campaign 12/12, lưu lượng tăng gấp 7 lần dự kiến. Trang thanh toán sập 40 phút trong khung giờ vàng. Ước tính thiệt hại GMV mất khoảng 6 tỷ đồng, chưa kể khách hàng chuyển sang đối thủ.
Sau sự cố, VP Engineering làm một việc thay đổi cục diện: tách riêng một engineering roadmap, đặt theme "Reliability cho mùa cao điểm" vào nhóm KTLO, với outcome đo được là "chịu tải 10x mà p99 latency dưới 800ms". Điều quan trọng là ông trình bày nó cạnh con số 6 tỷ vừa mất, nên CEO duyệt ngay 20% năng lực đội cho theme này.
Bài học: khi engineering investment không có chỗ trên bản đồ chính thức, nó vô hình cho đến khi phát nổ. Một dòng roadmap gắn với con số thiệt hại có sức thuyết phục hơn mười email cảnh báo kỹ thuật.
Ví dụ 2 — Startup fintech Singapore và bài toán "60% thời gian trả nợ"
Một startup fintech ở Singapore (Series A, 25 kỹ sư) rơi vào tình trạng velocity giảm dần mỗi quý. Mỗi feature mới tốn thời gian gấp đôi so với một năm trước vì codebase quá rối. Đội kiệt sức, còn CEO thì bực vì "sao trước làm nhanh giờ làm chậm".
Tech Lead quyết định làm engineering roadmap minh bạch. Cô đo và trình bày một con số gây sốc: đội đang tiêu 60% thời gian để đi vòng qua tech debt (workaround, sửa lỗi lặp lại, thời gian chờ pipeline). Thay vì xin "một sprint refactor", cô đề xuất một theme dài hai quý: "Khôi phục tốc độ giao hàng", với cam kết cụ thể — sau hai quý, thời gian trung bình để ship một feature vừa sẽ giảm 40%, và cô sẽ báo cáo chỉ số này hai tuần một lần.
Cách đóng khung này khác hẳn "xin thời gian dọn dẹp". Nó là một khoản đầu tư có ROI đo được và có lịch báo cáo. CEO duyệt. Sau hai quý, thời gian ship giảm 45%, và quan trọng hơn, business bắt đầu tin engineering roadmap là công cụ tăng trưởng chứ không phải cái cớ.
Bài học: business không phản đối việc trả nợ kỹ thuật — họ phản đối việc trả nợ mù mờ, không có ROI, không có deadline, không có báo cáo. Hãy biến nợ thành một khoản đầu tư có con số.
Ví dụ 3 — Grab và câu chuyện "enable the future" đúng lúc
Ở một công ty tech lớn khu vực Đông Nam Á như Grab, engineering roadmap không chỉ vá lỗi hiện tại mà còn phải mở đường cho tham vọng sắp tới. Giả sử ban lãnh đạo quyết định năm sau mở rộng mạnh sang mảng dịch vụ tài chính, đòi hỏi hạ tầng tuân thủ quy định ngặt nghèo hơn và độ cách ly dữ liệu cao hơn.
Nếu đội platform chờ đến khi product roadmap tài chính bắt đầu mới lo hạ tầng, họ sẽ luôn trễ nhịp và biến thành nút cổ chai. Thay vào đó, engineering roadmap đặt theme "Nền tảng sẵn sàng cho dịch vụ tài chính" vào nhóm "enable the future" trước cả khi product ra mắt — xây sẵn khả năng phân vùng dữ liệu, audit trail, và kiểm soát truy cập.
Bài học: engineering roadmap tốt luôn đi trước product roadmap một nhịp ở nhóm "enable the future". Nền tảng phải sẵn sàng trước khi tính năng cần đến nó, nếu không đội platform vĩnh viễn chạy theo sau.
Hướng dẫn từng bước
Đây là quy trình sáu bước để bạn xây một engineering roadmap từ con số không:
Bước 1 — Thu thập input từ nhiều nguồn. Đừng ngồi một mình viết. Gom đề xuất từ: kỹ sư (họ đau ở đâu mỗi ngày), dữ liệu sự cố (postmortem chỉ thẳng vào điểm yếu), metrics (build time, deploy frequency, MTTR), và định hướng business năm tới (để biết cần "enable" cái gì).
Bước 2 — Phân loại vào bốn nhóm. Xếp mọi hạng mục vào KTLO / Reduce friction / Enable the future / Bets. Việc phân loại này lộ ngay sự mất cân bằng — nếu 90% là KTLO, đội bạn đang chỉ chữa cháy và không đầu tư cho tương lai.
Bước 3 — Chuyển từ task sang theme có outcome. Nhóm các hạng mục liên quan thành theme, và với mỗi theme viết một câu outcome đo được. Không có metric thì không phải theme, chỉ là mong muốn.
Bước 4 — Dịch sang ngôn ngữ business. Với mỗi theme, viết một dòng "điều này mang lại gì cho công ty". Nếu không dịch được, cân nhắc bỏ hoặc gộp.
Bước 5 — Ưu tiên và phân bổ dung lượng. Quyết định tỷ lệ. Một khởi điểm hợp lý cho nhiều đội: khoảng 60-70% năng lực cho product roadmap, 20-30% cho engineering roadmap, phần còn lại cho việc bất ngờ. Tỷ lệ này thương lượng với business, và chính việc thương lượng nó một cách minh bạch mới là giá trị lớn nhất.
Bước 6 — Trình bày và thiết lập nhịp cập nhật. Trình bày theo timeline mềm (now / next / later thay vì ngày cụ thể cứng nhắc), và cam kết một nhịp review — ví dụ mỗi quý cập nhật lại, mỗi tháng báo cáo tiến độ theme. Roadmap không phải tài liệu viết một lần rồi cất; nó là một cuộc đối thoại liên tục.
Lỗi thường gặp & mẹo
Lỗi 1 — Giấu engineering work trong product roadmap. Nhiều Tech Lead lén nhét 20% thời gian trả nợ vào từng feature. Nó tạo cảm giác an toàn nhưng khiến engineering investment vô hình, không được ưu tiên đúng, và biến mất ngay khi deadline siết. Mẹo: làm nó công khai, có tên, có chỗ trên bản đồ chính thức.
Lỗi 2 — Roadmap toàn thuật ngữ kỹ thuật. Nếu slide của bạn đầy chữ "migrate to gRPC", "eliminate N+1 queries", business sẽ gật gù mà không hiểu và không ủng hộ. Mẹo: luôn có phiên bản dịch sang outcome kinh doanh cho tầng lãnh đạo, giữ chi tiết kỹ thuật cho tài liệu phụ.
Lỗi 3 — Cam kết ngày tháng cứng nhắc. Engineering work vốn khó ước lượng, đặc biệt việc refactor và migration. Đặt deadline chính xác cho theme lớn là tự đào hố. Mẹo: dùng khung "now / next / later" và cam kết vào outcome + nhịp báo cáo, không cam kết vào ngày.
Lỗi 4 — Không đo, không báo cáo. Roadmap được duyệt rồi bỏ quên là cách nhanh nhất để mất niềm tin lần sau. Mẹo: mỗi theme phải có metric baseline (con số hiện tại) và cập nhật đều đặn. Một biểu đồ MTTR giảm dần thuyết phục hơn mọi lời hứa.
Lỗi 5 — 100% roadmap là dọn dẹp quá khứ. Nếu bạn chỉ toàn KTLO và reduce friction mà không có "enable the future", đội bạn sẽ luôn chạy theo sau tham vọng công ty. Mẹo: luôn dành một phần cho tương lai, dù nhỏ.
Mẹo vàng — Đóng khung là "đầu tư", không phải "chi phí". Ngôn ngữ quyết định số phận. "Xin thời gian trả nợ" nghe như chi phí phải chịu đựng. "Đầu tư để tăng 40% tốc độ giao hàng" nghe như cơ hội. Cùng một công việc, hai số phận khác nhau hoàn toàn.
Bài tập thực hành
- Kiểm kê ẩn. Liệt kê tất cả các công việc kỹ thuật (không phải feature) mà đội bạn đang làm hoặc muốn làm nhưng chưa xuất hiện trên bất kỳ roadmap chính thức nào. Đây chính là engineering roadmap vô hình của bạn.
- Phân loại và cân đối. Xếp danh sách trên vào bốn nhóm KTLO / Reduce friction / Enable the future / Bets. Tính tỷ lệ phần trăm mỗi nhóm. Đội bạn đang mất cân bằng ở đâu?
- Viết ba theme. Chọn ba hạng mục quan trọng nhất, gộp và viết lại thành theme với: (a) một câu outcome đo được có con số, (b) một dòng dịch sang ngôn ngữ business, (c) metric baseline hiện tại.
- Bài toán thương lượng. Giả sử business chỉ cho bạn 20% năng lực cho engineering roadmap trong khi bạn cần 35%. Viết một đoạn ngắn (150 từ) bạn sẽ nói với CEO để thương lượng, dùng đúng ngôn ngữ đầu tư và ROI. Đây là bài tập quan trọng nhất — thực hành nó ra tiếng.
Tóm tắt
Engineering roadmap là bản kế hoạch đầu tư vào những thứ người dùng không trực tiếp thấy nhưng luôn gánh chịu hậu quả nếu bỏ bê: platform, hạ tầng, độ tin cậy, năng suất kỹ sư và tech debt. Nó tồn tại song song với product roadmap, không phải thay thế, và điều nguy hiểm nhất là để nó vô hình.
Những điều cần khắc cốt: cấu trúc roadmap thành bốn nhóm đầu tư (KTLO, reduce friction, enable the future, bets) để cân đối và dễ giải thích; viết thành theme có outcome đo được chứ không phải danh sách task; dịch mọi theme sang ngôn ngữ business để có sự ủng hộ; đóng khung công việc là đầu tư có ROI chứ không phải chi phí phải chịu đựng; và duy trì một nhịp báo cáo minh bạch với metric thật.
Kỹ năng này là thứ tách một Tech Lead giỏi kỹ thuật khỏi một Tech Lead thực sự dẫn dắt: người đầu ước ao có thời gian trả nợ, người sau biến nhu cầu kỹ thuật thành một câu chuyện đầu tư mà cả công ty cùng đặt cược.