Author: امین مصباحی
Site: امین مصباحی
Source: https://mesbahi.net/fa/blog/1405/02/15/product-manager-engineer-collaboration-part-2
⚠️ Article content is partial (Telegram Instant View delivered in segments).
♻️♻️ مدیر محصول و مهندس نرم‌افزار: همکاری یا تنش؟ (بخش دوم)
بخش ۲، فلوی شکل‌گیری ایده تا رسیدن به محصول و محیط عملیاتی
در بخش اول دیدیم که ریشه‌ی تنش بین مدیر محصول و مهندس، بیشتر از اینکه یه موضوع فردی باشه، یک مشکل ساختاریه. ابهام در مالکیت، اشتباه گرفتن Product Manager با Project Manager، و موندن توی مدل Feature Team، باعث می‌شه سیستم به سمت اصطکاک هدایت بشه، نه همکاری.
اما دونستن ریشه کافی نیست. سوال عملی اینه: یک ایده چطور باید از ذهن مدیر محصول به محیط عملیاتی برسه؟ **چه کسی در هر مرحله مالک است؟ **چه ابزاری کمک می‌کنه؟ و شرکت‌های بزرگ این مسیر رو چطور طی می‌کنن؟ در این بخش به همین سوال‌ها خواهم پرداخت.
فلوی کامل: از ایده تا Production
مسیر یک فیچر از لحظه‌ی تولد تا استقرار، از شش مرحله‌ی مجزا عبور می‌کنه. هر مرحله یک مالک مشخص، یک ورودی مشخص، و یک خروجی مشخص باید داشته باشه.
Discovery → Shaping → Spec → RFC → Development → Release
مطلب کامل رو از لینک زیر مطالعه کنید:
💬 نظر و تجربه شما چیه؟
بخش ۲، فلوی شکل‌گیری ایده تا رسیدن به محصول و محیط عملیاتی
در بخش اول دیدیم که ریشه‌ی تنش بین مدیر محصول و مهندس، بیشتر از اینکه یه موضوع فردی باشه، یک مشکل ساختاریه. ابهام در مالکیت، اشتباه گرفتن 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 هستن؟
- محدودیت‌های شناخته‌شده کدوم‌هاست؟