PHẦN 3 — QUY TRÌNH BẢY GIAI ĐOẠN

G0 Tiếp nhận → G1 Làm rõ → G2 Chốt yêu cầu → G3 Đặc tả → G4 Thực thi → G5 Nghiệm thu → G6 Đo lường
   (BA+PM)      (BA+AI)      (BA+PM+KH)      (DEV→BA)     (DEV+AI)      (PM+AI)        (PM+AI)

Chú giải màu:

• xám = hai vai trò cùng làm
• tím = BA chủ trì
• xanh lá = DEV chủ trì
• cam đất = PM chủ trì

G3 màu xám vì đây là giai đoạn duy nhất DEV và BA phải cùng ngồi xuống chốt một tài liệu. Ba đường nét đứt là vòng lặp ngược; đường G3 → G1 đáng giá nhất — nó bắt lỗi yêu cầu khi chi phí sửa còn là năm phút.

G0 — TIẾP NHẬN YÊU CẦU (BA + PM)

Đầu ra: biên bản thô. Commit ngay. Không cho AI xử lý ở bước này — nguyên liệu thô là bằng chứng, khi hai tháng sau có tranh cãi "khách hàng có nói vậy không" thì cần bản gốc chưa qua diễn giải.

G1 — LÀM RÕ YÊU CẦU (BA + AI)

Điều kiện thoát: không còn open question mức P1.

Ba mức Open Question dùng xuyên suốt quy trình:

G2 — CHỐT YÊU CẦU (BA + PM + khách hàng)

Đầu ra: PRD baseline + issue có checklist AC. Chưa ước lượng ở giai đoạn này — ước lượng trước khi có spec là đoán mò, DEV chưa biết mình phải xử lý bao nhiêu trường hợp biên.

Toàn bộ luồng yêu cầu G0 → G2:

Luồng này không còn kết thúc ở `ready-for-dev` như v1.0 — nó dừng ở status::spec và bàn giao sang G3. Điều kiện thoát vòng lặp làm rõ vẫn là hết câu hỏi mức P1, không phải hết mọi câu hỏi.

G3 — ĐẶC TẢ (DEV sinh → BA duyệt)

Đây là bản dịch từ ngôn ngữ nghiệp vụ sang ngôn ngữ kiểm chứng được. Là hợp đồng giữa BA và DEV, và là artifact duy nhất cả hai con AI cùng đọc trước khi làm việc.

Đầu ra: spec đã duyệt + ước lượng đáng tin.

Vì sao DEV viết spec chứ không phải BA. Nghe ngược, nhưng lý do rất thực tế. Bắt DEV viết lại yêu cầu dưới dạng kiểm chứng được sẽ ép DEV đọc kỹ PRD, và mọi chỗ hiểu sai lộ ra ngay tại đây. Nếu BA viết cả spec, DEV vẫn có thể đọc lướt rồi code theo cách hiểu riêng — và không ai biết cho tới lúc UAT. Bước BA duyệt spec là lần duy nhất trong cả quy trình có hai người cùng đọc một mô tả và xác nhận "tôi hiểu giống anh".

Ba nhánh khi BA đọc spec:

Phân biệt hai trường hợp cuối rất quan trọng. Nhầm "PRD thiếu" thành "DEV hiểu sai" sẽ khiến cùng một lỗ hổng tài liệu lặp lại ở mọi feature sau.

Definition of Ready — điều kiện gắn status::ready-for-dev:

• ☐ Issue link tới PRD tại tag baseline cụ thể
• ☐ Spec đã `approved`, tag `FE-XXX-spec-vX.Y`
• ☐ Mọi AC trong PRD đều có mục tương ứng trong spec, không sót
• ☐ Mục "Câu hỏi phát sinh" trong spec đã đóng hết mức P1
• ☐ Checklist AC ID đã có trong issue description
• ☐ API contract và thay đổi DB đã mô tả
• ☐ Có wireframe nếu có UI
• ☐ Đã có weight, estimate, milestone, assignee, module::, prio::

🔒 Luật cứng: DEV không bắt đầu code khi spec chưa approved.

G4 — THỰC THI (DEV + AI)

Spec đứng trước PRD trong thứ tự nạp context. Spec chính xác hơn và đã được duyệt; PRD lúc này là tài liệu tham chiếu bối cảnh. Nếu ở G4.2 phát hiện spec vẫn thiếu — comment vào issue, gắn status::spec, trả về G3. Không tự suy diễn rồi code.

G5 — NGHIỆM THU (PM + AI)

Sinh test case từ spec chứ không từ PRD là thay đổi quan trọng. PRD viết bằng ngôn ngữ nghiệp vụ nên test case sinh ra dễ mơ hồ; spec đã có sẵn Given/When/Then và dữ liệu mẫu nên test case bám sát được.

Toàn bộ luồng thực thi G4 → G5:

Definition of Done:

• ☐ MR đã merge, không còn comment chưa xử lý
• ☐ Tech note khớp code thực tế
• ☐ Mọi AC trong spec đều có test tương ứng — script `/trace` pass
• ☐ Checklist AC trong issue đã tick đủ
• ☐ Không còn defect Sev1/Sev2 mở
• ☐ Deploy staging thành công
• ☐ /spend ghi nhận đầy đủ
• ☐ Biên bản UAT có xác nhận khách hàng (với type::feature)

Phân mức defect:

G6 — ĐO LƯỜNG (PM + AI)

G7 — LUỒNG NGOẠI LỆ: CHANGE REQUEST

Khách hàng đổi yêu cầu sau baseline
   → BA ghi 02-requirements/change-requests/CR-XXX.md
   → BA + AI phân tích tác động: module nào, AC nào đổi, issue nào làm lại
   → DEV cập nhật spec cho các AC bị ảnh hưởng, ước lượng lại
   → PM tính chi phí + tác động tiến độ, trình khách hàng
   → Duyệt   → PRD v1.1 + tag mới → spec v1.1 + tag mới → issue type::cr
   → Không duyệt → CR status rejected, LƯU LẠI

Một CR kéo theo hai tài liệu phải lên version: PRD và spec. Trường prd_baseline trong header spec là thứ giúp phát hiện chỗ nào còn bám vào bản cũ — đưa việc kiểm trường này vào CI thì không ai quên được.

Ba điểm dễ sai:

• CR bị từ chối vẫn phải lưu. Nhiều team xóa đi cho gọn, rồi sáu tháng sau khách hàng hỏi "sao tính năng này không có" — không còn gì chứng minh là họ đã từ chối.
• Thay đổi nhỏ vẫn cần CR. Khách hàng thường mở đầu bằng "nhờ tí thôi". Hai mươi cái nhỏ cộng lại là một tháng công không có trong hợp đồng.
• Ước lượng CR phải gồm phần làm lại. Chi phí thật không phải code phần mới, mà là code lại phần đã xong cộng test lại vùng ảnh hưởng.