چه مدیرعامل هستی، چه مدیرمحصول، چه پروداکت اونر و خلاصه هر کسی که مدیرعامل یا یکی از سهامدارا اومده و بهت گفته که یک ایده دارم میخوام یک محصول تولید کنیم بدون این پست وبلاگ دقیقا برای تو نوشته شده.
در طول این سال‌ها، درگیر فرآیندهای مختلف طراحی محصول بوده‌ام، چه آن‌هایی که از ابتدا شروع شده‌اند و چه محصولاتی که در مرحله توسعه بوده‌اند. برای من، چالش‌برانگیزترین و هم‌زمان جذاب‌ترین بخش زمانی است که علاوه بر شکل‌گیری هسته اصلی تیم، باید محصول هم طراحی شود.
در چند تجربه کاری اخیرم که به عنوان مشاور کنار چند کسب‌وکار سنتی بودم، مسئولیت جمع‌آوری تیمی برای توسعه ایده‌های بنیان‌گذاران یا شرکت‌ها بر عهده من بود. هم تیم را انتخاب کردم و هم مسیر توسعه محصول را طراحی کردم. این تجربه، در کنار تجارب دیگرم در پیدا کردن افراد مناسب، به من آموخت که چه مواردی باید پیش از شروع توسعه محصول و حتی قبل از استخدام یک مدیر محصول (PM) یا اولین فرد فنی (PO) انجام شود.
به‌عنوان صاحب ایده و مدیرعامل، خودتون باید این مستند رو که در ادامه معرفی میکنم بنویسید، یا حداقل پیش‌نویسش رو آماده کنید. یا اگر به‌عنوان مدیر محصول تو شرایط مشابه هستید، بهتره که اول این نوع مستند رو درست کنید. این مستند پر از خلاقیته و به همین دلیل بهتره بیشتر روی بخش‌ها تمرکز کنید و نه اینکه چطور این مستند پر میشه. هر بخش رو به هر شکلی که دوست دارید می‌تونید کامل کنید.
این فایل که من درست کردم رو به اسم Product Requirement Document (PRD) تهیه کردم که می‌تونه به شما کمک کنه تا از ابتدا فکرتون رو متمرکز کنید، چون برای شروع طراحی محصول واقعاً مهم‌ترین موضوعه. حتی به‌عنوان مدیرعامل و صاحب کسب‌وکار بهتون پیشنهاد میکنم که قبل از استخدام مدیر محصول، این فایل رو تا جایی که می‌تونید خودتون بنویسید و بعد از مدیر محصول بخواهید که ادامه کار رو انجام بده. در اصل، من این نمونه فایل Product Requirement Document (PRD) رو رایگان آماده کردم و می‌تونید به‌راحتی ازش استفاده کنید. چندین مستند مرتبط رو بررسی کردم و تجربه‌ام از همه اون‌ها رو توی این فایل خلاصه کردم تا بهترین خروجی رو بهتون ارائه بدم.
در ادامه این بلاگ پست میخوام بخش‌بندی‌های این فایل Product Requirement Document رو بیشتر توضیح بدم. توی فایل، بخش اول با What is the Product شروع کردم، که باید خلاصه‌ترین پاسخ رو برای هر کسی که می‌خواد بدونه محصول چی هست بنویسید. بعد از اون، بخش بسیار مهمی به نام What is the Problem? هست که باید به‌صورت کامل و دقیق توضیح بدید که مشکل دقیقاً چیه. چه مشکلی وجود داشته یا الان هست که شما رو به فکر این ایده انداخته. در نهایت، به What is our Solution? می‌رسیم، که باید با جزئیات مشخص کنید برای هر کدوم از چالش‌های مطرح‌شده در بخش قبلی، چه پیشنهاد یا راهکاری دارید که اون‌ها رو حل کنه.
یکی دیگه از بخش‌ها که در این فایل اومده، بخش Product Vision هست. به نظر من، یکی از مهم‌ترین کارهایی که باید برای یک محصول انجام داد، تعیین این ویژن و مشخص کردن آینده محصول است. باید دقیقاً مشخص کنید که محصول در آینده کجا خواهد بود و چه جایگاهی خواهد داشت. به اعتقاد من، محصولی که ویژن نداشته باشه، واقعاً در معرض شکست قرار داره. بنابراین، باید یک ویژن و میشن خیلی مشخص و روشن داشته باشید تا مسیر توسعه و موفقیت محصول به‌خوبی تعریف بشه.
یکی دیگه از بخش‌هایی که من دوست دارم توی فایل باشه و همیشه روش تأکید دارم، به‌ویژه به خاطر تأثیری که در یکپارچه‌سازی دیدگاه‌هامون درباره محصول داره، بخش Personas (How it Works) - Types of Users هست. در این بخش، باید توضیح بدیم که این مدل چطور کار می‌کنه و چطور می‌تونیم ازش استفاده کنیم. همچنین باید به چند دسته کاربر و نوع کاربرد هر کدوم اشاره کنیم. شناخت دقیق از این دسته‌ها واقعاً کلیدی هست، چون به ما کمک می‌کنه تا نیازهای مختلف کاربران رو بهتر درک کنیم و محصول رو به‌گونه‌ای طراحی کنیم که به نیازهای هر گروه پاسخ بده.
جدای از اینکه برای محصولی که در فکرتون هست، چقدر Business Model Canvas تهیه کرده‌اید، من پیشنهاد میکنم حتماً بخش‌های Business Model رو هم توی مستند بگنجونید. برای من، این بخش‌ها شامل موارد زیر هستند:
برای هر کدوم از این پنج بخش، چند خط توضیح می‌نویسم تا هر کسی که در تیم این مستند رو می‌خونه، بتونه با هر چیزی که در ذهن داره کار کنه. این توضیحات به اون‌ها کمک می‌کنه تا ببینند چه مواردی با هم هم‌خوانی داره یا نداره. همچنین، حتی بخش فنی باید بدونه که چه مواردی لازمه که برای توسعه محصول در نظر بگیره تا به چشم‌انداز محصول کمک کنه.
یه نکته دیگه که به نظر من ممکنه تکراری به نظر برسه ولی ارزشمند هست، اینه که می‌تونیم برای هر کدوم از دسته‌های مشتری‌هامون، بخش Services and Features رو اضافه کنیم. در این بخش، من بر اساس دسته‌های مختلف مشتری، می‌نویسم که برای هر کدوم چه سرویس‌ها و امکاناتی لازم هست. در فایل که درست کردم، چندین نمونه رندوم نوشتم که مثلاً چه سرویس یا فیچری می‌تونه برای اون مشتری مفید باشه. این کار به ما کمک می‌کنه تا نیازهای خاص هر دسته از مشتریان رو شناسایی کنیم و راهکارهای مناسب‌تری ارائه بدیم.
یکی از مهم‌ترین بخش‌ها در این مدل مستندات، Acceptance Criteria هست. باید واقعاً به شفاف‌ترین حالت ممکن نوشته بشه که این معیارها چی هستن و خروجی مدنظر ما دقیقاً چه چیزی هست. این بخش به تیم کمک می‌کنه تا بفهمه چه انتظاراتی از محصول وجود داره و چه شرایطی باید برآورده بشه تا محصول مورد تأیید قرار بگیره. شفاف‌سازی این معیارها، به تسهیل فرآیند تست و ارزیابی محصول کمک می‌کنه و باعث میشه همه اعضای تیم درک مشترکی از اهداف داشته باشن.
برای مثال، دو نمونه از Acceptance Criteria استاندارد:
معیار اول: کاربر باید بتواند با استفاده از ایمیل و رمز عبور خود وارد حساب کاربری‌اش شود. اگر اطلاعات نادرست وارد کند، باید پیغام خطای مناسبی نمایش داده شود.
معیار دوم: محصول باید در تمامی مرورگرهای اصلی (مانند Chrome، Firefox و Safari) به درستی نمایش داده شود و کارکردهای کلیدی آن بدون هیچ‌گونه مشکلی عمل کند.
و برای افزودن چالش‌های بیشتری، دو نمونه از Acceptance Criteria پیچیده‌تر:
معیار سوم: سیستم باید بتواند به‌طور خودکار رفتار کاربران را تحلیل کند و پیش‌بینی کند که کدام کاربر احتمالاً بیشتر تمایل به خرید دارد. اگر پیش‌بینی نادرست باشد، باید گزارشی از نتایج تحلیل ارائه دهد.
معیار چهارم: برای بخش پرداخت، سیستم باید از چندین درگاه پرداخت مختلف (مثل کارت اعتباری و پی‌پال) پشتیبانی کند. در صورت بروز خطا در یکی از درگاه‌ها، کاربر باید به‌طور خودکار به درگاه دیگر منتقل شود و پیغام خطای مناسبی دریافت کند که وضعیت تراکنش را توضیح دهد.
این نمونه‌ها به وضوح شرایط مورد انتظار را مشخص می‌کنند و کمک می‌کنند تا تیم در فرآیند توسعه و ارزیابی هم‌راستا باشد.
یه نکته بسیار مهم که باید بهش توجه کنیم، این هست که بخشی به نام Timing and Deadline داشته باشیم که هر موردی که مربوط به زمان‌بندی هست رو در اون جمع‌آوری کنیم. برای مثال، باید مشخص کنیم که «شروع برنامه‌نویسی کی هست، تیم استخدام کی انجام میشه، زمان پایان برای توسعه محصول اولیه چیه، ترکیب اسپرینت‌ها چطوری خواهد بود—مثلاً در یک پروژه، من نوشته بودم که اسپرینت‌ها دو هفته‌ای هستن، ولی بعد از مشورت با تیم، تصمیم گرفتیم که به‌خاطر موضوع، اسپرینت‌ها یک هفته‌ای باشن، زمان لانچ اولیه کی هست و زمان لانچ نهایی باید چه تاریخی باشه». این‌ها مواردی هستن که به زمان و زمان‌بندی بستگی دارن و من همه رو در یک بخش جمع‌آوری کردم و توضیحات لازم رو برای هر کدوم می‌نویسم. این کار به تیم کمک می‌کنه تا درک روشنی از زمان‌های مهم پروژه داشته باشه و برنامه‌ریزی بهتری انجام بده.
یک بخش دیگه که به زمان‌بندی و موارد مرتبط اضافه میکنم، Product Timeline - Product Roadmap and Main Marketing Activities هست. در این بخش، یک جدول طراحی میکنم که شامل سه ستون است. ستون اول مربوط به ماه‌هاست و حداقل تا ۹ یا ۱۲ ماه رو مشخص میکنم که در هر ماه چه کارهایی باید انجام بشه.
در ستون دوم، که مربوط به Sprint Goal, Activity, Task هست، کلیدترین مواردی که باید در اون ماه خروجی داشته باشیم رو اضافه میکنم. برای مثال، در ماه دوم، ممکنه نوشته بشه که «تمام تست‌ها انجام شده و آماده‌ایم». در ماه چهارم، هدف باید این باشه که «پرداخت ریالی فعال شده» و در ماه پنجم، هدف اینه که «پرداخت دلاری به سیستم اضافه بشه».
معمولاً یک ستون سومی هم هست که در آن خلاصه‌ای از فعالیت‌های اصلی مارکتینگ اون ماه رو می‌نویسم. این جدول به تیم کمک می‌کنه تا به‌طور واضح و مشخص برنامه‌ریزی کنه و فعالیت‌ها رو پیگیری کنه.
یک بخش دیگه که به مستند اضافه میکنم، Developments هست. در این بخش، هر چیزی که به ذهنم میرسه رو وارد میکنم، مثلاً مدل توسعه چی باید باشه، از چه متالوژی می‌خواهیم استفاده کنیم و مواردی از این قبیل. ممکنه این اطلاعات از ابتدا کامل باشه و من دانش لازم رو داشته باشم، یا مدیر محصول یا یک مشاور اون رو کامل کنه. ولی در نهایت، وقتی که این مستند به تیم فنی برسه، دقیقاً می‌دونن که باید چه کارهایی انجام بدن.
در ادامه، بخش دیگه‌ای اضافه میکنم به نام Technical Requirements که شامل موارد فنی مورد نیاز هست. به عنوان مثال، باید مشخص کنیم که دامنه سایت چه چیزی هست، سورس از کجا می‌آید، آیا باید از آمازون استفاده کنیم یا این موضوع مهم نیست، سیستم ایمیل پرووایدر چی هست، آنلاین‌پیمنت خارجی چه چیزی است و آنلاین‌پیمنت داخلی چه چیزهایی رو شامل می‌شود. همچنین، آیا نیاز به گیت‌هاب داریم یا جیرا؟ این‌ها هم توضیحات فنی هستن که به تیم کمک می‌کنند تا نیازهای تکنیکی پروژه رو به‌خوبی درک کنند.
برای خودم در این مدل مستندات، بخشی مربوط به Team (Small and Agile) دارم که به‌طور دقیق مشخص میکنم که تیم کی هست و چه ویژگی‌هایی داره. در این بخش، اطلاعات زیادی قرار می‌دهم، از جمله نام افرادی که در تیم هستن، پوزیشن‌ها، و کاندیداهای استخدامی. مشخص میکنم که کی به‌صورت فول‌تایم و کی به‌صورت پارت‌تایم کار می‌کنه، همچنین زمان کاری و روزهایی که باید جلسات برگزار کنیم و روزهایی که جلسات نخواهیم داشت.
علاوه بر این، زمان برگزاری استندآپ میتینگ‌ها رو هم تعیین میکنم. این موارد به‌طور خلاصه شامل جزئیاتی هستند که به تیم کمک می‌کنند تا در آینده یک دست و هماهنگ عمل کنن. برای مثال، شخصی که استخدام میشه، می‌دونه که کی باید بیاد و کی باید بره. این مستند سازی تلاش برای پیوستگی و یک‌دستی تیم هست که خیلی کمک می‌کنه تا همه اعضا به‌طور مؤثری با هم همکاری کنن.
در پروژه‌هایی که سرمایه‌گذار داریم یا در آینده به دنبال جذب سرمایه‌گذار هستیم، بخش Investment Requirements بسیار مهم هست. در این بخش، هر چیزی که مربوط به سرمایه‌گذار هست و باید بدونه رو مشخص میکنم. به عنوان مثال، مواردی مثل حقوق‌هایی که باید پرداخت بشه، حداقل هزینه‌های ریالی چقدر هست، هزینه‌های دلاری چقدر هست و سایر موارد مالی مرتبط.
این بخش برای مدیرعامل و هر کسی که در این مدل شرکت‌ها فعالیت می‌کنه، از جمله مشاوران و مدیران محصول، بسیار حائز اهمیت هست. از روز اول باید این مسائل رو با مدیر شفاف کنیم تا فردا نیاد بگه که «استخدام کردیم، ولی هزینه نمی‌دیم» یا اینکه به اشتباه فکر کنه حقوق‌ها کم‌تر از آن چیزی است که در واقعیت وجود داره، مثلاً «فکر کردم حقوق ۵ میلیون تومان هست».
به‌طور خلاصه، هر چیزی که از سرمایه‌گذاری انتظار داریم و نیازمند شفاف‌سازی هست، باید به‌دقت و روشن در این بخش نوشته بشه تا هیچ‌گونه ابهامی باقی نماند و همه اعضای تیم با توقعات مالی آشنا بشن.
در نهایت، هر چقدر هم که تلاش کنید و فکر کنید، برای همه چیز پاسخ ندارید. به‌طور مثال، ممکنه زمان گذاشته باشید تا این فایل رو در مدت ۲ هفته جمع‌آوری کنید، ولی برخی موارد بدون پاسخ باقی بمونند. به همین دلیل، من بخشی به نام Open Questions ایجاد میکنم که در آن سوالاتی رو می‌نویسم که نیاز هست در آینده به اون‌ها پاسخ بدیم.
این پاسخ‌ها ممکنه بر میزان پول مورد نیاز یا زمان‌بندی که در حال حاضر انجام شده، تأثیر بذارند. بنابراین، توضیحات لازم رو هم در این بخش می‌گم تا تیم بدونه که باید دقیقاً به چه سوالاتی پاسخ بده و چه مواردی رو مدنظر قرار بده. این کار به ما کمک می‌کنه تا مسائل را به‌طور واضح‌تر شناسایی کنیم و در آینده تصمیم‌گیری بهتری داشته باشیم.
اگر تا اینجا مسیر رو به‌درستی طی کرده باشید، چندین بخش داریم که به عنوان مدیر محصول، مالک محصول، یا حتی مدیرعامل یک شرکت، در صورتی که دانش فنی زیادی نداشته باشید، می‌توانید این بخش‌ها رو پر کنید. اما از جهت ماندگاری و ادامه‌دار بودن، بعد از استخدام مدیر فنی یا تکنیکال لید، یا به‌طور کلی اولین فرد فنی با تجربه، این مستند باید توسط او کامل بشه.
در ادامه، به ساختار فایل اشاره میکنم که شامل چندین بخش کلیدی هست. یکی از این بخش‌ها Technical Stack and Tools است که در آن ابزارهایی که برای توسعه و پشتیبانی محصول مورد استفاده قرار می‌گیرند، مانند Docker، Kubernetes و ابزارهای نظارتی و لاگ‌گیری نظیر Datadog، New Relic، Sentry و Grafana ذکر می‌شود. همچنین، بخش Database and Table Structure شامل توضیحات مربوط به ساختار بانک اطلاعاتی و جداول و ارتباطات آن‌هاست. در نهایت، بخش User API جدولی را شامل می‌شود که تمام APIهایی که برای پروژه نیاز داریم را به همراه توضیحات مربوط به هر یک ارائه می‌دهد. این ساختار به تیم فنی کمک می‌کند تا به‌راحتی با مستندات و نیازهای پروژه آشنا شوند و در نتیجه، توسعه محصول به شکلی مؤثر و کارآمد پیش برود.
در هر صورت امیدوارم که این بلاگ پست و این فایل Product Requirement Document (PRD) بتونه به شما کمک کنه تا محصول بهتری رو داشته باشد و توسعه بدید.
