Mở đầu — vì sao bài này quan trọng
Có một câu chuyện gần như lặp lại ở mọi công ty công nghệ: một kỹ sư đứng lên trong buổi họp planning, đề xuất "chúng ta cần dành hai sprint để refactor lại module authentication". Người quản lý sản phẩm nhìn xuống roadmap, thấy ba tính năng khách hàng đang chờ, rồi trả lời một câu quen thuộc: "Nó vẫn chạy được mà, để sau đi." Ba tháng sau, hệ thống login sập vào đúng ngày ra mắt chiến dịch marketing, mất bốn tiếng downtime, và bây giờ thì ai cũng hỏi "tại sao không ai cảnh báo trước?"
Vấn đề không nằm ở chỗ tech debt (nợ kỹ thuật) tồn tại — mọi codebase đều có nợ, và nợ ở mức hợp lý thậm chí là lành mạnh. Vấn đề nằm ở chỗ kỹ sư và người ra quyết định kinh doanh nói hai ngôn ngữ khác nhau. Kỹ sư nói về "coupling", "code smell", "spaghetti code"; còn business nghe những từ đó như tiếng nước ngoài và mặc định đó là chuyện nội bộ của dev, không liên quan đến tiền hay khách hàng.
Bài học này không dạy bạn tech debt là gì về mặt kỹ thuật — bạn đã biết rồi. Nó dạy bạn cách giao tiếp về tech debt để nó được nhìn nhận, ưu tiên và cấp ngân sách. Đây là một kỹ năng phân biệt giữa một kỹ sư giỏi code và một kỹ sư có ảnh hưởng lên hướng đi của sản phẩm. Nếu bạn từng ức chế vì "không ai chịu nghe" khi bạn nói về nợ kỹ thuật, thì phần lớn nguyên nhân nằm ở cách bạn diễn đạt, chứ không phải ở việc business "không quan tâm chất lượng".
Khái niệm cốt lõi
Business không ghét tech debt — họ chỉ không nhìn thấy nó
Điều quan trọng đầu tiên phải hiểu: người làm business không cố tình bỏ mặc chất lượng kỹ thuật. Họ đơn giản là không có công cụ để nhìn thấy nó. Nợ kỹ thuật là thứ vô hình với người không đọc code. Một tính năng chậm ra mắt thì họ thấy ngay; một module rối rắm đang âm thầm bào mòn tốc độ của cả team thì họ không thấy, cho đến khi hậu quả nổ ra.
Nhiệm vụ của bạn là chuyển thứ vô hình đó thành thứ hữu hình — và đơn vị hữu hình mà business hiểu là: tiền, thời gian, rủi ro, và khách hàng. Chừng nào bạn còn nói "code này xấu", bạn đang mô tả cảm nhận thẩm mỹ của kỹ sư. Khi bạn nói "code này khiến mỗi tính năng mới liên quan đến thanh toán mất thêm 3 ngày và có 30% khả năng gây bug production", bạn đang nói ngôn ngữ ra quyết định.
Bốn "cái giá" mà business thực sự quan tâm
Mọi lập luận về tech debt hiệu quả đều quy về một trong bốn thứ này:
- Customer-facing impact (ảnh hưởng đến khách hàng): Nợ kỹ thuật này có làm chậm, làm lỗi, hay làm giảm trải nghiệm mà khách hàng cảm nhận được không? Ví dụ: trang checkout load 8 giây vì query database chưa tối ưu.
- Velocity tax (thuế tốc độ): Nợ này khiến mọi tính năng tương lai đắt hơn bao nhiêu? Đây là "lãi kép" của nợ kỹ thuật — mỗi lần đụng vào vùng code đó, cả team phải trả thêm.
- Risk / rủi ro vận hành: Xác suất và mức độ nghiêm trọng của sự cố. Downtime, mất dữ liệu, lỗ hổng bảo mật, chi phí tuân thủ.
- Talent / con người: Nợ kỹ thuật làm kỹ sư giỏi nản lòng, onboarding người mới lâu hơn, tăng nguy cơ nghỉ việc. Chi phí tuyển và đào tạo lại một senior engineer ở Việt Nam không hề nhỏ.
Phân loại nợ để nói cho đúng
Không phải nợ kỹ thuật nào cũng giống nhau, và trộn lẫn chúng khiến lập luận yếu đi. Một cách phân loại hữu ích khi giao tiếp:
- Nợ đang chảy máu (bleeding): Đang gây thiệt hại ngay bây giờ — bug lặp lại, downtime, khách hàng phàn nàn. Đây là loại dễ được duyệt nhất vì hậu quả nhìn thấy được.
- Nợ đang tăng lãi (compounding): Chưa gây sự cố nhưng làm chậm mọi thứ và ngày càng tệ. Cần dữ liệu để chứng minh.
- Nợ ngủ đông (dormant): Xấu về mặt kỹ thuật nhưng ở vùng code không ai đụng tới và không có kế hoạch đụng tới. Thành thật mà nói, loại này thường không đáng ưu tiên — và việc bạn thừa nhận điều đó làm tăng uy tín cho những lập luận khác của bạn.
Đóng khung tech debt như một quyết định đầu tư, không phải lời phàn nàn
Đây là chuyển dịch tư duy quan trọng nhất. Đừng đến gặp business với tâm thế "hãy cho tôi dọn dẹp mớ hỗn độn này". Hãy đến với tâm thế "đây là một khoản đầu tư với ROI cụ thể". Ẩn dụ tài chính "nợ / lãi suất" cực kỳ mạnh vì nó nói đúng ngôn ngữ của người quản lý: bạn có thể trả lãi mãi mãi (chấp nhận velocity tax) hoặc trả gốc một lần (refactor) — con số nào rẻ hơn?
Tình huống thực tế
Tình huống 1: Từ "refactor auth" thành ngôn ngữ tiền bạc
Một startup fintech ở TP.HCM, tạm gọi là PayNhanh, có khoảng 25 kỹ sư. Module xác thực người dùng được viết vội trong giai đoạn MVP hai năm trước, giờ trở thành nút thắt. Kỹ sư backend tên Tú đã đề xuất refactor ba lần trong ba quý, và cả ba lần đều bị gạt vì "không phải ưu tiên kinh doanh".
Lần thứ tư, Tú đổi cách trình bày. Anh không nói "code auth rối". Thay vào đó, anh mang đến buổi họp một bảng số liệu: trong 6 tháng qua, có 14 tính năng phải chạm vào module auth, và mỗi tính năng trung bình mất thêm 2,5 ngày so với ước tính ban đầu chỉ vì phải "gỡ rối" phần auth. Tổng cộng: khoảng 35 ngày công bị đốt. Ngoài ra, 4 trong 9 sự cố production quý vừa rồi bắt nguồn từ module này, trong đó một sự cố khiến 1.200 người dùng không đăng nhập được trong 40 phút — đúng khung giờ cao điểm giao dịch.
Rồi anh đưa ra lời đề nghị dưới dạng đầu tư: "Chúng ta refactor mất khoảng 12 ngày công. Đổi lại, tôi ước tính giảm được khoảng 2 ngày mỗi tính năng auth trong tương lai, và cắt phần lớn rủi ro sự cố loại này. Khoản đầu tư này hoàn vốn sau khoảng 6 tính năng — tức trong một quý."
Lần này được duyệt trong 15 phút.
Bài học rút ra: Không có con số nào ở đây là chính xác tuyệt đối, và điều đó không sao. Ước lượng hợp lý, có cơ sở, luôn thắng cảm giác mơ hồ. Tú đã dịch "code xấu" thành "35 ngày công đã mất + rủi ro downtime giờ vàng + điểm hoàn vốn rõ ràng". Đó là ngôn ngữ mà PM và founder ra quyết định được.
Tình huống 2: Cái bẫy "refactor toàn bộ" ở một công ty e-commerce
Một công ty thương mại điện tử tại Hà Nội, tạm gọi Chợ Xanh, có team engineering muốn viết lại (rewrite) toàn bộ hệ thống quản lý đơn hàng từ đầu vì "kiến trúc cũ quá tệ". Họ trình bày với ban lãnh đạo một kế hoạch 4 tháng, dừng gần hết tính năng mới trong thời gian đó. Lãnh đạo từ chối thẳng, và mối quan hệ giữa engineering với business trở nên căng thẳng — business bắt đầu nghĩ "đội kỹ thuật này chỉ thích đồ chơi mới".
Sáu tháng sau, một tech lead mới tiếp cận vấn đề khác hẳn. Thay vì đòi rewrite 4 tháng, cô chia nợ kỹ thuật của hệ thống đơn hàng thành các "miếng" nhỏ, mỗi miếng gắn với một lợi ích kinh doanh cụ thể. Miếng đầu tiên: tách phần tính phí ship ra khỏi khối logic khổng lồ, mất 1 sprint, đổi lại việc thêm một đối tác vận chuyển mới giảm từ 2 tuần xuống 3 ngày — điều mà bộ phận vận hành đang rất cần. Miếng thứ hai gắn với việc giảm tỷ lệ đơn lỗi trạng thái mà chăm sóc khách hàng vẫn than phiền.
Cô gọi đây là chiến lược "refactor cơ hội" (opportunistic refactoring): mỗi khi có một tính năng kinh doanh đi ngang qua vùng code nợ nần, ta trả một phần nợ ngay tại đó, và tính chi phí đó vào chính tính năng ấy.
Bài học rút ra: Business gần như luôn nói "không" với một đề nghị lớn, mờ mịt, dừng mọi thứ khác. Nhưng họ nói "có" với những đề nghị nhỏ gắn liền lợi ích rõ ràng. "Big bang rewrite" không chỉ rủi ro về kỹ thuật mà còn là thảm họa về giao tiếp — nó buộc business phải đặt cược lớn vào thứ họ không nhìn thấy. Chia nhỏ và gắn nợ vào giá trị là cách bán tech debt hiệu quả nhất.
Tình huống 3: Khi im lặng là sai lầm — làm tech debt hữu hình liên tục
Một công ty SaaS khu vực Đông Nam Á với văn phòng ở Singapore và Đà Nẵng gặp vấn đề ngược lại: kỹ sư không nói gì về tech debt cho đến khi nó bùng nổ, vì họ nghĩ "nói cũng không ai nghe". Kết quả là mỗi sự cố đều khiến lãnh đạo bị bất ngờ, và mỗi lần bất ngờ lại làm xói mòn niềm tin vào đội kỹ thuật.
Engineering manager mới quyết định thiết lập một cơ chế minh bạch đơn giản. Cô lập một "tech debt register" — về bản chất là một bảng theo dõi, mỗi dòng gồm: mô tả nợ bằng ngôn ngữ tác động (không phải ngôn ngữ code), vùng ảnh hưởng, ước lượng chi phí đang trả, và mức độ ưu tiên đề xuất. Mỗi sprint, team dành cố định 15–20% năng lực cho việc trả nợ, và trong buổi sprint review, cô dành 3 phút báo cáo "quý này ta đã trả những khoản nợ này, giảm được những rủi ro này". Cô cũng gắn một chỉ số đơn giản cho lãnh đạo theo dõi: tỷ lệ thời gian team dành cho "sửa cái đã có" so với "làm cái mới".
Sau hai quý, chỉ số này giảm từ 40% xuống 25%, nghĩa là team dành nhiều thời gian hơn cho tính năng mới. Lãnh đạo nhìn thấy tech debt được quản lý chủ động thay vì nổ ra bất ngờ, và bắt đầu tin tưởng các đề xuất kỹ thuật.
Bài học rút ra: Giao tiếp về tech debt không phải là một cuộc trình bày đơn lẻ mà là một thói quen minh bạch liên tục. Khi bạn làm nợ kỹ thuật hữu hình đều đặn — có sổ theo dõi, có ngân sách cố định, có báo cáo tiến độ — bạn biến nó từ "những lời phàn nàn ngẫu hứng của dev" thành "một hạng mục quản trị bình thường". Niềm tin được xây bằng sự đều đặn, không phải bằng những bài diễn thuyết hùng hồn khi khủng hoảng.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng lần tới khi cần đề xuất trả một khoản nợ kỹ thuật:
Bước 1 — Xác định "cái giá" cụ thể, không nói cảm tính. Trước khi mở miệng, tự hỏi: khoản nợ này đang lấy đi cái gì? Thời gian dev? Rủi ro downtime? Trải nghiệm khách hàng? Chọn ra một đến hai cái giá rõ ràng nhất.
Bước 2 — Thu thập bằng chứng có thể lượng hóa. Đào dữ liệu bạn đã có: số giờ mất trên các ticket liên quan, số incident bắt nguồn từ vùng code đó, thời gian build, số bug lặp lại, phàn nàn của khách hàng. Không cần chính xác đến từng số lẻ — cần đủ để lập luận đứng vững.
Bước 3 — Dịch sang ngôn ngữ business. Chuyển mỗi bằng chứng kỹ thuật thành câu nói theo mẫu: "Vì [tình trạng code], mỗi khi [hoạt động kinh doanh], chúng ta mất [chi phí] và chịu [rủi ro]." Loại bỏ mọi thuật ngữ mà PM không hiểu.
Bước 4 — Đóng khung như một khoản đầu tư với ROI. Nêu rõ: chi phí trả nợ là bao nhiêu (thời gian), lợi ích thu về là gì, và điểm hoàn vốn. Con số hoàn vốn ("hòa vốn sau X tính năng / Y tuần") là vũ khí mạnh nhất của bạn.
Bước 5 — Đề xuất phương án nhỏ nhất có ý nghĩa. Đừng đòi refactor cả thế giới. Đề xuất miếng nhỏ nhất mang lại lợi ích đo được, tốt nhất là gắn với một ưu tiên kinh doanh sắp tới. Cho họ thấy con đường thay vì một bức tường.
Bước 6 — Thiết lập cơ chế minh bạch liên tục. Đừng để đây là cuộc trò chuyện một lần. Lập tech debt register, đề xuất ngân sách cố định (ví dụ 15–20% mỗi sprint), và báo cáo tiến độ định kỳ để xây niềm tin dài hạn.
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng thuật ngữ kỹ thuật với người không kỹ thuật. "Coupling cao", "cyclomatic complexity", "God object" — những từ này khiến người nghe cảm thấy bị loại khỏi cuộc trò chuyện và mặc định đây là chuyện của dev. Mẹo: nếu bà của bạn không hiểu câu bạn nói, PM cũng sẽ không thấy động lực để hành động.
Lỗi 2 — Biến nó thành lời phàn nàn đạo đức. "Người trước viết ẩu quá", "chúng ta đang làm sai chuẩn" nghe như đổ lỗi và than vãn. Business không cấp ngân sách cho cảm xúc. Mẹo: luôn nói về tương lai và lợi ích, không về quá khứ và lỗi lầm.
Lỗi 3 — Đòi "big bang rewrite". Đề nghị dừng mọi tính năng để viết lại từ đầu gần như luôn bị từ chối, và còn làm hỏng uy tín của bạn. Mẹo: chia nhỏ, gắn từng miếng nợ với một giá trị kinh doanh cụ thể, ưu tiên "refactor cơ hội".
Lỗi 4 — Cường điệu ("mọi thứ sắp sập"). Nếu bạn báo động đỏ với mọi khoản nợ, người ta sẽ ngừng tin bạn khi có nguy cơ thật. Mẹo: hãy thành thật thừa nhận những khoản nợ không đáng ưu tiên (nợ ngủ đông). Sự trung thực này làm những cảnh báo nghiêm túc của bạn đáng tin hơn nhiều.
Lỗi 5 — Chỉ nói khi khủng hoảng. Nếu lần duy nhất business nghe về tech debt là lúc mọi thứ đang cháy, họ sẽ luôn cảm thấy bị bất ngờ và mất niềm tin. Mẹo: giao tiếp đều đặn, có sổ theo dõi và báo cáo định kỳ.
Mẹo bonus — Gắn tech debt vào chính bản ước tính tính năng. Khi ước tính một tính năng đi qua vùng nợ, hãy nói rõ: "Tính năng này mất 5 ngày, nhưng vì phần code X đang nợ, sẽ thành 8 ngày; nếu ta trả nợ X trước thì các tính năng sau ở vùng này sẽ nhanh hơn." Cách này biến tech debt thành một phần tự nhiên của cuộc trò chuyện ước tính, thay vì một chủ đề riêng khó bán.
Bài tập thực hành
Bài tập 1 — Dịch thuật. Lấy ba khoản tech debt thật trong dự án hiện tại của bạn. Với mỗi khoản, viết hai phiên bản: (a) cách bạn thường mô tả nó với đồng nghiệp kỹ sư, và (b) cách diễn đạt lại theo mẫu "Vì [tình trạng], mỗi khi [hoạt động kinh doanh], ta mất [chi phí] và chịu [rủi ro]." So sánh hai phiên bản.
Bài tập 2 — Xây dựng lập luận ROI. Chọn khoản nợ đáng lo nhất trong ba khoản trên. Ước lượng: chi phí trả nợ (ngày công), lợi ích định kỳ thu về, và điểm hoàn vốn. Không cần dữ liệu hoàn hảo — dùng ước lượng hợp lý và ghi rõ giả định của bạn. Viết thành một đoạn pitch dài tối đa 5 câu.
Bài tập 3 — Lập tech debt register mini. Tạo một bảng đơn giản với 5 dòng nợ kỹ thuật của team, mỗi dòng gồm: mô tả theo ngôn ngữ tác động, vùng ảnh hưởng, chi phí đang trả, phân loại (chảy máu / tăng lãi / ngủ đông), và ưu tiên đề xuất. Trình bày với một đồng nghiệp và xin phản hồi: dòng nào thuyết phục, dòng nào còn mơ hồ?
Bài tập 4 — Chia nhỏ. Lấy một "ước mơ rewrite" nào đó mà team bạn hằng ao ước. Chia nó thành ít nhất 4 miếng độc lập, và với mỗi miếng, ghép nó với một lợi ích kinh doanh hoặc một tính năng sắp tới mà nó có thể "đi ghép cùng".
Tóm tắt
Tech debt không được ưu tiên không phải vì business ghét chất lượng, mà vì nó vô hình với người không đọc code. Công việc của bạn là làm nó hữu hình bằng ngôn ngữ mà người ra quyết định hiểu: tiền, thời gian, rủi ro và khách hàng. Hãy dừng nói "code này xấu" và bắt đầu nói "code này khiến mỗi tính năng chậm thêm X ngày và có Y% rủi ro sự cố".
Ba nguyên tắc cốt lõi cần nhớ: (1) dịch mọi khoản nợ kỹ thuật sang cái giá cụ thể mà business quan tâm; (2) đóng khung nó như một khoản đầu tư có ROI và điểm hoàn vốn, chia nhỏ thay vì đòi big bang rewrite; và (3) xây niềm tin bằng sự minh bạch liên tục — tech debt register, ngân sách cố định mỗi sprint, báo cáo định kỳ — thay vì chỉ lên tiếng khi khủng hoảng. Một kỹ sư biết code là quý; một kỹ sư biết khiến tổ chức đầu tư đúng chỗ vào chất lượng kỹ thuật là vô giá.