Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Tech Lead của một công ty fintech ở TP.HCM với 40 kỹ sư chia thành sáu team. Một buổi sáng, team Payment quyết định dùng Kafka cho hàng đợi sự kiện. Ba tuần sau, team Lending — không biết chuyện đó — lại chọn RabbitMQ cho cùng một loại bài toán. Sáu tháng sau, bạn có hai công nghệ message queue trong cùng một hệ thống, hai bộ kiến thức vận hành khác nhau, hai lần chi phí đào tạo, và không ai dám đụng vào cả hai vì "team kia rành hơn". Đây không phải lỗi của kỹ sư nào cả. Đây là lỗi của việc tổ chức không có một cơ chế minh bạch để trả lời câu hỏi tưởng như đơn giản: "Ở công ty mình, công nghệ nào nên dùng, công nghệ nào nên tránh, và công nghệ nào đang trong giai đoạn thử nghiệm?"
Tech Radar chính là công cụ trả lời câu hỏi đó. Với vai trò Technical Leadership, một trong những trách nhiệm quan trọng nhất của bạn không phải là tự tay chọn từng công nghệ, mà là tạo ra một khung minh bạch, có kỷ luật để cả tổ chức cùng đưa ra và chia sẻ những lựa chọn công nghệ đó. Bài học này giúp bạn hiểu bản chất Tech Radar, cách xây dựng nó phù hợp với công ty của mình, và cách dùng nó như một công cụ lãnh đạo chứ không phải một bản slide trang trí.
Khái niệm cốt lõi
Tech Radar là gì
Tech Radar là một artifact (hiện vật) do ThoughtWorks — một công ty tư vấn công nghệ toàn cầu — phổ biến từ năm 2010. Về bản chất, nó là một tấm bản đồ phân loại các công nghệ mà tổ chức đang dùng hoặc đang cân nhắc, giúp mọi người trong công ty thống nhất được đâu là lựa chọn được khuyến nghị.
Cấu trúc của Tech Radar gồm hai chiều: rings (vòng) và quadrants (góc phần tư).
Bốn rings — mức độ chín muồi của công nghệ
Đây là phần quan trọng nhất. Mỗi công nghệ được đặt vào một trong bốn vòng, tính từ tâm ra ngoài:
- Adopt (Áp dụng): Công nghệ đã được chứng minh, tổ chức tin tưởng hoàn toàn và khuyến nghị dùng cho các dự án phù hợp. Đây là lựa chọn mặc định. Ví dụ: PostgreSQL, Docker, React ở nhiều công ty đã trưởng thành.
- Trial (Thử nghiệm): Công nghệ đáng để đầu tư thử trên các dự án thật nhưng có kiểm soát, có thể chấp nhận rủi ro. Bạn đã dùng nó trong ít nhất một dự án thực tế và thấy triển vọng, nhưng chưa đủ dữ liệu để đưa lên Adopt.
- Assess (Đánh giá): Công nghệ đáng để tìm hiểu, làm proof-of-concept, nhưng chưa nên đưa vào dự án production quan trọng. Bạn đang theo dõi để hiểu nó giải quyết được vấn đề gì cho mình.
- Hold (Tạm giữ / Tránh): Công nghệ nên thận trọng, không nên bắt đầu dự án mới với nó. Lưu ý quan trọng: Hold không có nghĩa là "cấm" hay "xóa bỏ ngay". Nó có thể là công nghệ đang được dùng nhưng tổ chức muốn ngừng mở rộng thêm, hoặc một xu hướng bị thổi phồng mà bạn muốn cảnh báo đội ngũ đừng chạy theo.
Bốn quadrants — loại công nghệ
ThoughtWorks chia công nghệ thành bốn nhóm để dễ tổ chức:
- Techniques (Kỹ thuật): các phương pháp, thực hành như Trunk-based development, Feature flags, Micro frontends.
- Tools (Công cụ): Docker, Terraform, Grafana, Playwright.
- Platforms (Nền tảng): AWS, Kubernetes, Databricks, Supabase.
- Languages & Frameworks (Ngôn ngữ & Framework): TypeScript, Go, Next.js, Spring Boot.
Blips và sự dịch chuyển
Mỗi điểm trên radar gọi là một blip. Điều làm Tech Radar sống động là các blip di chuyển theo thời gian: một công nghệ có thể đi từ Assess → Trial → Adopt qua vài kỳ radar, hoặc bị đẩy ngược ra Hold khi tổ chức nhận ra nó không phù hợp. Chính sự dịch chuyển này kể câu chuyện về hướng đi công nghệ của tổ chức — và đó là giá trị lãnh đạo thực sự của công cụ.
Phân biệt: Tech Radar không phải là gì
Tech Radar không phải là danh sách công nghệ "được phép" mang tính pháp lệnh (đó là governance cứng nhắc). Nó cũng không phải Tech Stack cố định của một dự án cụ thể. Nó là một hướng dẫn có chủ ý (opinionated guidance) — thể hiện quan điểm tập thể của tổ chức tại một thời điểm, và luôn kèm lý do (rationale) cho mỗi vị trí.
Tình huống thực tế
Tình huống 1 — Tiki chuẩn hóa để giảm phân mảnh
Bối cảnh: Một công ty thương mại điện tử lớn tại Việt Nam (tạm gọi theo mô hình của Tiki) có khoảng 120 kỹ sư. Qua nhiều năm phát triển nhanh, các team tự chọn stack riêng: có team dùng Node.js, team dùng Java, team dùng Python cho backend; có team dùng MySQL, team dùng MongoDB. Khi một kỹ sư chuyển team, họ mất trung bình 3-4 tuần để làm quen stack mới. Chi phí vận hành phình to vì SRE phải hỗ trợ quá nhiều loại hệ thống.
Diễn giải: Tech Lead nhóm Platform quyết định lập Tech Radar đầu tiên. Họ không "cấm" gì cả — thay vào đó đặt Java Spring Boot và Node.js vào Adopt (hai ngôn ngữ backend chính), MongoDB vào Hold cho các dự án mới (khuyến nghị dùng PostgreSQL thay thế trừ trường hợp đặc biệt), và Go vào Trial vì một team đã dùng thành công cho service high-throughput. Mỗi quyết định đi kèm lý do viết rõ.
Bài học: Sau hai kỳ radar (khoảng 6 tháng), số lượng ngôn ngữ backend mới được khởi tạo giảm rõ rệt, và thời gian onboarding kỹ sư chuyển team rút xuống còn khoảng 1-2 tuần. Điểm hay là radar không tạo cảm giác bị áp đặt, vì nó minh bạch lý do và cho phép ngoại lệ có kiểm soát.
Tình huống 2 — Startup 15 người và cái bẫy "công nghệ hot"
Bối cảnh: Một startup SaaS ở Hà Nội với 15 kỹ sư. Một kỹ sư senior rất hào hứng với một database vector mới nổi và muốn đưa vào core sản phẩm ngay sau khi đọc vài bài blog. CTO băn khoăn vì công nghệ này chưa có phiên bản ổn định, cộng đồng nhỏ, và team chưa ai vận hành production bao giờ.
Diễn giải: Thay vì tranh cãi "nên hay không", CTO dùng Tech Radar làm ngôn ngữ chung. Công nghệ đó được đặt vào Assess, kèm ghi chú: "Đáng làm PoC cho tính năng semantic search trong sprint tới, giới hạn 1 tuần, không đưa vào luồng thanh toán". Điều này vừa tôn trọng sự nhiệt tình của kỹ sư, vừa đặt ranh giới rõ ràng để bảo vệ sản phẩm.
Bài học: Tech Radar biến một cuộc tranh luận cảm tính thành một quyết định có khung. Với công ty nhỏ, bạn không cần công cụ cầu kỳ — một trang tài liệu với bốn ring cũng đủ để tránh việc "chạy theo hype" làm hỏng sản phẩm non trẻ. Ring Assess đặc biệt hữu ích ở đây: nó nói "có, chúng ta quan tâm" nhưng cũng nói "chưa phải bây giờ, và có điều kiện".
Tình huống 3 — ThoughtWorks và tính công khai của radar
Bối cảnh: ThoughtWorks xuất bản Technology Radar công khai hai lần mỗi năm, tổng hợp ý kiến từ một hội đồng kỹ thuật cấp cao (Doppler Group). Đây là ví dụ kinh điển về radar được vận hành có kỷ luật.
Diễn giải: Điều đáng học không phải nội dung các blip của họ (vì bối cảnh của họ khác bạn), mà là quy trình: có nhịp định kỳ, có hội đồng thảo luận và tranh biện, mỗi blip có một đoạn giải thích ngắn gọn nhưng sắc bén về lý do vì sao nó ở vị trí đó, và họ sẵn sàng đưa cả những công nghệ phổ biến vào Hold khi thấy bị lạm dụng.
Bài học: Giá trị của radar nằm ở quá trình đối thoại tạo ra nó, không phải ở tấm hình cuối cùng. Nếu bạn copy nguyên radar của ThoughtWorks về dùng, bạn đã bỏ lỡ toàn bộ điểm mấu chốt — vì "Adopt" ở công ty họ chưa chắc phù hợp với công ty bạn.
Hướng dẫn từng bước
Đây là cách bạn xây dựng và duy trì Tech Radar cho tổ chức của mình:
Bước 1 — Xác định phạm vi và người tham gia. Quyết định radar này áp dụng cho ai (cả công ty hay một bộ phận), và lập một nhóm biên tập nhỏ gồm Tech Lead các team chính cộng một số kỹ sư senior có uy tín. Nhóm này khoảng 4-8 người là hợp lý.
Bước 2 — Thu thập blip. Đề nghị mỗi team đề xuất công nghệ họ muốn đưa lên radar, kèm đề xuất ring và lý do. Đây là bước dân chủ hóa: ai cũng có thể đề cử, không chỉ lãnh đạo.
Bước 3 — Họp radar và tranh biện. Tổ chức một buổi họp (thường 2-3 giờ) để cả nhóm biên tập thảo luận từng blip. Đây là trái tim của quy trình. Mỗi blip phải chốt được: ring nào, quadrant nào, và một đoạn rationale 2-4 câu. Nếu không thống nhất được, đó là tín hiệu công nghệ đó nên ở Assess hoặc Trial chứ chưa phải Adopt.
Bước 4 — Viết rationale rõ ràng. Với mỗi blip, viết ngắn gọn: vì sao ở ring này, và điều kiện để nó dịch chuyển. Ví dụ: "Go — Trial. Đã dùng thành công cho service notification xử lý 5.000 req/s. Sẽ cân nhắc Adopt nếu team thứ hai triển khai thành công trong 6 tháng tới."
Bước 5 — Xuất bản ở nơi dễ thấy. Dùng công cụ mã nguồn mở như "build-your-own-radar" của ThoughtWorks (nhận dữ liệu từ một Google Sheet), hoặc đơn giản là một trang trong wiki nội bộ. Quan trọng là ai cũng truy cập được.
Bước 6 — Đặt nhịp cập nhật. Chọn chu kỳ phù hợp: 6 tháng/lần cho công ty lớn, 3 tháng/lần cho công ty đang thay đổi nhanh. Mỗi kỳ, xem lại toàn bộ và cập nhật sự dịch chuyển của các blip.
Bước 7 — Gắn radar vào quy trình thực tế. Đây là bước hay bị bỏ quên. Hãy tham chiếu radar trong các quy trình khác: khi review kiến trúc, khi duyệt dự án mới, khi onboarding. Nếu ai đó muốn dùng công nghệ ở Hold, họ cần một buổi thảo luận ngoại lệ ngắn — không cấm tuyệt đối, nhưng cần có lý do.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến radar thành công cụ cấm đoán từ trên xuống. Nếu radar chỉ là danh sách "được dùng / không được dùng" do lãnh đạo áp đặt, kỹ sư sẽ chống đối ngầm và tìm cách lách. Mẹo: luôn để các team tham gia đề cử và tranh biện. Radar là quan điểm tập thể, không phải mệnh lệnh.
Lỗi 2 — Làm một lần rồi bỏ đó. Một radar không cập nhật sau 8 tháng còn tệ hơn không có radar, vì nó hướng dẫn sai. Mẹo: đặt lịch cố định như một sự kiện kỹ thuật định kỳ, gắn với một người chịu trách nhiệm rõ ràng.
Lỗi 3 — Quên viết rationale. Một blip không có lý do đi kèm sẽ gây tranh cãi vô tận sáu tháng sau, khi không ai nhớ vì sao nó ở đó. Mẹo: không blip nào được lên radar mà thiếu 2-4 câu giải thích.
Lỗi 4 — Nhầm Hold với "xóa bỏ". Nhiều người tưởng Hold nghĩa là phải gỡ công nghệ đó ngay. Thực ra Hold thường nghĩa là "đừng bắt đầu dự án mới với nó". Mẹo: viết rõ Hold là "không mở rộng" hay "cần thay thế theo lộ trình".
Lỗi 5 — Copy radar của công ty khác. Radar phản ánh bối cảnh riêng — quy mô, năng lực đội ngũ, loại sản phẩm. Mẹo: tham khảo radar công khai để lấy cảm hứng về quy trình, nhưng nội dung phải do chính bạn tranh biện ra.
Mẹo cho công ty nhỏ: Nếu bạn chỉ có 10-20 kỹ sư, đừng phức tạp hóa. Một bảng bốn cột (Adopt/Trial/Assess/Hold) trong Notion, cập nhật mỗi quý, đã đủ tạo ra 80% giá trị.
Bài tập thực hành
- Vẽ radar hiện trạng (30 phút): Liệt kê 15-20 công nghệ mà tổ chức hoặc team của bạn đang dùng. Đặt mỗi cái vào một trong bốn ring Adopt/Trial/Assess/Hold. Ghi chú công nghệ nào bạn thấy khó phân loại — đó thường là nơi cần thảo luận nhất.
- Viết rationale (20 phút): Chọn 5 blip và viết cho mỗi cái một đoạn giải thích 2-4 câu: vì sao nó ở ring đó và điều kiện để nó dịch chuyển.
- Tìm sự phân mảnh (30 phút): Rà soát xem có hai công nghệ nào đang cùng giải quyết một loại vấn đề trong tổ chức không (ví dụ hai message queue, hai loại database). Đề xuất công nghệ nào nên ở Adopt và công nghệ nào nên chuyển sang Hold, kèm lộ trình.
- Thiết kế nhịp (15 phút): Xác định cho tổ chức của bạn: chu kỳ cập nhật radar là bao lâu, ai trong nhóm biên tập, và bạn sẽ gắn radar vào quy trình nào (review kiến trúc, duyệt dự án, onboarding).
Tóm tắt
Tech Radar là một artifact do ThoughtWorks phổ biến, phân loại công nghệ thành bốn ring — Adopt, Trial, Assess, Hold — theo mức độ chín và mức độ khuyến nghị, chia theo bốn quadrant loại công nghệ. Nó không phải công cụ cấm đoán mà là một hướng dẫn có chủ ý, thể hiện quan điểm tập thể của tổ chức tại một thời điểm.
Giá trị lãnh đạo thực sự của Tech Radar nằm ở ba điều: nó giảm phân mảnh công nghệ, nó biến các tranh luận cảm tính thành quyết định có khung, và quan trọng nhất — quá trình tranh biện để tạo ra nó giúp cả tổ chức đồng thuận về hướng đi. Với vai trò Technical Leadership, bạn không cần tự chọn mọi công nghệ; bạn cần tạo ra cơ chế minh bạch, dân chủ và có kỷ luật để tổ chức cùng chọn. Hãy nhớ ba nguyên tắc: để đội ngũ tham gia đề cử, luôn viết rationale, và duy trì nhịp cập nhật đều đặn. Một radar sống — dịch chuyển theo thời gian — mới thực sự dẫn đường; một radar tĩnh chỉ là tấm poster trên tường.