194 lines
11 KiB
Markdown
194 lines
11 KiB
Markdown
# Project Profile — ba trục quyết định cách chạy pipeline
|
||
|
||
Bộ skill này **không phụ thuộc ngành nghiệp vụ** (bán lẻ, y tế, logistics, ngân hàng, HR…
|
||
đều dùng chung khung). Nhưng nó **phụ thuộc ba thứ khác**, và ba thứ đó phải được khai báo
|
||
ngay ở Bước 0 của mọi skill:
|
||
|
||
```
|
||
PROFILE = PRODUCT × LIFECYCLE × RIGOR
|
||
```
|
||
|
||
Khai sai profile ⇒ skill đòi bạn điền những mục không tồn tại trong loại sản phẩm của bạn,
|
||
hoặc bỏ qua những mục sống còn. Đây là thứ quyết định mọi guideline phía sau.
|
||
|
||
---
|
||
|
||
## 0. Cách khai báo
|
||
|
||
Lần đầu chạy một project, `ba-lifecycle` tạo `00-index/PROFILE_<PROJECT>.md`:
|
||
|
||
```markdown
|
||
# PROFILE — <PROJECT>
|
||
|
||
| | |
|
||
|---|---|
|
||
| **PRODUCT** | screen |
|
||
| **LIFECYCLE** | brownfield |
|
||
| **RIGOR** | standard |
|
||
| **Ngành** | Bán lẻ / đối soát doanh thu |
|
||
| **Người chốt profile** | <PO/BA Lead>, ngày… |
|
||
| **Lý do chọn** | … |
|
||
|
||
## Hệ quả đã áp dụng
|
||
| Quyết định | Vì trục nào |
|
||
|---|---|
|
||
| Dùng biến thể SRS PART 2 = `screen` | PRODUCT |
|
||
| Bắt buộc AS-IS đầy đủ + phân tích dữ liệu cũ | LIFECYCLE |
|
||
| Gate ký bởi PO + Tech Lead + QA | RIGOR |
|
||
```
|
||
|
||
Mọi artifact khác thêm một dòng vào header: `| **Profile** | screen · brownfield · standard |`
|
||
|
||
**Đổi profile giữa chừng** phải ghi `DEC-nn` và nêu artifact nào phải viết lại.
|
||
|
||
---
|
||
|
||
## 1. Trục PRODUCT — loại sản phẩm
|
||
|
||
Trục quan trọng nhất. Nó quyết định **GĐ3 viết cái gì**.
|
||
|
||
| Giá trị | Sản phẩm là gì | Biến thể SRS PART 2 |
|
||
|---|---|---|
|
||
| `screen` | Có giao diện người dùng — web admin, web app, app di động | `srs-part2/screen.md` |
|
||
| `api-service` | Chỉ API/service, không giao diện; người tiêu thụ là hệ thống khác | `srs-part2/api-service.md` |
|
||
| `data-pipeline` | Sản phẩm là **dữ liệu** — ETL, ingest, kho dữ liệu, báo cáo BI | `srs-part2/data-pipeline.md` |
|
||
| `ml-model` | Sản phẩm là **mô hình dự đoán** — phân loại, xếp hạng, dự báo, sinh nội dung | `srs-part2/ml-model.md` |
|
||
| `batch-job` | Job chạy theo lịch, không giao diện — đối soát đêm, sinh báo cáo, dọn dữ liệu | `srs-part2/batch-job.md` |
|
||
| `process-only` | **Không phải phần mềm** — cải tiến quy trình, đổi cách làm việc | Không có PART 2 |
|
||
|
||
### Hệ quả theo từng giai đoạn
|
||
|
||
| | `screen` | `api-service` | `data-pipeline` | `ml-model` | `batch-job` | `process-only` |
|
||
|---|---|---|---|---|---|---|
|
||
| **GĐ1** Discovery | Đủ | Đủ; "người dùng" là **team tiêu thụ API** | Đủ; hỏi thêm về nguồn dữ liệu | Đủ; **bắt buộc** hỏi chi phí của dự đoán sai | Đủ | Đủ |
|
||
| **GĐ2** `PROCESS` | Đủ | Đủ | Đủ | Đủ | Đủ | Đủ — **trọng tâm** |
|
||
| **GĐ2** `RBAC` | Đủ | Theo client/scope thay vì vai trò người | Theo tập dữ liệu + độ nhạy cảm | Ai được xem điểm số/lý do | Ai được chạy tay | Đủ |
|
||
| **GĐ3** PART 2 | Màn hình, field | Endpoint, schema | Luồng dữ liệu, data contract | Bài toán, metric, ngưỡng | Job, lịch, chạy lại | ❌ N/A |
|
||
| **GĐ3** `AC` | 4 nhóm đầy đủ | 4 nhóm đầy đủ | 4 nhóm + **đối soát nguồn–đích** | 🔴 Chỉ áp cho hệ thống bao quanh; phần dự đoán dùng **ngưỡng metric** | 4 nhóm + **chạy lại** | Tiêu chí quy trình |
|
||
| **GĐ3** text hiển thị | Bắt buộc | N/A | N/A | Chỉ phần hiển thị cho người | N/A | N/A |
|
||
| **GĐ3** design (`ba-design`: `DS`, `HIFI`, `FIGMA`, `DSPEC`) | Bắt buộc ở `standard`+ | ❌ N/A | ❌ N/A | Chỉ phần màn hình cho người (nếu có) | ❌ N/A | ❌ N/A |
|
||
| **GĐ4** UAT | Người dùng thao tác | Team tiêu thụ tích hợp thử | Đối soát số liệu song song | 🔴 Đánh giá trên tập giữ lại + shadow mode | Chạy song song với cách cũ | Chạy thử quy trình |
|
||
| **GĐ5** `MANUAL` | Cho người dùng cuối | **Tài liệu tích hợp** cho dev | Từ điển dữ liệu + hướng dẫn đọc số | Hướng dẫn diễn giải kết quả | Sổ tay vận hành | Quy trình mới |
|
||
|
||
🔴 **`ml-model` là loại lệch nhiều nhất.** Yêu cầu mang tính xác suất, nên Given/When/Then
|
||
không mô tả được — đọc kỹ phần đầu `srs-part2/ml-model.md` trước khi bắt đầu.
|
||
|
||
### Loại chưa hỗ trợ
|
||
|
||
`embedded` / IoT / firmware: NFR khác hẳn (điện năng, nhiệt độ, thời gian thực cứng, an
|
||
toàn chức năng), và không có khái niệm "trạng thái rỗng". **Bộ skill này chưa có biến thể
|
||
PART 2 cho nó.** Dùng khung GĐ1/GĐ2/GĐ4/GĐ5 vẫn được; PART 2 của GĐ3 phải tự viết. Nói rõ
|
||
điều này với người dùng thay vì cố nhét vào biến thể gần đúng nhất.
|
||
|
||
### Một project có nhiều loại
|
||
|
||
Bình thường — một tính năng thường gồm `screen` + `api-service`, đôi khi + `batch-job`.
|
||
Cách xử lý: **profile khai loại chính**, và GĐ3 nạp nhiều biến thể PART 2, mỗi biến thể một
|
||
mục con. Không tách thành nhiều project.
|
||
|
||
---
|
||
|
||
## 2. Trục LIFECYCLE — nền cũ hay nền mới
|
||
|
||
Quyết định **GĐ1 và GĐ2 nặng ở đâu**.
|
||
|
||
| Giá trị | Nghĩa | AS-IS | Dữ liệu cũ | `IMPACT` |
|
||
|---|---|---|---|---|
|
||
| `greenfield` | Chưa có gì, không thay thế cái nào | Chỉ mô tả cách làm thủ công hiện tại (nếu có) | N/A — ghi rõ | Rút gọn: chỉ trục tích hợp |
|
||
| `brownfield` | Thay thế/bổ sung hệ thống đang chạy | 🔴 **Bắt buộc đầy đủ** | 🔴 **Bắt buộc chọn 1 trong 3 phương án** | Đầy đủ 6 trục |
|
||
| `enhancement` | Thêm/sửa trên module đã có | Chỉ phần bị đụng | Bắt buộc nếu đổi schema/rule | Đầy đủ 6 trục — **trọng tâm** |
|
||
|
||
**Hệ quả cụ thể:**
|
||
|
||
- `greenfield` ⇒ [process-model.md](../../ba-2-analysis/templates/process-model.md) PHẦN A rút
|
||
gọn còn A3 (điểm đau) + A4 (đường tắt) + A5 (ngoại lệ). Bỏ A1, A2, A6 và **ghi rõ lý do**,
|
||
đừng để trống.
|
||
- `enhancement` ⇒ GĐ1 chạy chế độ rút gọn (`--mode enhancement`): chỉ `RQ` + rủi ro, bỏ
|
||
`BRIEF` đầy đủ. Nhưng `IMPACT` ở GĐ2 thì **nặng hơn** bình thường.
|
||
- `brownfield` ⇒ mục "dữ liệu cũ xử lý thế nào" trong `IMPACT` §1.2 là blocker của G2.
|
||
|
||
---
|
||
|
||
## 3. Trục RIGOR — mức nghiêm ngặt
|
||
|
||
Quyết định **gate chặt tới đâu và ai phải ký**. `standard` là baseline; `light` bớt đi,
|
||
`strict` thêm vào.
|
||
|
||
| Giá trị | Dùng khi | Ký gate |
|
||
|---|---|---|
|
||
| `light` | POC, thử nghiệm, công cụ nội bộ ≤ 2 tuần, không đụng tiền/dữ liệu cá nhân | Chỉ PO |
|
||
| `standard` | Mặc định — sản phẩm thật, có người dùng thật | PO + Tech Lead + QA (theo từng gate); `PRODUCT = screen` thêm **Designer ở G3** (`UICONV`, `WF`, và `DS`/`HIFI`/`DSPEC` do `ba-design` sinh) |
|
||
| `strict` | Có tiền, dữ liệu cá nhân, yêu cầu pháp lý, chịu kiểm toán (tài chính, y tế, bảo hiểm) | Như standard **+ Bảo mật/Pháp chế ở G2 và G3** |
|
||
|
||
Chi tiết tiêu chí bớt/thêm theo từng gate: [workflow.md §2.0](workflow.md).
|
||
|
||
### Chọn `light` không phải là được phép làm ẩu
|
||
|
||
`light` bỏ **thủ tục**, không bỏ **tư duy**. Bốn thứ không bao giờ được bỏ ở bất kỳ mức nào:
|
||
|
||
1. Phát biểu bài toán (không có thì không biết đang giải gì)
|
||
2. Ít nhất một `GOAL` có cách đo (không có thì không biết có thành công không)
|
||
3. `OQ` cho mọi chỗ chưa rõ (bịa vẫn là bịa, kể cả trong POC)
|
||
4. Ghi lại quyết định `DEC-nn` (POC hôm nay thành sản phẩm sáu tháng sau là chuyện thường)
|
||
|
||
### Nâng mức giữa chừng
|
||
|
||
POC `light` được duyệt thành sản phẩm ⇒ **nâng lên `standard` và chạy bù**: rà lại G1, G2,
|
||
G3 theo checklist đầy đủ trước khi làm tiếp. Ghi `DEC-nn`. Không nâng bù là cách một POC
|
||
mang theo mọi thiếu sót của nó vào sản phẩm thật.
|
||
|
||
---
|
||
|
||
## 4. Bảng tra nhanh — profile nào nạp gì
|
||
|
||
| Profile | Template GĐ2 nạp | Biến thể PART 2 | Gate ký bởi |
|
||
|---|---|---|---|
|
||
| `screen · brownfield · standard` | Đủ 5 | `screen` | PO + TL + QA |
|
||
| `screen · greenfield · light` | `BACKLOG`, `BR` | `screen` | PO |
|
||
| `api-service · enhancement · standard` | `BACKLOG`, `BR`, `IMPACT` (nặng) | `api-service` | PO + TL + QA |
|
||
| `data-pipeline · brownfield · strict` | Đủ 5 + đối soát | `data-pipeline` | PO + TL + QA + Bảo mật |
|
||
| `ml-model · greenfield · standard` | `PROCESS`, `BACKLOG`, `BR` | `ml-model` | PO + TL + QA |
|
||
| `batch-job · enhancement · strict` | `BACKLOG`, `BR`, `RBAC`, `IMPACT` | `batch-job` | PO + TL + QA + Bảo mật |
|
||
| `process-only · brownfield · standard` | `PROCESS` (trọng tâm), `RBAC` | ❌ | PO |
|
||
|
||
---
|
||
|
||
## 5. Ba ví dụ profile thật
|
||
|
||
**① Màn hình quản trị đối soát trong hệ thống bán lẻ đang chạy**
|
||
```
|
||
screen · brownfield · standard
|
||
```
|
||
Có giao diện, thay thế quy trình Excel đang dùng, đụng dữ liệu giao dịch có sẵn, không phải
|
||
hệ thống chịu kiểm toán trực tiếp. → PART 2 `screen`, AS-IS bắt buộc, ký 3 bên.
|
||
|
||
**② Luồng nạp dữ liệu POS hằng đêm vào kho dữ liệu, phục vụ báo cáo tài chính**
|
||
```
|
||
data-pipeline · greenfield · strict
|
||
```
|
||
Không giao diện, sản phẩm là dữ liệu, phục vụ báo cáo tài chính nên chịu kiểm toán. → PART 2
|
||
`data-pipeline`, bắt buộc mục đối soát nguồn–đích và audit log, thêm chữ ký Bảo mật.
|
||
|
||
**③ Thử nghiệm gợi ý sản phẩm cho app khách hàng, chạy 3 tuần xem có đáng đầu tư không**
|
||
```
|
||
ml-model · greenfield · light
|
||
```
|
||
POC, chưa có người dùng thật ngoài nhóm thử. → PART 2 `ml-model` nhưng chỉ mục 2.1–2.5,
|
||
gate chỉ PO ký. Vẫn bắt buộc: bài toán, một metric có ngưỡng, `OQ`, `DEC`.
|
||
|
||
---
|
||
|
||
## 6. Chọn thế nào khi lưỡng lự
|
||
|
||
| Lưỡng lự | Chọn | Vì |
|
||
|---|---|---|
|
||
| `screen` hay `api-service` | Theo **người tiêu thụ**: người → `screen`, hệ thống → `api-service` | Ai đọc AC quyết định AC viết thế nào |
|
||
| `data-pipeline` hay `batch-job` | Sản phẩm là **dữ liệu để phân tích** → pipeline; là **việc được làm xong** → batch-job | Pipeline cần data contract, batch-job cần idempotency |
|
||
| `ml-model` hay `screen` | Có thành phần dự đoán ⇒ **nạp cả hai biến thể** | Màn hình vẫn cần spec bình thường |
|
||
| `brownfield` hay `enhancement` | Thay cả quy trình → brownfield; thêm một mẩu vào cái đang chạy → enhancement | Quyết AS-IS nặng hay nhẹ |
|
||
| `standard` hay `strict` | Có tiền, dữ liệu cá nhân, hoặc ai đó có thể bị kiểm toán ⇒ `strict` | Nâng mức rẻ hơn nhiều so với sửa sau kiểm toán |
|
||
| `light` hay `standard` | Kết quả sẽ được dùng thật bởi người ngoài nhóm ⇒ `standard` | "POC" mà có người dùng thật thì không còn là POC |
|
||
|
||
**Không chắc ⇒ chọn mức cao hơn và hỏi người dùng.** Sai hướng "chặt quá" tốn thêm ít thủ
|
||
tục; sai hướng "lỏng quá" mất thông tin không lấy lại được.
|