Câu nói “PO ưu tiên tính năng mới hơn là sửa lỗi và cải thiện hiệu năng hệ thống” đã nêu bật một lối đi phổ biến nhưng cũng đầy nguy hiểm trong phát triển phần mềm. Dù việc ra mắt các tính năng mới có thể thu hút người dùng và tạo ra sự phấn khích, việc liên tục phớt lờ các lỗi và vấn đề về hiệu năng sẽ dẫn đến sự tích tụ của technical debt (nợ kỹ thuật) – một thứ có thể làm tê liệt sản phẩm về lâu dài.
Hãy cùng nhìn sâu hơn, vấn đề cốt lõi ở đây là một chiến lược ưu tiên thiển cận, chỉ thiên về những lợi ích tức thời và hữu hình (tính năng mới) mà bỏ qua những giá trị lâu dài, ít thấy rõ hơn (sự ổn định và “sức khỏe” của hệ thống). Điều này thường xuất phát từ áp lực phải đáp ứng deadline, gây ấn tượng với các bên liên quan (stakeholder) bằng những chức năng hào nhoáng, hoặc đơn giản là do chưa thấu hiểu hết tác động tiêu cực cộng dồn của technical debt. Món nợ này, cũng giống như nợ tài chính, sẽ ngày càng tính “lãi”: các lỗi, các điểm nghẽn về hiệu năng, và kiến trúc lỗi thời sẽ khiến hệ thống khó bảo trì hơn, dễ phát sinh lỗi hơn, và khó thích ứng với các thay đổi trong tương lai. Nó kéo theo sự sụt giảm năng suất của lập trình viên, gia tăng chi phí hỗ trợ, và cuối cùng là sự bất mãn của người dùng.
Vậy, làm thế nào để chúng ta thuần hóa con quái vật vô hình này?
Có một vài vũ khí chiến lược. Đầu tiên là nâng cao nhận thức: hãy giáo dục PO và các stakeholder về khái niệm và hậu quả của technical debt. Tiếp theo, hãy tạo ra một lá chắn kiên cố bằng cách dành ra một tỷ lệ công suất cụ thể trong mỗi sprint để giải quyết nợ kỹ thuật, bao gồm sửa lỗi và cải thiện hiệu năng. Một cánh cổng chất lượng cũng cần được dựng lên, đó là việc tích hợp các tiêu chí về chất lượng mã nguồn, kiểm thử, và hiệu năng vào trong Definition of Done (DoD). Điều này ngăn chặn các tính năng mới được coi là “hoàn thành” nếu chúng lại tạo ra thêm nợ.
Quan trọng hơn cả là một la bàn định hướng: hãy triển khai một prioritization framework (khung đánh giá ưu tiên) như Weighted Shortest Job First - WSJF hoặc RICE (Reach, Impact, Confidence and Effort). Những công cụ này cho phép chúng ta cân nhắc một cách có hệ thống giữa giá trị kinh doanh của tính năng mới và tác động của việc giải quyết technical debt, từ đó đưa ra quyết định sáng suốt hơn. Cuối cùng, hãy đưa technical debt ra ánh sáng. Sự minh bạch là chìa khóa – hãy sử dụng một backlog chuyên dụng hoặc các công cụ trực quan để theo dõi và truyền thông về tình trạng hiện tại của nợ kỹ thuật cho tất cả mọi người.
Cách tiếp cận tốt nhất thường là sự kết hợp của các giải pháp trên, nhưng việc dành ra “công suất chuyên dụng” và áp dụng một “khung đánh giá ưu tiên” mạnh mẽ là những bước đi cốt lõi đầu tiên. Hành trình này bắt đầu bằng việc định lượng món nợ kỹ thuật hiện có, sau đó tích hợp các giải pháp đã chọn vào quy trình làm việc của nhóm, như trong các buổi sprint planning hay backlog refinement.
Làm sao để biết chúng ta đang chiến thắng?
Hãy theo dõi các chỉ số như số lượng lỗi, hiệu năng hệ thống (thời gian phản hồi, tỷ lệ lỗi), velocity của lập trình viên, và sự hài lòng của khách hàng. Chúng sẽ cho thấy liệu các giải pháp của chúng ta có đang quản lý technical debt một cách hiệu quả hay không. Cuộc chiến này là một cuộc chiến trường kỳ, không phải một trận đánh duy nhất. Hãy thường xuyên thảo luận về technical debt trong các buổi retrospective, xác định những gì đã hiệu quả, những gì chưa, và làm thế nào để cải thiện trong các sprint tương lai. Việc học hỏi và thích ứng liên tục chính là chìa khóa cho thành công dài hạn.
