بخش ۲، فلوی شکلگیری ایده تا رسیدن به محصول و محیط عملیاتی
در بخش اول دیدیم که ریشهی تنش بین مدیر محصول و مهندس، بیشتر از اینکه یه موضوع فردی باشه، یک مشکل ساختاریه. ابهام در مالکیت، اشتباه گرفتن Product Manager با Project Manager، و موندن توی مدل Feature Team، باعث میشه سیستم به سمت اصطکاک هدایت بشه، نه همکاری.
اما دونستن ریشه کافی نیست. سوال عملی اینه: یک ایده چطور باید از ذهن مدیر محصول به محیط عملیاتی برسه؟ چه کسی در هر مرحله مالک است؟ چه ابزاری کمک میکنه؟ و شرکتهای بزرگ این مسیر رو چطور طی میکنن؟ در این بخش به همین سوالها خواهم پرداخت.
فلوی کامل: از ایده تا Production
مسیر یک فیچر از لحظهی تولد تا استقرار، از شش مرحلهی مجزا عبور میکنه. هر مرحله یک مالک مشخص، یک ورودی مشخص، و یک خروجی مشخص باید داشته باشه.
Discovery → Shaping → Spec → RFC → Development → Releaseمرحله ۱، Discovery: مسئله رو قبل از راهحل بفهمید
مالک: مدیر محصول
مشارکتکننده: مهندس (بهعنوان Contributor، نه Approver)
Discovery جاییه که PM باید ثابت کنه مشکل واقعی وجود داره. نه یک فرض، نه یک درخواست stakeholder، نه یک ایدهی جذاب؛ یک مشکل اثباتشده با داده.
در این مرحله PM باید جواب سه سوال رو داشته باشه:
۱. چه کسی این مشکل رو داره؟ (سگمنت کاربری مشخص)
۲. چه وقت این مشکل اتفاق میافته؟ (context دقیق)
۳. شواهد چی میگن؟ (داده کمی یا کیفی)
نقش مهندس در این مرحله چیه؟ شرکت در مصاحبههای کاربری، کمک به تحلیل دادههای سیستم، و مطرح کردن محدودیتهای فنی که ممکنه روی تعریف مسئله تاثیر بگذارن. و نه بیشتر!
یک اشتباه رایج: مهندس در Discovery غایبه و اولین باری که مسئله رو میشنود، در جلسهی Kick-off است. این یعنی یک فرصت طلایی رو از دست داده برای پیدا کردن بینش فنی در اوایل کار و قبل از پیادهسازی، جایی که هزینهی تغییر هنوز پایینه.
مرحله ۲، Shaping: ایده رو شکل بدید، نه اینکه بهصورت کامل طراحی کنید
مالک: مدیر محصول + مهندس ارشد
چارچوب: Shape Up (Basecamp)
Shaping یکی از کمترشناختهشدهترین و در عین حال مهمترین مراحل است. طی این مرحله، PM و یک مهندس ارشد (نه کل تیم) با هم روی ایده کار میکنن تا به اندازهی کافی مشخص و تبیینش کنن؛ نه به اندازهی یک spec کامل، بلکه به اندازهای که بشه دربارهی ارزش، اندازه، ریسک و مرزهای کار تصمیم گرفت.
Ryan Singer در Shape Up یک مفهوم کلیدی رو طرح میکنه: Appetite در برابر Estimate.
Estimate یعنی میپرسیم «این چقدر طول میکشه؟» و مهندس باید زیر فشار، عددی بده که بعداً به تعهد تبدیل میشه.
Appetite یعنی میپرسیم «ما حاضریم چقدر وقت روی این بگذاریم؟» و این یک تصمیم تجاری است، نه یک پیشبینی فنی.
این تفاوت ظاهراً کوچک، کل دینامیک جلسه رو عوض میکنه. دیگه مهندس زیر فشار برای تخمین زمانی دادن (Estimate) نیست؛ در عوض، با PM روی این سوال کار میکنه که «با دو هفته، چه سطحی از این مسئله رو میشه حل کرد؟»
البته این به معنی حذف نظر فنی نیست. Engineering کمک میکنه بفهمیم appetite چه سطحی از راهحل واقعبینانه است.
خروجی Shaping یک Pitch است؛ یک سند کوتاه که شامل:
- تعریف مسئله
- راهحل پیشنهادی در سطح کلی (نه wireframe کامل)
- appetite مشخص (مثلاً: دو هفته، یک نفر)
- خطرات و موارد خارج از scope
مرحله ۳، Spec: مسئله رو مکتوب کنید
مالک: مدیر محصول
خروجی: Product Requirements Document (PRD)
بعد از مرحله Shaping، مدیرمحصول spec رو مینویسه. اول چند مفهوم رو به اختصار توضیح میدم و بعد توضیح میدم که spec خوب چه شکلیه؟
Spec (مشخصات): سندیه که توضیح میده «چه چیزی باید ساخته بشه و چرا» — نه «چطور». این سند شامل تعریف مسئله، رفتار مورد انتظار سیستم، و موارد خارج از scope است. مخاطبش هم تیم مهندسیه.
PRD (Product Requirements Document): در واقع همون Spec است، با یک اسم رسمیتر. بعضی شرکتها این دو تا رو مترادف هم به کار میبرن، بعضی هم PRD رو سندِ سطح بالاتر میدونن و Spec رو جزئیات فنیترش. در عمل، اونچه که مهمه محتواست نه اسم؛ سندی که «چرا» و «چی» رو شفاف کنه، نه «چطور».
Press Release: یک صفحهی کوتاه که انگار محصول ساخته شده رو میخواهید به کاربر اعلام و معرفی کنید. مثل یک خبر رسمی؛ «امروز قابلیت X رو منتشر کردیم که مشکل Y رو برای کاربر Z حل میکنه.» هدفش اینه که محدیرمحصول رو مجبور کنه از دید کاربر فکر کنه، نه از دید فیچر. این متن میتونی فرضی و ذهنی باشه حتی.
Amazon یک متدولوژی منحصربهفرد داره که اسمش رو Working Backwards گذاشته. قبل از نوشتن هر spec، مدیرمحصول باید یک Press Release فرضی و FAQ فرضی بنویسه، درست انگار که محصول ساخته شده و الان میخوان به کاربر اعلام کنن.
این تمرین، ساده اما قدرتمنده، چون:
۱. مدیرمحصول رو مجبور میکنه از دید کاربر فکر کنه، نه از دید فیچر
۲. ابهام در «ارزش» رو آشکار میکنه؛ اگه نتونه یک خبر جذاب بنویسه، شاید اصلاً ارزشی برای کاربر وجود نداره
۳. مهندس وقتی این رو میخونه، «چرا» رو دقیقاً میفهمه، نه فقط «چی» رو.
یک PRD خوب (صرفنظر از فرمت) باید به این سوالها جواب بده:
- مشکل چیه و برای چه کسیه؟
- موفقیت چطور اندازه گرفته میشه؟ (متریک مشخص)
- چه چیزهایی خارج از scope هستن؟
- محدودیتهای شناختهشده کدومهاست؟
آخرین مورد اغلب نوشته نمیشه و همین باعث میشود مهندس در وسط پیادهسازی با سوالهایی مواجه بشه که جوابش رو باید از مدیرمحصول بگیره. در تیمهایی که از Shape Up خالص استفاده میکنن، Pitch میتونه جایگزین بسیاری از specهای سنگین بشه. اما در سازمانهای بزرگتر، مخصوصا جایی که چند تیم، QA، Security، Support یا Compliance درگیرن، معمولا لازمه بعد از Shaping یک PRD سبک یا Product Spec هم نوشته بشه.
مرحله ۴، RFC: راهحل فنی رو مستند کنید
مالک: مهندس ارشد
مشارکتکننده: PM (بهعنوان Contributor)
چارچوب: Request for Comments
بعد از اینکه spec آماده شد، نوبت تیم مهندسیه تا مهندس ارشد یک RFC (Request for Comments) بنویسه؛ سندی که رویکرد فنی پیشنهادی رو توضیح میده.
فرهنگ نوشتن design doc، RFC یا proposal فنی توی خیلی از شرکتهای مهندسیمحور رایجه؛ هر شرکت اسم و فرمت خودش رو داره. (مثل Google، Amazon، تسلا و Stripe) استفاده میشه و چند هدف داره:
۱. اجماع: همهی اعضای تیم میتونن قبل از اینکه کدی نوشته بشه نظر بدن
۲. مستندسازی: دلیل تصمیمهای فنی ثبت بشه، نه فقط خود تصمیم
۳. مرز: مدیرمحصول میتونه روی trade-offهای محصولی، تجربه کاربر، scope و ریسک زمانی نظر بده؛ اما approver راهحل فنی نباید PM باشد. تصمیم فنی دست مهندسی است.
یک RFC معمولاً شامل:
- خلاصهی مسئلهی فنی
- راهحلهای جایگزینی که بررسی شدن
- راهحل پیشنهادی و دلیل انتخابش
- trade-offها و ریسکهای شناختهشده
- سوالات باز (Open Questions)
وقتی RFC وجود داره، این جمله دیگه در جلسات نباید شنیده بشه: «این معماری رو چه کسی تصویب کرده؟»
مرحله ۵، Development: بسازید و بازخورد بگیرید
مالک: تیم مهندسی
چارچوب: Dual-Track Agile
توی Dual-Track Agile، دو مسیر موازی وجود داره:
- Discovery Track: مدیرمحصول و طراح روی مسئلهی بعدی کار میکنن
- Delivery Track: مهندسها فیچر فعلی رو میسازن
این موازی بودن باعث میشه تا مدیرمحصول همیشه چند هفته جلوتر از تیم باشه و مهندسها هیچوقت idle (منتظر) نمونن که منتظر spec باشن.
اما توی این مرحله یک نکتهی کلیدی وجود داره: مدیرمحصول باید در دسترس باشه، نه ناظر.
در دسترس بودن یعنی وقتی مهندس به سوالی برمیخوره که جوابش در spec نیست، بتونه در همون روز جواب بگیره. ولی ناظر بودن یعنی هر روز بپرسه «کِی تموم میشه؟» که مهندس رو از ساختن به justify کردن میکشونه.
در بعضی تیمهای محصولمحور، این مسئله با یک قرارداد ساده حل میشه: مدیرمحصول در طول روز یا در یک بازه مشخص برای سوالهای تیم در دسترسه، اما وارد micromanagement کار مهندسی نمیشه. (قریب به مضمون، Spotify توی مدل Squad خودش این مسئله رو با یه قرارداد ساده حل کرده: PM هر روز یک بازهی مشخص در دسترسه برای سوالهای تیم، اما به جز اون بازه، در کار تیم دخالت نمیکنه. البته مدل اسپاتیفای رو نمیشه توی یک خط توضیح داد و شاید یه مطلب مفصل در موردش بعداً بنویسم)
مرحله ۶، Release: انتشار هوشمند
مالک: مشترک (PM + مهندس ارشد + DevOps)
پایان ماجرا، رسیدن به production نیست؛ بلکه تازه آغاز اندازهگیری است.
شرکتهای بزرگ معمولاً از چند تکنیک برای release استفاده میکنن:
Feature Flag: فیچر توی کد وجود داره اما برای همه فعال نیست. میشه اون رو فقط برای تعدادی از کاربرها روشن کرد، نتایج رو دید، و بعد گسترش داد، یا برگشت. (اینجا مفصلتر توضیح دادهام)
Canary Release: نسخهی جدید ابتدا روی یک زیرمجموعهی کوچیک از سرورها اجرا میشه. اگر مشکلی پیش بیاد، rollback سریع انجام میشه.
A/B Testing: دو نسخه از فیچر همزمان برای دو گروه از کاربرها اجرا میشه و نتایج رو میشه مقایسه کرد.
در هر سه روش، مدیرمحصول و مهندس هر دو در تعریف «موفقیت» شریکن. قبل از release باید مشخص باشه: چه متریکی رو در چه بازهی زمانی نگاه میکنیم، و اگر نتیجهی مثبت نداشت، چه میکنیم؟
چکلیست عملی
برای اینکه این فلو در واقعیت کار کنه، هر طرف باید چند تعهد ساده رو رعایت کنه:
مدیر محصول:
- قبل از مرحله Shaping، شواهد مسئله رو داشته باشه (نه فرض)
- سند spec رو با بخش «خارج از scope» تمام کنه
- در طول Development، در دسترس باشه؛ نه ناظر
- موفقیت رو با متریک تعریف کنه، نه با تحویل فیچر
مهندس:
- در مرحله Discovery حاضر باشه و بینش فنی بده
- RFC بنویسه؛ حتی برای تصمیمهای فنی کوچک. البته هر تصمیمی RFC نمیخواد؛ اما تصمیمهایی که روی معماری، داده، امنیت، performance، نگهداری یا چند تیم اثر میگذارن، باید مکتوب شن. (گاهی هم ADR لازمه، قبلا در مورد ADR توضیح دادم)
- وقتی spec ابهام داره، بپرسه؛ نه اینکه حدس بزنه
- نتایج release رو با مدیرمحصول در میان بگذاره
جمعبندی
رابطهی مدیر محصول و مهندس، وقتی درست طراحی بشه، یکی از قویترین ترکیبهای ممکن در ساختن محصوله. یکی میدونه چه مشکلی باید حل بشه، اون یکی میدونه چطور اون رو حل کنه؛ و هیچکدوم بدون دیگری به نتیجه نمیرسه.
اونچه طی این دو بخش سعی کردم بیان کنم اینه که: تنش طبیعیه، اما فرسایش ضروری نیست. با مالکیتِ روشن در هر مرحله، ابزارهای مناسب، و فرهنگی که هر دو طرف در اون context دارن، میشه از Feature Factory خارج شد و تیمی ساخت که واقعاً مسئله حل میکنه.
در ضمن قرار نیست همه با خوندن یک کتاب، گذروندن یک دوره آموزشی یا داشتن یه عنوان شغلی مشابه، خروجی و کیفیت برابر داشته باشن. قیمت آدمها یا کیفیت خروجی کارشون به عنوان شغلی، مدرک یا سرتیفیکیتشون نیست، بلکه به عمق دانش، تجربه و استعداد و تلاششون است.