Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Ưu tiên nợ kỹ thuật bên cạnh tính năng — một danh mục đầu tư, không phải xin thời gian

Đã đọc 0/8 mục · còn khoảng 5 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Vì sao "xin thời gian trả nợ" luôn thua

Kịch bản quen thuộc: tech lead xin một sprint để "dọn dẹp". PM đồng ý miễn cưỡng. Đến giữa quý, một khách lớn yêu cầu tính năng gấp, và sprint dọn dẹp bị hoãn. Quý sau lặp lại.

Nợ thua vì nó được trình bày như một ân huệ — xin thời gian ra khỏi công việc "thật". Tính năng có người bảo vệ, có doanh thu gắn kèm; khoản nợ chỉ có một kỹ sư lo lắng. Muốn thoát vòng này, phải đổi khung: năng lực kỹ thuật là một danh mục đầu tư, và nợ kỹ thuật là một loại tài sản trong danh mục đó, có lợi suất đo được.

Chia ngân sách thành các ngăn

Ở ChởNhanh (giả định), 60 kỹ sư cho 720 tuần-kỹ sư mỗi quý. Mai và anh Đạt thống nhất chia như sau:

NgănTỉ lệTuần-kỹ sư/quýAi quyết bên trong ngăn
Tính năng60%432PM các đội, theo roadmap
Nợ kỹ thuật20%144Engineering Manager, theo sổ nợ
Vận hành và sự cố10%72Đội trực, theo thực tế phát sinh
Nền tảng dùng chung10%72CTO cùng Head of Product
Tổng100%720Head of Product và CTO ký tỉ lệ
Hai điều làm cách chia này khác "xin thời gian":

  • Tỉ lệ được ký một lần mỗi quý, không bàn lại từng sprint. Khi khách lớn yêu cầu gấp, tính năng đó tranh chỗ với tính năng khác trong ngăn 432, không lấy từ ngăn nợ.
  • Bên trong mỗi ngăn có người quyết. Mai không duyệt từng khoản nợ, cũng như anh Đạt không duyệt từng tính năng. Mỗi bên chịu trách nhiệm báo lại kết quả.

Xếp hạng bên trong ngăn nợ

Ngăn nợ có 144 tuần-kỹ sư. Sổ nợ của ChởNhanh có năm khoản lớn:

Khoản nợGốcLãi mỗi quýKỳ hạn
Phí giao hàng tính ở ba nơi1016Không có
Đối soát COD chạy theo mẻ ban đêm, lỗi 2 lần/tháng, mỗi lần 3 tuần-kỹ sư xử lý3018Không có
Thư viện bản đồ của app tài xế8Hết hỗ trợ cuối tháng 6
Thiếu kiểm thử tự động cho app tài xế2412Không có
Tách đối soát COD khỏi lõi cũ200Rủi ro quá tải mùa cao điểmTrước cao điểm cuối năm
Lãi của khoản đối soát: 2 lỗi/tháng × 3 tuần-kỹ sư × 3 tháng = 18 tuần-kỹ sư mỗi quý.

Một thước đo đơn giản là thời gian hoàn vốn = gốc chia lãi mỗi quý:

  • Phí giao hàng: 10 / 16 ≈ 0,6 quý
  • Đối soát theo mẻ: 30 / 18 ≈ 1,7 quý
  • Kiểm thử app tài xế: 24 / 12 = 2 quý
Nếu chỉ theo bảng, thứ tự là phí giao hàng, đối soát theo mẻ, rồi kiểm thử. Nhưng hai khoản còn lại không thể xếp bằng phép chia.

Hai quyết định không theo phép chia

Thư viện bản đồ có lãi bằng không nhưng có kỳ hạn. Hôm nay nó không tốn gì. Cuối tháng 6, nó hết hỗ trợ, và app tài xế có thể ngừng hoạt động trên điện thoại mới. Khoản nợ có kỳ hạn phải được trả trước kỳ hạn, bất kể lãi — nó như khoản vay đáo hạn một lần.

Không trả gốc cho thứ sắp bị thay. Viết lại đối soát theo mẻ tốn 30 tuần-kỹ sư, nhưng chính phần đó sẽ được tách khỏi lõi cũ trong ba quý tới. Trả gốc bây giờ là sửa nhà trước khi phá. Thay vào đó, đội chi 6 tuần-kỹ sư cho một bản vá: giám sát tốt hơn và tự chạy lại khi lỗi. Ước tính số lỗi giảm từ 2 xuống khoảng 0,5 lần/tháng, lãi còn 0,5 × 3 × 3 = 4,5 tuần-kỹ sư mỗi quý.

Kết quả phân bổ ngăn nợ quý này

Hạng mụcTuần-kỹ sư
Gom phí giao hàng về một nơi10
Thay thư viện bản đồ8
Kiểm thử tự động app tài xế24
Bản vá đối soát theo mẻ6
Tách đối soát COD khỏi lõi cũ, giai đoạn đầu72
Dự phòng cho khoản nợ phát sinh24
Tổng144
Khoản lớn nhất — tách đối soát COD — sẽ được bàn kỹ ở bài 7. Ở đây chỉ cần thấy nó được đặt trong cùng một ngân sách và cạnh tranh công khai với các khoản khác.

Báo cáo danh mục, không báo cáo công việc

Cuối quý, Mai không báo "đội đã làm xong 6 hạng mục nợ". Chị báo lợi suất:

  • Lãi phí giao hàng giảm từ 16 về gần 0 tuần-kỹ sư mỗi quý. Quý sau, 8 lần đổi giá tốn 8 tuần-kỹ sư thay vì 24.
  • Sự cố đối soát giảm từ 6 xuống 2 trong quý.
  • App tài xế phát hành được hai tuần một lần thay vì bốn tuần.
Ba câu đó trả lời câu hỏi "sao quý này ít tính năng mới" tốt hơn mọi lời giải thích kỹ thuật. Đây cũng là chỗ Head of Product đứng ra bảo vệ ngân sách — xem thêm Roadmap & OKRs để đưa các kết quả này thành mục tiêu đo được.

Khi nào đổi tỉ lệ

Tỉ lệ 20% không phải con số thiêng. Đổi khi dữ liệu nói cần đổi:

Tín hiệuHướng điều chỉnh
Tổng lãi trong sổ nợ tăng ba quý liên tiếpTăng ngăn nợ lên 25–30%
Sự cố ngốn vượt ngăn vận hành hai quý liềnTăng ngăn nợ, nhắm vào nguồn gây sự cố
Sổ nợ còn toàn khoản lãi thấp, không kỳ hạnGiảm ngăn nợ, trả công sức cho tính năng
Sắp có hạn chót thị trường lớn, nợ ổn địnhGiảm tạm một quý, ghi rõ quý sau bù lại
Điều quan trọng là thay đổi được bàn và ký như một quyết định đầu tư, không bị bào mòn từng sprint.

Làm ngay

Ước tính tổng năng lực đội của bạn mỗi quý bằng tuần-kỹ sư. Hỏi Engineering Manager quý vừa rồi thực tế bao nhiêu phần trăm đi vào tính năng, nợ, vận hành và sự cố — thường con số thật khác hẳn con số ai cũng nghĩ. Rồi lấy sổ nợ ba dòng ở bài 2, tính thời gian hoàn vốn cho từng khoản, đánh dấu khoản nào có kỳ hạn, khoản nào sắp bị thay. Đề xuất một tỉ lệ cho quý tới và mang nó đến cuộc họp lập kế hoạch.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi