11 KiB
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:
# 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Đ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 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ưngIMPACTở GĐ2 thì nặng hơn bình thường.brownfield⇒ mục "dữ liệu cũ xử lý thế nào" trongIMPACT§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) |
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.
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:
- Phát biểu bài toán (không có thì không biết đang giải gì)
- Ít nhất một
GOALcó cách đo (không có thì không biết có thành công không) OQcho mọi chỗ chưa rõ (bịa vẫn là bịa, kể cả trong POC)- 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.