Report: Đánh giá skill ba-qna-generator dựa trên tư duy BA thật

Ngày: 2026-08-17 Người review: AI (theo yêu cầu BA) Nguồn phân tích: Toàn bộ file trong References/QnA from clients/ (10 category folder, ~30 file, bao gồm STAGE1 Checkout/Onboarding, STAGE2 Dashboard/Failure & Recovery/Community/Settings/Founding Mentor, STAGE3 KYC, STAGE4 Live Trading, STAGE5 Payout, STAGE6 Career, Authentication) + .agent/skills/ba-qna-generator/SKILL.md + references/example-output.md Mục tiêu: Tìm gap giữa "lý thuyết" skill mô tả và cách BA thật (Huyen/Hexie) thực sự đặt câu hỏi cho khách (Adrian Stack, Adam) — từ đó đề xuất hướng update skill.

---

Kết luận nhanh (executive summary)

Skill hiện tại được thiết kế theo tư duy "audit gap kỹ thuật rồi generate câu hỏi kiểu checklist 1-hàng-1-câu, có priority tag, có glossary cho non-technical client, có 'alternatives considered'". Thực tế BA làm khác ở gần như mọi điểm đó:

• Khách hàng (Adrian, Adam) là người kỹ thuật — tự viết SQL, tự sửa formula, dùng đúng thuật ngữ DB. Glossary "giải thích cho CEO không biết code" là dư và có thể gây phản cảm.
• BA thật không hỏi 1 câu rời rạc — họ elaborate toàn bộ flow/logic thành đề xuất cụ thể (có số, có field, có bước) rồi hỏi "đúng không?", và gộp nhiều sub-question (1)(2)(3)... hoặc (a)(b)(c)... vào cùng 1 lượt hỏi theo mạch 1 flow, không tách thành nhiều ID độc lập như bảng Q&A skill hiện tại yêu cầu.
• Priority tag (🔴🟠🟡⚪) và "Alternatives considered: Option B/C" không tồn tại trong raw Q&A gửi khách — đây là artifact nội bộ (BA tự phân loại sau), không phải thứ khách nhìn thấy.
• BA thật hay cross-reference lại chính câu trả lời cũ của khách bằng ID (STAGE2-005, FR-01, QN-AUTH-...) để giữ nhất quán và tránh hỏi lại — skill có nhắc "check đã trả lời chưa" nhưng không có cơ chế active-supersede khi 1 câu trả lời cũ bị khách tự sửa lại sau.
• BA thật thường tự đề xuất field/table mới hoàn toàn không có trong spec gốc (không phải chỉ là "gap kỹ thuật của spec đã có") — và khách approve nguyên văn. Skill hiện tại giới hạn phạm vi vào "gap trong requirement đưa vào", chưa khuyến khích việc này.

---

A. Pattern tư duy đặt câu hỏi của BA thật (quan sát từ nguồn)

A1. Propose-full-flow-then-confirm (đề xuất trọn logic rồi hỏi đúng/sai)

BA không hỏi "nên làm thế nào" — họ tự viết ra flow đầy đủ, kèm số liệu/field cụ thể, rồi hỏi khách xác nhận hoặc sửa.

"Email 1: Send right after the payment is successful... Email 2: Send after SIM account is created... Is this correct?" — QnA_STAGE1_CHECKOUT_ONBOARDING.md (STAGE1-091)

"Anh đọc giúp 16 bước này và kiểm tra xem có đúng không?" — QnA_STAGE2_SETTINGS_CAREER_VIRAL.md (LUC-BIZ-01)

Hiệu quả vì biến việc "trả lời từ đầu" thành việc "review/sửa" — khách chỉ cần gật hoặc chỉnh 1-2 điểm sai, tốc độ trả lời nhanh hơn nhiều so với hỏi mở.

A2. Bundled sub-questions trong 1 chủ đề (không tách ID rời rạc)

Một lượt hỏi thường gồm nhiều câu (1)(2)(3)... hoặc (a)(b)(c)(d)... đều xoay quanh cùng 1 flow, gửi 1 lần.

STAGE1-050: "(a) Có table riêng cho abandoned checkout không? (b) field lưu step nào? (c) 'Pending Order' có phải 1 status trong DB không? (d) Sau khi user claim lại account, record cũ xử lý thế nào?"

Trong QnA_STAGE2_FAILURE_AND_RECOVERY.md, một lượt hỏi của BA về Flow 7 gồm liền 9 câu (1..9) từ pricing retrieval, resignation logic, defense eligibility, virtual_equity, Crash Protection, GL Posting, email template, Typeform routing, đến status definition — tất cả trong 1 message.

A3. "Vì sao dùng field X mà không dùng field Y" — truy vấn rationale để lộ lỗi

Không hỏi field là gì, mà hỏi tại sao chọn field đó — cách này thường lộ ra lỗi logic có sẵn.

FR-17 (Failure and Recovery): BA hỏi tại sao check is_professional mà không dùng Status = "Active_DMA" — khách xác nhận lý do (Active_DMA đã đổi trạng thái tại thời điểm check nên không dùng được), phát hiện đúng edge-case logic timing.

A4. Cross-reference ID cũ để bắt xung đột tên field/khái niệm

BA đối chiếu nhiều nguồn/câu trả lời trước để bắt naming inconsistency, rồi đề xuất 1 tên chuẩn.

STAGE1-090: phát hiện Active_SIM vs Active_Challenge dùng lẫn lộn giữa 2 tài liệu → Adam: "good catch. Let's use Active_SIM." QN-AUTH-001: "BR-06 nói max 3 lần, nhưng SR-01/SR-02/BR-07 nói 5 lần. Cái nào đúng?"

A5. Đề xuất field/table hoàn toàn mới, suy từ nghiệp vụ (không chỉ từ gap kỹ thuật của spec đưa vào)

BA tự suy luận ra nhu cầu nghiệp vụ chưa được đề cập ở đâu cả, đề xuất thẳng schema mới.

STAGE1-081: BA đề xuất thêm field max_uses_per_user (NULL = unlimited) cho voucher — không có trong bất kỳ source nào, được approve nguyên văn. STAGE1-053/057: BA đề xuất 5 cột billing/IP mới vào bảng Users.

A6. Race condition kèm số liệu cụ thể, không hỏi khái niệm chung

"2 users cùng click purchase khi founder_count = 499, cả 2 đều thấy 'còn 1 slot' — ai nhận slot cuối?" — STAGE1-005

A7. Hỏi rõ nhánh ELSE / trường hợp không được nhắc tới

"GET /public/platform-options trả về empty array — UI xử lý thế nào?" — STAGE1-011

A8. Tự tính formula, mời khách chỉ sửa lỗi thay vì hỏi công thức từ đầu

FR-33: BA tự tính sẵn Floor(50,000 × 0.25, 100) = 12,500 — khách chỉ cần sửa đúng 2 lỗi toán học nhỏ, còn lại confirm nguyên.

A9. Khách tự override giả định cũ của BA bằng cách dẫn nguồn mới hơn

FR-30: BA giả định threshold "Level 3+", khách: "Severance giờ bắt đầu từ Level 7, đã update 2 tuần trước trong External User Journey doc." → đây cho thấy nguồn thông tin có thể lỗi thời, BA cần biết field này có thể bị supersede.

A10. Short-answer harvesting — câu hỏi elaborate đủ kỹ để khách chỉ cần "Yes/Sure"

STAGE1-038: "Lưu data ở Step 5 được không?" → "fine." Đây là mục tiêu chiến lược: giảm effort trả lời của khách xuống mức tối thiểu bằng cách BA làm hết phần "nghĩ hộ".

A11. Reject kèm lý do business cụ thể (không chỉ "no")

STAGE1-097: BA đề xuất OTP gate ở Step 5 → Adam: "No! Forcing users to verify email before pay will destroy our conversion rate." — câu trả lời dạy BA 1 business constraint chưa biết (conversion rate), không chỉ từ chối đề xuất.

---

B. Gap cụ thể giữa SKILL.md hiện tại và thực tế

---

C. Đề xuất hướng update SKILL.md (để BA quyết định áp dụng)

Không tự sửa file — chỉ nêu hướng, để BA chốt trước khi tôi động vào skill:

1. Cho phép/khuyến khích bundle sub-question theo flow. Đổi cấu trúc: 1 ID có thể chứa nhiều sub-question (a)(b)(c) nếu chúng cùng thuộc 1 flow/1 step-cluster — giống cách STAGE1-050, Flow 7 (Failure and Recovery) làm. Bảng Q&A vẫn giữ 1 row/1 ID nhưng cột Question cho phép multi-part.

2. Bỏ mandatory glossary, chuyển thành optional theo mức độ jargon. Chỉ thêm glossary khi thuật ngữ thực sự hiếm gặp ngay cả với dev (ví dụ tên riêng của platform), không áp dụng glossary cho DB/cron/webhook — vì khách đã là technical stakeholder.

3. Bỏ "Alternatives considered (Option B/C)" mandatory, thay bằng: đưa 1 đề xuất elaborate đầy đủ (giống pattern A1/A8) — nếu BA cảm thấy có 2 hướng ngang nhau thật, mới liệt kê, không bắt buộc mọi câu.

4. Priority tag chuyển thành optional / chỉ dùng ở bước tổng hợp nội bộ, không phải lúc generate câu hỏi gửi khách — tránh làm raw Q&A trông "official" hơn thực tế và tránh BA phải quyết định priority trước khi biết câu trả lời.

5. Nới "No Fabrication" thành "Proposed New Field/Table" — có đánh dấu riêng. Cho phép BA (qua skill) đề xuất field/table hoàn toàn mới ngoài source, miễn đánh dấu rõ [PROPOSED — not in any source, suy luận từ nghiệp vụ] khác với [ASSUMPTION — điền tạm để không block]. Đây là 2 loại khác nhau: assumption (điền placeholder) vs proposal (đề xuất mở rộng scope).

6. Thêm Layer 6 — "Rationale Check" (tại sao dùng X mà không dùng Y) vào Phase 3, làm rõ mẫu câu: "Requirement dùng field/logic [X] — vì sao không dùng [Y] đã có sẵn/tương đương? Có phải vì [lý do suy luận]?"

7. Thêm hướng dẫn "compute example numbers before asking" cho mọi business rule có formula — tự chạy con số cụ thể (giống FR-33) trước khi hỏi, để khách chỉ cần sửa lỗi tính toán thay vì tự làm từ đầu.

8. Thêm cơ chế Supersede Flag khi cross-check QnA from clients/. Khi 1 QnA cũ có khả năng lỗi thời (được ghi đè bởi CR/QnA mới hơn — xem CLAUDE.md priority chain), skill nên flag rõ: "⚠️ [ID cũ] có thể đã outdated — [ID mới] override ngày [date]" thay vì chỉ im lặng bỏ qua.

9. Giữ nguyên các phần đã đúng: ngôn ngữ song ngữ (Question=EN, Technical Analysis=VI), 5-layer analysis (Source Compliance, Internal Contradiction, Technical Gap, Business Logic Gap, Missing Spec) — cấu trúc này khớp với thực tế BA vẫn cross-check nguồn kỹ (A4) và luôn hỏi nhánh ELSE (A7).

---

Report này chỉ để BA review và quyết định điểm nào áp dụng vào SKILL.md — chưa có thay đổi nào được thực hiện lên skill hiện tại.