PRD là gì? Cách viết tài liệu yêu cầu một trang

Tình huống: tài liệu mười lăm trang và những câu hỏi lặp lại

Bạn mới nhận vai trò PO được vài tuần. Tính năng đầu tiên được giao là cho khách sửa địa chỉ giao hàng sau khi đặt. Muốn làm thật kỹ, bạn viết một tài liệu mười lăm trang: bối cảnh thị trường, mười hai user story, sơ đồ màn hình, danh sách trường dữ liệu, cả phần câu hỏi thường gặp.

Một sprint sau, kỹ sư hỏi: “Đơn đã đóng gói rồi thì có cho sửa không ạ?” Câu trả lời nằm ở trang chín. Designer làm màn hình theo một hướng khác vì chỉ kịp đọc hai trang đầu. Bộ phận chăm sóc khách hàng thì chưa từng mở tài liệu. Bạn đã viết đủ mọi thứ, nhưng team vẫn hỏi lại từng điều.

Đây là tình huống minh họa, không phải câu chuyện của một team cụ thể. Bài này giới thiệu một cách khác: tài liệu yêu cầu một trang, hay PRD ngắn. Nó không thay cho user story hay tiêu chí chấp nhận. Nó là trang đầu tiên ai cũng đọc được trong vài phút để biết vì sao làm, làm tới đâu và còn gì chưa rõ.

Vì sao viết tài liệu yêu cầu lại khó với người mới?

PRD là viết tắt của product requirements document, tài liệu yêu cầu sản phẩm. Có team gọi là PRD, có team gọi là spec. Cái khó không nằm ở việc biết tài liệu có những mục nào. Mẫu PRD trên mạng có rất nhiều. Cái khó là chọn viết gì và bỏ gì.

• Dài cho cảm giác kỹ. Khi còn mới, viết thật nhiều giúp bạn thấy an toàn: nếu có chuyện, ít nhất bạn đã ghi lại. Nhưng người đọc không có thời gian đọc hết, nên điều quan trọng bị chìm giữa những điều phụ.
• Sợ bị hỏi mà không trả lời được. Người mới dễ cố trả lời trước mọi câu hỏi có thể có, kể cả những câu chưa ai có dữ liệu. Kết quả là tài liệu chứa nhiều đoán định trông như sự thật.
• Chưa biết phần nào là việc của team. Cách hiển thị, cách lưu dữ liệu, cách chia API là chỗ designer và kỹ sư giỏi hơn PO. Viết sẵn những phần đó làm team mất chỗ đóng góp, và tài liệu cũng nhanh lỗi thời.
• Viết một mình rồi mới gửi. Tài liệu viết xong mới chia sẻ thì người đọc chỉ còn vai trò duyệt, không còn vai trò cùng nghĩ.

Atlassian liệt kê vài dấu hiệu nên tránh khi viết yêu cầu theo cách agile, trong đó có việc toàn bộ dự án đã được đặc tả rất chi tiết trước khi kỹ sư bắt đầu, và PO tự viết yêu cầu mà không có team tham gia. Scrum Guide cũng xem việc thêm chi tiết cho các hạng mục backlog là hoạt động liên tục, gọi là refinement, chứ không phải việc làm xong một lần từ đầu.

Vì vậy, mục tiêu của một trang không phải là viết ít cho nhanh. Mục tiêu là ghi những điều cả team phải hiểu giống nhau, và để chỗ trống rõ ràng cho những điều còn cần cùng tìm.

PRD một trang gồm những phần nào?

Một trang có thể gói trong bảy phần, chia thành bốn nhóm. Thứ tự này cũng là thứ tự nên viết: hiểu vấn đề trước, rồi mới tới giải pháp và giới hạn.

Từng phần cần trả lời được điều sau:

• Vấn đề: một đến ba câu mô tả chuyện đang xảy ra, bằng lời của người gặp nó. Không nhắc giải pháp ở đây.
• Người dùng: ai gặp vấn đề, trong tình huống nào. Nếu có nhiều nhóm, ghi nhóm nào được ưu tiên lần này.
• Mục tiêu và cách đo: kết quả mong muốn và một chỉ số để kiểm tra sau khi ra mắt, kèm nguồn số. Nếu chưa có số hiện tại, ghi rõ là cần đo trước.
• Phạm vi và phần không làm: những gì nằm trong lần này, và những gì cố ý để sau. Atlassian gọi phần này là “what we're not doing”. Phần này giúp tránh được nhiều tranh cãi về sau.
• Luồng chính: vài bước người dùng đi qua, cả luồng thuận và một hai trường hợp bị chặn. Không vẽ màn hình ở đây, chỉ link tới thiết kế khi có.
• Câu hỏi mở: những điều cần quyết hoặc cần tìm hiểu, kèm người trả lời và hạn. Đây là chỗ bạn được phép nói “chưa biết”.
• Rủi ro và phụ thuộc: điều có thể làm sai kết quả, và team hay hệ thống khác mà việc này cần tới.

Phần nào cũng có thể chỉ vài dòng. Nếu một phần dài hơn nửa trang, đó là tín hiệu nên tách nó ra tài liệu riêng và để lại một đường link.

Viết PRD một trang theo những bước nào?

Một trang viết nhanh hơn mười lăm trang, nhưng không có nghĩa là viết trong một lần. Một cách làm là đi qua bốn bước sau.

• Bước 1, viết nháp phần vấn đề và người dùng trước. Nếu bạn chưa nói được vấn đề trong ba câu mà không nhắc tới giải pháp, hãy quay lại hỏi người gửi yêu cầu. Bài xử lý yêu cầu tính năng bên dưới có bộ câu hỏi cho bước này.
• Bước 2, chốt mục tiêu và cách đo cùng người có số. Hỏi bộ phận đang giữ dữ liệu xem chỉ số đó có đo được không, lấy ở đâu, hiện là bao nhiêu. Một mục tiêu không đo được thì không kiểm tra được sau khi ra mắt.
• Bước 3, ngồi với designer và kỹ sư khoảng ba mươi phút để đọc chung phạm vi, luồng chính và câu hỏi mở. Họ dễ thấy những rủi ro bạn chưa nghĩ tới, như dữ liệu cũ, quyền truy cập hay hệ thống bên ngoài.
• Bước 4, gửi cho stakeholder đọc và giữ trang sống. Khi một câu hỏi mở được trả lời, chuyển câu trả lời vào đúng phần và ghi ngày. Trang không còn đúng thì team sẽ thôi đọc nó.

Sau bước 3, bạn mới chia việc thành user story và viết tiêu chí chấp nhận cho từng story. Trang một trang trả lời “vì sao và tới đâu”. User story và tiêu chí chấp nhận trả lời “cụ thể làm gì và thế nào là xong”. Link chúng ngược về trang này để ai mở story cũng tìm được bối cảnh.

• Cách xử lý một yêu cầu tính năng
• Cách viết user story cho người mới

Ví dụ: từ một tin nhắn mơ hồ tới một trang rõ ràng

Quay lại tình huống đầu bài, áp vào một cửa hàng gốm online giả định tên Gốm Mộc. Trưởng nhóm chăm sóc khách hàng nhắn: “Cho khách tự sửa địa chỉ trên app đi em, khách gọi tổng đài nhiều quá.” Bảng dưới cho thấy tin nhắn đó trở thành từng phần của trang như thế nào. Mọi con số trong bảng là số giả định để minh họa.

Để ý vài điều. Mục tiêu có con số hiện tại, con số đích và một nguồn đo cụ thể mà tổng đài đang dùng, nên sau bốn tuần ai cũng kiểm tra được. Phần không làm nói rõ lý do, nên khi có người hỏi “sao không cho đổi sang tỉnh khác”, câu trả lời đã nằm sẵn trên trang. Câu hỏi mở có tên người trả lời, nên nó không bị treo.

Cả trang không có màn hình, không có tên trường dữ liệu, không có thiết kế API. Đó là phần designer và kỹ sư sẽ đề xuất sau khi đọc. Còn tiêu chí chấp nhận cụ thể, như thông báo hiện trong bao lâu hay địa chỉ hợp lệ gồm những gì, nằm trong từng user story.

• Acceptance criteria viết sao cho kiểm thử được

Khi nào cần spec đầy đủ thay vì một trang?

Một trang hợp với nhiều tính năng vừa và nhỏ, nhưng không phải tất cả. Bộ lọc dưới đây giúp bạn quyết định. Trả lời “có” cho cả bốn câu thì một trang là đủ.

Ngay cả khi cần spec dài, một trang vẫn có ích ở vị trí đầu tiên. Người đọc lướt trang này để hiểu bối cảnh, rồi chỉ mở phần chi tiết liên quan tới việc của mình. Atlassian cũng mô tả trang yêu cầu như một “landing page” cho mọi thứ liên quan, dùng link để dẫn người đọc tới chi tiết khi cần.

Cách làm “Working Backwards” mà Werner Vogels mô tả ở Amazon đi theo hướng tương tự về tinh thần: viết từ phía khách hàng trước, bằng một thông cáo ra mắt và phần hỏi đáp, rồi mới lùi về phần công nghệ cần có. Bạn không cần dùng đúng hình thức đó. Điều đáng học là bắt đầu từ người dùng và kết quả, không bắt đầu từ danh sách tính năng.

Mẫu PRD một trang để dùng ngay

Bạn copy mẫu dưới đây vào công cụ tài liệu của team, như Confluence, Notion hay Google Docs. Giữ các tiêu đề, thay phần trong ngoặc vuông. Phần nào chưa có câu trả lời thì ghi vào mục câu hỏi mở thay vì đoán.

Tên tính năng: [tên ngắn]
Người phụ trách: [PO] | Team: [design, kỹ sư, kiểm thử, vận hành]
Trạng thái: [nháp / đang làm rõ / đã chốt] | Cập nhật: [ngày]

1. Vấn đề
[1 đến 3 câu: chuyện gì đang xảy ra, bằng lời của người gặp nó. Chưa nhắc giải pháp.]

2. Người dùng
[Ai gặp vấn đề, trong tình huống nào. Nhóm nào được ưu tiên lần này.]

3. Mục tiêu và cách đo
Kết quả mong muốn: [điều gì thay đổi]
Chỉ số: [tên chỉ số] | Hiện tại: [số, nguồn] | Mục tiêu: [số] sau [thời gian]

4. Phạm vi
Làm lần này:
- [ ]
Không làm lần này (và lý do):
- [ ]

5. Luồng chính
Luồng thuận: [bước 1] > [bước 2] > [bước 3]
Trường hợp bị chặn: [khi nào, người dùng thấy gì]
Thiết kế: [link]

6. Câu hỏi mở
- [Câu hỏi] | Người trả lời: [tên] | Hạn: [ngày]

7. Rủi ro và phụ thuộc
Rủi ro: [điều có thể làm sai kết quả, cách giảm]
Phụ thuộc: [team, hệ thống, đối tác]

Link chi tiết: [user story] | [tiêu chí chấp nhận] | [tài liệu khác]

Trước khi gửi, đọc lại và tự hỏi: một người mới vào team đọc trang này trong năm phút có nói lại được vấn đề, mục tiêu và phần không làm không? Nếu không, trang còn thiếu hoặc còn quá dài.

Những lỗi dễ gặp khi viết PRD ngắn

• Bắt đầu bằng giải pháp. Phần vấn đề viết thành “Thêm nút sửa địa chỉ” là đang mô tả giải pháp. Viết lại bằng chuyện người dùng đang gặp.
• Mục tiêu không đo được. “Cải thiện trải nghiệm khách hàng” không kiểm tra được sau khi ra mắt. Cần một chỉ số, nguồn số và mốc thời gian.
• Bỏ trống phần không làm. Không ghi rõ phần để sau thì mỗi người tự hiểu phạm vi theo ý mình, và tranh cãi xuất hiện lúc nghiệm thu.
• Chép chi tiết vào thay vì link. Dán cả bộ tiêu chí chấp nhận hay ảnh thiết kế vào trang làm nó dài lại, và hai bản dễ lệch nhau.
• Giấu câu hỏi mở. Ghi đoán định như sự thật để trang trông hoàn chỉnh. Một câu hỏi mở có người trả lời và có hạn đáng tin hơn một câu trả lời đoán.
• Viết xong rồi để đó. Trang không được cập nhật khi quyết định thay đổi thì team sẽ quay lại hỏi qua chat, và trang mất vai trò điểm vào.

Tóm tắt

• PRD một trang ghi những điều cả team phải hiểu giống nhau: vấn đề, người dùng, mục tiêu và cách đo, phạm vi và phần không làm, luồng chính, câu hỏi mở, rủi ro và phụ thuộc.
• Viết theo thứ tự: vấn đề trước, giải pháp sau. Đọc chung với designer và kỹ sư trước khi chia việc thành user story.
• Phần không làm và câu hỏi mở giúp tránh được nhiều hiểu lầm về sau. Đừng bỏ trống chúng.
• Chi tiết nằm trong user story, tiêu chí chấp nhận và thiết kế, được link từ trang, không chép vào.
• Với thanh toán, pháp lý, dữ liệu cá nhân hay việc nhiều team tích hợp, cần thêm tài liệu chi tiết, nhưng vẫn giữ một trang làm điểm vào.

Mình đang soạn thêm các tình huống PO khác theo cùng khung này, kèm mẫu dùng ngay. Nếu bạn muốn nhận khi có bài mới, đăng ký bản tin bên dưới.

• Nhận bài mới qua email

Câu hỏi thường gặp

PRD là gì?

PRD (product requirements document) là tài liệu mô tả vì sao làm một tính năng, cho ai, kết quả mong muốn và phạm vi. Nó giúp designer, kỹ sư và stakeholder cùng hiểu một điều trước khi chia việc thành user story.

PRD một trang gồm những phần nào?

Bảy phần: vấn đề, người dùng, mục tiêu và cách đo, phạm vi và phần không làm, luồng chính, câu hỏi mở, rủi ro và phụ thuộc. Chi tiết như tiêu chí chấp nhận hay thiết kế được link từ trang, không chép vào.

Khi nào một trang là không đủ?

Khi tính năng chạm tới thanh toán, pháp lý hay dữ liệu cá nhân, khi nhiều team phải tích hợp với nhau, hoặc khi quy tắc nghiệp vụ dài. Lúc đó vẫn giữ trang chính làm điểm vào và tách phần chi tiết ra tài liệu riêng có link.

Nguồn kiểm tra

• Atlassian: How to create a product requirements document
• Scrum Guide 2020: Product Owner and Product Backlog
• All Things Distributed: Working Backwards

Bài liên quan

• User story là gì? Cách viết cho người mới, kèm mẫu và ví dụ: Mẫu “Là…, tôi muốn…, để…” là phần dễ. Bài này chỉ cách chọn đúng người dùng, đúng vấn đề và cắt story đủ nhỏ, kèm ví dụ trước và sau.
• Acceptance criteria là gì? Cách viết để QA kiểm thử được: Cách viết acceptance criteria rõ đến mức QA đọc xong là biết phải thử gì, kèm ví dụ mã giảm giá và mẫu dùng ngay.
• Ưu tiên backlog khi việc nào cũng gấp: chọn cách nào?: Cách chọn giữa value vs effort, MoSCoW và RICE, tách hạn chót thật khỏi cảm giác gấp, và gửi stakeholder một ghi chú ưu tiên một trang.
• Cách nói không với sếp và stakeholder mà không mất lòng: Ba cách nói không thay cho một chữ “không”, cách xử lý khi người yêu cầu là sếp hoặc CEO, lúc nào nên escalate, kèm hội thoại mẫu và tin nhắn theo từng cấp.