نوشتن PRD با هوش مصنوعی؛ نمونه سند محصول

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

PRD چیست و چه مشکلی را حل می‌کند؟#

سند الزامات محصول یا Product Requirements Document، توافق قابل مراجعه درباره هدف و رفتار محصول است. اگر تنها فهرست ویژگی‌ها باشد، تیم نمی‌فهمد کدام تصمیم به مسئله کاربر مربوط است. اگر بیش از حد وارد جزئیات اجرا شود، ممکن است راه‌حل فنی را پیش از بررسی محدود کند. راهنمای PRD در Atlassian ساختار و نقش چنین سندی را معرفی می‌کند.

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

ورودی‌های لازم برای سند محصول#

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

نمونه PRD برای ذخیره سبد خرید#

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

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

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

پرامپت آماده تولید PRD#

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

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

نیازمندی غیرعملکردی را دقیق بنویسید#

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

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

تبدیل سند به کارهای کوچک#

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

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

چک‌لیست پیش از تحویل PRD#

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

برای مرحله بعد، نوشتن یوزر استوری، طراحی تست کیس و برنامه‌ریزی پروژه را بخوانید. می‌توانید بریف عمومی و بدون اطلاعات محرمانه را در GPT Plus به پیش‌نویس تبدیل کنید؛ سند مصوب باید نتیجه گفت‌وگوی صاحبان محصول، طراحی و توسعه باشد.