چطور سند نیازمندی‌های محصول (PRD) را با هوش مصنوعی بنویسیم (قالب رایگان)

سند نیازمندی‌های محصول (PRD) توضیحی کوتاه و ساده از چیزی است که می‌سازید، برای چه کسی است، چه کاری باید انجام دهد و از کجا می‌فهمید که درست کار می‌کند. هوش مصنوعی نوشتن آن را خیلی سریع‌تر می‌کند: یادداشت‌های خام خود را به آن می‌دهید و او آن‌ها را به بخش‌های ساختاریافته، یوزر استوری و حالت‌های لبه تبدیل می‌کند. وظیفه‌ی شما این است که تصمیم‌هایی را که هوش مصنوعی نمی‌تواند بگیرد تأمین کنید، یعنی هدف، محدوده و آنچه کنار گذاشته می‌شود، و آنچه را اضافه می‌کند بررسی کنید.

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

PRD برای چیست (و برای چه نیست)

یک PRD به چهار سؤال جواب می‌دهد:

1. چرا این را می‌سازیم؟ کدام مسئله، برای چه کسی؟
2. نسخه‌ی اول چه کاری باید انجام دهد؟
3. چه کاری را هنوز انجام نمی‌دهد؟
4. چطور می‌فهمیم که کار کرده است؟

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

چه کسانی به آن نیاز دارند

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

هوش مصنوعی در چه کاری خوب است و در چه کاری نه

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

قدم ۱: آنچه می‌دانید را بریزید روی کاغذ

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

• مسئله، در یک یا دو جمله، از دید کاربر.
• چه کسی آن را دارد. مشخص باشید: «حسابدارهای فریلنس با ۱۰ تا ۴۰ مشتری»، نه «کسب‌وکارهای کوچک».
• امروز به جایش چه کار می‌کنند (یک صفحه‌گسترده، ایمیل، ابزاری که از آن خوششان نمی‌آید).
• آن یک نتیجه‌ای که اگر حاصل شود، نسخه‌ی اول موفق است.
• هر چیزی که از قبل می‌دانید انجامش نمی‌دهید.
• محدودیت‌های سخت: ددلاین، بودجه، باید روی گوشی کار کند، باید با ابزاری که از قبل دارید وصل شود.

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

قدم ۲: از هوش مصنوعی یک پیش‌نویس اول بخواهید

یادداشت‌هایتان را بچسبانید و پیش‌نویسی با ساختار ثابت بخواهید. یک پرامپت خوب:

این یادداشت‌های من درباره‌ی یک محصول است. آن‌ها را دقیقاً با این بخش‌ها به یک سند نیازمندی‌های محصول تبدیل کن: خلاصه، مسئله، کاربران، اهداف و معیارهای موفقیت، محدوده (داخل / خارج)، یوزر استوری همراه با معیارهای پذیرش، داده‌ها، دسترسی‌ها، حالت‌های لبه، سؤال‌های باز. زیر دو صفحه بماند. درباره‌ی کاربران یا بازار واقعیتی از خودت نساز؛ هر جا یادداشت‌های من چیزی نگفته، آن را به‌صورت سؤال زیر «سؤال‌های باز» بنویس.

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

قدم ۳: هر بخش را محکم‌تر کنید

پیش‌نویس را بخش به بخش مرور کنید. این پرامپت‌های پیگیری کمک می‌کنند:

مسئله و کاربران

بیان مسئله را در یک یا دو جمله از دید کاربر بازنویسی کن. هیچ کلمه‌ی راه‌حل نباشد.

اگر بیان مسئله اسم محصول شما را ببرد، دارد راه‌حل را توصیف می‌کند، نه مسئله را.

اهداف و معیارهای موفقیت

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

یکی یا دو تا را انتخاب کنید. «بیست حسابدار به مدت یک ماه هفته‌ای یک بار از آن استفاده کنند» قابل اندازه‌گیری است. «بهره‌وری را بهتر کند» نیست.

محدوده

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

ابزارهای هوش مصنوعی تمایل دارند قابلیت اضافه کنند. این پرامپت کاری خلاف آن می‌کند. سختگیر باشید: اکثر PRDهای نسخه‌ی اول بزرگ‌تر از حد لازم‌اند. MVP چیست توضیح می‌دهد چرا نسخه‌های اول کوچک‌تر بیشتر به شما یاد می‌دهند.

یوزر استوری‌ها و معیارهای پذیرش

هر نیازمندی را به شکل یوزر استوری بنویس («به‌عنوان [کاربر]، می‌خواهم [عمل] تا [نتیجه]») همراه با دو تا چهار معیار پذیرش به شکل Given / When / Then.

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

حالت‌های لبه و دسترسی‌ها

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

اینجا هوش مصنوعی ارزشش را نشان می‌دهد. در پیدا کردن حالت‌های خالی و جاهای خالیِ دسترسی که آدم‌ها فراموش می‌کنند سریع است.

قدم ۴: مثل یک آدم شکاک بازبینی کنید

یک بار دیگر کل متن را بخوانید و بررسی کنید:

• هر ادعایی درباره‌ی کاربران از خودتان یا از تحقیق آمده، نه از هوش مصنوعی.
• بخش «خارج» دست‌کم به اندازه‌ی بخش «داخل» بلند باشد.
• هر یوزر استوری معیارهای پذیرشی داشته باشد که کسی بدون پرسیدن از شما بتواند آزمایشش کند.
• بخش داده‌ها هر نوع رکوردی را که اپ نگه می‌دارد و اینکه چه کسی می‌تواند ببیندش فهرست کند.
• سؤال‌های باز صاحب و تاریخ داشته باشند.
• هیچ مطلب فنی بی‌دعوت وارد نشده باشد، مگر اینکه محدودیت واقعی باشد («باید آفلاین کار کند» یک نیازمندی است؛ «از Redis استفاده کن» نیست).

بعد آن را با یک نفر که از محصول استفاده می‌کند یا آن را می‌سازد در میان بگذارید و بپرسید چه چیزی مبهم است. سؤال‌های آن‌ها همان شکاف‌ها هستند.

قالب آماده‌ی PRD

این را در یک سند کپی کنید و کروشه‌ها را جایگزین کنید. بخش‌هایی را که واقعاً کاربرد ندارند حذف کنید.

نام محصول: [نام] مسئول: [شخصی که مسئول تصمیم‌هاست] وضعیت: [پیش‌نویس / در حال بررسی / توافق‌شده] — آخرین به‌روزرسانی: [تاریخ]

۱. خلاصه

[دو یا سه جمله: این چیست، برای چه کسی است و نتیجه‌ی اصلی‌اش چیست.]

۲. مسئله

[مسئله از دید کاربر. امروز چه کاری انجام می‌دهد و چرا این کار آزاردهنده است.]

۳. کاربران

۴. اهداف و معیارهای موفقیت

• هدف: [نتیجه‌ای که نسخه‌ی اول باید به آن برسد]
• معیار: [چطور اندازه‌اش می‌گیرید و هدف عددی]
• غیرهدف: [چیزی که مردم ممکن است فرض کنند، ولی این نسخه قصد ندارد انجامش دهد]

۵. محدوده

در نسخه‌ی اول:

• [قابلیت]
• [قابلیت]

در نسخه‌ی اول نیست:

• [قابلیت، و اینکه چرا می‌تواند صبر کند]
• [قابلیت، و اینکه چرا می‌تواند صبر کند]

۶. یوزر استوری‌ها

استوری ۱: به‌عنوان [کاربر]، می‌خواهم [عمل] تا [نتیجه].

• Given [زمینه]، when [عمل]، then [نتیجه].
• Given [زمینه]، when [عمل]، then [نتیجه].

استوری ۲: به‌عنوان [کاربر]، می‌خواهم [عمل] تا [نتیجه].

• Given [زمینه]، when [عمل]، then [نتیجه].

۷. داده‌ها

۸. دسترسی‌ها

[چه کسی می‌تواند وارد شود، چه نقش‌هایی وجود دارند، و هر نقش چه چیزی را می‌بیند و چه چیزی را می‌تواند تغییر دهد.]

۹. حالت‌های لبه

• [حالت خالی: وقتی هنوز داده‌ای نیست چه نشان داده می‌شود]
• [ورودی نامعتبر: با ایمیل اشتباه یا فیلد خالی چه می‌شود]
• [دسترسی: وقتی کسی صفحه‌ای را باز می‌کند که نباید، چه اتفاقی می‌افتد]

۱۰. یکپارچه‌سازی‌ها و محدودیت‌ها

[پرداخت، ایمیل، ابزارهای موجود، ددلاین، بودجه، دستگاه‌هایی که باید روی آن‌ها کار کند.]

۱۱. سؤال‌های باز

از PRD تا پرامپت

یک PRD خوب تقریباً مستقیم به پرامپت برای ابزار ساخت با هوش مصنوعی تبدیل می‌شود:

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

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

اشتباهات رایج

• نوشتن راه‌حل به‌جای مسئله. «کاربران به داشبورد نیاز دارند» یک راه‌حل است. «صاحبان کسب‌وکار بدون باز کردن تک‌تک فاکتورها نمی‌توانند ببینند کدام‌ها سررسید گذشته دارند» یک مسئله است.
• نبودن بخش «خارج از محدوده». بدون آن، هر گفتگو محدوده را دوباره باز می‌کند.
• گذاشتن هوش مصنوعی کاربر را اختراع کند. پرسونایی که هوش مصنوعی ساخته واقعی به نظر می‌رسد ولی نیست.
• معیارهایی که نمی‌توانید اندازه بگیرید. اگر راهی برای شمارش آن ندارید، معیار نیست.
• هیچ‌وقت به‌روز نکردنش. PRDی که دیگر با آنچه می‌سازید همخوانی ندارد، از نداشتنش بدتر است. تاریخ «آخرین به‌روزرسانی» را نگه دارید و وقتی تصمیم‌ها عوض می‌شوند آن را تغییر دهید.

استفاده از PRD با Mythex

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

پرسش‌ها