BENEFIT — Benefit Realization Review —
|
|
| Version |
1.0 |
| Date |
YYYY-MM-DD |
| Author |
(skill ba-5-post-release) |
| Status |
🟡 Draft |
| Approved by |
PO: — · BA Lead: — |
| Ngày go-live |
|
| Cửa sổ đo |
từ … đến … (sau go-live … tháng) |
| Source |
BRIEF_… v1.0 §4 · UAT_… · QLOG_… · CR_… |
🔴 Tài liệu này viết để học, không phải để khoe. Một báo cáo nói "KPI không đạt vì lý
do X" có giá trị hơn nhiều một báo cáo toàn màu xanh mà không ai tin.
1. Kết luận
|
|
| Số GOAL đạt |
… / … |
| Kết luận tổng thể |
✅ Đạt kỳ vọng / 🟠 Đạt một phần / 🔴 Không đạt / ⏳ Chưa đo được |
| Phát hiện quan trọng nhất |
|
| Đề xuất chính |
|
Viết mục này sau cùng.
2. KPI so với baseline
| GOAL |
Chỉ số |
Baseline (GĐ1) |
Mục tiêu |
Thực tế |
Đạt? |
Nguồn số liệu |
Cách tính |
| GOAL-01 |
|
|
|
|
✅/🟠/🔴/⏳ |
|
|
| GOAL-02 |
|
|
|
|
|
|
|
Bốn quy tắc đo — xác nhận từng cái:
| # |
Quy tắc |
☐/✅ |
Ghi chú |
| 1 |
Đo cùng cách với lúc lấy baseline |
|
Đổi cách đo ⇒ không so sánh được |
| 2 |
Đo sau khi hệ thống ổn định (≥1 tháng, tốt nhất 3 tháng) |
|
Tuần đầu luôn nhiễu |
| 3 |
Đã ghi rõ yếu tố nhiễu |
|
Xem §2.1 |
| 4 |
Không đo được thì ghi là không đo được |
|
Không ước lượng một con số đẹp |
🔴 Quy tắc 1 hay bị vi phạm đúng lúc kết quả không đẹp: người ta đổi sang cách đo "chính xác
hơn". Nếu buộc phải đổi cách đo, trình cả hai con số và giải thích.
2.1 Yếu tố nhiễu
Cùng thời gian đó có thay đổi gì khác không? Không có yếu tố nhiễu là chuyện hiếm.
| # |
Yếu tố |
Ảnh hưởng tới GOAL nào |
Theo hướng nào |
Ước tính mức độ |
| 1 |
(vd: tuyển thêm 2 nhân viên đối soát) |
GOAL-01 |
Làm kết quả đẹp hơn thực chất |
|
| 2 |
(vd: tháng cao điểm, khối lượng gấp đôi) |
GOAL-02 |
Làm kết quả xấu hơn thực chất |
|
2.2 GOAL không đo được
| GOAL |
Vì sao không đo được |
Khắc phục cho lần sau |
|
(vd: GĐ1 không ghi baseline) |
Bắt buộc điền baseline trước khi qua G1 |
🔴 Không có baseline là bài học của GĐ1, không phải lý do để bỏ qua. Có thể ước lượng
ngược từ log/số liệu cũ nếu còn — nhưng phải ghi rõ là ước lượng ngược, độ tin cậy thấp.
3. Mức độ sử dụng thật
Số liệu không nói dối. Đây là phần đối trọng với phản hồi chủ quan ở §4.
| Chức năng |
US |
Số lượt dùng/tháng |
Số người dùng khác nhau |
Kỳ vọng |
Nhận xét |
|
US-011 |
|
|
|
|
Chức năng gần như không ai dùng:
| Chức năng |
Lượt dùng |
Vì sao (giả thuyết) |
Đã xác minh bằng cách nào |
🔴 Chức năng ai cũng khen nhưng log cho thấy không ai dùng là phát hiện quan trọng hơn
cả hai nguồn riêng lẻ. Đối chiếu §3 với §4 để tìm những chỗ như vậy.
4. Phản hồi người dùng
4.1 Nguồn thu thập
| Nguồn |
Số lượng |
Thời gian thu thập |
Độ tin cậy |
| Khảo sát |
|
|
Thiên lệch về người bức xúc |
| Phỏng vấn sâu |
|
|
|
| Ticket hỗ trợ / CS |
|
|
Chỉ thấy phần nổi |
| Số liệu sử dụng |
|
|
Không nói dối, không giải thích được vì sao |
4.2 Phân loại
| Nhóm |
Số lượng |
Ví dụ tiêu biểu |
Đi đâu |
| Lỗi |
|
|
Ticket defect |
| Yêu cầu tính năng mới |
|
|
Backlog vòng sau |
| Khó dùng / không tìm thấy |
|
|
Cải thiện thiết kế hoặc đào tạo |
| Hiểu nhầm |
|
|
Bổ sung tài liệu/đào tạo |
4.3 Đối chiếu ba nguồn
| Phát hiện |
Số liệu nói gì |
Người dùng nói gì |
Ticket nói gì |
Kết luận |
|
|
|
|
|
5. Bài học
Mẫu bắt buộc: quan sát được → nguyên nhân → lần sau làm khác thế nào.
Bài học kiểu "cần giao tiếp tốt hơn" là không dùng được.
5.1 Rút từ dữ liệu có sẵn — không ngồi nhớ lại
| Nguồn |
Số liệu |
Rút ra được gì |
QLOG loại 2 (spec mơ hồ) |
… câu |
Cao ⇒ vi phạm quy tắc W2, cần viết chặt hơn ở mục nào |
QLOG loại 3 (spec không nói) |
… câu |
Cao ⇒ đặc tả thiếu phạm vi, rà lại checklist G3 |
QLOG loại 4 (spec sai) |
… câu |
Cao ⇒ GĐ2 hiểu sai nghiệp vụ |
QLOG câu hỏi lặp lại |
… |
Mục tài liệu nào khó tra cứu |
CR — số spec gap |
… / … CR |
Chỗ nào của đặc tả hay bỏ sót |
UAT "hiểu nhầm cách dùng" |
… |
Thiết kế hoặc đào tạo chưa đủ |
RISK đã xảy ra thật |
… / … |
Rủi ro nào dự đoán đúng, rủi ro nào không lường được |
5.2 Bảng bài học
| # |
Quan sát được |
Nguyên nhân |
Lần sau làm khác thế nào |
Áp dụng ở giai đoạn |
| 1 |
7/12 CR là spec gap về xử lý dữ liệu cũ |
GĐ2 chỉ rà tác động code, không rà dữ liệu lịch sử |
Bắt buộc điền §1.2 của IMPACT với số bản ghi thật, không để "sẽ xử lý sau" |
GĐ2 |
| 2 |
Kế toán phủ quyết ở tuần cuối UAT |
Không có trong stakeholder map từ đầu |
Rà đích danh 3 nhóm hay bị sót ở Bước 1 GĐ1 |
GĐ1 |
5.3 Cái gì đã làm tốt — giữ lại
Bài học không chỉ là danh sách sai lầm. Cái làm tốt mà không ghi lại thì lần sau cũng không lặp lại được.
6. Đề xuất vòng sau
Mỗi đề xuất phải có bằng chứng từ §3/§4. Đề xuất không có bằng chứng là ý kiến cá nhân.
| # |
Đề xuất |
Vấn đề nó giải quyết |
Bằng chứng |
Ước lượng |
Lợi ích kỳ vọng |
Ưu tiên BA đề xuất |
| 1 |
|
|
§4.2: 14 phản hồi cùng nội dung |
|
|
Cao |
Khuyến nghị của BA: …
(Khuyến nghị, không phải quyết định — PO chốt.)
7. Tự chấm Gate G5
| # |
Tiêu chí |
☐/✅ |
Ghi chú |
| 1 |
RELNOTE đã phát hành cho người dùng |
|
|
| 2 |
MANUAL / tài liệu đào tạo đã bàn giao |
|
|
| 3 |
KPI thực tế đã so sánh với baseline và mục tiêu |
|
|
| 4 |
Feedback đã thu thập và phân loại |
|
|
| 5 |
Bài học đã viết theo mẫu quan sát→nguyên nhân→hành động |
|
|
| 6 |
Đề xuất vòng sau đã lập và đưa vào backlog |
|
|
8. Kết thúc hay mở vòng mới
|
|
| Quyết định |
Đóng dự án / Mở vòng cải tiến / Chờ đo lại sau … tháng |
| Người quyết |
|
| Ngày |
|
| Nếu mở vòng mới |
Chạy /ba-1-discovery <PROJECT> — BRIEF phiên bản mới, không sửa đè bản cũ |
