راهنمای مولد PRD اولیه؛ از مسئله خام تا سند قابل نقد

مولد PRD اولیه زمانی مفید است که مسئله را روشن‌تر کند؛ نه زمانی که چند ورودی مبهم را به سندی رسمی و غیرقابل پرسش تبدیل کند. ظاهر مرتب یک PRD می‌تواند حس قطعیت ایجاد کند، حتی اگر تعریف کاربر، شواهد، محدوده یا معیار موفقیت هنوز بر حدس تکیه داشته باشد. بنابراین کیفیت خروجی بیشتر از هر چیز به کیفیت ورودی و شیوه بازبینی تیم بستگی دارد.

مولد PRD اولیه میم‌یار یک ابزار زنده و رایگان است که اطلاعات خام مسئله را به پیش‌نویسی ساختاریافته تبدیل می‌کند. ابزار از ورودی‌های شما هدف، Non-goal، User story، معیار پذیرش، سنجه، ریسک و وابستگی می‌سازد و امکان کپی یا دریافت خروجی Markdown را می‌دهد. بااین‌حال تحقیق کاربر، تصمیم تیم و بررسی فنی را جعل یا جایگزین نمی‌کند. خروجی نسخه ۰.۱ است: نقطه شروع گفت‌وگو، نه قرارداد نهایی ساخت.

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

PRD اولیه چه کاری باید انجام دهد؟ {#what-prd-should-do}

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

راهنمای رسمی Atlassian درباره PRD بر جهت مشترک، نیاز کاربر، انعطاف و همکاری تیم تأکید می‌کند و از سند بسیار جزئی و امضاشده پیش از مشارکت طراحی و مهندسی به‌عنوان الگوی مسئله‌دار یاد می‌کند. یک PRD خوب باید «به‌اندازه کافی» زمینه بدهد تا تیم بتواند گزینه‌ها را نقد کند؛ نه این‌که راه‌حل را از پیش قطعی جلوه دهد.

سه خروجی عملی از PRD اولیه انتظار داشته باشید:

• اختلاف برداشت نقش‌ها زود آشکار شود؛
• فرض‌ها و سؤال‌های باز قابل مشاهده باشند؛
• محدوده و معیار تصمیم پیش از شروع ساخت قابل نقد شوند.

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

قبل از ورود به ابزار: گیت آمادگی {#readiness-gate}

پیش از پرکردن فرم، بررسی کنید حداقل اطلاعات لازم واقعاً وجود دارد. نام قابلیت به‌تنهایی کافی نیست. شما باید بتوانید کاربر اولیه، موقعیت مسئله، شاهد موجود، نتیجه مطلوب و یک معیار قابل مشاهده را توضیح دهید. اگر این موارد مبهم‌اند، ابزار فقط ابهام را مرتب می‌کند.

چهار سؤال گیت:

1. آیا مسئله بدون نام‌بردن از راه‌حل قابل بیان است؟
2. آیا شواهدی فراتر از نظر داخلی دارید؟
3. آیا اولین گروه کاربر آن‌قدر دقیق است که بتوانید او را پیدا کنید؟
4. آیا می‌دانید چه رفتاری ادامه، اصلاح یا توقف را فعال می‌کند؟

اگر پاسخ چند سؤال «نه» است، ابتدا ارزیابی آمادگی MVP یا ابزار بررسی وضوح مسئله را اجرا کنید. PRD نباید جای Discovery را بگیرد. در عوض، آنچه از Discovery آموخته‌اید را به زبان قابل تصمیم تبدیل می‌کند.

فیلدهای زمینه و صورت مسئله {#context-and-problem}

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

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

صورت مسئله را با نام قابلیت شروع نکنید. «کاربر به داشبورد جدید نیاز دارد» راه‌حل را داخل مسئله پنهان می‌کند. قالب کاربردی‌تر چنین است: «[گروه کاربر] در [موقعیت] برای [کار] با [مانع قابل مشاهده] روبه‌رو است و در نتیجه [پیامد] رخ می‌دهد.»

راهنمای GOV.UK برای تعریف نیاز کاربر نیز بر مسئله و نتیجه مورد نیاز کاربر تأکید می‌کند، نه کانال یا راه‌حل از پیش انتخاب‌شده. این مرز اجازه می‌دهد تیم چند گزینه را مقایسه کند.

کاربر اولیه و شواهد موجود {#audience-and-evidence}

در فیلد «کاربر اولیه» از عنوان‌های بسیار عمومی پرهیز کنید. «همه مدیران»، «فروشگاه‌ها» یا «کاربران اپ» برای آزمون اولیه کافی نیستند. نقش، زمینه، محرک و رفتار فعلی را بنویسید. هدف ساخت Persona تزئینی نیست؛ هدف تشخیص گروهی است که مسئله را در شرایط مشابه تجربه می‌کند.

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

راهنمای GOV.UK درباره شناخت نیازهای کاربران توصیه می‌کند نظرها و پیشنهادهایی که از کاربران نیامده‌اند به‌عنوان فرض نیازمند تحقیق دیده شوند. در PRD نیز بهتر است هر ادعا یکی از این برچسب‌ها را داشته باشد: شاهد، استنباط، فرض یا سؤال باز.

نتیجه مطلوب و معیار موفقیت {#outcome-and-metric}

نتیجه مطلوب توضیح می‌دهد کاربر پس از حل مسئله چه چیزی را بهتر، سریع‌تر یا مطمئن‌تر انجام می‌دهد. نتیجه را با خروجی تیم اشتباه نگیرید. «انتشار صفحه گزارش» خروجی است؛ «کاربر بتواند وضعیت پروژه را بدون جمع‌آوری دستی اطلاعات تشخیص دهد» به نتیجه نزدیک‌تر است.

معیار موفقیت باید چهار جزء داشته باشد: رفتار، سنجه، آستانه و بازه تصمیم. اگر آستانه واقعی هنوز تعیین نشده است، مقدار جعلی وارد نکنید. بنویسید چه چیزی باید در جلسه تصمیم تعیین شود. معیار «افزایش رضایت» بدون روش اندازه‌گیری و زمان بازبینی قابل استفاده نیست.

معیار را به تصمیم وصل کنید:

• چه نتیجه‌ای فرضیه را پشتیبانی می‌کند؟
• چه نتیجه‌ای نیازمند اصلاح است؟
• چه نتیجه‌ای باعث توقف یا بازتعریف مسئله می‌شود؟

این قواعد بهتر است پیش از مشاهده داده نوشته شوند تا تیم بعداً هر نتیجه‌ای را موفق تفسیر نکند.

داخل محدوده و خارج از محدوده {#scope-and-non-goals}

ابزار دو فیلد جدا برای Scope و Non-goal دارد. داخل محدوده باید کوچک‌ترین جریان کامل لازم برای آزمون فرضیه را نشان دهد. خارج از محدوده نیز مواردی را ثبت می‌کند که ممکن است ارزشمند باشند اما فعلاً برای پاسخ به سؤال اصلی ضروری نیستند.

Non-goal فهرست دورریختنی‌ها نیست. یک قرارداد تمرکز است. برای هر مورد خارج محدوده، دلیل کوتاهی بنویسید: وابسته به یادگیری مرحله اول، ریسک بیشتر از ارزش فعلی، یا مناسب نسخه بعد. این توضیح هنگام ورود درخواست‌های تازه از بحث سلیقه‌ای جلوگیری می‌کند.

Atlassian نیز در راهنمای PRD توصیه می‌کند تیم صریحاً مشخص کند چه کاری انجام نمی‌دهد. مرز خوب به تیم اجازه می‌دهد بدون قفل‌کردن آینده، نسخه جاری را کنترل کند.

محدودیت‌ها، وابستگی‌ها و ریسک‌ها {#constraints-risks}

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

این سه را با هم مخلوط نکنید. «API پرداخت موجود نیست» می‌تواند وابستگی باز باشد؛ «ممکن است تأیید آن دیر برسد» ریسک است؛ «اطلاعات کارت نباید در سامانه ذخیره شود» محدودیت امنیتی است. خروجی مولد می‌تواند این مواد خام را ساختاربندی کند، اما اعتبار فنی یا حقوقی آن‌ها باید توسط نقش مسئول بررسی شود.

برای هر ریسک، مالک، نشانه هشدار و اقدام کاهش بنویسید. فهرست ریسک بدون مسئول و اقدام فقط اضطراب را مستند می‌کند.

مثال فرضی: گزارش وضعیت پروژه {#hypothetical-example}

فرض کنید تیمی می‌خواهد یک قابلیت «گزارش وضعیت پروژه» را بررسی کند. داده‌های زیر نمونه آموزشی‌اند و واقعیت بازار یا تجربه میم‌یار نیستند.

زمینه فعلی: مدیر پروژه برای آماده‌کردن جلسه هفتگی اطلاعات را از چند کانال جمع می‌کند و اعضا درباره وضعیت یکسان برداشت متفاوت دارند. دلیل تصمیم، کاهش ابهام پیش از جلسه است.

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

کاربر اولیه: مدیر پروژه تیم پنج تا پانزده نفره که کار را در یک ابزار پیگیری می‌کند اما تصمیم‌ها و Blockerها در کانال‌های جدا ثبت می‌شوند. این مشخصات صرفاً فرض نمونه‌اند.

شاهد: چند یادداشت داخلی وجود دارد، اما تحقیق کافی انجام نشده است؛ بنابراین باید به‌عنوان فرض نیازمند بررسی ثبت شود.

نتیجه مطلوب: مدیر بتواند پیش از جلسه، وضعیت، مانع و تصمیم بعدی را در یک نمای قابل مرور تشخیص دهد.

داخل محدوده: نمایش پروژه، کارهای متوقف، تصمیم‌های باز و مالک هر اقدام.

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

معیار: رفتار و بازه بازبینی تعریف می‌شوند، اما آستانه عددی تا پیش از خط پایه جعل نمی‌شود.

این ورودی‌ها باید پیش‌نویسی بسازند که تیم بتواند نقد کند: آیا گروه کاربر بیش از حد گسترده است؟ آیا شاهد کافی است؟ آیا «نمای وضعیت» راه‌حل زودهنگام است؟ آیا معیار واقعاً نتیجه را می‌سنجد؟ ارزش ابزار در ایجاد همین پرسش‌هاست.

خروجی مولد را چگونه نقد کنیم؟ {#review-generated-prd}

پس از تولید سند، بلافاصله آن را وارد Backlog توسعه نکنید. یک بازبینی کوتاه با محصول، طراحی، مهندسی و در صورت نیاز داده، محتوا، امنیت یا عملیات برگزار کنید. هر نقش باید از زاویه ریسک خودش سند را نقد کند.

چک‌های اصلی:

• آیا مسئله بدون راه‌حل قابل فهم است؟
• آیا User story شامل کاربر، نیاز و هدف است؟
• آیا معیار پذیرش «نتیجه قابل مشاهده» است یا دستور پیاده‌سازی؟
• آیا Non-goal واقعاً جلوی تورم محدوده را می‌گیرد؟
• آیا محدودیت و وابستگی مالک دارد؟
• آیا معیار موفقیت به تصمیم مشخص وصل است؟
• کدام جمله شاهد ندارد و باید فرض علامت بخورد؟

راهنمای GOV.UK درباره User story می‌گوید Story باید کاربر، نیاز و هدف را توضیح دهد و Acceptance Criteria فهرستی از Outcomeها برای تشخیص انجام‌شدن کار باشد. اگر خروجی ابزار معیار پذیرشی مبهم ساخت، آن را بازنویسی کنید؛ تولید خودکار دلیل کافی برای پذیرش نیست.

خطاهای رایج در استفاده از مولد PRD {#common-mistakes}

نوشتن راه‌حل به‌جای مسئله: باعث می‌شود ابزار سندی منظم برای گزینه‌ای بسازد که هنوز مقایسه نشده است.

ساختن شاهد و عدد: اگر داده ندارید، نبود آن را ثبت کنید. عدد بی‌منبع اعتماد کاذب ایجاد می‌کند.

پرکردن فرم توسط یک نفر: PRD قرارداد گفت‌وگوست. مهندسی و طراحی باید پیش از تعهد به Scope امکان نقد داشته باشند.

تبدیل نسخه اولیه به سند ثابت: با یادگیری تازه، شواهد، سؤال‌ها و محدوده تغییر می‌کنند. تاریخ و مالک بازبینی را مشخص کنید.

کپی مستقیم به توسعه: خروجی Markdown آماده انتقال است، اما قبل از تبدیل به Ticket باید تصمیم‌ها، وابستگی‌ها و معیار پذیرش تأیید شوند.

گردش کار پیشنهادی پس از تولید {#next-workflow}

1. خروجی Markdown را ذخیره و نسخه آن را مشخص کنید.
2. فرض‌ها و سؤال‌های باز را از متن جدا و مالک‌گذاری کنید.
3. یک بازبینی چندتخصصی برگزار کنید.
4. Scope و Non-goal را بر اساس ظرفیت و ریسک اصلاح کنید.
5. User storyها را به واحدهای قابل آزمون تقسیم کنید.
6. معیار پذیرش و Definition of Done را با تیم تحویل هماهنگ کنید.
7. لینک شواهد، طراحی و تصمیم‌ها را به سند اضافه کنید.
8. پس از هر یادگیری مهم، PRD را به‌روزرسانی و دلیل تغییر را ثبت کنید.

PRD اولیه باید مسیر یادگیری را باز نگه دارد. راهنمای Service Standard دولت بریتانیا نیز بر روش‌های تکرارشونده، مشاهده کاربران و انطباق بر اساس یادگیری تأکید می‌کند؛ مشخص‌کردن همه چیز پیش از شناخت کافی، ریسک ساختن چیز اشتباه را بالا می‌برد.

اکنون می‌توانید مولد PRD اولیه را اجرا کنید. ورودی‌ها را بر اساس وضعیت امروز و شواهد واقعی بنویسید، خروجی را نسخه ۰.۱ بدانید و پیش از ورود به ساخت آن را با تیم کامل نقد کنید.