Nguyên tắc 5: Stakeholder-Centric

Spec chỉ thật sự có giá trị khi người chịu hậu quả đã đọc nó.

Spec không nên chỉ là tài liệu giữa dev và AI; nó phải được đọc bởi người chịu hậu quả khi sản phẩm sai.

Tình huống

Khoa implement feature tích điểm 3 ngày: demo đẹp, test xanh, UI ổn. PO Vy xem xong hỏi: “Khi khách hủy đơn, điểm đã tích có bị trừ lại không?” Khoa: “Spec không nói chỗ đó.” Vy: “Vì với business thì chuyện đó đương nhiên.”

Đương nhiên với Vy (3 năm làm nghiệp vụ) nhưng không đương nhiên với Khoa, càng không với AI. Một buổi review spec 30 phút trước khi code có thể đã bắt được case này.

Cách áp dụng

Với feature nghiệp vụ, cần hai góc nhìn:

• Kỹ thuật: spec có implement được không, có lệch kiến trúc không?
• Nghiệp vụ: spec có đúng thực tế không, có thiếu rule “đương nhiên” không?

→ Spec PR nên có ít nhất một approval từ nghiệp vụ + một từ kỹ thuật. Mỗi sprint có một buổi walkthrough 15-30 phút: PO mở spec mới, đọc flow + AC, team đặt câu hỏi. Với spec quan trọng, kéo customer support & operations vào sớm - họ biết edge case mà dev và PO không nhớ.

Nếu bạn là PO, không cần thành dev để tham gia SDD. Việc quan trọng nhất là đọc spec và hỏi: “Nếu A thì sao? B có được tính không? Mình không thấy xử lý C.”

Liên quan

• Sáu nguyên tắc Spec-Driven - nguyên tắc số 5
• Vai trò trong SDD - ai đọc, ai duyệt spec
• Code Review trong SDD - spec PR cần approval nghiệp vụ