Khoản nợ kỹ thuật lớn nhất của bạn không nằm trong mã nguồn

Mọi lãnh đạo kỹ thuật đều biết cảm giác đó. Bạn kế thừa một hệ thống. Bạn mở codebase ra. Bạn tìm thấy mớ hỗn độn. Bạn lập lộ trình sửa nó. Bạn không bao giờ có thời gian.

Nhưng còn một khoản nợ sâu hơn mà hầu hết các đội không bao giờ thừa nhận. Nó không nằm trong mã nguồn, mà nằm trong hiểu biết tập thể của tổ chức về mã nguồn.

Kiến thức truyền miệng là một khoản nợ

Mỗi quyết định không được ghi chép là một khoản thuế đánh vào tương lai. Mỗi lựa chọn kiến trúc chỉ có hai người hiểu là một điểm lỗi đơn lẻ. Nợ mã nguồn cộng dồn chậm. Nợ kiến thức cộng dồn theo cấp số nhân — bởi mỗi người rời đi đều mang theo sự hiểu biết mà không ai khác có.

Tôi từng chứng kiến những đội mạnh dừng lại, không phải vì mã nguồn tệ, mà vì người hiểu đường dẫn quan trọng đã chuyển việc. Mã nguồn vẫn ổn. Sự hiểu biết thì đã mất. Đó mới là khoản nợ thực sự.

Vì sao AI thay đổi phép tính

Trước AI, giải quyết nợ kiến thức nghĩa là viết thêm tài liệu. Và tài liệu có một vấn đề ai cũng biết — nó được viết một lần, thỉnh thoảng mới được đọc, và ít được tin tưởng hơn việc hỏi người từng ở đó.

AI thay đổi điều này theo hai cách. Thứ nhất, AI tiêu hóa kiến thức có cấu trúc. Nếu bạn có hồ sơ quyết định kiến trúc, runbook và postmortem — dù lộn xộn — AI có thể khiến chúng tìm kiếm được và trả lời câu hỏi dựa trên chúng. Thứ hai, AI có thể lộ ra nơi kiến thức còn thiếu. Khi cùng một câu hỏi được hỏi ba lần trên Slack mà không có câu trả lời được ghi chép, đó là tín hiệu hạ tầng kiến thức của bạn đang hỏng.

Các đội đầu tư vào việc ghi chép kiến thức có cấu trúc không chỉ ngăn nắp hơn. Họ đang xây nền tảng giúp AI thực sự hữu ích trong bối cảnh của họ.

Cái giá của việc phớt lờ điều này

Nợ mã nguồn làm chậm tốc độ kỹ thuật của bạn. Nợ kiến thức khiến nó dừng hẳn. Khác biệt nằm ở khả năng nhìn thấy. Bạn có thể đo nợ mã nguồn, có thể ưu tiên nó. Nợ kiến thức thì vô hình cho đến khi nó cắn bạn, và lúc đó chi phí phục hồi rất đắt.

Đội giải quyết nợ mã nguồn sẽ nhanh hơn. Đội giải quyết nợ kiến thức sẽ không thể ngăn cản — bởi hiểu biết của họ cộng dồn thay vì rò rỉ.

Bắt đầu từ đâu

Chọn một hệ thống có rủi ro bus-factor cao nhất. Nếu người hiểu nó rõ nhất nghỉ việc vào ngày mai, sẽ mất bao lâu để khôi phục sự hiểu biết đó? Bất kể câu trả lời là gì, đó chính là khoản nợ kỹ thuật thực sự của bạn.

Ghi chép các quyết định kiến trúc. Nắm bắt các runbook. Làm cho kiến thức đủ cấu trúc để AI có thể làm việc với nó. Không phải vì viết tài liệu vui — mà vì đó là cách duy nhất để trí tuệ tổ chức của bạn bền vững.

Một ví dụ thực tế

Tôi từng làm việc với một đội có đường ống dữ liệu quan trọng mà chỉ một người hiểu. Anh ấy rất giỏi, đã xây nó từ đầu. Khi anh ấy nghỉ phép, mọi sự cố đường ống đều đồng nghĩa với việc chờ anh ấy quay lại. Đội đã chấp nhận điều đó như chuyện bình thường.

Chúng tôi dành một quý để nắm bắt kiến thức của anh ấy. Các quyết định kiến trúc, chế độ hỏng hóc, quy trình phục hồi — tất cả được ghi chép dưới dạng có cấu trúc. Chúng tôi xây một giao diện AI đơn giản có thể trả lời câu hỏi về đường ống dựa trên tài liệu đó.

Khi anh ấy rời đi, quá trình chuyển giao mất hai tuần thay vì sáu tháng mà đội từng lo sợ. Kiến thức không rời đi cùng anh ấy. Nó được gắn vào các hệ thống mà đội dùng hằng ngày.

Đó là lợi tức đầu tư khi coi kiến thức như hạ tầng.

Đo lường đúng thứ

Hầu hết các đội đo nợ kỹ thuật bằng mã nguồn. Số dòng mã có vấn đề đã biết. Các TODO chưa giải quyết. Các dependency lỗi thời. Những thứ này dễ đo và đáng theo dõi.

Nhưng chúng bỏ lỡ bức tranh lớn hơn. Mười nghìn dòng mã sạch, được bảo trì tốt cũng vô dụng nếu không ai hiểu hệ thống vận hành đầu cuối ra sao. Khoản nợ thực sự thường vô hình cho đến khi ai đó rời đi và mang theo sự hiểu biết.

Hãy bắt đầu đo mức độ tập trung kiến thức. Với mỗi hệ thống quan trọng, hãy hỏi: có bao nhiêu người có thể độc lập giải thích nó hoạt động thế nào, vì sao nó được xây theo cách đó, và cách phục hồi khi nó hỏng? Nếu câu trả lời là một hoặc hai, bạn đang có nợ kiến thức, và khoản nợ đó rồi sẽ đến hạn.

Vì sao điều này khó được ưu tiên

Nợ kiến thức khó được ưu tiên vì nó không hiện ra như một vấn đề khẩn cấp. Không có cảnh báo kích hoạt. Không có hệ thống nào sập. Nhưng cái giá là thật và đang cộng dồn. Mỗi tuần trôi qua mà không ghi chép kiến thức sẽ khiến quá trình chuyển giao cuối cùng khó khăn hơn.

Các đội coi trọng điều này xem việc ghi chép kiến thức là một hoạt động kỹ thuật hạng nhất. Không phải việc làm khi có thời gian, mà là một phần của mọi dự án quan trọng. Hồ sơ quyết định kiến trúc. Postmortem sự cố. Runbook vận hành. Đây không phải chi phí phụ, mà là nền tảng giúp mọi thứ khác khả thi.

AI khiến khoản đầu tư này sinh lời nhanh hơn bao giờ hết. Nhưng nó chỉ hiệu quả nếu kiến thức đã tồn tại để được nắm bắt. Hãy xây nền tảng trước. Mọi thứ khác đều phụ thuộc vào nó.

Nghĩ rằng lập luận này phù hợp với sự kiện của bạn? Hãy kể cho tôi về khán phòng — lịch trình có chọn lọc.