Sổ nợ kỹ thuật
Mẫu & ví dụ Technical TemplatesMỗi khoản nợ kỹ thuật một dòng có lãi mỗi sprint, gốc, điểm kích hoạt, chủ sở hữu và quyết định — để đặt cạnh tính năng trong kế hoạch quý bằng cùng một đơn vị.
Mẫu này giúp bạn
Bắt đầu từ đây
Hiểu nợ kỹ thuật như một khoản vay có gốc, lãi và kỳ hạn, và rằng lãi chỉ phát sinh ở phần hệ thống đội còn phải chạm vào.
Khi đã làm được
Lập và giữ sổ nợ có lãi đo từ lịch sử, gốc, điểm kích hoạt và chủ sở hữu; xếp hạng trong ngăn nợ theo kỳ hạn rồi theo hoàn vốn; đặt khoản nợ cạnh tính năng trong kế hoạch quý bằng cùng đơn vị, và báo cáo lợi suất thay vì số hạng mục.
Mẫu, ví dụ đã điền và cách dùng
Sổ nợ kỹ thuật dùng để làm gì?
Trong hầu hết các đội, nợ kỹ thuật chỉ tồn tại trong đầu kỹ sư và trong những câu than ở retro. Đến buổi lập kế hoạch quý, tính năng có PM bảo vệ, có doanh thu đi kèm; còn nợ chỉ có một câu "phần này cần làm lại" — và nó thua. Sổ nợ kỹ thuật biến từng khoản nợ thành một dòng có số: trả dứt tốn bao nhiêu, giữ lại thì mỗi sprint tốn thêm bao nhiêu, và đến lúc nào thì buộc phải trả.
Sổ mượn ngôn ngữ của một khoản vay. Gốc là công sức làm lại cho đúng, tính một lần. Lãi là công sức thêm mỗi lần đội phải chạm vào phần đó, cộng chi phí sự cố nó gây ra, tính đều đặn mỗi sprint. Điểm kích hoạt là ngày hoặc ngưỡng mà sau đó không trả không được nữa. Ba con số đó đủ để đặt một khoản nợ cạnh một tính năng và so sánh bằng cùng một đơn vị: tuần-kỹ sư.
Điều quan trọng nhất sổ dạy: lãi chỉ phát sinh khi bạn chạm vào. Một module viết xấu mà ba quý không ai sửa có lãi gần bằng không, và trả gốc cho nó là mua sự gọn gàng, không mua tốc độ. Sổ tốt vì thế có cả những dòng ghi quyết định "giữ, không trả" — kèm lý do.
Dành cho: Engineering Manager · Tech lead · PM · Head of Product · CPO
Dùng khi: Lập một lần khi đội bắt đầu dành ngân sách riêng cho nợ, cập nhật lãi mỗi tháng, và mở ra trong buổi lập kế hoạch quý — đặt cạnh danh sách tính năng, không nộp riêng sau đó.
Khác gì với backlog lỗi và danh sách "việc muốn làm lại"?
| Chứa gì | Giúp quyết định gì | |
|---|---|---|
| Backlog lỗi | Hành vi sai mà người dùng hoặc QA đã thấy | Sửa lỗi nào trước, theo mức nghiêm trọng |
| Danh sách "việc muốn làm lại" | Những gì kỹ sư thấy khó chịu, không có số | Gần như không gì — nó không so được với tính năng |
| Sổ nợ kỹ thuật | Lối tắt đang làm mọi thay đổi sau đó tốn hơn, kèm gốc, lãi, điểm kích hoạt | Trả khoản nào quý này, giữ khoản nào, và cần bao nhiêu phần năng lực cho nợ |
Một lỗi có thể là triệu chứng của một khoản nợ: ba lỗi lệch giá trong một tháng thường đến từ cùng một chỗ tính giá bị viết hai lần. Ghi lỗi vào backlog lỗi; ghi nguyên nhân vào sổ nợ, và đếm ba lỗi đó vào lãi của nó.
Bản trắng — copy và dán vào tài liệu của bạn
Ba phần. Phần A là ngân sách và quy ước đơn vị, viết một lần mỗi quý. Phần B là các khoản nợ, mỗi khoản một khối. Phần C là bảng dùng trong buổi lập kế hoạch quý, nơi khoản nợ đứng cạnh tính năng.
SỔ NỢ KỸ THUẬT — [Tên sản phẩm / khối] — Quý ......
Người giữ sổ (Engineering Manager): ...... PM cùng ký: ......
Cập nhật lãi lần cuối: ......
PHẦN A — NGÂN SÁCH VÀ ĐƠN VỊ
Đơn vị: tuần-kỹ sư (1 kỹ sư làm 1 tuần) ≈ ...... triệu đồng
Sprint: ...... tuần, ...... sprint/quý
Năng lực quý: ...... tuần-kỹ sư
Chia ngăn: Tính năng ......% | Nợ kỹ thuật ......% |
Vận hành và sự cố ......% | Nền tảng ......%
Ngăn nợ quý này: ...... tuần-kỹ sư Ai quyết trong ngăn: ......
PHẦN B — CÁC KHOẢN NỢ (mỗi khoản một khối)
#N-.. Khoản nợ (một câu): ......
Khu vực / hệ thống: ...... Kiểu: có chủ đích / liều /
phát hiện sau / thiếu hiểu biết
LÃI — mỗi sprint: ...... tuần-kỹ sư (quy ra quý: ......)
Bằng chứng: chạm ...... lần/sprint, mỗi lần thêm ......;
sự cố ...... lần/tháng; ticket ......
GỐC — trả dứt: ...... tuần-kỹ sư Hoàn vốn: gốc / lãi quý = ......
Rủi ro nếu để nguyên: ......
Điểm kích hoạt (ngày, ngưỡng, sự kiện buộc phải trả): ......
Chủ sở hữu (một đội, một người): ......
Quyết định quý này: TRẢ DỨT / TRẢ MỘT PHẦN (......) / VÁ /
GIỮ, KHÔNG TRẢ / XOÁ KHỎI SỔ
Lý do quyết định: ......
Đo lại lãi lần cuối: ......
PHẦN C — ĐẶT CẠNH TÍNH NĂNG TRONG KẾ HOẠCH QUÝ
Hạng mục | Loại (tính năng / nợ) | Chi phí | Được gì mỗi quý |
Mất gì nếu không làm | Ngăn | Quyết định
......
NHẬT KÝ (không xoá dòng)
Ngày | Khoản | Thay đổi (lãi, gốc, quyết định) | Vì sao
Ký: Engineering Manager ...... Head of Product ...... Ngày ......Từng ô điền gì, và vì sao ô đó tồn tại
| Ô | Điền gì | Bỏ trống thì hỏng ở đâu |
|---|---|---|
| Đơn vị tuần-kỹ sư và giá tiền (phần A) | Một đơn vị chung cho mọi khoản nợ và mọi tính năng, kèm số tiền tương ứng. | Nợ đo bằng story point còn tính năng đo bằng doanh thu thì không bao giờ so được với nhau. Quy ra tiền giúp CEO hiểu ngay "16 tuần-kỹ sư mỗi quý" là bao nhiêu. |
| Chia ngăn | Tỉ lệ năng lực cho tính năng, nợ, vận hành, nền tảng — ký một lần mỗi quý. | Không có ngăn, mỗi khoản nợ phải xin thời gian như một ân huệ và bị hoãn ngay khi có khách lớn đòi tính năng gấp. |
| Khu vực và kiểu nợ | Hệ thống nào, và đây là vay có chủ đích, vay liều, nợ phát hiện sau hay nợ do thiếu hiểu biết. | Kiểu nợ quyết định cách xử lý: vay liều cần sửa quy trình, nợ do thiếu hiểu biết cần đào tạo. Không ghi kiểu thì đội trả gốc mà vẫn tiếp tục đẻ nợ mới. |
| Lãi mỗi sprint | Công sức thêm mỗi sprint vì khoản nợ này, cộng sự cố và ticket nó gây ra. | Đây là cột thắng hay thua trong phòng họp. Không có lãi, khoản nợ chỉ còn là cảm giác "code này xấu". |
| Bằng chứng lãi | Đếm số lần chạm, số sự cố, số ticket trong hai quý gần nhất. | Lãi ước theo trí nhớ thường bị thổi phồng gấp đôi. Đếm từ lịch sử commit và sự cố mới có con số người khác tin. |
| Gốc và thời gian hoàn vốn | Công sức trả dứt, và gốc chia lãi mỗi quý. | Không có hoàn vốn thì không xếp được khoản 12 tuần-kỹ sư hoàn vốn trong một quý trước khoản 40 tuần-kỹ sư hoàn vốn trong ba năm. |
| Rủi ro nếu để nguyên | Điều xấu nhất có thể xảy ra, viết bằng hậu quả kinh doanh. | Một số khoản có lãi nhỏ nhưng rủi ro lớn — lộ dữ liệu, mất tiền, app bị gỡ khỏi kho. Phép chia hoàn vốn không thấy những khoản đó. |
| Điểm kích hoạt | Ngày hết hỗ trợ, ngưỡng tải, quy định mới, hoặc ngưỡng lãi mà vượt qua thì phải trả. | Khoản nợ có kỳ hạn phải trả trước kỳ hạn bất kể lãi. Không ghi thì đội phát hiện kỳ hạn vào đúng tuần nó đến. |
| Chủ sở hữu | Một đội và một người đo lại lãi. | "Mọi người" sở hữu nghĩa là không ai đo lại, và con số trong sổ đứng yên trong khi thực tế đã đổi. |
| Quyết định và lý do | Trả dứt, trả một phần, vá, giữ, hoặc xoá khỏi sổ — kèm một câu vì sao. | Sổ không có quyết định chỉ là danh sách lo lắng. Dòng "giữ, không trả" có lý do giúp quý sau không phải tranh luận lại. |
Cách dùng — hai giờ để lập, 20 phút mỗi tháng để giữ
- Hỏi mỗi tech lead một câu: "Nếu chỉ được sửa một thứ trong hệ thống của đội, đó là gì?" Câu trả lời là dòng đầu tiên của sổ. Đừng bắt đầu bằng việc quét toàn bộ mã nguồn; một sổ có 80 dòng chưa ai đo lãi tệ hơn một sổ có 8 dòng đã đo.
- Đo lãi từ lịch sử, không từ trí nhớ. Mở hai quý commit, sự cố và ticket. Đếm số lần phải chạm vào phần đó và mỗi lần tốn thêm bao nhiêu so với nếu nó được làm đúng. Không đo được thì ghi "chưa đo" — không đoán.
- Ước gốc với hai con số: trả dứt, và trả một phần đủ để lãi giảm rõ. Nhiều khoản không cần trả hết; một bản vá 20% gốc có thể cắt 70% lãi.
- Ghi điểm kích hoạt cho từng dòng, kể cả khi câu trả lời là "không có". Hỏi cụ thể: thư viện nào hết hỗ trợ, tải sẽ chạm ngưỡng nào vào tháng nào, quy định nào sắp áp dụng.
- Xếp hạng bên trong ngăn nợ. Khoản có kỳ hạn sắp đến lấy chỗ trước. Sau đó xếp theo thời gian hoàn vốn. Khoản sắp bị thay thế thì chỉ vá, không trả gốc — đừng sửa nhà trước khi phá.
- Mang phần C vào buổi lập kế hoạch quý, cùng một bảng với tính năng. Viết cột "được gì mỗi quý" cho khoản nợ bằng ngôn ngữ của PM: tuần-kỹ sư trả lại cho tính năng, sự cố bớt đi, tốc độ phát hành tăng. Khoản nào vượt ngăn nợ thì đem ra bàn như một khoản đầu tư, cạnh tranh công khai với tính năng.
- Mỗi tháng, chủ sở hữu đo lại lãi và ghi vào nhật ký. Cuối quý báo cáo lợi suất — lãi đã giảm bao nhiêu — chứ không báo "đã làm xong 5 hạng mục nợ".
Ví dụ đã điền đầy đủ
ĐặtSỉ (giả định) là nền tảng cho 18.000 tiệm tạp hoá đặt hàng sỉ từ 230 nhà phân phối, khoảng 14.000 đơn mỗi ngày, tăng chừng 8% mỗi tháng. Khối kỹ thuật có 40 kỹ sư, sprint hai tuần. Đây là sổ của anh Vinh (Engineering Manager) và chị Thư (Head of Product) trước buổi lập kế hoạch quý 2.
SỔ NỢ KỸ THUẬT — ĐặtSỉ, toàn khối — Quý 2/2027
Người giữ sổ: anh Vinh (EM) PM cùng ký: chị Thư (Head of Product)
Cập nhật lãi lần cuối: 24/03/2027
PHẦN A — NGÂN SÁCH VÀ ĐƠN VỊ
1 tuần-kỹ sư ≈ 11 triệu đồng
Sprint 2 tuần, 6 sprint/quý; năng lực quý: 40 × 12 = 480 tuần-kỹ sư
Chia ngăn: Tính năng 65% (312) | Nợ 15% (72) | Vận hành 10% (48) |
Nền tảng 10% (48)
Ai quyết trong ngăn nợ: anh Vinh, báo lại chị Thư mỗi tháng
PHẦN B — CÁC KHOẢN NỢ
#N-01 Khuyến mãi tính ở hai nơi: app tiệm và hệ thống đơn của nhà
phân phối, hai đội viết vào hai thời điểm
Khu vực: Đặt hàng + Đơn nhà phân phối Kiểu: phát hiện sau
LÃI mỗi sprint: 1,5 (quy ra quý: 9)
Bằng chứng: khoảng 1 lần đổi chương trình khuyến mãi mỗi sprint,
mỗi lần sửa và kiểm hai nơi tốn thêm 1,5 tuần-kỹ sư;
thêm 25 ticket "giá trên app khác hoá đơn" mỗi tháng
GỐC: 12 Hoàn vốn: 12 / 9 ≈ 1,3 quý
Rủi ro nếu để nguyên: tiệm bị tính sai tiền, nhà phân phối
đòi bồi hoàn; mỗi chương trình mới càng làm hai nơi lệch xa hơn
Điểm kích hoạt: ticket lệch giá trên 40/tháng, hoặc nhà phân
phối lớn thứ hai phàn nàn bằng văn bản
Chủ sở hữu: đội Đặt hàng, Lâm (tech lead)
Quyết định: TRẢ DỨT — gom về một dịch vụ tính khuyến mãi
Lý do: hoàn vốn chưa tới hai quý, và chạm tiền
Đo lại: 20/03
#N-02 Đồng bộ tồn kho với phần mềm kế toán của nhà phân phối không
có kiểm thử tự động
Khu vực: Tích hợp nhà phân phối Kiểu: vay có chủ đích (2025,
để kịp ký 40 nhà phân phối đầu tiên)
LÃI mỗi sprint: 2 (quy ra quý: 12)
Bằng chứng: mỗi lần phát hành, 2 kỹ sư kiểm tay một tuần;
2 sự cố tồn kho ảo trong quý 1
GỐC: 20 Hoàn vốn: 20 / 12 ≈ 1,7 quý
Rủi ro nếu để nguyên: tiệm đặt hàng đã hết, nhà phân phối huỷ
đơn; tốc độ phát hành bị kẹp ở 2 tuần một lần
Điểm kích hoạt: không có ngày; lãi tăng theo số nhà phân phối
Chủ sở hữu: đội Tích hợp, Hạnh
Quyết định: TRẢ DỨT
Lý do: hoàn vốn dưới hai quý; mở khoá phát hành hằng tuần
Đo lại: 18/03
#N-03 App Android dùng SDK cổng thanh toán bản cũ
Khu vực: App tiệm Kiểu: phát hiện sau
LÃI mỗi sprint: 0
GỐC: 6 Hoàn vốn: không áp dụng
Rủi ro nếu để nguyên: cổng thanh toán ngừng hỗ trợ, tiệm không
trả trước được; khoảng 30% đơn trả trước
Điểm kích hoạt: SDK hết hỗ trợ 30/06/2027
Chủ sở hữu: đội App, Duy
Quyết định: TRẢ DỨT trong sprint 2 của quý
Lý do: có kỳ hạn; lãi bằng không không có nghĩa là an toàn
Đo lại: 10/03
#N-04 Bảng đơn hàng duy nhất, truy vấn báo cáo chạy cùng bảng giao
dịch; chậm vào giờ cao điểm 6-8 giờ sáng
Khu vực: Lõi đơn hàng Kiểu: phát hiện sau
LÃI mỗi sprint: 1 (quy ra quý: 6)
Bằng chứng: 1 sự cố chậm mỗi tháng, mỗi lần 2 tuần-kỹ sư
xử lý và dọn dữ liệu
GỐC: 40 (hai giai đoạn: tách đọc báo cáo 16; chia bảng 24)
Hoàn vốn theo lãi: gần 7 quý — nhưng không quyết theo phép chia
Rủi ro nếu để nguyên: ước tính bảng quá tải ở khoảng 25.000 đơn/
ngày; với tăng trưởng 8%/tháng, chạm mức đó khoảng tháng 10
Điểm kích hoạt: 20.000 đơn/ngày, hoặc 2 sự cố chậm/tháng
Chủ sở hữu: đội Nền tảng, anh Vinh
Quyết định: TRẢ MỘT PHẦN — giai đoạn 1 (16) quý này
Lý do: giai đoạn 1 lùi điểm quá tải thêm khoảng 2 tháng;
giai đoạn 2 xếp quý 3, trước mùa Tết
Đo lại: 24/03
#N-05 38 feature flag cũ chưa dọn
Khu vực: Toàn khối Kiểu: vay liều
LÃI mỗi sprint: 0,5 (quy ra quý: 3)
Bằng chứng: 2 lần trong quý 1 bật nhầm flag cũ khi kiểm thử
GỐC: 4 Hoàn vốn: 4 / 3 ≈ 1,3 quý
Rủi ro nếu để nguyên: một flag cũ bật lại luồng giá đã bỏ
Điểm kích hoạt: không có
Chủ sở hữu: mỗi đội dọn flag của mình
Quyết định: TRẢ DỨT; thêm quy tắc "mỗi flag có ngày xoá"
Lý do: rẻ, và chặn được kiểu vay liều tái diễn
Đo lại: 15/03
#N-06 Module báo cáo công nợ viết năm 2021, khó đọc, không có test
Khu vực: Báo cáo Kiểu: thiếu hiểu biết
LÃI mỗi sprint: gần 0 — ba quý không ai chạm
GỐC: 15
Rủi ro nếu để nguyên: thấp; báo cáo vẫn đúng
Điểm kích hoạt: khi roadmap có việc phải sửa module này
Chủ sở hữu: đội Báo cáo, Nhi
Quyết định: GIỮ, KHÔNG TRẢ
Lý do: trả gốc lúc này là mua sự gọn gàng, không mua tốc độ
Đo lại: 05/03
PHẦN C — ĐẶT CẠNH TÍNH NĂNG TRONG KẾ HOẠCH QUÝ 2
Đặt lại đơn cũ một chạm | tính năng | 30 | ước +6% đơn lặp lại |
trễ một quý | Tính năng | LÀM
Công nợ theo hạn mức cho tiệm | tính năng | 64 | mở 1.200 tiệm
đang chờ | mất hợp đồng 3 nhà phân phối | Tính năng | LÀM
N-01 Gom khuyến mãi | nợ | 12 | trả lại 9 tuần-kỹ sư/quý, bớt
75 ticket/quý | lãi tiếp tục, rủi ro bồi hoàn | Nợ | LÀM
N-02 Kiểm thử đồng bộ tồn kho | nợ | 20 | trả lại 12/quý, phát
hành hằng tuần | kẹp ở 2 tuần/lần | Nợ | LÀM
N-03 SDK thanh toán | nợ | 6 | không lãi; tránh mất 30% đơn trả
trước sau 30/06 | mất trả trước | Nợ | LÀM TRƯỚC
N-04 Tách đọc báo cáo, giai đoạn 1 | nợ | 16 | lùi điểm quá tải
khoảng 2 tháng | sự cố giờ cao điểm mùa Tết | Nợ | LÀM
N-05 Dọn flag | nợ | 4 | trả lại 3/quý | lỗi bật nhầm | Nợ | LÀM
Dự phòng nợ phát sinh | nợ | 14 | | | Nợ |
Tổng ngăn nợ: 6 + 12 + 20 + 16 + 4 + 14 = 72
NHẬT KÝ
24/03 | N-04 | lãi từ 0,5 lên 1/sprint | sự cố chậm tăng từ 1 lên 2
lần trong tháng 3 khi đơn vượt 14.000/ngày
24/03 | N-06 | quyết định giữ | ba quý không có commit nào
Ký: anh Vinh 26/03 chị Thư 26/03Hai dòng đáng đọc kỹ. N-03 có lãi bằng không, theo phép chia hoàn vốn thì đứng cuối bảng — nhưng có kỳ hạn 30/06, nên được làm trước tất cả. N-04 hoàn vốn theo lãi mất gần 7 quý, nếu chỉ nhìn số sẽ bị hoãn mãi; nhưng rủi ro quá tải trước mùa Tết là lý do trả một phần ngay. Còn N-06 là dòng mà nhiều đội sẽ muốn trả nhất vì code xấu nhất, và là dòng sổ chủ động quyết không trả. Ở phần C, chị Thư đọc khoản nợ bằng cùng ngôn ngữ với tính năng: được gì mỗi quý và mất gì nếu không làm — đó là lý do không ai trong phòng hỏi "nợ thì để sau được không".
Hiccups thường gặp và cách xử lý
| Hiccup | Vì sao xảy ra | Xử lý |
|---|---|---|
| Sổ dài 80 dòng, không dòng nào có lãi | Quét toàn bộ mã nguồn và ghi mọi thứ trông xấu | Bắt đầu với 5–8 khoản đội đang thực sự chạm vào; chỉ thêm dòng khi đo được lãi. |
| Lãi ước theo cảm giác | Không ai muốn mở lại lịch sử sự cố | Đếm từ commit, sự cố, ticket hai quý gần nhất; ghi nguồn đếm vào ô bằng chứng. |
| Trả gốc cho thứ sắp bị thay | Kỹ sư muốn làm cho đúng | Hỏi "phần này còn sống bao lâu?". Sắp thay thì chỉ vá đủ để giảm lãi. |
| Bỏ qua khoản lãi bằng không có kỳ hạn | Xếp hạng chỉ bằng phép chia hoàn vốn | Mọi khoản có điểm kích hoạt trong hai quý tới được xếp trước, bất kể lãi. |
| Ngăn nợ bị rút giữa quý cho tính năng gấp | Tỉ lệ không được ký, hoặc được bàn lại mỗi sprint | Ký tỉ lệ một lần mỗi quý; tính năng gấp tranh chỗ với tính năng khác trong ngăn tính năng. |
| Báo cáo việc đã làm, không báo lợi suất | Quen báo cáo theo số hạng mục | Cuối quý báo lãi đã giảm bao nhiêu tuần-kỹ sư, sự cố bớt bao nhiêu, phát hành nhanh hơn bao nhiêu. |
Vì sao vai trò của bạn cần cái này
| Vai trò | Bạn dùng nó để |
|---|---|
| Engineering Manager | Giữ sổ, quyết bên trong ngăn nợ, và mang vào phòng họp một đề xuất có số thay cho lời xin thời gian |
| PM | Hiểu khoản nợ nào đang làm chậm chính tính năng mình muốn ra, và đặt nó vào kế hoạch quý cùng một bảng |
| Head of Product | Ký tỉ lệ ngăn nợ cùng CTO, và trả lời được CEO khi bị hỏi "sao quý này ít tính năng mới" |
| CPO | Nhìn tổng lãi trong sổ qua nhiều quý để biết năng lực của cả khối đang bị bào mòn hay được giải phóng |
| Product Owner | Đưa phần trả nợ đã quyết vào sprint đúng lúc, nhất là các khoản có kỳ hạn |
Definition of done
- Phần A có đơn vị, giá một tuần-kỹ sư và tỉ lệ chia ngăn đã ký.
- Mỗi khoản nợ có lãi mỗi sprint kèm bằng chứng đếm được, hoặc ghi rõ "chưa đo".
- Mỗi khoản có gốc, rủi ro nếu để nguyên, điểm kích hoạt và một chủ sở hữu có tên.
- Mỗi khoản có quyết định quý này và một câu lý do, kể cả quyết định giữ.
- Phần C đặt khoản nợ cạnh tính năng với cùng các cột chi phí, được gì, mất gì.
- Lãi được đo lại trong tháng gần nhất, và thay đổi được ghi vào nhật ký.
Thảo luận & tài liệu thêm 0
Chia sẻ kinh nghiệm, đặt câu hỏi, hoặc đính kèm tài liệu/YouTube giúp người khác học kỹ năng này.