Hướng dẫn sử dụng — `ba-1-discovery` (Giai đoạn 1)

Giai đoạn này giải quyết gì

Đầu vào là một câu mơ hồ kiểu "khách muốn làm màn hình quản lý đối soát". Đầu ra là một bài toán phát biểu được, có chủ, có cách đo thành công, có danh sách yêu cầu mức nghiệp vụ đã xếp ưu tiên.

Không làm ở giai đoạn này: vẽ màn hình, chọn công nghệ, viết user story chi tiết, ước lượng công sức. Thấy mình đang làm mấy thứ đó ⇒ đã trượt sang GĐ2/GĐ3.

Khi nào gọi

Tình huống	Có nên gọi
Nhận module hoàn toàn mới	✅ Chạy đầy đủ
Enhancement trên module đã có	✅ Chạy rút gọn — chỉ `RQ` + rủi ro, bỏ `BRIEF` đầy đủ
Sửa lỗi nghiệp vụ nhỏ	❌ Sang thẳng `ba-3-specification`
Sắp họp với khách, cần bộ câu hỏi	✅ Gọi và nói rõ "chỉ cần bộ câu hỏi cho buổi họp"
Đã có SRS rồi, chỉ muốn bổ sung KPI	✅ Gọi rút gọn, nói rõ chỉ cần mục 4 của BRIEF

Cú pháp

/ba-1-discovery <PROJECT|US-id> [--mode new|enhancement] [--out <đường-dẫn>] [go]

Tham số	Ý nghĩa
`--mode new`	Module mới — chạy đủ 6 bước (mặc định khi không đoán được)
`--mode enhancement`	Chỉ chạy Bước 1 (rà stakeholder bị ảnh hưởng), Bước 4 (`RQ`), Bước 6 (rủi ro)
`go`	Bỏ bước dừng xác nhận input

Kèm file input bằng cách đính kèm trong hội thoại hoặc ghi đường dẫn:

/ba-1-discovery Settlement — input: d:/Kakao/Docs/yeu-cau-khach.docx, biên bản họp 2026-08-22

Chuẩn bị gì trước khi gọi

Tối thiểu (không có thì skill vẫn chạy nhưng sẽ sinh nhiều OQ):

Câu mô tả yêu cầu ban đầu, dù mơ hồ
Tên người có thể trả lời câu hỏi nghiệp vụ

Nên có (chất lượng output tăng rõ rệt):

Biên bản/email trao đổi với khách
Ảnh chụp màn hình hoặc file Excel người dùng đang dùng thủ công
Số liệu hiện trạng: bao nhiêu giao dịch/ngày, bao nhiêu người thao tác

Quy trình 6 bước — bạn tham gia ở đâu

Bước	Skill làm	Bạn làm
1. Stakeholder	Sinh khung, gợi ý nhóm hay bị sót	Điền tên thật, xác nhận ai ký được
2. Chuẩn bị khai thác	Sinh bộ câu hỏi theo vai trò	Duyệt, cắt bớt, gửi trước cho khách
3. Khai thác	Sinh mẫu biên bản	Đi họp và ghi — skill không họp thay bạn
4. Chưng cất `RQ`	Chuyển phát ngôn → RQ, gắn MoSCoW	Xác nhận MoSCoW với PO
5. Mục tiêu & phạm vi	Viết `BRIEF`, đòi baseline	Cung cấp/đi hỏi baseline
6. Rủi ro & giả định	Rà 4 chỗ giả định, 6 loại rủi ro	Chỉ định người chịu trách nhiệm

🔴 Bước 3 là bước skill không làm thay được. Nó chuẩn bị câu hỏi và mẫu biên bản; việc ngồi nghe khách nói là của bạn. Đưa biên bản thô vào, skill sẽ chưng cất thành RQ.

Bạn sẽ nhận được gì

Bốn file trong ba-output/<PROJECT>/01-discovery/:

BRIEF_<PROJECT>_v1.0.md           ← tài liệu chính, PO ký cái này
STAKEHOLDER_<PROJECT>_v1.0.md
ELICITATION_<chủ đề>_<ngày>.md    ← mỗi buổi một file
RISK_<PROJECT>_v1.0.md

Cộng với ba bảng tự chấm in ra màn hình: Gate G1 · quy tắc viết W1–W13 · danh sách OQ mở.

Ví dụ hội thoại

Bạn:    /ba-1-discovery Settlement
        Khách bảo cần màn hình đối soát doanh thu POS với hệ thống.
        Đính kèm: bien-ban-hop-2026-08-22.md

Claude: [Bước 0]
        Input dùng được:
        | bien-ban-hop-2026-08-22.md | Biên bản họp khởi động | Cao |
        | ba-output/Settlement/ | Chưa tồn tại | — |

        Phân loại: module MỚI (chưa thấy artifact nào của Settlement).

        Người cần tiếp cận — tôi suy ra từ biên bản, xác nhận giúp:
        - Người quyết định: chị Lan (Trưởng phòng Tài chính)?
        - Người sử dụng: nhân viên đối soát — chưa biết tên
        - Bị ảnh hưởng: cửa hàng/POS operator — chưa xác nhận
        - Cung cấp thông tin: ai quản trị hệ thống POS?

        Cách hiểu: bài toán gốc là phát hiện chênh lệch muộn (cuối tháng), không phải
        "thiếu một màn hình". Tôi sẽ viết BRIEF theo hướng đó.

        Ghi vào ba-output/Settlement/01-discovery/. Xác nhận giúp tôi 4 điểm trên.

Bạn:    Đúng rồi. Người dùng là anh Sơn + 2 bạn. POS do bên NCC X vận hành, đầu mối anh Huy.

Claude: [sinh STAKEHOLDER + bộ câu hỏi cho từng người + khung BRIEF với các OQ]

Lỗi thường gặp

"Skill viết BRIEF toàn OQ, gần như trống." Đúng như thiết kế. Chưa đi hỏi khách thì chưa có thông tin, và quy tắc số 1 là không bịa. Danh sách OQ chính là danh sách việc bạn cần đi hỏi. Hỏi xong đưa biên bản vào, chạy lại.

"Khách đã nói rõ muốn gì rồi, sao còn phải phát biểu bài toán?" Vì thứ khách nói thường là giải pháp, không phải vấn đề. "Cần nút export" → hỏi "xuất ra để làm gì" → hoá ra để gửi kế toán đối chiếu → hoá ra vấn đề thật là hai hệ thống không khớp số. Giải pháp đúng có thể không phải nút export.

"Không lấy được baseline, khách không có số." Đừng bỏ trống. Ghi OQ + đề xuất cách đo: bấm giờ 3 ngày, đếm số ca lỗi tháng trước, hoặc lấy log hệ thống cũ. Baseline ước lượng có ghi rõ cách ước lượng vẫn tốt hơn không có gì.

"Must chiếm 90% danh sách RQ." Việc phân loại chưa xảy ra. Hỏi PO đúng một câu: "Nếu chỉ kịp một nửa thì cắt cái nào?" — câu này ép ra thứ tự thật.

"Có hai bên nói ngược nhau, tôi chọn bên nào?" Không chọn. Ghi cả hai vào mục 6 của STAKEHOLDER, tạo OQ, đưa PO quyết. BA tự chọn là vi phạm nguyên tắc 2 và là nguồn gốc của CR ở UAT.

Ra khỏi giai đoạn này khi nào

Đủ cả ba:

Bảng tự chấm G1 toàn ✅
PO đã điền Approved by vào header BRIEF
Không còn OQ nào chặn việc phân rã user story

Rồi chạy /ba-2-analysis <PROJECT>.

Liên quan

Tiêu chí gate G1: ../ba-lifecycle/references/workflow.md §2
Quy tắc viết: ../ba-lifecycle/references/writing-rules.md
Template: templates/project-brief.md · templates/stakeholder-map.md · templates/elicitation-guide.md · templates/risk-register.md

6.9 KiB Raw Blame History Unescape Escape

Hướng dẫn sử dụng — ba-1-discovery (Giai đoạn 1)