Nợ kỹ thuật là phần thiết kế/mã nguồn được chấp nhận ở mức chưa tốt để đi nhanh hơn trong ngắn hạn; phần chênh lệch đó sinh "lãi" dưới dạng mọi thay đổi về sau đều chậm và rủi ro hơn. Nợ không xấu tự thân — nợ có ý thức và có kế hoạch trả là một quyết định kinh doanh hợp lệ; nợ do cẩu thả và không ai biết mới là vấn đề.
Nhận diện qua tín hiệu đo được, không qua cảm tính:
- Một thay đổi nhỏ phải sửa nhiều nơi, hoặc lặp lại cùng một lỗi ở nhiều chỗ.
- Thời gian từ commit tới lên production dài, deploy phải làm tay.
- Vùng code có tần suất sửa lỗi cao (dùng git log đếm số commit fix theo file).
- Không dám sửa vì không có test bao phủ.
Ghi nhận: tạo ticket trong cùng backlog với feature, mô tả theo tác động chứ không theo mỹ học code — "module X không có test nên mỗi lần sửa mất thêm 1 ngày kiểm thử tay", kèm chi phí ước lượng để trả.
Thuyết phục: quy về ngôn ngữ của người quyết định — thời gian, rủi ro, tiền. So sánh "trả 3 ngày bây giờ" với "mỗi tính năng liên quan tốn thêm 1 ngày, quý này còn 6 tính năng". Đề xuất tỷ lệ cố định mỗi sprint (thường 10-20% năng lực) dễ được duyệt hơn xin một đợt refactor lớn. Và gắn việc trả nợ vào tính năng sắp làm: dọn ngay vùng code mà sprint tới phải đụng đến.