PRD چیست و چطور یک سند نیازمندی محصول کاربردی بنویسیم
PRD یا سند نیازمندی محصول، نقطه‌ی اتصال کسب‌وکار و تیم فنی است. در این راهنما می‌بینید یک PRD خوب چه بخش‌هایی دارد، چه چیزهایی نباید در آن باشد و چطور آن را کوتاه و قابل‌استفاده نگه دارید.
PRD مخفف Product Requirements Document است: سندی که می‌گوید چه چیزی ساخته می‌شود، برای چه کسی، و چرا. این سند قرار نیست طولانی یا رسمی باشد. قرار است یک کار انجام دهد: همه‌ی افراد درگیر پروژه، تصویر یکسانی از محصول داشته باشند.
PRD چه چیزی نیست
پیش از اینکه بگویم چه بخش‌هایی دارد، سه برداشت اشتباه را کنار بگذاریم:
- PRD طراحی فنی نیست. درباره‌ی جدول و سرویس و زبان برنامه‌نویسی حرف نمی‌زند. آن‌ها در سند معماری می‌آیند.
- PRD فهرست آرزوها نیست. هر چیزی که «خوب است داشته باشیم» در آن جا ندارد.
- PRD قرارداد سنگی نیست. با یادگیری تیم تغییر می‌کند؛ فقط تغییرش باید مکتوب باشد.
بخش‌های یک PRD کاربردی
۱. مسئله
یک یا دو پاراگراف: چه مشکلی وجود دارد، برای چه کسی، و امروز چطور حل می‌شود. اگر نتوانید مسئله را بدون اشاره به راه‌حل بنویسید، هنوز آن را نفهمیده‌اید.
۲. کاربر و موقعیت
کاربر اصلی کیست و در چه موقعیتی سراغ محصول می‌آید؟ یک پرسونای واقع‌بینانه کافی است. «همه» مخاطب هیچ محصولی نیست.
۳. هدف و معیار موفقیت
هدف باید قابل‌سنجش باشد. «تجربه‌ی بهتر» هدف نیست؛ «کاربر بتواند بدون تماس تلفنی سفارشش را ثبت کند» هدف است. درباره‌ی انتخاب شاخص درست در معیار موفقیت محصول بیشتر نوشته‌ام.
۴. دامنه‌ی نسخه‌ی اول
دو فهرست کنار هم: آنچه در نسخه‌ی اول هست، و آنچه نیست. فهرست دوم مهم‌تر است، چون جلوی بزرگ شدن بی‌صدای پروژه را می‌گیرد. روش بستن دامنه را در MVP واقعی توضیح داده‌ام.
۵. سناریوها
مسیرهای اصلی کاربر، قدم به قدم. نه همه‌ی حالت‌ها؛ فقط آن‌هایی که ارزش محصول را می‌سازند.
۶. قیدها و ریسک‌ها
محدودیت‌های قانونی، فنی، زمانی و بودجه‌ای. هر چیزی که اگر نادیده گرفته شود پروژه را زمین می‌زند.
۷. پرسش‌های باز
چیزهایی که هنوز نمی‌دانید. نوشتن آن‌ها نشانه‌ی ضعف نیست؛ نشانه‌ی صداقت سند است.
یک قالب ساده برای شروع
| بخش | پرسشی که جواب می‌دهد |
|---|---|
| مسئله | چه مشکلی را حل می‌کنیم؟ |
| کاربر | برای چه کسی؟ |
| معیار موفقیت | از کجا بفهمیم موفق شده‌ایم؟ |
| دامنه | چه چیزی در نسخه‌ی اول هست و نیست؟ |
| سناریوها | کاربر چه مسیری را طی می‌کند؟ |
| قیدها | چه چیزی دست ما را می‌بندد؟ |
| پرسش‌های باز | چه چیزی را هنوز نمی‌دانیم؟ |
اشتباه‌های رایج
- نوشتن راه‌حل به جای نیاز. «دکمه‌ی سبز بالای صفحه» نیاز نیست؛ «کاربر باید بتواند در یک قدم سفارش را تأیید کند» نیاز است.
- سند پنجاه‌صفحه‌ای. سندی که خوانده نشود وجود ندارد. PRD خوب را می‌شود در یک نشست خواند.
- نبودن بخش «خارج از دامنه». هر چیزی که صریح کنار گذاشته نشود، دیر یا زود وارد پروژه می‌شود.
- نوشتن در تنهایی. PRD حاصل گفت‌وگو با ذی‌نفعان است، نه حدس یک نفر.
بعد از PRD چه می‌شود
PRD ورودی مرحله‌ی معماری است. وقتی «چه چیزی» روشن شد، نوبت «چطور» می‌رسد: معماری سامانه، مدل داده و قرارداد API. در روش کار من، PRD خروجی گام دوم است و تا تأیید نشود، گام معماری شروع نمی‌شود.
اگر ایده‌ای دارید که هنوز به سند تبدیل نشده، کشف و تعریف محصول همین کار را انجام می‌دهد.