# Skill: Xử lý và Thiết kế Q&A (Q&A Specification) - Phiên bản v1

## 1. Mục đích (Purpose)
Kỹ năng này giúp BA thiết kế các câu hỏi rõ ràng, khách quan và chuyên nghiệp để gửi tới khách hàng/stakeholders nhằm làm rõ các khoảng trống nghiệp vụ (Gaps). Đồng thời, hướng dẫn cách tiếp nhận câu trả lời để cập nhật tài liệu phân tích một cách nhất quán, tránh hiểu sai hoặc tự ý giả định thông tin.

Ngôn ngữ output: auto-detect theo ngôn ngữ của ticket/task input — xem `custom/rules/output-language.md` (input tiếng Việt → output tiếng Việt; ngược lại mặc định tiếng Anh).

## 2. Kiến thức cần có (Prerequisite Knowledge)
- **Kỹ năng giao tiếp bằng văn bản (Written Communication):** Sử dụng câu từ ngắn gọn, lịch sự, đi thẳng vào vấn đề.
- **Kỹ thuật đặt câu hỏi mở và đóng:**
    - Tránh câu hỏi mập mờ (ví dụ: "Hệ thống có cần khóa tài khoản không?").
    - Nên đưa ra các tùy chọn rõ ràng (ví dụ: "Khi nhập sai mật khẩu liên tiếp, hệ thống sẽ xử lý thế nào? Tùy chọn A: Khóa tài khoản sau 5 lần sai trong 30 phút. Tùy chọn B: Chỉ hiển thị thông báo lỗi mà không khóa tài khoản. Tùy chọn C: Ý kiến khác...").
- **Tư duy kiểm thử (Testing Mindset):** Đứng dưới góc nhìn của Tester để hỏi về các biên dữ liệu, các trường hợp lỗi mạng, mất kết nối cơ sở dữ liệu, hoặc dữ liệu không hợp lệ.

## 3. Quy trình thực hiện (Step-by-step Process)
- **Bước 1: Chuyển đổi Gap thành câu hỏi Q&A:**
  Từ danh sách khoảng trống phát hiện ở bước Phân tích ban đầu, chuyển mỗi dòng thành một câu hỏi Q&A cụ thể. Số lượng câu hỏi phải phản ánh đúng số Gap thực tế — không tự giới hạn theo một số cố định (ví dụ luôn dừng ở 5-6 câu) bất kể yêu cầu đơn giản hay phức tạp. Nếu phát sinh Gap mới trong lúc soạn câu hỏi (đọc kỹ hơn thấy còn điểm mơ hồ), bổ sung ngay câu hỏi mới, không bỏ qua để "gọn danh sách".
- **Bước 2: Gắn nhãn mức độ ảnh hưởng (Blocking/Non-blocking):**
  Trước khi chuẩn hóa câu hỏi, gắn nhãn:
  - 🔴 **Blocking** — ảnh hưởng cấu trúc dữ liệu, luồng chính (happy path), phân quyền/bảo mật, hoặc quyết định kiến trúc khó đảo ngược sau khi code.
  - 🟡 **Non-blocking** — chi tiết UI/text, giá trị mặc định có thể đổi sau, alternative/exception flow hiếm gặp.
  Nhãn này quyết định câu hỏi có bắt buộc phải Confirmed trước khi qua gate tiếp theo hay được phép defer.
- **Bước 3: Chuẩn hóa câu hỏi theo mẫu `@skill-ba-qna-template-v1.md`:**
  - Xác định phân vùng nghiệp vụ (Module/Screen).
  - Trích dẫn yêu cầu hiện tại (Current Status/Requirement).
  - Nêu rõ vấn đề mơ hồ.
  - Đưa ra các giải pháp đề xuất (Options) cùng giả định của BA.
  - Điền cột Mức độ ảnh hưởng (🔴 Blocking / 🟡 Non-blocking) đã gắn ở Bước 2.
- **Bước 4: Nhận phản hồi và Cập nhật (Process Responses):**
  - Khi nhận được câu trả lời: Đọc kỹ để đảm bảo câu trả lời đã giải quyết triệt để câu hỏi.
  - Ghi nhận đầy đủ 3 cột theo dõi phản hồi cho mỗi câu đã trả lời:
    - **Người trả lời** — mặc định tự lấy từ `git config user.email` (chạy `git config user.email`, fallback `git config user.name` nếu email trống) của người đang thao tác trong phiên hiện tại; nếu BA chỉ định rõ người trả lời khác (ví dụ trả lời hộ khách hàng, hoặc người phản hồi không phải chính người đang chat) thì dùng giá trị BA nhập, không tự lấy git config.
    - **Ngày trả lời** — tự động lấy theo ngày giờ hệ thống hiện tại (không hỏi lại BA), định dạng `dd/mm/yyyy`.
    - **Nguồn** — luôn hỏi BA nhập tay (ví dụ: "Khách hàng", "Nội bộ team", "Team Marketing", "Team Dev"...); không tự suy đoán hoặc đặt giá trị mặc định.
    Câu hỏi còn **Open** để trống cả 3 cột này (`—`).
  - Đã rõ ràng → đánh dấu **Confirmed**, cập nhật thông tin đó trực tiếp vào tài liệu phân tích hiện tại, xóa marker `[PENDING - QA-ID]` liên quan nếu có.
  - Chưa rõ ràng / khách hàng chưa trả lời được ngay:
    - 🟡 Non-blocking → giữ **Open** (deferred), tiếp tục các câu khác/gate tiếp theo bình thường, ghi marker `[PENDING - QA-ID]` tại vị trí nội dung liên quan trong tài liệu.
    - 🔴 Blocking → giữ **Open** nhưng cảnh báo rõ cho BA lý do đây là blocking và hệ quả nếu bỏ qua trước khi cho phép gate tiếp theo tiến hành; không tự hạ nhãn xuống Non-blocking để né cảnh báo.
  - Ghi nhận lịch sử thay đổi để Dev/Test nắm được lý do thay đổi logic.

## 4. Checklist kiểm tra (Checklist for Verification)
- [ ] Mỗi câu hỏi có chỉ rõ phần màn hình/tính năng liên quan không?
- [ ] Câu hỏi có sử dụng từ ngữ trung lập, không mang tính áp đặt ý kiến chủ quan của BA không?
- [ ] Có đưa ra các phương án gợi ý (Option A, Option B...) cho các vấn đề phức tạp để khách hàng dễ lựa chọn không?
- [ ] Các thuật ngữ viết tắt trong câu hỏi có được giải thích rõ không?
- [ ] Mỗi câu hỏi đã có nhãn Mức độ ảnh hưởng (🔴 Blocking / 🟡 Non-blocking) chưa?
- [ ] Số lượng câu hỏi có phản ánh đúng độ phức tạp thực tế của yêu cầu, không bị gò về một số cố định không?
- [ ] Đã cập nhật đúng và đầy đủ tất cả câu trả lời của khách hàng vào tài liệu phân tích chưa? (Không bỏ sót bất kỳ điểm chốt nào).
- [ ] Mỗi câu hỏi **Confirmed** đã điền đủ Người trả lời, Ngày trả lời, Nguồn chưa?
- [ ] Mọi nội dung phụ thuộc câu hỏi còn Open đã có marker `[PENDING - QA-ID]` tại đúng vị trí, chưa bị tự suy diễn để lấp đầy?

## 5. Output mong đợi (Expected Output)
- File danh sách câu hỏi Q&A định dạng markdown, cấu trúc thống nhất dựa theo `@skill-ba-qna-template-v1.md`, đặt tên theo chuẩn: `QnA-Log_v(m).md` trong thư mục `02.BA-Specs/02.QnA/[functionId]/`.
- Tài liệu phân tích được cập nhật tương ứng với phiên bản mới tăng dần `(n+1)`.