سند الزامات محصول، PRD یا Product Requirements Document چیست؟
سند الزامات محصول (PRD) در فرآیند توسعه محصول استفاده می‌شود تا قابلیت‌هایی را که باید در انتشار محصول گنجانده شود به تیم‌های توسعه و آزمایش ارسال کند. این سند معمولاً بیشتر در محیط‌هایی استفاده می‌شود در آن تعریف، طراحی و تحویل محصول به صورت متوالی اتفاق می‌افتد.
PRD چیست؟
PRD حاوی همه چیزهایی است که باید در یک نسخه گنجانده شود تا کامل در نظر گرفته شود و به عنوان راهنمای اسناد بعدی در فرآیند انتشار عمل می‌کند. در حالی که PRDها ممکن است به یک پیاده سازی بالقوه برای نشان دادن یک مورد استفاده اشاره کنند، اما ممکن است اجرای خاصی را دیکته نکنند.
تفاوت بین PRD و MRD چیست؟
برای چندین دهه، سند الزامات محصول (PRD) مهمترین مصنوعاتی بود که مدیران محصول ایجاد می‌کردند. با زحمت تمام موارد مورد نیاز برای انتشار محصول معین را فهرست می‌کند و به عنوان سند سابقه‌ای عمل می‌کند که کل نسخه بر اساس آن است. به طور خلاصه، اگر در PRD چیزی گنجانده نشود، در نسخه گنجانده نخواهد شد.
PRD ممکن است از یک سند الزامات بازاریابی (MRD) پیروی کند که توسط بازاریابی محصول، بازاریابی یا مدیریت محصول نیز ایجاد شده است که تقاضای مشتری، فرصت بازار و یک مورد تجاری برای محصول کلی یا یک محصول خاص را توصیف می‌کند.
PRD به خودی خود به سوددهی و کسب درآمد مستقیم از بازار نمی‌پردازد، بلکه در موارد استفاده و عملکرد مطلوب ریشه دارد. هر ویژگی یا قابلیت معمولاً به عنوان یک آیتم جداگانه توصیف می‌شود و معمولاً برای هر مورد نیز یک مورد استفاده در نظر گرفته می‌شود.
بر اساس PRD، تعدادی از مصنوعات دیگر توسط دیگران در سازمان ایجاد خواهد شد. مهندسی یک مشخصات کاربردی ایجاد می‌کند که نحوه اجرای هر آیتم در PRD را توضیح می‌دهد. همچنین در صورت نیاز، قاب‌ها و ماکت‌ها را ایجاد می‌کند و تضمین کیفیت یک طرح آزمایشی می‌نویسد تا اطمینان حاصل شود که هر مورد استفاده در PRD می‌تواند با موفقیت در طول آزمایش اجرا شود.
یک PRD یا سند الزامات محصول باید شامل چه مواردی باشد؟
PRD باید شامل هر قابلیت صریح مورد نیاز برای انتشار باشد. برای پشتیبانی از هر قابلیت مورد نظر، باید یک مورد استفاده همراه وجود داشته باشد که نشان دهد کاربر چگونه از این قابلیت استفاده می‌کند و برنامه آزمایش را اطلاع رسانی می‌کند.
اگر یک ویژگی، پیچیده باشد، ممکن است از موارد فرعی برای ارائه جزئیات بیشتر برای تیم‌های فنی استفاده شود. هر یک از این موارد فرعی باید موارد استفاده خاص خود را در صورت لزوم شامل شود. علاوه بر ویژگی‌ها و قابلیت‌های خاص، PRD باید شامل یک نمای کلی وهدف برای انتشار باشد. در حالی که این نباید سعی کند آنچه را در MRD است تکرار کند، بلکه باید دقیقاً آنچه را که تیم محصول در تلاش است با این نسخه خاص به دست آورد (از آنجا که یک MRD ممکن است برای چندین نسخه از یک محصول یا مجموعه محصولات یکسان استفاده شود) را توضیح دهد.
علاوه بر الزامات عملکردی، PRD باید سایر الزامات را نیز مشخص کند. این‌ها شامل هرگونه الزامات سیستمی یا محیطی (یعنی این محصول باید در ویندوز 10 یا جدیدتر اجرا شود، یا باید در مرورگرهای فایرفاکس، کروم و سافاری اجرا شود)، و همچنین هرگونه الزامات قابلیت استفاده (یعنی قابلیت کار کردن با یک دست برای برنامه‌های تلفن همراه) را شامل می‌شود. دسته نهایی مواد تشکیل دهنده برای PRD فرضیات، محدودیت‌ها و وابستگی‌ها هستند.
نمونه‌‌ای از سند الزامات محصول
در زیر یک طرح کلی از آنچه باید در PRD گنجانده شود آورده شده است. هیچ قانون سخت و سریعی برای این وجود ندارد، اما این موارد معمولاً وجود دارند:
- هدف: توضیح دهید که چرا این کار را می‌سازید و امیدوارید چه کاری انجام دهید.
- ویژگی‌ها: برای هر ویژگی، حداقل باید شرح، هدف و مورد استفاده را در نظر بگیرید. جزئیات بیشتر ممکن است بسته به پیچیدگی ویژگی مفید یا ضروری باشد، مانند موارد خارج از محدوده.
- یادداشت‌های جریان و طراحی UX: اکثر سازمان‌ها طراحی UX ویژگی‌ها را پس از بررسی و پذیرش PRD تکمیل می‌کنند. با این حال، ممکن است در این مرحله برای اطمینان از دستیابی به اهداف انتشار، راهنمایی‌های کلی لازم باشد. این مکان برای ماکت‌های پیکسلی کامل یا وایرفریم‌هایی نیست که هر سناریوی ممکن را ترسیم می‌کنند. در عوض، می‌توان از آن برای توصیف گردش کار کلی کاربر استفاده کرد.
- سیستم و محیط مورد نیاز: کدام محیط‌های کاربر نهایی پشتیبانی خواهند شد (مانند مرورگرها، سیستم عامل ها، حافظه و قدرت پردازش و غیره).
- مفروضات، محدودیت‌ها و وابستگی‌ها: فهرستی از آنچه از کاربران انتظار می‌رود، هر محدودیتی برای اجرا و هر عنصر خارجی مورد نیاز برای عملکرد راه‌حل نهایی را فهرست کنید.
مراحل ایجاد PRD
- با فرض اینکه یک MRD از قبل وجود داشته باشد، مدیریت محصول باید ابتدا با بازاریابی محصول مشورت کند تا اطمینان حاصل شود که درک کاملی از محرک‌های کسب و کار برای انتشار خاصی که در PRD شرح داده شده است وجود دارد. از آنجا، هر کدام از روش‌های اولویت‌بندی محصول که قبلاً مورد استفاده قرار گرفته‌اند، باید برای شناسایی مواردی که در حوزه عرضه هستند، مورد استفاده قرار گیرد.
- سپس نوبت به نگارش سند، با استفاده از یادداشت‌ها و بازخورد کاربر برای هر ویژگی موجود در نسخه می‌رسد. در صورت امکان، سند باید چندین دور بررسی را با سایرین در تیم محصول طی کند تا اطمینان حاصل شود که به بسیاری از سؤالات احتمالی پاسخ داده شده است و سند تا حد امکان کامل است.
- با یک PRD کاملاً کامل، باید بعداً در بین سهامداران طرف تجاری منتشر شود تا تأیید شود که آنها با هدف انتشار و ویژگی‌های گنجانده شده برای رسیدن به آن هدف هماهنگ هستند. وقتی به اجماع رسید، زمان آن فرا رسیده است که PRD را به مهندسی بسپاریم.
- در این مرحله سوالات، شفاف سازی‌ها و چالش‌هایی از سوی تیم فنی مطرح می‌شود که باید به صورت شفاهی به آن پرداخته و در صورت لزوم در PRD به روز شود. هدف این است که یک PRD کامل و به اندازه کافی جامع داشته باشیم تا بعداً هیچ غافل‌گیری نداشته باشیم. هنگامی که توافق شد که PRD به آن مرحله رسیده است، سپس برای طراحی UX، مشخصات عملکردی و تعریف طرح آزمایشی به تیم‌های دیگر منتقل می‌شود.
- با گنجاندن همه این تیم‌ها در فرآیند ایجاد و بررسی PRD، همه افراد را با نتیجه و محتوای مورد نظر از انتشار آشنا می‌کند. در مورد اینکه چه چیزی ارسال خواهد شد، چه سودی برای کسب و کار و تأثیر آن بر کاربران در پایان فرآیند خواهد داشت، سؤال کمی وجود دارد.