سند نیازمندی محصول (PRD) چیست؟ ساختار، نمونه و اشتباه‌های رایج
سند نیازمندی محصول (PRD) جایی است که مدیر محصول می‌نویسد چه چیزی، برای چه کسی و چرا ساخته می‌شود و موفقیت یعنی چه. این راهنما ساختار ساده‌ای برایش می‌دهد، با یک نمونهٔ کوتاه، و می‌گوید PRD با تسک و نقشهٔ راه چه فرقی دارد.
آخرین بازبینی: ۱۷ مهر ۱۴۰۵
PRD چیست؟
PRD مخفف Product Requirements Document است: سندی که یک قابلیت یا محصول را برای طراحی، مهندسی و تست روشن می‌کند. هدفش این نیست که همه‌چیز را از قبل تعیین کند، بلکه این است که همه یک تصویر مشترک از مشکل و نتیجهٔ مورد انتظار داشته باشند.
PRD خوب کوتاه است. اگر کسی نتواند در پنج دقیقه بفهمد این کار برای چیست، سند بلند فقط کار را کند می‌کند.
ساختار پیشنهادی
این بخش‌ها برای بیشتر سندها کافی است:
| بخش | چه چیزی می‌نویسیم؟ |
|---|---|
| مشکل | کدام مشکل کاربر را حل می‌کنیم و از کجا می‌دانیم؟ |
| هدف و معیار موفقیت | اگر موفق شویم چه چیزی عوض می‌شود و با چه عددی می‌سنجیم؟ |
| کاربران | برای چه کسانی ساخته می‌شود؟ |
| خارج از دامنه | چه چیزی را در این مرحله نمی‌سازیم؟ |
| نیازمندی‌ها | چه چیزهایی باید درست کار کند؟ هر کدام قابل‌آزمایش |
| طراحی و وابستگی‌ها | لینک طراحی، API و تیم‌هایی که در این کار شریک‌اند |
| برنامه و ریسک‌ها | در کدام هفته‌های فصل؟ چه چیزی ممکن است خراب شود؟ |
| پرسش‌های باز | چه چیزی هنوز معلوم نیست و چه کسی باید جواب بدهد؟ |
یک نمونهٔ کوتاه
برای قابلیت «ورود با رمز یک‌بار مصرف» در یک اپ پرداخت، بخش‌ها این‌طور پر می‌شود:
- مشکل: ۱۸٪ ورودهای ناموفق به‌خاطر فراموشی رمز است و پشتیبانی هر هفته ده‌ها درخواست بازیابی می‌گیرد.
- هدف: کم‌کردن ورودهای ناموفق به نصف تا پایان فصل؛ معیار: نرخ ورود موفق در هفتهٔ اول هر ماه.
- کاربران: مشتریان فعلی اپ موبایل.
- خارج از دامنه: ورود با اثر انگشت.
- نیازمندی: وقتی کاربر کد اشتباه وارد کند، پیام «کد درست نیست» می‌آید؛ بعد از پنج تلاش ناموفق ورود ده دقیقه قفل می‌شود.
- پرسش باز: پیامک را کدام سرویس بفرستد؟ (تیم زیرساخت، تا پایان هفتهٔ اول)
(این عددها و جزئیات فقط یک نمونه‌اند.)
PRD، تسک و نقشهٔ راه
- نقشهٔ راه می‌گوید چه چیزی، کی و به دست چه تیمی انجام می‌شود.
- PRD می‌گوید آن چیز چیست و چرا، و موفقیتش چطور سنجیده می‌شود.
- تسکها کار قابل‌انجام برای یک نفر هستند که از PRD بیرون می‌آیند.
سه‌تایی که به هم وصل باشند، یعنی از هر تسک می‌شود به سند رسید و از سند به آیتم نقشهٔ راه.
اشتباه‌های رایج
- سندی که فقط راه‌حل می‌نویسد و مشکل را نه؛ تیم نمی‌تواند راه بهتری پیشنهاد بدهد.
- نیازمندی‌های مبهم («سریع باشد»)؛ هر نیازمندی باید قابل‌آزمایش باشد.
- ننوشتن «خارج از دامنه»؛ دامنه کم‌کم بزرگ می‌شود.
- سندی که یک بار نوشته می‌شود و بعد کسی به‌روزش نمی‌کند.
- نوشتن سند به‌جای صحبت با تیم؛ سند جای گفتوگو را نمی‌گیرد، آن را ثبت می‌کند.
PRD در مسیر
در مستندات مسیر می‌توانید PRD را با Markdown و در فضا و درخت صفحه‌ها بنویسید، آن را به آیتم نقشهٔ راه یا تسکها وصل کنید و تاریخچهٔ نسخه‌ها را نگه دارید. از روی همان سند، دستیار هوشمند پیش‌نویس تسکها را می‌نویسد و پس از مرور و تأیید شما ساخته می‌شوند.
پرسش‌های رایج
PRD چند صفحه باشد؟
تا جایی که لازم است و نه بیشتر. برای یک قابلیت معمولی یک تا دو صفحه کافی است. اگر سند بلند شد، آن را به چند سند وابسته بشکنید.
در تیم چابک هم PRD لازم است؟
بله، ولی سبکتر. بسیاری از تیمهای چابک سندی کوتاه مینویسند و جزئیات را در تسکها و گفتوگو روشن میکنند.
چه کسی PRD را می‌نویسد؟
معمولاً مدیر محصول، با مشورت طراحی و مهندسی. مهم این است که کسانی که آن را می‌سازند قبل از نهایی‌شدن بخوانندش.
صفحه‌های مرتبط
مدیر محصول چیست؟
مدیر محصول مسئول این است که تیم چیز درست را بسازد: شناخت مشکل کاربر، استراتژی، نقشهٔ راه و اولویت‌ها. وظایف و فرقش با مدیر پروژه.
ویکی و مستندات شرکت
مستندات محصول، راهنماها و تصمیم‌های شرکت را در یک ویکی بنویسید: درخت صفحه‌ها، Markdown، تاریخچهٔ نسخه‌ها، جست‌وجو و اتصال به آیتم‌ها و تسکها.
نوشتن تسک خوب
تسک خوب عنوان روشن، نتیجهٔ مورد انتظار و شرایط پذیرش دارد. فرمول ساده، یک نمونهٔ مبهم و آماده کنار هم، و چک‌لیست پیش از ساختن تسک.
ویکی داخلی شرکت
ویکی داخلی جایی است که دانش تیم نوشته می‌شود. چه چیزی بنویسیم، ساختار صفحه‌ها چه باشد و چطور مستندات کهنه نشود.
مسیر را یک هفته رایگان امتحان کنید
ثبت‌نام کمتر از یک دقیقه طول می‌کشد و به کارت بانکی نیازی نیست.
شروع رایگان