Effort và Confidence là hai biến còn lại của RICE. Effort đặt ở mẫu số nên sai một chút là đảo thứ tự ưu tiên. Confidence là "phanh" giúp bạn không ưu tiên những ước lượng quá mơ hồ.
Định nghĩa
- Effort: Tổng công sức, thường tính person-month hoặc person-week (gồm cả design, dev, QA, không chỉ code).
- Confidence: Độ tin cậy vào các ước lượng Reach/Impact/Effort, thang %: 100% = có dữ liệu chắc, 80% = khá chắc, 50% = phỏng đoán. Confidence thấp kéo điểm RICE xuống — đúng như mong muốn.
AI giúp gì ở đây?
AI không biết codebase của bạn, nên không thể ước lượng effort chính xác thay dev. Nhưng AI cực mạnh trong việc: (1) bóc tách một item mơ hồ thành các đầu việc để bạn hỏi dev đúng chỗ; (2) chỉ ra rủi ro ẩn làm phình effort; (3) chấm Confidence dựa trên độ mơ hồ của giả định.
Ví dụ cụ thể
Item: "Thêm đăng nhập Google". Nghe nhỏ, nhưng...
Prompt mẫu
Vai trò: Trợ lý PO giúp bóc tách EFFORT và chấm CONFIDENCE. Không giả vờ biết codebase của tôi.
Item: "Thêm đăng nhập bằng Google (OAuth) cho web app hiện có login email/password".
Yêu cầu:
1. Liệt kê các đầu việc cần thiết (design, backend, frontend, QA, bảo mật, migration user cũ, edge case).
2. Với mỗi đầu việc, nêu câu hỏi tôi CẦN hỏi dev để ước lượng đúng.
3. Chỉ ra 3 rủi ro ẩn thường làm phình effort của tính năng này.
4. Đề xuất Confidence (%) cho toàn item và giải thích điều gì làm giảm confidence.
5. KHÔNG đưa số person-week cụ thể vì bạn không biết team tôi.
AI sẽ trả ra danh sách: xử lý tài khoản trùng email, đồng bộ session, xử lý user đã có mật khẩu, compliance, logout... và nêu rủi ro "merge tài khoản trùng" thường bị bỏ sót. Bạn cầm danh sách này đi hỏi dev → có Effort thật thay vì đoán "2 ngày".
Quan trọng: một tính năng tưởng nhỏ như đăng nhập Google có thể ẩn cả tuần công việc trong các edge case. Nếu bạn ước lượng Effort quá thấp, item sẽ leo lên top RICE một cách sai lệch (vì Effort ở mẫu số), team nhận việc rồi vỡ kế hoạch sprint. Vai trò của AI ở đây là phơi bày độ phức tạp ẩn để bạn và team cùng nhìn thấy trước khi cam kết.
Ba mức Confidence nên chuẩn hóa trong team
Để chấm Confidence nhất quán giữa các PO, hãy quy ước sẵn: 100% = có dữ liệu thật hoặc đã làm việc tương tự; 80% = có logic vững nhưng vài giả định chưa xác thực; 50% = phần lớn là phỏng đoán, chưa có bằng chứng. Khi cả team dùng chung thang này, điểm RICE giữa các item mới thực sự so sánh được với nhau, và bạn tránh được tình trạng mỗi người hiểu Confidence một kiểu.
Các bước làm
- Với item mơ hồ, chạy prompt bóc tách trước khi hỏi dev để chuẩn bị câu hỏi đúng trọng tâm.
- Mang checklist đầu việc + câu hỏi của AI đến buổi refinement; để dev bổ sung đầu việc AI bỏ sót.
- Lấy Effort từ dev (person-week, gồm cả design/QA/bảo mật), không lấy từ AI.
- Chấm Confidence theo thang chuẩn của team: mỗi giả định chưa xác thực → giảm một bậc (10–20%).
- Áp quy tắc: Confidence < 50% thì KHÔNG đưa vào sprint tới — đi làm spike/nghiên cứu nhỏ để nâng độ tin cậy trước.
- Ghi lại rủi ro ẩn mà AI cảnh báo vào ghi chú item để lần lập kế hoạch sau không quên.
Template: Bảng Effort & Confidence
Item: ______
Đầu việc: [ ]design [ ]BE [ ]FE [ ]QA [ ]bảo mật [ ]migration [ ]khác
Effort dev cung cấp (person-week): ____
Rủi ro ẩn AI cảnh báo: ____
Confidence %: ____ | Giảm vì: ____
Quyết định: đưa vào sprint / cần spike trước
Sai lầm thường gặp
- Để AI đưa con số person-week. Nó sẽ bịa vì không biết team bạn — đây là ảo giác nguy hiểm nhất trong Effort. Chỉ dùng AI để bóc tách và cảnh báo rủi ro.
- Confidence luôn để 100%. Làm vậy triệt tiêu tác dụng của biến này; item mơ hồ sẽ leo lên top sai.
- Quên các đầu việc phi-code (design, QA, compliance) → Effort thấp giả tạo.
- Phụ thuộc quá mức: Dùng effort của AI mà bỏ qua dev sẽ phá vỡ niềm tin của team và cho ra số sai. AI là công cụ chuẩn bị câu hỏi, dev mới là nguồn effort.
- Rò rỉ dữ liệu: Không dán sơ đồ kiến trúc nội bộ hay chi tiết bảo mật vào AI công cộng.