sys-analysis-design/.claude/skills/ba-1-discovery/SKILL.md

name, description

name

description

ba-1-discovery

Giai đoạn 1 của quy trình BA — khai thác và làm rõ yêu cầu. Dùng khi nhận một ý tưởng/module mới còn mơ hồ và cần xác định stakeholder, phát biểu bài toán, mục tiêu kinh doanh kèm KPI, phạm vi in/out, yêu cầu mức nghiệp vụ (RQ), rủi ro và giả định. Kích hoạt khi người dùng nói "khách hàng muốn làm X", "phân tích yêu cầu mới", "chuẩn bị họp với khách", "cần bộ câu hỏi phỏng vấn", "viết project brief", "xác định stakeholder", "làm rõ scope". Output ghi vào ba-output/<PROJECT>/01-discovery/ và phải qua Gate G1 trước khi sang ba-2-analysis.

GĐ1 · DISCOVERY — Khai thác & làm rõ yêu cầu

Mục tiêu duy nhất: chuyển một mong muốn mơ hồ thành một bài toán phát biểu được, có người chịu trách nhiệm, có cách đo thành công. Chưa bàn giải pháp, chưa vẽ màn hình.

Output: BRIEF · STAKEHOLDER · ELICITATION · RISK trong ba-output/<PROJECT>/01-discovery/

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

1. Không bịa yêu cầu — thiếu thông tin ⇒ OQ-nnn, không điền giá trị "hợp lý".
2. Không quyết định thay PO — trình phương án kèm khuyến nghị, PO chốt.
3. Mọi phát biểu phải truy vết được về một stakeholder cụ thể. Không nguồn ⇒ ASM-nn.
4. Không ghi đè tài liệu đã qua gate — sửa qua CR-nnn kèm Change Log.

Nạp thêm: ../ba-lifecycle/references/domain-profiles.md (ba trục quyết định khối lượng công việc) · ../ba-lifecycle/references/writing-rules.md (13 quy tắc W1–W13) · ../ba-lifecycle/references/artifact-map.md §2 (header bắt buộc) · ../ba-lifecycle/references/diagram-rules.md (ranh giới hệ thống, ma trận stakeholder, 5-Why).

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

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ờ người dùng trả lời:

1. Profile — đọc 00-index/PROFILE_<PROJECT>.md. Chưa có ⇒ đây là skill tạo nó: đề xuất PRODUCT · LIFECYCLE · RIGOR kèm lý do, và hỏi xác nhận. Ba trục này quyết định khối lượng của chính lần chạy này.
2. Input dùng được — bảng File/Nguồn | Vai trò | Độ tin cậy. Gồm: file người dùng đưa trong hội thoại (ưu tiên cao nhất), file trong lệnh, và những gì tự tìm thấy trong ba-output/, .docs/, docs/.
3. Khối lượng theo profile — nêu rõ sẽ chạy đủ hay rút gọn: LIFECYCLE = enhancement ⇒ chỉ RQ + rủi ro · RIGOR = light ⇒ bỏ biên bản chính thức, STAKEHOLDER chỉ 2 nhóm, chỉ cần 1 GOAL có baseline (xem workflow.md §2 — G1).
4. Ai là người trả lời được — liệt kê tên/vai trò cần tiếp cận. Chưa biết ⇒ nói rõ.
5. Cách hiểu bài toán — 2–3 câu, kèm tên file định ghi ra.
6. Hỏi người dùng xác nhận năm điểm trên.

Bỏ qua bước dừng khi lệnh có go / chạy luôn — khi đó ghi phần tự đánh giá input vào mục Open Questions của BRIEF.

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

Bước 1 — Stakeholder trước, yêu cầu sau

Làm việc này đầu tiên. Yêu cầu không có chủ là yêu cầu không ai bảo vệ khi cắt scope.

Điền templates/stakeholder-map.md. Bốn nhóm, thiếu nhóm nào cũng là lỗ hổng:

Nhóm	Câu hỏi nhận diện	Rủi ro nếu bỏ sót
Quyết định	Ai ký duyệt? Ai cắt được scope?	Làm xong bị bác
Sử dụng	Ai ngồi trước màn hình mỗi ngày?	Đúng spec nhưng không ai dùng
Bị ảnh hưởng	Quy trình của ai thay đổi? Ai mất/được việc?	Kháng cự lúc go-live
Cung cấp thông tin	Ai biết nghiệp vụ hiện tại? Ai giữ dữ liệu?	Hiểu sai AS-IS

Mỗi stakeholder: STK-nn · tên thật · vai trò · mức quan tâm × mức ảnh hưởng · kênh liên lạc · người thay thế khi vắng.

🔴 Ba nhóm hay bị bỏ sót nhất, phải hỏi đích danh: vận hành/CS (người nhận cuộc gọi khiếu nại), kế toán/đối soát (người chịu hậu quả nếu số liệu sai), bộ phận pháp chế/bảo mật (người có quyền phủ quyết muộn nhất và đau nhất).

Bước 2 — Chuẩn bị khai thác

Sinh bộ câu hỏi từ templates/elicitation-guide.md, cắt theo đúng người sắp gặp — đừng đưa một danh sách 60 câu chung chung.

Chọn kỹ thuật theo tình huống:

Tình huống	Kỹ thuật	Vì sao
Chưa biết gì về nghiệp vụ	Phỏng vấn 1-1 + quan sát tại chỗ	Người ta kể quy trình nên thế, làm mới lộ quy trình thật
Nhiều bên mâu thuẫn	Workshop có facilitator	Bắt mâu thuẫn lộ ra sớm, rẻ hơn lộ ở UAT
Đã có hệ thống cũ	Phân tích tài liệu + soi dữ liệu thật	Dữ liệu không biết nói dối
Đông người dùng cuối	Khảo sát + phỏng vấn sâu vài người	Định lượng rồi mới định tính
Yêu cầu mơ hồ về UX	Prototype thấp + phản ứng	Người ta phê bình giỏi hơn mô tả

Trước buổi làm việc luôn gửi trước agenda + câu hỏi. Người được hỏi cần thời gian tra số liệu; hỏi bất ngờ thì nhận về phỏng đoán.

Bước 3 — Khai thác và ghi biên bản

Ghi vào ELICITATION_<phạm vi>_<ngày>.md. Mỗi buổi một file, không gộp.

Quy tắc ghi biên bản:

• Ghi nguyên văn câu trả lời quan trọng, không diễn giải lại. Diễn giải làm mất sắc thái ("thường thì" ≠ "luôn luôn").
• Tách rõ ba loại phát ngôn: sự thật (đo được) · ý kiến (mong muốn) · giả định (tưởng là thật). Trộn ba thứ này là lỗi kinh điển.
• Câu trả lời mâu thuẫn với buổi khác ⇒ ghi cả hai, đánh dấu ⚠️ mâu thuẫn với STK-03 ngày …, không tự chọn bên nào.
• Kết thúc mỗi buổi: đọc lại tóm tắt cho người được hỏi xác nhận ngay tại chỗ.

Năm câu phải hỏi trong mọi buổi, hỏi nguyên văn:

1. "Hôm nay anh/chị làm việc này thế nào? Cho tôi xem một ca thật được không?"
2. "Chỗ nào mất thời gian nhất / hay sai nhất?"
3. "Trường hợp ngoại lệ nào hay gặp? Lúc đó xử lý sao?"
4. "Nếu hệ thống mới làm được đúng một thứ thôi, anh/chị chọn thứ gì?"
5. "Làm thế nào để biết dự án này thành công?" (đây là nguồn của KPI)

Bước 4 — Chưng cất thành RQ-nnn

Chuyển phát ngôn thành yêu cầu mức nghiệp vụ. Không phải chức năng, không phải màn hình.

RQ-nnn | <ai> phải <đạt được gì>, thay vì <cách làm hiện tại>.
         Nguồn: STK-nn, biên bản <ngày> · MoSCoW: … · Liên quan: GOAL-nn
         Giải pháp khách gợi ý: <nếu có>

Mỗi RQ: phát biểu · nguồn (STK-nn + ngày) · MoSCoW · liên kết GOAL-nn.

Ví dụ ở ba domain khác nhau (bán lẻ, y tế, logistics): examples.md.

Quy tắc MoSCoW: Must là "không có thì bản phát hành này vô nghĩa", không phải "rất quan trọng". Nếu >60% số RQ là Must thì việc phân loại chưa xảy ra — quay lại hỏi PO "nếu chỉ kịp một nửa, cắt cái nào".

🔴 Bẫy giải pháp giả dạng yêu cầu. Thứ khách nói ra thường là giải pháp họ nghĩ ra, không phải vấn đề của họ. Hỏi ngược cho tới khi ra vấn đề gốc: "Cái đó để làm gì? Sau khi có nó thì anh/chị làm gì tiếp?" — câu trả lời mới là RQ.

Ghi giải pháp khách đề xuất vào cột riêng "Giải pháp khách gợi ý": có giá trị tham khảo, nhưng không phải yêu cầu. Rất thường xuyên, giải pháp đúng khác thứ khách yêu cầu và rẻ hơn — ba ca thật ở ba domain: examples.md.

Bước 5 — Mục tiêu, KPI và phạm vi

Điền templates/project-brief.md.

GOAL-nn phải có baseline. Không có số hiện tại thì GĐ5 không đo được gì:

GOAL-nn | <mục tiêu>
          Baseline: <số hiện tại> (<kỳ đo>, nguồn: <ai/đâu>)
          Mục tiêu: <số đích> · Đo bằng: <định nghĩa phép đo>
          Ai đo: <người> · Tần suất: <…>

Chưa có baseline ⇒ ghi OQ và đề xuất cách đo baseline kèm chi phí ước tính, đừng bỏ trống. Baseline ước lượng có ghi rõ cách ước lượng vẫn tốt hơn không có gì — ví dụ cả hai trường hợp: examples.md.

Phạm vi phải viết cả hai vế. Vế "ngoài phạm vi" quan trọng hơn, vì nó chặn tranh cãi sau này. Mỗi mục out-of-scope ghi kèm lý do và "sẽ xử lý ở đâu/khi nào".

Bước 6 — Rủi ro và giả định

Điền templates/risk-register.md.

Giả định ASM-nn — mọi thứ bạn tin là đúng nhưng chưa ai xác nhận. Bắt buộc rà bốn chỗ này, đây là nơi giả định hay ẩn nấp:

• Dữ liệu: "hệ thống cũ có sẵn trường này" — đã mở DB ra xem chưa?
• Tích hợp: "API bên kia trả về realtime" — đã đọc tài liệu của họ chưa?
• Con người: "vận hành sẽ nhập liệu hằng ngày" — đã hỏi vận hành chưa?
• Pháp lý: "được phép lưu thông tin này" — đã hỏi pháp chế chưa?

Mỗi ASM phải có cách xác minh và hệ quả nếu sai. Giả định sai mà hệ quả lớn ⇒ nâng thành RISK và xác minh ngay trong GĐ1, đừng để sang GĐ3.

Trước khi kết thúc

In ba thứ:

① Bảng tự chấm Gate G1 (checklist ở ../ba-lifecycle/references/workflow.md §2) dạng ☐/✅. Mục chưa đạt phải nói rõ thiếu gì — không đánh ✅ cho có.

② Checklist W1–W13 (../ba-lifecycle/references/writing-rules.md) dạng ☐/✅.

③ Danh sách OQ mở kèm người phải trả lời và deadline đề xuất.

Chấm G1 theo đúng RIGOR đã khai — áp bảng "Bớt ở light" / "Thêm ở strict" ở ../ba-lifecycle/references/workflow.md §2, và nói rõ đang chấm ở mức nào.

Rồi nhắc người dùng: G1 cần PO ký (điền Approved by vào header); mức strict cần thêm Bảo mật/Pháp chế. Ký xong mới chạy /ba-2-analysis.

Bẫy thường gặp

Nhảy sang giải pháp quá sớm. Dấu hiệu: trong BRIEF đã xuất hiện tên màn hình, tên nút, tên bảng dữ liệu. GĐ1 chỉ nói vấn đề và kết quả mong muốn. Thấy mình đang vẽ màn hình ⇒ dừng, quay lại hỏi "vấn đề gốc là gì".

Chỉ hỏi người ký duyệt. Người ký duyệt mô tả quy trình nên thế. Người ngồi làm mỗi ngày mới biết quy trình thật — và họ là người sẽ dùng hệ thống.

Nhận yêu cầu qua nhiều lớp trung gian. "Sếp bảo là khách muốn…" — mỗi lớp truyền tin làm mất một phần ngữ cảnh. Ghi rõ trong nguồn là thông tin gián tiếp, và tìm cách xác minh với người gốc.

Ghi biên bản sau buổi họp một tuần. Trí nhớ thay thế sự thật bằng phiên bản hợp lý hơn. Ghi trong ngày, gửi xác nhận trong 24 giờ.

Coi "không có ý kiến gì" là đồng ý. Im lặng ở GĐ1 thường thành phủ quyết ở UAT. Với stakeholder ảnh hưởng cao mà im lặng, phải chủ động hỏi từng điểm một.