Product & Project ManagerTôi không xem đây là cuộc chọn một trong hai mà là đưa nợ kỹ thuật lên cùng một bàn cân với tính năng, bằng ngôn ngữ business hiểu được.
1. Nhờ engineering định lượng tác động của khoản nợ — không chấp nhận câu "code xấu quá":
- Làm chậm tính năng: "mỗi thay đổi ở module thanh toán mất thêm khoảng 3 ngày".
- Gây sự cố: số incident, số hotfix mỗi tháng do phần này.
- Rủi ro: thư viện hết hỗ trợ bảo mật, hạ tầng sắp chạm giới hạn tải.
2. Ưu tiên nợ nằm ở nơi code hay bị sửa. Martin Fowler so nợ kỹ thuật với tiền lãi: chỉ trả lãi khi động vào vùng code đó. Nợ ở module ổn định, ít ai sửa thì có thể để yên; nợ ở module sắp làm tính năng mới thì trả trước hoặc trả cùng lúc.
3. Chọn cách phân bổ:
- Dành cố định một phần capacity mỗi sprint (nhiều đội chọn khoảng 15–20%) cho nợ kỹ thuật, để việc trả nợ không phải xin phép từng lần.
- Gắn khoản nợ vào tính năng liên quan — làm lại luồng giỏ hàng thì dọn luôn module giỏ hàng, ước lượng tính năng đã gồm phần đó.
- Khoản nợ lớn (đổi kiến trúc, nâng framework) thì đưa lên roadmap như một hạng mục riêng, có mục tiêu đo được.
Lưu ý: việc trả nợ phải hiện trên backlog và roadmap. Giấu trong ước lượng của tính năng thì business thấy team "chậm" mà không biết vì sao, và lần sau lại bị cắt.