بخش اول: ریشهشناسی یک تنش ساختاری
مقدمه: دعوای ظاهری، مشکل ساختاری
این گفتوگو تکراری، بین مدیرمحصول و مهندس نرمافزار رو توی خیلی از تیمهای نرمافزاری میبینیم:
– مدیر محصول یه فیچر رو تعریف میکنه
+ مهندس نرمافزار: «اینجوری نمیشه»
– مدیر محصول: «چرا نمیشه؟»
+ مهندس: «چون پیچیده ست»
و همینجاست که یک رابطهی کاری شروع به فرسایش میکنه.
اما اگر دقیقتر نگاه کنیم، این تنش نه ناشی از بدنیتیه، نه از ناتوانی فردی. بلکه ریشهاش ساختاریه. و هر مشکل ساختاری، راهحل ساختاری داره. (به بیان سادهتر، مشکل از دل طراحی نادرست سیستم همکاری میاد)
به دلیل اهمیت و جزئیات مسئله، این مطلب رو در دو بخش مینویسم:
بخش اول به ریشهشناسی تنش میپردازم؛ اینکه چرا این چالش شکل میگیره، چه مدلهای سازمانی میتونه تشدیدش کنه، و چه چارچوبهای فکری توی شرکتهای بزرگ برای حلش استفاده میشه.
بخش دوم فلوی عملیاتی رو بررسی میکنم؛ از لحظهی شکلگیری یک ایده تا رسیدنش به محیط عملیاتی، با مالکیت مشخص در هر مرحله، و ابزارهایی که این همکاری رو ساختارمند میکنن.
مشکل از کجا شروع میشه؟
بهتره با یه سوال شروع کنیم: مدیر محصول صاحب چیه؟
اگر این سوال رو از ده نفر در ده شرکت مختلف بپرسید، احتمالاً ده جواب متفاوت خواهید شنید. و همین ابهام، ریشهی اصلی تنش است.
در تعریف درست، مدیر محصول مالک مسئله است، نه راهحل. یعنی باید جواب این سوال رو داشته باشه که «چه مشکلی برای چه کسی باید حل بشه و چرا الان؟» اما «چطور حل بشه» در حوزهی مالکیت مهندس نرمافزار است.
وقتی این مرز مبهم میشه، دو تا اتفاق میوفته:
۱. مدیر محصول به سمت تعریف راهحل میره؛ چون احساس میکنه اگر «چطور» رو هم کنترل نکنه، «چرا»اش هم محقق نخواهد شد.
۲. مهندس نرمافزار از «چرا» بیخبر میمونه؛ چون کسی این پاسخ رو باهاش در میون نگذاشته، و در نتیجه نمیتونه راهحل هوشمندانهای ارائه بده.
هر دو طرف توی این سیکل معیوب، منطقی رفتار میکنن. اما عملا این سیستمه که غلط طراحی شده!
مقایسه 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 فرداست.
نتیجه:
بسیاری از اصطکاکها حاصل آدمهای غیرمنطقی نیستند؛ حاصل آدمهای منطقی در سیستم بدطراحیشده است.
اشتباه رایج: PM یا PM ؟!
مخفف Product Manager و Project Manager هر دو PM میشه! یک واقعیت که در بسیاری از تیمها خصوصا بنا به تجربه شخصی، در شرکتهای ایرانی خیلی بیشتر میبینیم اینه که: عنوان «مدیر محصول» به کسی داده شده که در اصل Project Manager است!
هر دو نقش در ظاهر شبیه به هم هستن، هر دو با تیم کار میکنن، هر دو در جلسات حاضرن، حتی گاه از ابزارهای مشابه استفاده میکنن؛ اما در جهتگیری تفاوتهای بنیادی دارن:
| Product Manager | Project Manager | |
|---|---|---|
| سوال اصلی | چه مشکلی رو حل میکنیم؟ | چطور این پروژه رو تحویل میدیم؟ |
| موفقیت | Outcome (نتیجه برای کاربر) | Output (تحویل به موقع) |
| رابطه با تیم | همکاری در کشف مسئله | هماهنگی در اجرا |
| رابطه با Roadmap | مالک و سازنده | مجری |
وقتی یک Project Manager با عنوان Product Manager کار میکنه، اتفاقی که میافته اینه: فشار اجرا و زمانبندی به مهندسها منتقل میشه، ولی بدون اینکه «چرا» روشن باشه. مهندسها هم به تدریج یاد میگیرن فقط بپرسن «چی بسازیم؟»؛ نه اینکه «چه مشکلی رو حل کنیم؟»
نتیجه؟ تیمی که از نظر تکنیکال قوی است، اما محصولی میسازه که کاربر نمیخواد!
چارچوب DACI: مالکیت روشن در هر تصمیم
یکی از ابزارهایی که توی شرکتهای بزرگ برای شفافسازی مالکیت استفاده میشه، DACI است:
- D — Driver: کسی که تصمیم رو پیش میبره و مسئول اجراست
- A — Approver: کسی که تصمیم نهایی رو میگیره (معمولاً یک نفر)
- C — Contributor: کسانی که نظر میدن اما تصمیم نمیگیرن
- I — Informed: کسانی که باید از نتیجه مطلع بشن
در تعامل PM و مهندس، این الگو میتونه ابهامهای زیادی رو از بین ببره. مثلاً:
- تعریف مسئله: Approver = PM، Contributor = مهندس
- انتخاب راهحل فنی: Approver = مهندس ارشد، Contributor = PM
- اولویتبندی: Approver = PM، Contributor = مهندس و stakeholder
وقتی این نقشها رو در ابتدای هر initiative مشخص کنیم، جلسات کمتری برای «این تصمیم دست کیه؟» برگزار میشه.
مثال:
| تصمیم | Driver | Approver | Contributor | Informed |
|---|---|---|---|---|
| تعریف مسئله | PM | PM / Product Lead | Engineering, Design, Support | Stakeholders |
| انتخاب راهحل فنی | Tech Lead | Engineering Lead | PM, QA, Security | Product, Support |
| اولویتبندی | PM | Product Lead | Engineering, Business | Team |
| Go/No-Go Release | Release Owner | Engineering/Product مشترک | QA, Ops, PM | Stakeholders |
| Rollback | Engineering | Engineering Lead | PM, Ops | Support, Business |
چرا مهندسها باید Context داشته باشن؟
یکی از باورهای اشتباه که در بعضی سازمانها وجود داره اینه که «مهندسها فقط باید بسازن، ارتباط و تعامل با کاربر به PM مربوطه.»
این باور خیلی مضر میتونه باشه. وقتی یک مهندسی میدونه که این فیچر برای چه کاربری ساخته میشه، چه مشکلی رو قراره حل کنه، و چه متریکی موفقیتش رو اندازه میگیره، تصمیمهای فنیاش هوشمندانهتر میشن. ممکنه بگه «اگر هدف اینه، ما میتونیم با یکسوم هزینه به همون نتیجه برسیم.» یا «این edge case که شما در نظر نگرفتی، دقیقاً برای این کاربر مهمه.»
Context دادن به مهندسها لطف نیست؛ مکانیزم افزایش کیفیت تصمیمهای فنی است.
آمازون یک مکانیزم ساده اما قوی برای این کار داره که در بخش دوم توضیح خواهم داد؛ ولی چکیدهاش اینه: مهندس باید مشتری رو بشناسه، نه فقط ticket رو!
جمعبندی بخش اول
تنش بین مدیر محصول و مهندس نرمافزار حذفشدنی نیست، چون این دو نقش، دو نگرانی متفاوت اما ضروری رو نمایندگی میکنن: ارزش و قابلیت اتکا. Product باید مطمئن بشه که تیم، مسئله رو درست حل میکنه و مسئلهی درست رو، حل میکنه! Engineering هم باید مطمئن باشه که راهحل انتخابشده، قابل ساخت، قابل نگهداری و قابل اتکا است.
مشکل زمانی شروع میشه که مالکیت مسئله و مالکیت راهحل، قاطی میشن، Product به Project Management تقلیل پیدا میکنه، و تیم به جای مالک outcome بودن، تبدیل به کارخونه تحویل فیچر میشه.