--- name: ba-4-delivery-support description: Giai đoạn 4 của quy trình BA — đồng hành cùng team trong lúc phát triển. Dùng để trả lời câu hỏi làm rõ của dev/QA (clarification log), quản lý change request có quy trình đánh giá tác động, review test case của QA xem có phủ đủ AC không, chuẩn bị và điều hành UAT, phân loại defect và change request. Kích hoạt khi người dùng nói "dev hỏi về spec", "trả lời câu hỏi của dev", "khách đòi thay đổi", "change request", "CR", "review test case", "chuẩn bị UAT", "kịch bản UAT", "phân loại bug hay CR", "grooming". Output vào ba-output//04-delivery/ và phải qua Gate G4 (UAT pass) trước khi go-live. --- # GĐ4 · DELIVERY SUPPORT — Đồng hành phát triển Mục tiêu: **giữ cho spec và sản phẩm không lệch nhau trong lúc code đang chạy.** Đây là giai đoạn chiếm nhiều thời gian thực tế nhất của BA, nhưng ít được ghi nhận nhất — vì phần lớn công việc là trả lời câu hỏi, và câu trả lời không được ghi lại thì mất luôn. Output: `QLOG` · `CR` · `TCREVIEW` · `UAT` trong `ba-output//04-delivery/` ## Bốn nguyên tắc bất di bất dịch 1. **Không bịa yêu cầu** — dev hỏi mà spec không nói ⇒ đi hỏi PO, không tự trả lời. 2. **Không quyết định thay PO** — mọi CR có ảnh hưởng scope/chi phí do PO quyết. 3. **Mọi phát biểu truy vết được** — mỗi câu trả lời trong `QLOG` phải chỉ về `BR`/`AC`/`DEC`. 4. **Không ghi đè tài liệu đã qua gate** — SRS đã Baselined chỉ sửa qua `CR-nnn`. 🔴 **Nguyên tắc riêng của giai đoạn này: mọi câu trả lời cho dev phải đi vào tài liệu.** Trả lời miệng hoặc qua chat rồi để đó là cách chắc chắn nhất khiến ba tháng sau không ai biết vì sao hệ thống hành xử như vậy — kể cả chính bạn. 🔴 **Mọi sơ đồ theo chuẩn Archify** (`W13`, `../ba-lifecycle/references/diagram-rules.md`): spec JSON `diagrams/_..json` (`quality_profile: showcase`, validate 0 lỗi) **+** mermaid có marker `` (hoặc `mermaid-only` cho ERD/use case/2×2) **+** bảng đi kèm. Một đường chính, ≤ 12 node, nhãn cạnh là điều kiện/giao thức, không màu. Không có Bash ⇒ ghi `humanInputNeeded` "chạy archify validate/deliver + diagram-check", không tự nhận đã validate. Cây phân loại Defect/CR/Spec gap (`CR` §0) → `workflow`. ## Bước 0 — Chốt việc cần làm rồi dừng lại **Chưa được ghi file.** Xác định **loại việc** trước, vì bốn loại có quy trình khác hẳn nhau: | Loại việc | Dấu hiệu | Chạy phần nào | |---|---|---| | **Câu hỏi làm rõ** | Dev/QA hỏi spec nói gì | Phần A | | **Yêu cầu thay đổi** | Ai đó muốn khác với spec đã chốt | Phần B | | **Review test case** | QA gửi test case cần đối chiếu AC | Phần C | | **UAT** | Sắp nghiệm thu | Phần D | Rồi làm bốn việc, **dừng chờ trả lời**: 1. **Profile** — đọc `00-index/PROFILE_.md`. Nó quyết định hình dạng của UAT (Phần D) và mức chặt của việc đóng defect: `PRODUCT = ml-model` ⇒ UAT là chuỗi offline → shadow → thí điểm, không phải pass/fail · `RIGOR = light` ⇒ demo + checklist thay UAT chính thức · `RIGOR = strict` ⇒ bằng chứng phải lưu trữ được, mọi defect kể cả Low đều phải có ticket. 2. **Input dùng được** — bảng `File | Vai trò | Version | Status`. Bắt buộc tìm `SRS` của US liên quan và `QLOG` hiện có. 3. **Phân loại sơ bộ** — với mỗi mục người dùng đưa vào, đoán loại và **nói rõ căn cứ**. 4. **Hỏi xác nhận** phân loại — vì phân loại sai giữa *câu hỏi* và *thay đổi* là lỗi tốn kém nhất ở giai đoạn này (xem §Phần B). Ví dụ phân loại thật ở nhiều domain: `examples.md`. Bỏ qua khi lệnh có `go`. --- ## PHẦN A — Trả lời câu hỏi làm rõ Dùng `templates/clarification-log.md`. ### A1. Phân loại câu hỏi | Loại | Ai trả lời được | Thời hạn mục tiêu | |---|---|---| | **Spec đã nói rõ, người hỏi chưa đọc thấy** | BA — trích dẫn đích danh mục nào | Trong ngày | | **Spec nói mơ hồ, hiểu được hai cách** | BA — làm rõ và **sửa spec** | 1 ngày | | **Spec không nói** | PO/Tech Lead — BA đi hỏi | 2 ngày | | **Spec nói sai** | PO — thành `CR` | 2 ngày | 🔴 **Ba loại sau đều phải sửa tài liệu.** Chỉ loại đầu tiên là trả lời xong là hết việc. Trả lời cho dev mà không sửa spec nghĩa là người tiếp theo đọc spec sẽ hỏi lại đúng câu đó. ### A2. Trả lời Mỗi câu trả lời trong `QLOG` phải có: - **Trích dẫn nguồn** — mục nào của tài liệu nào, hoặc ai quyết định và ngày nào - **Câu trả lời dứt khoát** — không "có thể", không "tuỳ" - **Hành động kèm theo** — sửa mục nào của tài liệu nào, hay không cần sửa (ghi rõ) Không trả lời được ngay ⇒ ghi `OQ`, nêu **người phải trả lời** và **hạn**, và nói với dev phương án tạm để không bị chặn (kèm cảnh báo là tạm). ### A3. Đóng vòng lặp Sau khi trả lời: 1. Sửa tài liệu (nếu thuộc loại 2/3/4) 2. Tăng version + ghi Change Log 3. **Báo cho những người đã đọc bản cũ** — dev khác, QA. Sửa spec âm thầm còn tệ hơn không sửa 4. Cập nhật `RTM` nếu AC/BR thay đổi --- ## PHẦN B — Quản lý Change Request Dùng `templates/change-request.md`. ### B1. Phân biệt Defect và Change Request 🔴 **Đây là phân loại tốn kém nhất khi làm sai**, và nó bị làm sai thường xuyên vì hai bên đều có động cơ: dev muốn gọi là CR (không phải lỗi của mình), khách muốn gọi là defect (không phải trả thêm tiền). Phép thử **duy nhất**, áp dụng máy móc: ``` Sản phẩm có làm đúng như tài liệu đã ký (SRS Baselined) không? ├── KHÔNG → DEFECT (bug). Dev sửa, không tính thêm chi phí. └── CÓ → Tài liệu có nói về tình huống này không? ├── CÓ, và khách muốn khác đi → CHANGE REQUEST └── KHÔNG nói gì → SPEC GAP → xem B2 ``` **Spec gap** — tài liệu im lặng về tình huống đó — là vùng xám thật sự, và trách nhiệm thuộc về BA. Xử lý thẳng thắn: ghi nhận là thiếu sót của đặc tả, đánh giá tác động như một CR, nhưng nêu rõ nguyên nhân gốc trong `BENEFIT` ở GĐ5 để lần sau đặc tả kỹ hơn chỗ đó. Đừng đẩy sang khách như một CR bình thường, cũng đừng nhận là bug của dev. ### B2. Quy trình xử lý CR — 6 bước, không bỏ bước | # | Bước | BA làm gì | Không được làm | |---|---|---|---| | 1 | **Ghi nhận** | Ghi nguyên văn yêu cầu, ai đề xuất, ngày | Diễn giải lại theo ý mình | | 2 | **Làm rõ** | Hỏi cho tới khi hiểu **vấn đề gốc**, không dừng ở giải pháp họ đề xuất | Nhận đúng câu chữ rồi đi làm | | 3 | **Đánh giá tác động** | Rà 6 trục như `IMPACT` ở GĐ2 + ước lượng cùng dev | Ước lượng một mình | | 4 | **Trình phương án** | ≥2 phương án kèm chi phí/rủi ro + **khuyến nghị của BA** | Chỉ trình một phương án | | 5 | **PO quyết** | Ghi `DEC-nn`: chấp nhận / hoãn / từ chối + lý do | Tự quyết vì "rõ ràng là nên làm" | | 6 | **Thực thi** | Sửa tài liệu, tăng version, cập nhật `RTM`, báo team | Sửa code trước, sửa tài liệu sau | 🔴 **Bước 2 là bước cứu được nhiều tiền nhất.** Thứ khách yêu cầu thường là giải pháp họ nghĩ ra; hỏi *"để làm gì?"* cho tới khi ra vấn đề gốc, rồi mới định giá. Câu hỏi ở đây là câu hỏi của GĐ1, dùng lại ở GĐ4. Ba ca thật, cả ba đều ra phương án rẻ hơn: `examples.md`. ### B3. CR đến vào lúc nào cũng phải qua quy trình Áp lực thường gặp: *"cái này nhỏ thôi, làm luôn đi cho nhanh"*. Trả lời: mọi thay đổi đều được ghi nhận, việc ghi nhận mất 5 phút. Thay đổi không ghi nhận sẽ: - Không vào test case ⇒ QA không test ⇒ lỗi lọt ra thật - Không vào tài liệu ⇒ người sau đọc spec thấy khác sản phẩm - Không vào ước lượng ⇒ trễ tiến độ mà không ai giải thích được vì sao --- ## PHẦN C — Review test case Dùng `templates/testcase-review.md`. BA **không viết** test case — QA viết. BA đối chiếu xem test case có phủ đúng AC không. ### C1. Bốn phép đối chiếu | # | Phép đối chiếu | Phát hiện | |---|---|---| | 1 | Mỗi `AC` → có ≥1 test case | AC bị bỏ sót khi test | | 2 | Mỗi test case → truy về được một `AC`/`BR` | Test thừa, hoặc AC chưa viết | | 3 | Mỗi `BR` → có test case kiểm tra cả ca vi phạm | Rule chỉ được test ở luồng đúng | | 4 | Mỗi dòng **bảng dữ liệu biên** → có test case | Bug ở giá trị biên, chỗ hay lỗi nhất | ### C2. Bốn nhóm hay thiếu trong test case Rà đích danh, đây là chỗ test case hay hụt: - **Phân quyền**: có test gọi thẳng API với token sai quyền không, hay chỉ test giao diện? - **Lỗi hệ thống**: có test timeout/5xx và kiểm tra **dữ liệu đã nhập được giữ nguyên** không? - **Đồng thời**: hai người sửa cùng một bản ghi thì sao? - **Dữ liệu cũ**: có test với bản ghi tạo trước khi có tính năng này không? ### C3. Kết quả review Không sửa test case của QA. Ghi nhận xét vào `TCREVIEW` với ba mức: 🔴 thiếu phủ AC (phải bổ sung) · 🟠 nên bổ sung · 💬 góp ý. Rồi thống nhất với QA, không áp đặt. --- ## PHẦN D — UAT Dùng `templates/uat-plan.md`. 🔴 **Hình dạng của UAT đổi theo `PRODUCT`.** Bảng dưới đây viết cho `screen`; ba loại khác nghiệm thu bằng cách khác — chi tiết ở đầu file biến thể PART 2 tương ứng: | `PRODUCT` | Nghiệm thu bằng | |---|---| | `screen` | Người dùng thao tác theo kịch bản công việc *(bảng D1 bên dưới)* | | `api-service` | Team tiêu thụ tích hợp thử trên sandbox, ký xác nhận hợp đồng | | `data-pipeline` | Chạy song song, **đối soát số liệu** với nguồn/hệ thống cũ ≥ 1 chu kỳ | | `batch-job` | Chạy song song với cách cũ, **thử ngắt giữa chừng rồi chạy lại** | | `ml-model` | offline → **shadow** → thí điểm → mở rộng; bỏ shadow là rủi ro lớn nhất | ### D1. Chuẩn bị — làm trước ngày UAT ít nhất một tuần | Việc | Chi tiết | Hay hỏng ở đâu | |---|---|---| | **Kịch bản** | Theo **luồng công việc thật**, không theo màn hình | Kịch bản viết theo màn hình thì người dùng không nhận ra công việc của mình | | **Dữ liệu** | Dữ liệu giống thật, đủ ca biên và ca ngoại lệ | Dữ liệu quá sạch ⇒ UAT pass, thật thì lỗi | | **Môi trường** | Ai có tài khoản gì, quyền gì, truy cập từ đâu | Ngày UAT mới phát hiện chưa cấp tài khoản | | **Người tham gia** | Đúng người **sẽ dùng thật**, không phải người đại diện | Người đại diện pass, người dùng thật từ chối | | **Tiêu chí pass** | Thoả thuận **trước**, bằng văn bản | Không thoả thuận trước ⇒ tranh cãi lúc kết luận | 🔴 **Tiêu chí pass phải chốt trước khi bắt đầu UAT.** Ví dụ: *100% kịch bản mức Must pass · không còn defect Critical/High · defect Medium có kế hoạch xử lý*. Chốt sau khi đã thấy kết quả thì không còn là tiêu chí nữa. ### D2. Trong lúc UAT BA làm **người quan sát và ghi chép**, không làm người hướng dẫn thao tác. Người dùng loay hoay ở đâu là thông tin quý — đừng cứu họ quá sớm, hãy ghi lại. Mỗi phát hiện ghi ngay: kịch bản nào · thao tác gì · mong đợi gì · thực tế gì · ảnh chụp · **phân loại sơ bộ** (defect / CR / hiểu nhầm cách dùng). Loại thứ ba — *hiểu nhầm cách dùng* — thường bị ghi thành defect. Nó là tín hiệu về đào tạo hoặc về thiết kế chưa rõ, và cần được ghi riêng để xử lý ở GĐ5. ### D3. Sau UAT Tổng hợp: số kịch bản pass/fail · defect theo mức · CR phát sinh · **quyết định go/no-go**. Defect được "chấp nhận tạm" phải có **ticket theo dõi và hạn xử lý**. Không có ticket thì nó biến mất, và quay lại sau sáu tháng dưới dạng khiếu nại của người dùng. --- ## Trước khi kết thúc Tuỳ phần đã chạy, in tương ứng: **Mọi lần chạy:** danh sách tài liệu đã sửa kèm version mới, và ai cần được báo. **Phần A:** bảng `QLOG` — câu hỏi mở, quá hạn (>2 ngày) đánh dấu 🔴. **Phần B:** bảng CR — trạng thái, tác động, ai đang chờ quyết. CR chờ >5 ngày ⇒ 🔴. **Phần C:** bảng phủ AC → test case, ô trống đánh dấu 🔴. **Phần D:** bảng tự chấm Gate G4 dạng ☐/✅ + kết luận go/no-go. ## Bẫy thường gặp **Trả lời dev qua chat rồi thôi.** Câu trả lời không vào tài liệu là câu trả lời sẽ mất. Ba tháng sau không ai biết vì sao hệ thống hành xử như vậy — kể cả bạn. **Nhận CR "nhỏ" không qua quy trình.** Không có CR nhỏ, chỉ có CR chưa được đánh giá tác động. Ghi nhận mất 5 phút, bỏ qua tốn hơn nhiều. **Tự quyết CR vì "rõ ràng là nên làm".** Vi phạm nguyên tắc 2. Kể cả khi bạn đúng, PO vẫn phải biết vì họ chịu trách nhiệm về scope và chi phí. **Sửa spec mà không báo ai.** Dev đang code theo bản cũ. Sửa âm thầm còn tệ hơn không sửa. **Cứu người dùng quá sớm trong UAT.** Chỗ họ loay hoay là dữ liệu quan trọng nhất của buổi UAT. Ghi lại trước, hướng dẫn sau. **UAT với dữ liệu quá sạch.** Dữ liệu thật có bản ghi thiếu trường, trùng, sai định dạng, tạo từ năm ngoái. Không đưa những thứ đó vào UAT thì UAT không chứng minh được gì. **Coi "không ai phản đối" là nghiệm thu.** Nghiệm thu phải có chữ ký và tiêu chí đã thoả thuận trước.