Bạn sẽ học gì
Bạn sẽ học tài liệu sản phẩm (PRD) là gì và tại sao người làm sản phẩm cần viết nó. Đây là kỹ năng nền tảng giúp bạn truyền đạt ý tưởng, đồng bộ team và tránh hiểu lầm ngay từ đầu.
Khái niệm
Tài liệu sản phẩm (Product Requirements Document – PRD) là một văn bản mô tả chi tiết về một tính năng hoặc sản phẩm sắp xây dựng. Nó trả lời các câu hỏi: 'Tại sao làm cái này?', 'Nó sẽ hoạt động như thế nào?', 'Cần những gì để hoàn thành?'. PRD là 'bản thiết kế' chung cho team (dev, design, QA) cùng làm.
Liên hệ dễ hiểu
Hãy tưởng tượng bạn là người chỉ huy xây một ngôi nhà. Nếu bạn chỉ nói miệng 'xây nhà đẹp' cho thợ, họ sẽ xây lung tung. PRD giống như bản vẽ kiến trúc: chỉ rõ phòng nào, cửa sổ bao nhiêu, màu sơn gì. Ai cũng nhìn vào bản vẽ đó để biết mình cần làm gì.
Ví dụ thực tế
Bạn là PM tại một app giao đồ ăn. Team muốn thêm tính năng 'đặt món trước' (scheduled order). PRD của bạn sẽ ghi: (1) Mục tiêu: giúp người dùng đặt đồ ăn cho giờ sau, tăng doanh thu. (2) Luồng: người dùng chọn giờ giao, thanh toán, nhận thông báo. (3) Yêu cầu: hệ thống phải gửi đơn đến nhà hàng đúng giờ. Nhờ PRD, dev biết code gì, design biết vẽ màn hình nào, QA biết test ra sao.
Sơ đồ
flowchart LR
A[Ý tưởng] --> B[Viết PRD]
B --> C[Dev hiểu yêu cầu]
B --> D[Design hiểu giao diện]
B --> E[QA hiểu cách test]
C & D & E --> F[Sản phẩm đúng mong đợi]Thực hành ngay
Hãy nghĩ về một tính năng bạn muốn thêm vào một app quen thuộc (ví dụ: chế độ tối cho Facebook). Viết 3-5 dòng mô tả: tính năng đó làm gì, vì sao cần nó, và nó hoạt động ra sao. Đây là bước đầu của một PRD.
Tóm tắt
- PRD là tài liệu mô tả chi tiết sản phẩm/tính năng.
- Giúp cả team hiểu đúng cùng một mục tiêu.
- Tránh hiểu lầm, tiết kiệm thời gian và công sức.
<!--les-append-->
Điều gì xảy ra khi không có tài liệu
Lý thuyết thì rõ. Nhưng hãy nhìn cụ thể chuyện gì xảy ra khi một tính năng được mô tả bằng miệng:
| Người nghe | Họ hiểu thành | Vì sao |
|---|---|---|
| Lập trình viên | "Làm nút xuất file Excel" | Họ nghe phần kỹ thuật |
| Thiết kế | "Thêm một nút vào màn hình báo cáo" | Họ nghe phần giao diện |
| Kiểm thử | "Kiểm nút đó bấm được" | Họ nghe phần kiểm tra |
| Người yêu cầu | "Tôi sẽ có báo cáo hằng tuần tự động" | Họ nghe kết quả họ cần |
Tài liệu không làm cho mọi người thông minh hơn. Nó làm cho sự bất đồng lộ ra sớm, lúc còn rẻ để sửa.
Ba thứ tài liệu làm được mà cuộc họp không làm được
Người vắng mặt vẫn theo được. Người nghỉ phép, người vào sau, người ở múi giờ khác — tất cả đều đọc được cùng một thứ. Một quyết định chỉ tồn tại trong trí nhớ của những người có mặt là một quyết định sẽ bị hiểu khác đi trong vòng một tháng.
Nó ghi lại VÌ SAO, không chỉ CÁI GÌ. Sáu tháng sau, ai đó sẽ hỏi "sao mình làm thế này?" Nếu không có tài liệu, câu trả lời là suy đoán — và đội thường quyết định lại từ đầu, đôi khi ra kết quả ngược với lần trước mà không biết.
Nó buộc người viết phải nghĩ rõ. Đây là lợi ích ít ai nói tới và có lẽ lớn nhất: rất nhiều ý tưởng nghe hợp lý khi nói ra và sụp đổ khi phải viết thành câu. Việc viết là một bộ lọc.
Khi nào KHÔNG cần viết tài liệu
Tài liệu có chi phí. Đừng viết cho mọi thứ:
- Sửa lỗi nhỏ, rõ ràng — một dòng mô tả trong hệ thống quản lý việc là đủ.
- Thử nghiệm sẽ vứt đi — nếu kết quả là học được điều gì đó rồi bỏ, tài liệu chỉ là chi phí.
- Việc một người làm trong một ngày — chi phí viết vượt lợi ích.
Sai lầm của người mới
| Sai lầm | Vì sao xảy ra | Hậu quả |
|---|---|---|
| Viết quá dài | Nghĩ rằng đầy đủ là tốt | Không ai đọc hết; phần quan trọng bị chôn |
| Viết sau khi đã quyết | Coi tài liệu là thủ tục | Mất tác dụng làm rõ suy nghĩ |
| Chỉ mô tả giải pháp | Đó là phần dễ viết nhất | Đội không đề xuất được cách làm rẻ hơn |
| Không nêu phần ngoài phạm vi | Nghĩ là hiển nhiên | Tranh cãi ở khâu nghiệm thu |
Làm ngay
Nhớ lại một lần gần đây đội bạn hiểu nhầm nhau về một tính năng. Viết ra hai câu: điều mỗi bên nghĩ là gì, và một dòng tài liệu nào đã có thể ngăn được chuyện đó. Dòng đó chính là loại nội dung đáng viết. <!--/les-append-->