مدیر محصول و مهندس نرم‌افزار: همکاری یا تنش؟ (بخش اول)

Author: امین مصباحی

Site: امین مصباحی

Source: https://mesbahi.net/fa/blog/1405/02/14/product-manager-engineer-collaboration-part-1

⚠️ Article content is partial (Telegram Instant View delivered in segments).

♻️ **مدیر محصول و مهندس نرم‌افزار: همکاری یا تنش؟ (بخش اول)
**
توی بیشتر تیم‌های نرم‌افزاری، تنش بین مدیر محصول و مهندس یه چیز آشنا و گاها حتی رایجه. یه طرف می‌گه «این فیچر باید تا آخر ماه آماده بشه»، طرف دیگه می‌گه «نمی‌شه» و این گفتگو هر بار همین‌جا تموم می‌شه. بدون اینکه کسی بپرسه چرا این الگو تکرار می‌شه.

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

🔗 بخش اول

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

📢 tech-afternoon

بخش اول: ریشه‌شناسی یک تنش ساختاری

مقدمه: دعوای ظاهری، مشکل ساختاری

این گفت‌وگو تکراری، بین مدیرمحصول و مهندس نرم‌افزار رو توی خیلی از تیم‌های نرم‌افزاری می‌بینیم:
– مدیر محصول یه فیچر رو تعریف می‌کنه

مهندس نرم‌افزار: «این‌‌جوری نمی‌شه»
– مدیر محصول: «چرا نمی‌شه؟»
مهندس: «چون پیچیده ست»
و همین‌جاست که یک رابطه‌ی کاری شروع به فرسایش می‌کنه.

اما اگر دقیق‌تر نگاه کنیم، این تنش نه ناشی از بدنیتیه، نه از ناتوانی فردی. بلکه ریشه‌اش ساختاریه. و هر مشکل ساختاری، راه‌حل ساختاری داره. (به بیان ساده‌تر، مشکل از دل طراحی نادرست سیستم همکاری میاد)
به دلیل اهمیت و جزئیات مسئله، این مطلب رو در دو بخش می‌نویسم:
بخش اول به ریشه‌شناسی تنش می‌پردازم؛ اینکه چرا این چالش شکل می‌گیره، چه مدل‌های سازمانی می‌تونه تشدیدش کنه، و چه چارچوب‌های فکری توی شرکت‌های بزرگ برای حلش استفاده می‌شه.

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

مشکل از کجا شروع می‌شه؟

بهتره با یه سوال شروع کنیم: مدیر محصول صاحب چیه؟

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

در تعریف درست، مدیر محصول مالک مسئله است، نه راه‌حل. یعنی باید جواب این سوال رو داشته باشه که «چه مشکلی برای چه کسی باید حل بشه و چرا الان؟» اما «چطور حل بشه» در حوزه‌ی مالکیت مهندس نرم‌افزار است.

وقتی این مرز مبهم می‌شه، دو تا اتفاق میوفته:

۱. مدیر محصول به سمت تعریف راه‌حل می‌ره؛ چون احساس می‌کنه اگر «چطور» رو هم کنترل نکنه، «چرا»اش هم محقق نخواهد شد.
۲. مهندس نرم‌افزار از «چرا» بی‌خبر می‌مونه؛ چون کسی این پاسخ رو باهاش در میون نگذاشته، و در نتیجه نمی‌تونه راه‌حل هوشمندانه‌ای ارائه بده.
هر دو طرف توی این سیکل معیوب، منطقی رفتار می‌کنن. اما عملا این سیستمه که غلط طراحی شده!

مقایسه Feature Team در برابر Empowered Team

در ادبیات Product Management، مخصوصا در نوشته‌های Marty Cagan (کتاب Inspired و بعدتر در Empowered)، تمایز مهمی بین Feature Team و Empowered Product Team وجود داره. Marty Cagan این تمایز رو با دقت توصیف می‌کنه، و به نظرم یکی از مفیدترین چارچوب‌های فکری برای فهمیدن این چالشه.

Feature Team تیمیه که roadmap رو اجرا می‌کنه. ورودیش لیستی از فیچرهاست و خروجی‌اش هم تحویل همون فیچرها! توی این مدل، مدیر محصول عملاً نقش Project Manager رو بازی می‌کنه؛ پیگیری زمان‌بندی، هماهنگی بین تیم‌ها، و گزارش پیشرفت. مهندس هم عملاً نقش مجری رو داره؛ کسی که باید «output» تحویل بده، و نه اینکه «outcome» ایجاد کنه. (تفاوت output، outcome و impact رو پیش‌تر به صورت کامل اینجا نوشتم)

Empowered Team اما متفاوته. این تیم مالک یک مسئله است، نه یک لیست از فیچرها. مثلاً به این تیم می‌گن «نرخ بازگشت کاربرهای ما در ۳۰ روز اول عَرضه محصول پایینه، این مشکل رو حل کنید.» تیم خودش کشف می‌کنه چه راه‌حلی مناسبه، راه‌حل رو می‌سازه، و نتیجه‌اش رو اندازه‌گیری می‌کنه.

توی یک Feature Team، تنش ساختاریه و اجتناب‌ناپذیر. در Empowered Team، تنش هنوز وجود داره، ولی چون اختلاف نظر بخشی از کار فکری مشترکه، اینجا سازنده است، و نه فرساینده. در Feature Team، تنش‌ها معمولا حول scope و deadline شکل می‌گیرن؛ در Empowered Team، تنش حول فهم مسئله، trade-off و کیفیت تصمیمه. به این دلایل است که می‌گم توی اولی فرساینده است، ولی دومی اگر درست مدیریت بشه، سازنده!

گوگل، اسپاتیفای، نتفلیکس، تسلا و آمازون همه از مدل دوم استفاده می‌کنن. اما نکته‌ی مهم اینجاست: رفتن از Feature Team به Empowered Team فقط تغییر ساختار نیست. تغییر فرهنگه و این تغییر از هر دو طرف می‌طلبه که مالکیت روشنی داشته باشن و به مالکیت طرف مقابل احترام بگذارن.

به‌صورت خلاصه، در یک ساختار سالم‌تر، مدیر محصول مالک مسئله، ارزش و اولویته، نه لزوما مالک راه‌حل. مدیرمحصول باید روشن کنه چه مشکلی، برای چه کاربری، چرا حالا، و با چه معیار موفقیتی باید حل بشه. اما اینکه این مسئله دقیقا با چه طراحی فنی، چه معماری، چه محدودیت‌هایی و چه trade-offهایی حل بشه، در حوزه مالکیت Engineering قرار می‌گیره. وقتی PM وارد قلمرو «چطور بسازیم» می‌شه و مهندس از قلمرو «چرا می‌سازیم» حذف می‌شه، همکاری تبدیل به سفارش‌گیری می‌شه!

چرا هر دو طرف منطقی رفتار می‌کنن، اما سیستم غلط است؟

مدیر محصول چرا راه‌حل تجویز می‌کنه؟

چون از سمت بیزنس تحت فشار است.
چون می‌ترسه تیم فنی مسئله رو جدی نگیره.
چون فکر می‌کنه اگر راه‌حل مشخص نباشه، زمان از دست می‌ره.
چون سازمان ازش output می‌خواد، نه outcome.
گاهاً پیشینه خودش مهندسی بوده و تصور می‌کنه کماکان باید مثل یک مهندس رفتار کنه

مهندس چرا مقاومت می‌کنه؟

چون شاهد ابهام در جزئیات پیاده‌سازی است.
چون هزینه نگهداری رو می‌فهمه و تجربه کرده.
چون با Legacy و Production درگیره.
چون می‌دونه تصمیم عجولانه امروز، Incident فرداست.

نتیجه:

بسیاری از اصطکاک‌ها حاصل آدم‌های غیرمنطقی نیستند؛ حاصل آدم‌های منطقی در سیستم بدطراحی‌شده‌ است.