186 lines
6.0 KiB
Markdown
186 lines
6.0 KiB
Markdown
# BRIEF — <Tên module/dự án>
|
||
|
||
| | |
|
||
|---|---|
|
||
| **Version** | 1.0 |
|
||
| **Date** | YYYY-MM-DD |
|
||
| **Author** | <BA> (skill ba-1-discovery) |
|
||
| **Status** | 🟡 Draft |
|
||
| **Approved by** | — |
|
||
| **Source** | <liệt kê file/biên bản đã dùng, mỗi cái một dòng> |
|
||
| **Scope** | <module / US id> |
|
||
|
||
## Change Log
|
||
|
||
| Version | Date | Người sửa | Thay đổi | CR |
|
||
|---|---|---|---|---|
|
||
| 1.0 | YYYY-MM-DD | | Bản đầu | — |
|
||
|
||
---
|
||
|
||
## 1. Tóm tắt cho người quyết định
|
||
|
||
> *Ba câu. Đọc xong biết: vấn đề gì, làm gì, được gì. Viết mục này SAU CÙNG.*
|
||
|
||
---
|
||
|
||
## 2. Bối cảnh
|
||
|
||
*Hiện tại việc này đang diễn ra thế nào? Ai làm, tần suất bao nhiêu, mất bao lâu, bằng
|
||
công cụ gì. Chỉ nêu sự thật quan sát được, kèm nguồn.*
|
||
|
||
| Thông tin hiện trạng | Giá trị | Nguồn |
|
||
|---|---|---|
|
||
| Số giao dịch/ngày | | |
|
||
| Số người thao tác | | |
|
||
| Thời gian xử lý trung bình | | |
|
||
| Tỷ lệ sai sót hiện tại | | |
|
||
|
||
## 3. Phát biểu bài toán
|
||
|
||
> **Vấn đề:** *<Ai> gặp <khó khăn gì> khi <làm việc gì>, dẫn tới <hậu quả đo được>.*
|
||
|
||
❌ Không viết giải pháp ở đây ("cần thêm màn hình…", "cần nút export…").
|
||
✅ Viết vấn đề đo được ("mất trung bình 2 giờ/ngày đối chiếu thủ công, sai sót 3–5 ca/tháng").
|
||
|
||
**Bằng chứng của vấn đề:**
|
||
|
||
| # | Bằng chứng | Nguồn | Loại |
|
||
|---|---|---|---|
|
||
| 1 | | STK-nn, biên bản ngày… | Sự thật / Ý kiến |
|
||
|
||
**Điều gì xảy ra nếu không làm gì cả?** *(câu này quyết định dự án có đáng làm không)*
|
||
|
||
## 4. Mục tiêu kinh doanh & KPI
|
||
|
||
| ID | Mục tiêu | Baseline hiện tại | Mục tiêu | Cách đo | Ai đo | Tần suất |
|
||
|---|---|---|---|---|---|---|
|
||
| GOAL-01 | | | | | | |
|
||
| GOAL-02 | | | | | | |
|
||
|
||
🔴 **Baseline trống ⇒ ghi `OQ` kèm đề xuất cách đo.** Không có baseline thì GĐ5 không có gì
|
||
để so sánh, và "dự án có thành công không" sẽ thành tranh cãi cảm tính.
|
||
|
||
## 5. Phạm vi
|
||
|
||
### 5.1 Trong phạm vi
|
||
|
||
| # | Hạng mục | Vì sao cần | RQ liên quan |
|
||
|---|---|---|---|
|
||
| 1 | | | RQ-001 |
|
||
|
||
### 5.2 Ngoài phạm vi *(quan trọng hơn mục 5.1)*
|
||
|
||
| # | Hạng mục | Lý do loại | Xử lý ở đâu / khi nào |
|
||
|---|---|---|---|
|
||
| 1 | | | |
|
||
|
||
### 5.3 Ranh giới hệ thống
|
||
|
||
*Hệ thống nào nằm trong, hệ thống nào chỉ tích hợp, dữ liệu đi qua đâu.*
|
||
|
||
<!-- archify: architecture · diagrams/BRIEF_ranh-gioi-he-thong.architecture.json -->
|
||
```mermaid
|
||
flowchart LR
|
||
NGUOIDUNG(["👤 Vai trò sử dụng"])
|
||
|
||
subgraph PHAMVI["Trong phạm vi dự án"]
|
||
HT["Hệ thống đang xây"]
|
||
end
|
||
|
||
HTA[["Hệ thống A — chỉ tích hợp"]]
|
||
HTB[["Hệ thống B — ngoài phạm vi"]]
|
||
|
||
NGUOIDUNG --> HT
|
||
HT <--> HTA
|
||
HT --> HTB
|
||
```
|
||
|
||
*Khung đôi `[[ ]]` = ngoài phạm vi dự án. Mũi tên hai chiều = có trao đổi dữ liệu hai chiều.*
|
||
|
||
| Hệ thống | Trong/Ngoài phạm vi | Dữ liệu trao đổi | Chiều | Đầu mối |
|
||
|---|---|---|---|---|
|
||
| | | | | |
|
||
|
||
*Bảng này là phần bắt buộc đi kèm sơ đồ (quy tắc W13) — sơ đồ không nói được dữ liệu gì đi
|
||
qua và ai chịu trách nhiệm.*
|
||
|
||
## 6. Yêu cầu mức nghiệp vụ
|
||
|
||
| ID | Phát biểu yêu cầu | Nguồn (STK + ngày) | MoSCoW | GOAL | Giải pháp khách gợi ý |
|
||
|---|---|---|---|---|---|
|
||
| RQ-001 | | STK-01, 2026-08-22 | Must | GOAL-01 | |
|
||
| RQ-002 | | | Should | | |
|
||
|
||
**Kiểm tra phân bổ MoSCoW:** Must ≤ 60% tổng số. Vượt ⇒ chưa phân loại thật, quay lại hỏi
|
||
PO *"nếu chỉ kịp một nửa thì cắt cái nào"*.
|
||
|
||
| MoSCoW | Nghĩa chính xác |
|
||
|---|---|
|
||
| **Must** | Không có thì bản phát hành này vô nghĩa |
|
||
| **Should** | Quan trọng, nhưng thiếu vẫn dùng được, có cách làm thủ công tạm |
|
||
| **Could** | Có thì tốt, cắt đầu tiên khi thiếu thời gian |
|
||
| **Won't (this time)** | Đã bàn và thống nhất **không** làm lần này — ghi để khỏi bàn lại |
|
||
|
||
## 7. Ràng buộc
|
||
|
||
| Loại | Nội dung | Nguồn | Ảnh hưởng |
|
||
|---|---|---|---|
|
||
| Thời gian | | | |
|
||
| Ngân sách / nguồn lực | | | |
|
||
| Công nghệ | | | |
|
||
| Pháp lý / tuân thủ | | | |
|
||
| Tổ chức / quy trình | | | |
|
||
|
||
## 8. Giả định và rủi ro
|
||
|
||
*Chi tiết ở `RISK_<...>.md`. Ở đây chỉ nêu những cái ảnh hưởng tới phạm vi.*
|
||
|
||
| ID | Nội dung | Nếu sai thì sao |
|
||
|---|---|---|
|
||
| ASM-01 | | |
|
||
| RISK-01 | | |
|
||
|
||
## 9. Tiêu chí thành công của giai đoạn
|
||
|
||
*Khi nào coi là "làm xong và làm đúng"? Khác với KPI ở mục 4 — mục này nói về sản phẩm,
|
||
mục 4 nói về hiệu quả kinh doanh.*
|
||
|
||
- [ ]
|
||
- [ ]
|
||
|
||
## 10. Open Questions
|
||
|
||
| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì | Phương án BA đề xuất |
|
||
|---|---|---|---|---|---|
|
||
| OQ-001 | | | | | *(đề xuất, chưa phải quyết định)* |
|
||
|
||
## 11. Ngoài phạm vi tài liệu này
|
||
|
||
*Những gì người đọc có thể tưởng là có trong tài liệu này nhưng không có, và tìm ở đâu.*
|
||
|
||
- Thiết kế màn hình → GĐ3, `SRS`
|
||
- Quy trình chi tiết từng bước → GĐ2, `PROCESS`
|
||
- Ước lượng công sức → PM
|
||
|
||
---
|
||
|
||
## Tự chấm
|
||
|
||
**Gate G1**
|
||
|
||
| # | Tiêu chí | ☐/✅ | Ghi chú |
|
||
|---|---|---|---|
|
||
| 1 | BRIEF có bối cảnh, phát biểu bài toán, phạm vi in/out, GOAL kèm KPI | | |
|
||
| 2 | STAKEHOLDER đủ 4 nhóm, có tên thật | | |
|
||
| 3 | ELICITATION có ≥1 buổi với nhóm quyết định và nhóm sử dụng | | |
|
||
| 4 | RQ có MoSCoW, truy về được stakeholder cụ thể | | |
|
||
| 5 | RISK/ASM đã ghi, rủi ro cao có người chịu trách nhiệm | | |
|
||
| 6 | KPI có baseline | | |
|
||
|
||
**Quy tắc viết W1–W13** — xem `../ba-lifecycle/references/writing-rules.md`
|
||
|
||
| W1 | W2 | W3 | W4 | W5 | W6 | W7 | W8 | W9 | W10 | W11 | W12 | W13 |
|
||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||
| | | | | | | | | | | | | |
|