PRD: Viết sao cho Dev không chửi, QA không khóc.
PRD là tài sản quan trọng nhất của PM. Nhưng viết dài quá thì không ai đọc, ngắn quá thì thiếu ý. Đây là cấu trúc tương đối chuẩn.
PRD không phải là viết truyện tiểu thuyết
Ngày xưa PRD dài cả trăm trang Word. Bây giờ, PRD trên Confluence/Notion cần nhất: Rõ ràng, Ngắn gọn, Đủ ý.
Cấu trúc PRD chuẩn
1. Context (Bối cảnh/Tại sao?)
Đừng bảo Dev “Làm cho anh cái nút này”. Hãy bảo: “User đang phàn nàn là không tìm thấy chỗ thanh toán (Data giảm 20%). Chúng ta cần làm nút này nổi bật hơn để cứu doanh số.” Khi Dev hiểu Why, họ sẽ làm tốt hơn bạn mong đợi.
2. User Stories & Acceptance Criteria (AC)
Story: “Là một User, tôi muốn nhận email khi quên mật khẩu...”
AC (Quan trọng nhất): Điều kiện để coi là Xong.
Email phải gửi trong vòng 30s.
Link trong email hết hạn sau 15 phút.
Nếu email không tồn tại trong hệ thống thì báo lỗi gì? AC càng chi tiết, QA càng dễ test và Dev càng ít code thiếu trường hợp Edge cases.
3. Design / Mockup
Link Figma đính kèm. Một hình ảnh bằng ngàn lời nói.
4. Technical Notes (Góc của Dev phải điền vào)
Để trống phần này cho Tech Lead điền vào: DB schema thay đổi thế nào? API nào cần gọi? Ko điền gì thì lúc làm đừng càm ràm và hãy điền trước khi bắt đầu plan.
5. Analytics và Tracking
Đừng đợi release xong mới nhớ ra chưa gắn Google Analytics. Ghi rõ: “Cần track sự kiện: Click nút ‘Mua ngay’, Gửi về tham số: Price, ProductID.”
Mẹo nhỏ
Dùng bảng Table cho các trạng thái Logic matrix.
Dùng sơ đồ Flowchart cho luồng đi của user.
Review PRD: Trước khi code, hãy họp cả team để review PRD 1 lần. Hỏi Dev: “Chỗ nào chưa rõ? Chỗ nào rủi ro?”. Sửa ngay trên giấy rẻ hơn sửa trên code gấp 100 lần.