Buổi 4 — Viết yêu cầu: từ brief chiến dịch sang PRD
Bạn đã viết brief. PRD không xa lạ như bạn nghĩ — nhưng nó nghiêm ngặt hơn ở đúng những chỗ mà brief cho phép mơ hồ.
Brief và PRD giống nhau ở đâu
Cả hai đều mở đầu bằng bối cảnh, nêu đối tượng, nêu mục tiêu và cách đo. Nếu bạn viết brief tốt, bạn đã có nửa kỹ năng viết PRD.
Khác nhau ở đâu — và vì sao
Brief chấp nhận tính từ. PRD thì không. "Trải nghiệm mượt mà" là brief hợp lệ. Trong PRD nó vô nghĩa: engineer không biết phải làm gì và QA không biết kiểm gì. PRD phải viết "màn hình phản hồi dưới 300ms; nếu quá 1 giây thì hiển thị trạng thái đang tải".
Brief mô tả kết quả mong muốn. PRD mô tả cả các nhánh hỏng. Đây là khác biệt lớn nhất và cũng là chỗ marketer chuyển sang PM hay hụt. Chiến dịch không có trạng thái lỗi — sản phẩm thì đầy: mạng rớt, dữ liệu rỗng, người dùng chưa đăng nhập, thanh toán bị từ chối.
Brief có ngày kết thúc. PRD tạo ra thứ tồn tại mãi. Vì vậy PRD cần phần "non-goals" — nói rõ cái gì KHÔNG làm lần này, để phạm vi không trôi.
Cấu trúc PRD tối thiểu
- Problem — vấn đề gì, của ai, bằng chứng nào. Có số càng tốt.
- Goals — kết quả mong muốn, đo được, có mốc xuất phát.
- Non-goals — ranh giới đã thống nhất.
- User stories + acceptance criteria — ai cần gì để làm được gì, và làm sao biết đã xong.
- Edge cases — rỗng, đang tải, lỗi, quyền truy cập.
- Metrics — sẽ theo dõi gì sau khi ship.
Acceptance criteria: kỹ năng cần luyện nhất
Tiêu chí tốt phải trả lời được đúng/sai mà không cần tranh luận.
Chưa được: "Người dùng có thể lọc danh sách dễ dàng." Được: "Người dùng chọn được khoảng ngày; danh sách cập nhật trong 1 giây; nếu không có kết quả thì hiển thị trạng thái rỗng kèm gợi ý mở rộng khoảng ngày."
Mẹo kiểm tra: đưa tiêu chí cho một người không tham gia thảo luận. Nếu họ hỏi lại "ý là sao", tiêu chí chưa đạt.
Cạm bẫy của người viết giỏi
Marketer viết trôi chảy. Trong PRD, trôi chảy là rủi ro: một đoạn văn mượt mà dễ khiến người đọc gật đầu mà không nhận ra nó chưa trả lời câu hỏi nào cụ thể.
Cách chống: sau khi viết xong, gạch chân mọi tính từ và mọi trạng từ. Với mỗi cái, hỏi "đo bằng gì". Cái nào không đo được thì hoặc bỏ đi, hoặc thay bằng con số.
Bài tập
Lấy brief gần nhất bạn viết. Chuyển nó thành PRD theo sáu mục trên. Chú ý riêng phần edge cases — nó sẽ dài hơn bạn tưởng, và đó là dấu hiệu bạn đang chuyển đổi đúng hướng.
<!--les-append-->
Bốn khác biệt cụ thể giữa brief và PRD
| Brief chiến dịch | PRD | |
|---|---|---|
| Tính từ | Chấp nhận được | Không — phải quy thành số hoặc hành vi |
| Nhánh hỏng | Ít khi nhắc | Bắt buộc — trạng thái rỗng, lỗi, không có quyền |
| Phạm vi | Ngầm hiểu | Viết rõ cả phần KHÔNG làm |
| Điều kiện xong | "Chiến dịch kết thúc" | Tiêu chí kiểm được, có ví dụ cụ thể |
Bốn trạng thái phải có cho mọi màn hình
- Bình thường — có dữ liệu, mọi thứ chạy
- Rỗng — chưa có dữ liệu. Đây là màn hình đầu tiên người dùng mới thấy, và nó hay bị bỏ trắng
- Đang tải — cần cho biết đang xảy ra gì
- Lỗi — nói rõ chuyện gì xảy ra và làm gì tiếp
Từ tính từ sang tiêu chí kiểm được
| Brief viết | PRD viết |
|---|---|
| "Trải nghiệm mượt mà" | "Màn hình phản hồi dưới 300ms; quá 1 giây thì hiện trạng thái đang tải" |
| "Dễ tìm kiếm" | "Kết quả hiện trong 2 giây với danh sách tới 500 mục" |
| "Thông báo rõ ràng" | "Thông báo nêu chuyện gì xảy ra và hành động tiếp theo; không hiện mã lỗi" |
| "Hỗ trợ khách hàng lớn" | "Hoạt động với tài khoản có tới 200 người dùng và 50.000 bản ghi" |
Độ dài
Một tới ba trang cho một tính năng thông thường. PRD 15 trang gần như chắc chắn không được đọc hết, nghĩa là phần quan trọng trong đó cũng không được đọc.
Làm ngay
Lấy một brief bạn từng viết. Chuyển nó thành PRD: bỏ mọi tính từ, thêm bốn trạng thái cho mỗi màn hình, và thêm một dòng "không thuộc phạm vi lần này". Rồi đưa cho một engineer và hỏi họ còn phải đoán gì. <!--/les-append-->