Phân hệ PM Study
  • Tình huốngTình huống thực chiến
  • Kịch bảnRa quyết định tình huống
  • Biểu mẫuKho biểu mẫu tải về
  • Thẻ ghi nhớHọc thuật ngữ PMP
  • Công cụMáy tính EVM, PERT, dự phòng
  • Hỏi đápHỏi đáp & thảo luận
  • Thử tháchMỗi ngày một câu hỏi PMP
  • Lý thuyếtBài học PMBOK 8 & ECO 2026
  • Luyện thiThi thử & ôn tập PMP
  • Bài viếtThư viện bài viết PMP
PM Study
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đáp
6 chuyên mụcXem tất cả bài viết →
  • Quản lý các bên liên quanTình huống về kỳ vọng, giao tiếp và gắn kết stakeholder.
  • Lãnh đạo & đội nhómXây dựng, dẫn dắt và giải quyết xung đột trong đội dự án.
  • Kế hoạch & tiến độLập kế hoạch, ước lượng, nén tiến độ và kiểm soát baseline.
  • Rủi ro & thay đổiNhận diện, ứng phó rủi ro và kiểm soát thay đổi phạm vi.
  • Agile & HybridLựa chọn và vận hành cách tiếp cận Agile, Predictive, Hybrid.
  • Luyện thi PMPChiến lược ôn tập và mẹo xử lý câu hỏi tình huống PMP.
Công cụBài viết
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đápChuyên mụcCông cụBài viết
/
PM Study

Học quản lý dự án và ôn thi PMP bằng tiếng Việt: lý thuyết PMBOK® Guide 8, tình huống thực tế và đề luyện thi theo ECO 2026.

Chuyên mục

  • Quản lý các bên liên quan
  • Lãnh đạo & đội nhóm
  • Kế hoạch & tiến độ
  • Rủi ro & thay đổi
  • Agile & Hybrid
  • Luyện thi PMP

Tài nguyên

  • Project Management Institute (PMI)
  • PMP Exam Content Outline
  • The Scrum Guide
  • PMI Vietnam Chapter

PM Study

  • Tất cả bài viết
  • Bài viết nổi bật
© 2026 PM StudyPMP® và PMBOK® là nhãn hiệu đã đăng ký của Project Management Institute.Phiên bản 1.12.1
  1. /Hỏi đáp
  2. /Kinh nghiệm thực tế
  3. /Product Owner không cho thời gian trả nợ kỹ thuậ…
Kinh nghiệm thực tếThảo luận

Product Owner không cho thời gian trả nợ kỹ thuật: mỗi sprint đều "tính năng trước, refactor sau"

HP
Nguyễn Thu Hà, PMP
đăng 2 tháng trước· 0 lượt xem

Tình huống tổng hợp, mang tính minh hoạ.

Sản phẩm thương mại điện tử của công ty đã chạy 3 năm. Đội phát triển liên tục đề xuất dành thời gian nâng cấp thư viện cũ, viết kiểm thử tự động, tách các mô-đun quá lớn. Product Owner lần nào cũng gật đầu "để sprint sau", vì phía kinh doanh luôn có tính năng gấp hơn.

Dấu hiệu gần đây: một thay đổi nhỏ ở giỏ hàng mất 2 tuần thay vì 2 ngày; mỗi lần phát hành đều phát sinh lỗi ở chỗ không liên quan; 2 lập trình viên giỏi xin nghỉ vì "chán sửa code rối".

Thảo luận:

  • Làm sao thuyết phục PO và kinh doanh đầu tư cho nợ kỹ thuật?
  • Nên dành cố định một tỷ lệ mỗi sprint, hay làm một đợt "dọn dẹp" riêng?
  • Định nghĩa hoàn thành (Definition of Done) có giúp gì không?
#agile#chat-luong#Kinh nghiệm

1 phản hồi

HP
Nguyễn Thu Hà, PMP2 tháng trước

Nợ kỹ thuật (technical debt) là ẩn dụ do Ward Cunningham đặt ra năm 1992: chọn giải pháp nhanh giúp tăng tốc ngắn hạn, nhưng "lãi" sẽ tích luỹ dưới dạng chi phí bảo trì và thay đổi ngày càng cao. Tình huống của bạn cho thấy "lãi" đã đến hạn: thời gian thay đổi tăng gấp nhiều lần, lỗi lan, người giỏi bỏ đi.

1. Thuyết phục bằng ngôn ngữ của PO và kinh doanh. Đừng nói "code xấu", hãy nói "thời gian đưa tính năng ra thị trường". Thu thập vài số liệu: thời gian chu trình (cycle time) của các thay đổi gần đây so với trước, số lỗi phát sinh sau mỗi lần phát hành, thời gian dành cho sửa lỗi khẩn. Trình bày: "Không đầu tư, mỗi tính năng mới sẽ tiếp tục chậm và rủi ro hơn". Đây là áp dụng nguyên tắc tập trung vào giá trị và đưa chất lượng vào quy trình và sản phẩm của PMBOK 7.

2. Đưa nợ kỹ thuật vào Product Backlog. Nợ vô hình thì không bao giờ được ưu tiên. Mỗi hạng mục nợ được viết rõ: vấn đề, tác động kinh doanh, công sức ước tính. PO là người sắp thứ tự backlog (theo Scrum Guide) — hãy cho PO đủ thông tin để sắp xếp đúng.

3. Tỷ lệ cố định hay đợt dọn dẹp? Mỗi cách có đánh đổi:

  • Tỷ lệ cố định mỗi sprint (ví dụ một phần năm năng lực): đều đặn, dễ dự báo, tránh nợ tích luỹ; nhưng có thể bị "mượn" khi kinh doanh gấp.
  • Đợt dọn dẹp riêng: tập trung xử lý được việc lớn (tách mô-đun); nhưng dừng tính năng hoàn toàn thường khó được chấp nhận, và nợ lại tích luỹ sau đó.
  • Thực tế nhiều đội kết hợp: tỷ lệ cố định cho việc nhỏ + hạng mục lớn được lên kế hoạch như một tính năng có giá trị kinh doanh rõ.

4. Định nghĩa hoàn thành giúp ngừng vay thêm nợ. Theo Agile Alliance, DoD là danh sách tiêu chí đội thống nhất phải đạt trước khi coi một phần tăng trưởng là "xong" — giúp giảm làm lại. Thêm tiêu chí như "có kiểm thử tự động cho logic mới", "không tăng cảnh báo phân tích mã" để mỗi tính năng mới không làm nợ phình thêm.

5. Nguyên tắc "hướng đạo sinh": mỗi khi chạm vào một đoạn mã, để nó sạch hơn một chút — chi phí nhỏ, lợi ích tích luỹ.

Việc người giỏi nghỉ vì chán là chi phí ẩn lớn nhất của nợ kỹ thuật — nên đưa vào sổ rủi ro.

Nguồn:

  • Technical debt — Wikipedia
  • Definition of Done — Agile Alliance Glossary

Bạn có câu hỏi?

Đặt câu hỏi hoặc mở thảo luận để cộng đồng PM cùng góp ý.

Đặt câu hỏi

Chuyên mục thảo luận

  • Tất cả chủ đề
  • Hỏi đáp chung134 chủ đề
  • Ôn thi PMP159 chủ đề
  • Kinh nghiệm thực tế109 chủ đề
Quảng cáoBộ đề thi thử PMP (mẫu)