Viết tài liệu đặc tả sản phẩm (Product Spec)

Vai trò: Bạn là Quản lý sản phẩm (Product Manager) đang viết tài liệu đặc tả (product spec/PRD) cho tính năng {feature_name} của sản phẩm {product_name}.

Bối cảnh: Tài liệu đặc tả sản phẩm đóng vai trò là bản cam kết thống nhất giữa các bộ phận Product, Design và Engineering. Tài liệu phải đủ chi tiết để các nhóm có thể làm việc độc lập mà vẫn đồng bộ hướng đi chung, nhưng không quá áp đặt giải pháp làm triệt tiêu khả năng sáng tạo của nhóm phát triển. Tài liệu này sẽ được đọc bởi {audience} (kỹ sư lập trình, nhà thiết kế UX, nhân viên kiểm thử QA, các bên liên quan).

Nhiệm vụ: Viết một tài liệu đặc tả sản phẩm toàn diện. Áp dụng lập luận cây tư duy (tree-of-thoughts): xem xét đồng thời luồng trải nghiệm người dùng, các hướng giải pháp kỹ thuật khả thi, các lỗi phát sinh tiềm ẩn và yêu cầu theo dõi đo lường trước khi soạn thảo từng chương mục.

Thông tin đầu vào khả dụng:

• {feature_name}: Tên của tính năng hoặc sản phẩm
• {problem_statement}: Vấn đề thực tế của người dùng hoặc bài toán kinh doanh cần giải quyết
• {target_users}: Ai sẽ sử dụng tính năng này và bối cảnh sử dụng của họ
• {solution_concept}: Ý tưởng giải pháp vĩ mô đề xuất
• {business_metrics}: Chỉ số đo lường hiệu quả kinh doanh của tính năng
• {constraints}: Các giới hạn về kỹ thuật, pháp lý, thời gian hoặc tài nguyên nhân sự
• {non_goals}: Những gì tài liệu đặc tả này tuyên bố rõ ràng sẽ KHÔNG giải quyết

Định dạng đầu ra:

1. Tuyên bố vấn đề và quy mô cơ hội thị trường
2. Mục tiêu chiến lược và các chỉ số đo lường thành công (nêu rõ số liệu nền tảng hiện tại và số liệu mục tiêu tương ứng)
3. Các nội dung ngoài phạm vi (Non-goals - những gì spec này tuyên bố không giải quyết)
4. Các kịch bản sử dụng (User Scenarios): 3–5 kịch bản chính kèm bối cảnh người dùng và hành vi kỳ vọng
5. Yêu cầu chức năng (Functional Requirements): Danh sách đánh số chi tiết từng hành vi nghiệp vụ của hệ thống
6. Yêu cầu phi chức năng (Non-functional Requirements): Các tiêu chuẩn về hiệu năng tải trang, bảo mật an toàn thông tin, khả năng tiếp cận
7. Các trường hợp lỗi và thông báo xử lý lỗi tương ứng
8. Yêu cầu thiết kế (các nguyên tắc UX chính cần tuân thủ, không đi vào chi tiết giao diện)
9. Lưu ý kỹ thuật vĩ mô (không tự quyết định kiến trúc hệ thống của kỹ sư)
10. Các câu hỏi mở cần giải quyết trước khi bắt đầu lập trình
11. Kế hoạch ra mắt và triển khai

Nguyên tắc & Kiểm soát chất lượng:

• Mỗi yêu cầu chức năng phải được mô tả sao cho có thể kiểm thử độc lập một cách khách quan
• Chỉ số đo lường thành công bắt buộc phải có số liệu hiện trạng làm mốc đối chiếu so sánh sau này
• Các câu hỏi mở phải ghi kèm thời hạn cần có câu trả lời và người chịu trách nhiệm ra quyết định
• Phần ngoài phạm vi (non-goals) cực kỳ quan trọng để ngăn chặn tình trạng phình to phạm vi dự án (scope creep) — hãy mô tả thật rõ ràng