Vai trò trong SDD (Ai làm gì)
Một hiểu nhầm phổ biến: “spec là việc của PO/BA”. Sai. Trong SDD, spec là nơi cả team gặp nhau, mỗi vai trò đóng góp một phần khác nhau.
| Vai trò | Trách nhiệm chính |
|---|---|
| PO / BA | Làm rõ “làm gì” & “vì sao”: chịu trách nhiệm BR, cùng viết UC (Actor, Trigger, Main Flow, ngoại lệ nghiệp vụ). Phần khó nhất là những câu “đương nhiên”: “Hủy đơn thì điểm có bị trừ không?” - dev và AI không đoán được. Không cần biết code/markdown đẹp, nhưng cần đọc spec và nói: “Đúng, đây là rule nghiệp vụ.” |
| Tech Lead | Giữ spec + kiến trúc: “cái này implement được không? có lệch Bounded Context không? có ép domain biết quá nhiều về DB/provider không?“. Quyết định đoạn nào để AI làm (AI-Assisted). Giữ ADR link với spec. |
| Dev | Hiện thực hóa spec, viết test map AC, và dẫn AI (AI Conductor): đưa context, giới hạn phạm vi, đọc lại phần AI sinh, không để AI tự quyết rule nghiệp vụ. Phát hiện spec thiếu → mở spec PR nhỏ, tag PO/TL, rồi quay lại code. |
| Engineering Manager | Giữ nhịp quy trình & chỉ số. Không review từng dòng spec. Lo: ai quá tải review? PO phản hồi trong 24h? Tool có làm team chậm? Lãnh đạo có hiểu vì sao tuần đầu chậm? |
| QA / Tester | Vào ngay từ giai đoạn viết spec, không đợi code xong. Đọc AC và hỏi: “AC này test được không? Given/When/Then đủ rõ không? Edge case nào user thật sẽ chạm?“. Bug rẻ nhất là bug bắt khi AC còn là một câu trong spec. |
Khi team nhỏ không đủ vai trò
Startup nhỏ một người đội nhiều mũ vẫn OK. Nhưng đừng tự duyệt mọi thứ của mình - nếu không có PO, kéo founder/customer/người vận hành/support vào đọc spec, vì bạn cần một người không viết code hỏi những câu đời thường (Stakeholder-Centric).
Liên quan
- Stakeholder-Centric - vì sao cần người nghiệp vụ đọc spec
- AI-Assisted - dev như người dẫn việc cho AI
- Code Review trong SDD · Chỉ số đo SDD