چطور ایده رو به یه PRD قابل‌اجرا تبدیل کنیم؟

با راه‌حل شروع نکن

ایده معمولاً به شکل قابلیت بیان می‌شه: «یه دستیار هوشمند بسازیم». قبل از فهرست امکانات، کاربر، موقعیت و تغییری که باید رخ بده رو روشن کن. صورت مسئلهٔ خوب می‌گه چه کسی الان برای انجام چه کاری با چه مانعی روبه‌روست و چرا حلش مهمه.

بدون این پایه، PRD به فهرست آرزوها تبدیل می‌شه و هر عضو تیم تعریف متفاوتی از موفقیت داره. بدتر اینکه وقتی وسط کار باید بین دو گزینه انتخاب کنی — و همیشه باید — هیچ معیاری برای انتخاب نداری.

یک تست ساده

صورت مسئله‌ت رو بخون و بپرس: می‌شه این جمله رو رد کرد؟ اگه هیچ‌کس نمی‌تونه بگه «نه، این‌طور نیست»، یعنی آن‌قدر کلی نوشتی که هیچی نگفتی. «کاربران تجربهٔ بهتری می‌خواهند» قابل رد نیست. «کاربران برای پیداکردن فاکتور ماه قبل به‌طور میانگین چهار صفحه جابه‌جا می‌شوند» قابل رده — و قابل ساختن.

شواهد و فرض‌ها رو از هم جدا کن

اونچه از مصاحبه، داده یا رفتار کاربر می‌دونی کنار شواهد بنویس و برداشت‌های هنوز آزموده‌نشده رو با برچسب فرض نگه دار. این جداسازی اجازه می‌ده نسخهٔ اول برای یادگیری طراحی بشه، نه برای اثبات سلیقهٔ تیم.

بعد فرض‌ها رو مرتب کن: کدوم یکی اگه غلط باشه، کل ایده می‌ریزه؟ اون فرض رو اول آزمایش کن. اگه مهم‌ترین فرض اینه که کاربر حاضره فایلش رو بارگذاری کنه، قبل از ساخت موتور پیچیده باید همین رفتار رو با نمونهٔ ساده آزمایش کنی.

جریان اصلی و خارج از دامنه رو ببند

مسیر طلایی کاربر رو از نقطهٔ ورود تا دریافت ارزش توی چند گام توصیف کن. اگه بیشتر از هفت هشت گام شد، احتمالاً داری دو تا مسیر رو با هم توصیف می‌کنی.

بعد موارد خارج از نسخهٔ اول رو صریح بنویس؛ مثلاً همکاری تیمی، اپ موبایل یا اتصال به همهٔ سرویس‌ها. خارج از دامنه به معنی بی‌اهمیت‌بودن نیست، بلکه از پخش‌شدن تمرکز جلوگیری می‌کنه. هر قابلیت باید مستقیم به یه گام از جریان اصلی یا یه محدودیت ضروری وصل باشه.

بخش «خارج از دامنه» معمولاً کم‌نوشته‌ترین و پرارزش‌ترین بخش یه PRDه. چیزی که ننوشتی بیرونه، یه نفر فرض می‌کنه داخله — و اون فرض معمولاً وسط کار، وقتی گران‌ترینه، معلوم می‌شه.

معیار پذیرش قابل مشاهده بنویس

عبارت‌هایی مثل «سریع باشه» یا «تجربهٔ خوبی بده» برای ساخت و آزمون کافی نیستن. مشخص کن کاربر چه عملی انجام می‌ده، سیستم توی هر حالت چه نتیجه‌ای نشون می‌ده و خطا چطور مدیریت می‌شه.

معیارها رو از دید رفتار بیرونی بنویس، نه جزئیات پیاده‌سازی. «باید از Redis استفاده کند» یه تصمیم معماری‌ست که جاش اینجا نیست؛ «نتیجهٔ جست‌وجو زیر یک ثانیه برمی‌گردد» یه معیار پذیرشه.

حالت‌هایی که همیشه جا می‌مونن

• حالت خالی — کاربر تازه ثبت‌نام کرده و هیچ داده‌ای نداره. چی می‌بینه؟
• حالت خطا — سرویس بیرونی جواب نمی‌ده. پیام چیه و کاربر چه کاری می‌تونه بکنه؟
• حالت انتظار — عملیات ده ثانیه طول می‌کشه. کاربر از کجا می‌فهمه که کار داره انجام می‌شه؟
• حالت مرزی داده — اسم خیلی بلند، عدد صفر، تاریخ گذشته، فایل خالی.
• حالت همزمانی — کاربر دو بار روی دکمه می‌زنه یا دو تب باز داره.

این پنج تا حدود نیمی از کار پیاده‌سازی واقعی رو تشکیل می‌دن و تقریباً هیچ‌وقت در نسخهٔ اول PRD نیستن. نوشتنشون از قبل، خیلی ارزون‌تر از کشف‌کردنشون در تست پذیرشه.

از یک جمله تا یک اسکلت: یک مثال

ایدهٔ خام: «می‌خوایم به کاربرها اعلان بدیم». این جمله هیچ‌کدوم از سؤال‌های بالا رو جواب نمی‌ده. ببینیم بعد از عبور از چهار بخش قبلی چه شکلی می‌شه.

# اعلان‌های درون‌برنامه

## مسئله
کاربرانی که بیش از سه روز وارد نشده‌اند، درخواست‌های باز خود را
از دست می‌دهند و از طریق پشتیبانی پیگیری می‌کنند.

## کاربر
کاربر فعالی که حداقل یک درخواست باز دارد.

## شاخص موفقیت
سهم درخواست‌هایی که بدون تماس با پشتیبانی بسته می‌شوند.

## جریان اصلی
1. رویدادی روی درخواست کاربر رخ می‌دهد.
2. اعلان ساخته و خوانده‌نشده علامت‌گذاری می‌شود.
3. کاربر نشانگر را می‌بیند و فهرست را باز می‌کند.
4. با کلیک روی اعلان به همان درخواست می‌رود.

## خارج از دامنه (نسخه اول)
- ایمیل و پیامک
- تنظیمات دلخواه کاربر برای انواع اعلان
- اعلان دسته‌جمعی از سمت ادمین

## معیار پذیرش
- اعلان خوانده‌شده دیگر در شمارنده نمی‌آید.
- کاربر بدون درخواست باز، حالت خالی با متن راهنما می‌بیند.
- اگر سرویس اعلان در دسترس نباشد، بقیه برنامه کار می‌کند.

## پرسش‌های باز
- اعلان خوانده‌نشده تا کِی نگه داشته شود؟

این سند هنوز کوتاهه و عمداً هم کوتاهه. ولی به تقریباً هر سؤالی که موقع ساخت پیش میاد جواب می‌ده: نمی‌دونی ایمیل هم باید بفرستی یا نه؟ نوشته که نه. نمی‌دونی حالت خالی چی باشه؟ نوشته.

و به اون بخش آخر دقت کن. یه پرسش باز که جوابش رو نمی‌دونی، نوشتنش صادقانه‌تر از حدس‌زدنه. اون پرسش بعداً یا با داده جواب داده می‌شه یا با یه تصمیم صریح — ولی در هر دو حالت، کسی بی‌خبر یه جواب دلبخواه براش انتخاب نمی‌کنه.

PRD در عصر ایجنت‌ها

یه تغییر جالب اتفاق افتاده: حالا PRD فقط برای آدم‌ها نوشته نمی‌شه. وقتی یه ایجنت کدنویس قراره بخشی از کار رو انجام بده، همون سند تبدیل می‌شه به منبع اصلی تصمیم‌هاش.

این یعنی ابهامی که قبلاً با یه سؤال در جلسه حل می‌شد، حالا به‌صورت یه حدس ساکت وارد کد می‌شه. PRD مبهم قبلاً هزینه‌ش یه جلسهٔ اضافه بود؛ حالا هزینه‌ش کدی‌ست که کار می‌کنه ولی چیزی که می‌خواستی نیست.

چیزهایی که به همین دلیل ارزششون بالا رفته: معیار پذیرش صریح، فهرست خارج از دامنه، و نام‌بردن از الگوی موجودی که باید دنبال بشه. این‌ها دقیقاً همون چیزهایی‌ان که یه قرارداد کار خوب رو می‌سازن.

PRD سند زندهٔ تصمیمه

PRD نباید بعد از جلسهٔ آغاز پروژه فراموش بشه. با تغییر شواهد، تصمیم و دامنه‌ش رو کوتاه و شفاف به‌روز کن و تاریخچهٔ دلیل‌ها رو نگه دار. شش ماه بعد، سؤال «چرا این‌طوری ساختیمش؟» حتماً پرسیده می‌شه.

بخش‌های اصلی شامل مسئله، کاربر، هدف، شاخص موفقیت، جریان، نیازمندی‌ها، خارج از دامنه، ریسک و پرسش بازه. اون بخش آخر — پرسش‌های باز — معمولاً حذف می‌شه چون ناتمام به نظر می‌رسه؛ در حالی که صادقانه‌ترین بخش سنده.

کیفیت PRD با تعداد صفحه سنجیده نمی‌شه؛ با کم‌شدن ابهام و سرعت تصمیم تیم سنجیده می‌شه. اگه بعد از نوشتنش، سؤال‌های جلسه کمتر نشد، هنوز کار داره.