Mỗi tài liệu phục vụ một quyết định
Bài 1 đã phân biệt PRD, spec, one-pager và RFC theo hình thức. Bài này nhìn chúng theo một góc khác: mỗi loại tài liệu tồn tại để giúp ai đó ra một quyết định, và các quyết định đó đến theo thứ tự. Xếp chúng lại, bạn có một bậc thang. Chỉ leo lên bậc tiếp theo khi bậc dưới đã được trả lời "có".
Lỗi phổ biến nhất của PM mới không phải viết PRD dở, mà là viết PRD quá sớm: mười lăm trang mô tả luồng màn hình cho một vấn đề mà chưa ai đồng ý là đáng giải. Khi lãnh đạo hỏi "sao lại làm cái này", cả tài liệu đổ, cùng với một tuần công sức. Lỗi ngược lại cũng hay gặp: dừng ở one-pager rồi giao thẳng cho kỹ sư, và đội phải tự đoán các trường hợp biên trong lúc code.
| Bậc | Quyết định nó phục vụ | Người đọc chính | Độ dài | Công viết |
|---|---|---|---|---|
| Problem brief | Vấn đề này có đáng tìm hiểu tiếp không? | Trưởng nhóm, người tài trợ | Nửa trang đến một trang | 1-2 giờ |
| One-pager | Hướng giải này có đáng vào kế hoạch quý không? | Lãnh đạo, trưởng các bộ phận | Một trang | Nửa ngày |
| PRD | Đội sẽ xây chính xác cái gì, đo thành công thế nào? | Kỹ sư, thiết kế, QA, data | 4-10 trang | 3-5 ngày, nhiều vòng |
| Spec kỹ thuật (RFC, design doc) | Xây bằng cách nào, rủi ro kỹ thuật ở đâu? | Kỹ sư, kiến trúc sư | Tùy độ phức tạp | Kỹ sư viết, PM đọc và hỏi |
Không phải việc nào cũng cần cả bốn bậc
Độ rủi ro quyết định bạn bắt đầu ở bậc nào và dừng ở bậc nào. Câu hỏi kiểm tra nhanh: nếu quyết định này sai, mất bao lâu để quay lại? Dưới một tuần thì viết ít. Trên một quý thì leo đủ bậc.
| Loại việc | Bắt đầu từ | Dừng ở | Vì sao |
|---|---|---|---|
| Sửa lỗi, chỉnh câu chữ | Ticket | Ticket | Không có quyết định nào cần thuyết phục |
| Cải tiến nhỏ trong một màn hình | One-pager rút gọn | One-pager kèm tiêu chí nghiệm thu | Rủi ro thấp, đảo ngược dễ |
| Tính năng mới, vài đội tham gia | Problem brief | PRD | Cần đồng thuận về vấn đề trước khi bàn giải pháp |
| Thay đổi thanh toán, dữ liệu, hạ tầng | Problem brief | Spec kỹ thuật | Khó đảo ngược, sai thì đắt |
| Đặt cược lớn, sản phẩm mới | Problem brief, rồi PRFAQ (Bài 62) | PRD và spec kỹ thuật | Thử ý tưởng bằng câu chữ trước khi tốn tiền |
Ví dụ giả định: Sỉ Nhanh
Công ty dưới đây là giả định, dùng xuyên suốt từ Bài 61 đến Bài 65.
Sỉ Nhanh là ứng dụng đặt hàng sỉ cho tiệm tạp hóa ở TP.HCM và Bình Dương. Mỗi tháng có 4.200 tiệm hoạt động, đặt hàng từ 18 nhà phân phối. Trung bình mỗi tiệm đặt 3 đơn một tháng, mỗi đơn 2,4 triệu đồng, tổng giá trị đơn khoảng 30,2 tỷ đồng một tháng (4.200 × 3 × 2,4 triệu).
Phỏng vấn 20 chủ tiệm cho thấy mỗi đơn mất trung bình 11 phút, phần lớn để dò lại sổ xem lần trước đã nhập gì; cứ 10 đơn thì khoảng 3 đơn sót món, phải đặt bổ sung. Dữ liệu đơn hàng xác nhận: 70% đơn lặp lại ít nhất một món từ đơn trước. PM của Sỉ Nhanh đi qua bậc thang như sau:
- Problem brief (một trang): vấn đề "nhập lại hàng quen mất thời gian và hay sót món", bằng chứng từ phỏng vấn và dữ liệu đơn. Quyết định của trưởng nhóm: đáng tìm hướng giải.
- One-pager: đề xuất "Gợi ý đơn nhập", app tự dựng giỏ hàng từ lịch sử nhập của tiệm. Mục tiêu, chi phí ước lượng 2 kỹ sư và 1 thiết kế trong 6 tuần, rủi ro chính. Quyết định của lãnh đạo: đưa vào quý.
- PRD: luồng màn hình, trường hợp tiệm mới chưa có lịch sử, giới hạn số lượng, chỉ số, kế hoạch tracking (Bài 64), ngưỡng chất lượng của mô hình (Bài 65).
- Spec kỹ thuật: kỹ sư chọn cách tính gợi ý, nơi lưu dữ liệu, chi phí hạ tầng; PM đọc và hỏi.
Mỗi bậc kế thừa bậc trước
Không viết lại từ đầu ở mỗi bậc. Problem brief trở thành mục Context và Problem của PRD (Bài 12, Bài 13). Mục tiêu trong one-pager trở thành Goals; những gì bạn đã cố ý bỏ ở one-pager đi vào Non-goals (Bài 14). Khi bậc trên mâu thuẫn với bậc dưới, ví dụ PRD đổi mục tiêu, hãy quay xuống sửa bậc dưới và báo cho người đã duyệt nó.
flowchart TD A["Problem brief, vấn đề có đáng giải?"] -->|Có| B["One-pager, hướng giải có vào kế hoạch?"] B -->|Có| C["PRD, xây chính xác cái gì?"] C --> D["Spec kỹ thuật, xây bằng cách nào?"] A -->|Không| X["Dừng, lưu lại bằng chứng"] B -->|Không| X
Nhánh "Dừng" là một kết quả tốt, không phải thất bại. Một problem brief bị từ chối sau hai giờ viết đã tiết kiệm cho đội hàng tuần làm việc vô ích, và bằng chứng trong đó vẫn dùng lại được khi bối cảnh thay đổi.
Dấu hiệu bạn đang ở sai bậc
- Buổi review PRD toàn tranh luận "có nên làm không": bạn đã bỏ qua bậc problem brief hoặc one-pager.
- Lãnh đạo hỏi chi tiết màn hình khi duyệt one-pager: one-pager đang trộn giải pháp chi tiết vào; rút về mục tiêu và đánh đổi.
- Kỹ sư hỏi lại cùng một câu về trường hợp biên nhiều lần: PRD còn thiếu, đừng đẩy phần đó sang spec kỹ thuật.
- Bạn đang chọn cơ sở dữ liệu hay viết API trong PRD: bạn đã leo lên bậc của kỹ sư.
Làm ngay
- Liệt kê ba việc đội bạn sắp làm. Với mỗi việc, trả lời: nếu sai, mất bao lâu để quay lại?
- Dùng bảng "Không phải việc nào cũng cần cả bốn bậc" để chọn bậc bắt đầu và bậc dừng cho từng việc.
- Với việc lớn nhất, viết problem brief bằng Problem brief template, rồi one-pager bằng One-pager template. Không mở PRD trước khi one-pager được duyệt.
- Ghi tên người ra quyết định ở mỗi bậc, và gửi tài liệu cho đúng người đó thay vì gửi cả nhóm.