sys-analysis-design/.claude/skills/ba-5-post-release/SKILL.md

name, description

name

description

ba-5-post-release

Giai đoạn 5 của quy trình BA — sau khi phát hành. Dùng để viết release note nghiệp vụ cho người dùng, soạn tài liệu hướng dẫn sử dụng và nội dung đào tạo, thu thập và phân loại phản hồi người dùng, đo KPI thực tế so với baseline đã ghi ở giai đoạn 1, rút bài học và đề xuất vòng cải tiến tiếp theo. Kích hoạt khi người dùng nói "viết release note", "tài liệu hướng dẫn sử dụng", "user manual", "đào tạo người dùng", "đo hiệu quả sau release", "KPI có đạt không", "benefit review", "thu thập feedback", "bài học dự án", "retrospective nghiệp vụ". Output vào ba-output/<PROJECT>/05-post-release/, kết thúc bằng Gate G5.

GĐ5 · POST-RELEASE — Bàn giao & đo hiệu quả

Mục tiêu: trả lời câu hỏi "làm xong rồi, có đạt được điều đã hứa không?" và biến câu trả lời thành đầu vào cho vòng sau.

Đây là giai đoạn bị bỏ nhiều nhất — release xong là team chuyển sang việc khác. Hậu quả: không ai biết dự án có đáng tiền không, và cùng một sai lầm lặp lại ở dự án sau.

Output: RELNOTE · MANUAL · BENEFIT trong ba-output/<PROJECT>/05-post-release/

Bốn nguyên tắc bất di bất dịch

1. Không bịa số liệu — không đo được ⇒ ghi rõ không đo được và vì sao, không ước lượng một con số đẹp.
2. Không quyết định thay PO — đề xuất vòng sau là đề xuất, PO chốt.
3. Mọi phát biểu truy vết được — mỗi con số KPI phải có nguồn và cách tính.
4. Không ghi đè tài liệu đã qua gate.

🔴 Nguyên tắc riêng: báo cáo trung thực kể cả khi kết quả xấu. BENEFIT 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.

Bước 0 — Chốt input rồi dừng lại

Chưa được ghi file. Làm sáu việc rồi dừng chờ trả lời:

1. Profile — đọc 00-index/PROFILE_<PROJECT>.md. Nó quyết định MANUAL viết cho ai: screen → người dùng cuối · api-service → tài liệu tích hợp cho dev · data-pipeline → từ điển dữ liệu + hướng dẫn đọc số · batch-job → sổ tay vận hành · ml-model → hướng dẫn diễn giải kết quả. RIGOR = light ⇒ được bỏ MANUAL nếu người dùng là chính nhóm làm, nhưng vẫn phải có RELNOTE.
2. Input dùng được — bảng File | Vai trò | Version. Bắt buộc tìm: BRIEF (để lấy GOAL-nn và baseline), UAT (kết quả nghiệm thu, danh sách "hiểu nhầm cách dùng"), QLOG + CR (để rút bài học).
3. Đã release chưa, ngày nào — mốc này quyết định cửa sổ đo KPI.
4. Việc cần làm lần này — RELNOTE? MANUAL? BENEFIT? Ba việc này thường ở ba thời điểm khác nhau (xem bảng dưới).
5. Có baseline không — mở BRIEF §4 kiểm tra. Không có baseline ⇒ nói thẳng ngay từ Bước 0, đừng để tới cuối mới phát hiện không so sánh được.
6. Hỏi xác nhận năm điểm trên.

Ví dụ minh hoạ nhiều domain: examples.md.

Ba việc, ba thời điểm:

Việc	Làm khi nào
RELNOTE	Trước hoặc ngay ngày go-live
MANUAL + đào tạo	Trước go-live 1–2 tuần
BENEFIT	Sau go-live đủ lâu để KPI ổn định — thường 1–3 tháng

Bỏ qua khi lệnh có go.

Thực hiện — 5 bước

Bước 1 — Release note nghiệp vụ

Dùng templates/release-note.md.

🔴 Đây không phải changelog kỹ thuật. Người đọc là người tiêu thụ sản phẩm — với screen là người dùng cuối, với api-service là team tích hợp, với data-pipeline là người đọc báo cáo, với batch-job là người vận hành. Viết bằng ngôn ngữ công việc của họ, không phải ngôn ngữ triển khai. Bốn cặp ví dụ ❌/✅: examples.md.

Bốn mục bắt buộc:

1. Có gì mới — theo công việc của người dùng, không theo màn hình
2. Có gì thay đổi so với cách làm cũ — phần quan trọng nhất, vì đây là chỗ gây bối rối
3. Cần làm gì — người dùng phải hành động gì (đổi thói quen? nhập bổ sung dữ liệu?)
4. Chưa có gì — hạn chế đã biết, cách xử lý tạm, dự kiến khi nào có

Mục 4 hay bị bỏ vì "không hay ho". Nhưng người dùng phát hiện hạn chế mà không được báo trước sẽ mất niềm tin vào toàn bộ hệ thống, không chỉ vào tính năng đó.

Bước 2 — Tài liệu hướng dẫn & đào tạo

Dùng templates/user-manual.md.

Viết theo công việc, không theo màn hình. Người dùng tìm "làm sao để đối soát ngày hôm qua", không tìm "màn hình SCR-01".

Nguồn nội dung có sẵn, dùng lại thay vì viết mới:

Nguồn	Dùng cho phần nào
PROCESS TO-BE	Cấu trúc chương mục theo luồng công việc
UAT §B3 quan sát	Chính xác chỗ người dùng loay hoay ⇒ phần cần hướng dẫn kỹ
UAT §B2 "hiểu nhầm cách dùng"	Danh sách câu hỏi thường gặp, viết sẵn câu trả lời
SRS bảng mã lỗi	Mục "gặp lỗi này thì làm gì"

🔴 Mục "hiểu nhầm cách dùng" từ UAT là vàng. Đó là danh sách chỗ người dùng thật sự vấp phải, đã được kiểm chứng — không phải phỏng đoán của người viết tài liệu.

Với mỗi thao tác: bối cảnh (khi nào dùng) · các bước · ảnh chụp · kết quả mong đợi · lỗi thường gặp. Bỏ ảnh chụp thì tài liệu gần như vô dụng với người dùng không rành máy tính.

Bước 3 — Thu thập phản hồi

Ba nguồn, giá trị khác nhau:

Nguồn	Ưu	Nhược	Cách lấy
Số liệu sử dụng thật	Không nói dối	Không giải thích được vì sao	Log, số lượt dùng chức năng
Phản hồi chủ động	Chi tiết, có ngữ cảnh	Thiên lệch về người bức xúc	Khảo sát, phỏng vấn
Ticket hỗ trợ / CS	Vấn đề thật, có mức độ	Chỉ thấy phần nổi	Hệ thống ticket

Đối chiếu ba nguồn là chỗ ra phát hiện: chức năng ai cũng khen nhưng log cho thấy gần như không ai dùng — đó là thông tin quan trọng hơn cả hai nguồn riêng lẻ.

Phân loại phản hồi thành bốn nhóm, mỗi nhóm đi một đường:

Nhóm	Đ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 bổ sung đào tạo
Hiểu nhầm	Bổ sung tài liệu/đào tạo

Bước 4 — Đo KPI so với baseline

Dùng templates/benefit-review.md. Đây là mục đích tồn tại của giai đoạn này.

Với mỗi GOAL-nn trong BRIEF:

GOAL	Baseline (GĐ1)	Mục tiêu	Thực tế	Đạt?	Nguồn số liệu	Cách tính

Ví dụ một GOAL đạt chuẩn và một GOAL không đo được: examples.md.

Bốn quy tắc đo:

1. Đo cùng cách với lúc lấy baseline. Đổi cách đo thì con số không so sánh được, và việc đổi cách đo giữa chừng là cách phổ biến để một kết quả xấu trông đẹp lên.
2. Đo sau khi hệ thống ổn định. Tuần đầu sau go-live luôn nhiễu (người dùng đang học, dữ liệu đang chuyển). Chờ ít nhất 1 tháng, tốt nhất 3 tháng.
3. Ghi rõ yếu tố nhiễu. Cùng lúc đó có thay đổi gì khác không (thêm người, đổi quy trình, mùa cao điểm)? Không có yếu tố nhiễu là chuyện hiếm.
4. Không đo được thì ghi là không đo được. Kèm lý do và cách khắc phục cho lần sau.

🔴 Không có baseline ⇒ ghi nhận đây là bài học của GĐ1, đừng lấp liếm. Có thể ước lượng ngược baseline từ log/số liệu cũ nếu còn, nhưng phải ghi rõ là ước lượng ngược và kém tin cậy.

Bước 5 — Bài học và đề xuất vòng sau

Bài học — rà bốn nguồn dữ liệu có sẵn, không ngồi nhớ lại:

Nguồn	Rút ra được gì
QLOG thống kê loại câu hỏi	Loại 2 nhiều ⇒ viết mơ hồ · loại 3 nhiều ⇒ đặc tả thiếu phạm vi · loại 4 nhiều ⇒ GĐ2 hiểu sai nghiệp vụ
CR — số spec gap	Chỗ nào của đặc tả hay bỏ sót
QLOG câu hỏi lặp lại	Mục tài liệu nào khó tra cứu
UAT "hiểu nhầm cách dùng"	Thiết kế hoặc đào tạo chưa đủ

Viết bài học theo mẫu: 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; nó phải cụ thể tới mức lần sau đọc là biết sửa chỗ nào trong quy trình. Bốn bài học đạt chuẩn: examples.md.

Đề xuất vòng sau — mỗi đề xuất phải có: vấn đề nó giải quyết · bằng chứng từ dữ liệu ở Bước 3/4 · ước lượng sơ bộ · lợi ích kỳ vọng. Đề xuất không có bằng chứng là ý kiến cá nhân.

Trước khi kết thúc

In bốn thứ:

① Bảng KPI — GOAL × baseline × mục tiêu × thực tế × đạt/không, kèm yếu tố nhiễu.

② Bảng tự chấm Gate G5 dạng ☐/✅.

③ Bài học — bảng quan sát → nguyên nhân → lần sau làm khác thế nào.

④ Đề xuất vòng sau — đã xếp theo giá trị/chi phí, kèm khuyến nghị của BA.

Bẫy thường gặp

Bỏ hẳn giai đoạn này. Phổ biến nhất. Hậu quả: không ai biết dự án có đáng tiền không, và cùng một sai lầm lặp lại ở dự án sau. Nếu thật sự không có thời gian, tối thiểu làm Bước 4 (đo KPI) và Bước 5 (bài học) — hai bước này rẻ nhất và có giá trị lâu nhất.

Release note viết như changelog kỹ thuật. Người dùng không quan tâm endpoint nào được thêm. Họ quan tâm việc của họ thay đổi thế nào.

Tài liệu hướng dẫn viết theo màn hình. Người dùng tìm theo công việc, không theo tên màn hình. Mục lục theo màn hình là mục lục không ai tra được.

Đo KPI quá sớm. Tuần đầu sau go-live luôn xấu vì người dùng đang học. Đo lúc đó rồi kết luận thất bại là kết luận sai.

Đổi cách đo giữa chừng. Nếu baseline đo bằng cách A thì thực tế cũng phải đo bằng cách A. Đổi sang cách B "chính xác hơn" làm mất khả năng so sánh — và thường xảy ra đúng lúc kết quả không đẹp.

Báo cáo toàn màu xanh. Không ai tin, và không ai học được gì. BENEFIT viết để học.

Bài học viết chung chung. "Cần giao tiếp tốt hơn" không dùng được. Bài học phải cụ thể tới mức lần sau đọc là biết làm khác chỗ nào.