Một API thanh toán vẫn chạy nhưng mỗi lần thêm phương thức mới, dev phải sửa cùng một logic ở nhiều nơi. Bộ test chưa bao phủ luồng hoàn tiền. Thư viện xác thực đã cũ, trong khi đội đang chuẩn bị mở quyền cho nhóm người dùng mới.
Cả ba đều có thể được gọi là nợ kỹ thuật. Roadmap cần thể hiện tác động đến người dùng và vận hành, thay vì chỉ ghi “refactor” hoặc “dọn code”.
Phân biệt nợ kỹ thuật với lỗi và bảo trì thường kỳ
Lỗi là hành vi hiện tại không đúng với yêu cầu đã chốt. Bảo trì gồm nâng phiên bản, gia hạn chứng chỉ, sao lưu và các việc lặp lại để hệ thống tiếp tục hoạt động. Nợ kỹ thuật xuất hiện khi một lựa chọn trước đây làm tăng rủi ro hoặc chi phí cho thay đổi tiếp theo.
Một truy vấn chậm khi dữ liệu vượt ngưỡng hiện tại có thể là nợ cần theo dõi. Nếu nó đã làm người dùng không mở được báo cáo theo cam kết, đó là lỗi. Nếu cơ sở dữ liệu sắp hết thời hạn hỗ trợ, đội phải xử lý như việc bảo trì có hạn chót.
Viết mục nợ kỹ thuật để Product có thể đánh giá
Một ticket “tách service đơn hàng” chưa cho Product biết vì sao phải làm trong quý này. Engineering nên bổ sung thay đổi đang bị chậm, sự cố có thể lặp lại, phạm vi người dùng chịu ảnh hưởng và cách xử lý khả thi.
Mô tả đủ dùng gồm:
- Thành phần hoặc luồng nghiệp vụ bị ảnh hưởng.
- Dấu hiệu hiện tại và tình huống kích hoạt, chẳng hạn tăng tải hoặc thêm vai trò.
- Hậu quả nếu trì hoãn cùng phương án nhỏ nhất để giảm rủi ro.
- Cách xác nhận sau khi sửa bằng test, giám sát hoặc thử có giới hạn.
Cách viết này gần với nguyên tắc trong bài quản lý thay đổi phạm vi MVP: giữ nguyên nguồn, tác động, người quyết định và đầu ra phải cập nhật.
Quy trình đưa nợ kỹ thuật vào roadmap
1. Ghi nhận tại nơi phát sinh
Engineering tạo mục khi gặp lỗi lặp, giới hạn kiến trúc, phụ thuộc cũ hoặc thao tác triển khai dễ sai. Đính kèm log, test thất bại hoặc điều kiện kích hoạt có thể kiểm tra.
2. Nhóm theo tác động
Phân loại theo an ninh, dữ liệu, độ tin cậy, tốc độ phát triển, chi phí hạ tầng hoặc khả năng hỗ trợ. Chọn một tác động chính để tránh chấm điểm hai lần.
3. Chọn cách xử lý nhỏ nhất
So sánh cô lập thành phần, bổ sung test, nâng phụ thuộc, chuyển dần dữ liệu và viết lại. Ưu tiên phương án giảm rủi ro chính mà vẫn kiểm tra và quay lại được.
4. So sánh với mục tiêu roadmap
Product xem nợ có chặn tính năng, phân khúc, chất lượng hoặc yêu cầu tuân thủ sắp tới hay không. Engineering xác nhận phạm vi, phụ thuộc và chi phí trì hoãn.
5. Chốt tiêu chí và xem lại kết quả
Ticket nêu phần sẽ sửa, phần chưa sửa, test phải qua, tín hiệu cần theo dõi và người duyệt. Sau phát hành, đối chiếu lỗi, tốc độ triển khai và thời gian xử lý. Nếu kết quả không đổi, kiểm tra lại giả định thay vì đóng ticket vì code đã được sắp xếp lại.
Khi nào nợ kỹ thuật phải chặn mốc phát hành?
Không phải mục nào cũng cần chặn release. Điều kiện chặn nên gắn với hậu quả khó đảo ngược: nguy cơ lộ dữ liệu, sai số tiền, mất khả năng khôi phục, dữ liệu không thể di chuyển hoặc quyền truy cập vượt phạm vi.
Vấn đề làm dev chậm nhưng chưa gây lỗi sản phẩm có thể được lên lịch cùng tính năng liên quan. Chẳng hạn, tách logic giảm giá trước khi thêm nhiều chính sách giá giúp đội kiểm thử trong cùng ngữ cảnh và tránh sửa một vùng code nhiều lần.
Chọn thời điểm xử lý nợ kỹ thuật
Xử lý trước hoặc cùng mốc phát hành khi
- Có nguy cơ ảnh hưởng an ninh, tính đúng của dữ liệu hoặc giao dịch.
- Thành phần hiện tại không đáp ứng tải hay quyền truy cập của phạm vi sắp mở.
- Không có cách phát hiện, khôi phục hoặc xử lý thủ công đáng tin cậy.
- Tính năng đã cam kết phụ thuộc trực tiếp vào phần cần sửa.
Theo dõi và lên lịch sau khi
- Tác động chỉ xuất hiện ngoài phạm vi roadmap hiện tại.
- Đội có cảnh báo, giới hạn tải và phương án tạm thời rõ.
- Phương án sửa còn thiếu dữ liệu hoặc có nguy cơ gián đoạn lớn hơn việc trì hoãn.
- Một thay đổi nền tảng sắp tới có thể làm phương án hiện tại trở nên thừa.
Đo kết quả sau khi xử lý
Đừng dùng số dòng code đã sửa hoặc số ticket đã đóng. Chọn tín hiệu khớp với lý do ưu tiên: số lỗi lặp, thời gian khôi phục, tỷ lệ triển khai thất bại, thời gian thêm một quy tắc mới, mức dùng tài nguyên hoặc phạm vi test tự động.
Rà các mục quan trọng trong cùng phiên ra quyết định sản phẩm hằng tuần. Kết quả có thể là giới hạn tính năng, thêm test, đặt cảnh báo hoặc yêu cầu dữ liệu trước khi chốt.
Nếu mục tiêu là chuẩn bị tăng tải, cần thử ở mức đã thống nhất. Nếu mục tiêu là giảm rủi ro thay đổi, hãy chạy bộ test phù hợp và kiểm tra phương án quay lại. Một thay đổi chỉ hoàn thành khi hậu quả ban đầu đã giảm theo tiêu chí đã chốt.
Dịch vụ Product Consultant của Auranium hỗ trợ đội làm rõ tác động, điều kiện ưu tiên và phạm vi trước khi đưa nợ kỹ thuật vào roadmap. Khi phạm vi đã rõ, Product Development có thể cùng đội thiết kế cách xử lý, test và bàn giao theo từng mốc.