Bạn viết một Product Requirements Document (PRD) tốt như thế nào?

Question

Accepted Answer

Một **Product Requirements Document (PRD)** giải thích *cái gì* bạn đang xây dựng, *tại sao*, và *bạn sẽ biết nó hiệu quả bằng cách nào* — để engineering và design có thể xây dựng đúng thứ mà không cần làm rõ liên tục. Một PRD tốt là một công cụ tư duy và một artifact đồng thuận, chứ không phải giấy tờ quan liêu.

## Một dàn ý PRD vững chắc

```text
1. PROBLEM / CONTEXT → vấn đề gì, cho ai, tại sao bây giờ
2. GOALS & SUCCESS METRICS → kết quả gì, đo lường thế nào
3. NON-GOALS → cái gì rõ ràng KHÔNG bao gồm
4. USER STORIES / REQUIREMENTS → nó phải làm gì
5. UX → flow, wireframe, các trạng thái chính
6. EDGE CASES → lỗi, trạng thái rỗng, giới hạn
7. DEPENDENCIES & RISKS → cái gì có thể chặn hoặc làm hỏng việc này
8. OPEN QUESTIONS → những ẩn số đã biết cần giải quyết
```

## Dẫn dắt bằng "tại sao"

Mục quan trọng nhất duy nhất là **vấn đề và mục tiêu**. Nếu đội ngũ hiểu *tại sao* và *thành công trông như thế nào*, họ thường tìm ra giải pháp tốt hơn cái bạn đã đặc tả. Một PRD chỉ là bản đặc tả tính năng sẽ bỏ lỡ điều này.

## Non-goals bị đánh giá thấp

Nêu rõ điều gì nằm ngoài scope ngăn chặn scope creep và cái bẫy "nhân tiện thì...". Nó có giá trị ngang với chính các requirement.

## Những cạm bẫy phổ biến

```text
✗ Đặc tả quá mức cái HOW → bó hẹp những ý tưởng tốt hơn của engineering
✗ Không có success metric → bạn không thể biết nó có hiệu quả không
✗ Viết nó một mình → đưa eng/design vào sớm để bắt vấn đề
✗ Xem nó như cố định → một PRD là một tài liệu sống
```

## Tại sao điều này quan trọng

Hầu hết việc làm lại đến từ thiếu đồng thuận: đội xây dựng cái được yêu cầu, không phải cái cần thiết.

Một PRD rõ ràng phơi bày những khoảng trống đó *trước* khi ai đó viết code.

Nó cũng buộc *bạn* phải suy nghĩ thấu đáo vấn đề.

Nếu bạn không thể viết rõ ràng mục tiêu và success metric, bạn chưa hiểu vấn đề đủ rõ để xây dựng nó.