# 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:

1. Bảng tự chấm G1 toàn ✅
2. PO đã điền `Approved by` vào header `BRIEF`
3. 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`