مدیریت محصول / PMگری چه هست و چه نیست؟

مدیریت محصول (PM) یک نقش نسبتا جدید است، رشته دانشگاهی نداشته، و در هر سازمانی به شکلی شکل گرفته است - در بسیاری جاها به شکل اصطکاک‌زا. در این یادداشت نگاهی به آن‌چه PMگری نیست و آن‌چه هست، می‌کنیم. بدیهیات: منظور از فلان هست و فلان نیست صرفا یعنی فلان مدل معمولا کارآمد هست/نیست، وگرنه همه در تعریف هر نقشی آزادند. همچنین نظرهای زیر، صرفا شخصی و بر اساس تجربیات محدود از یک سازمان خاص (گوگل) است.

۱. مدیریت اجرای پروژه

مدیریت محصول در آغاز به شکل نارستی در بازار ایران رواج پیدا کرد - گویی یعنی مدیریت پروژه. دوست عزیزی می‌گفت در آغاز که از ایران به گوگل آمده بودم، به PMهامون گفتم شما همان‌هایید که نمودار گانت می‌کشید؟ و چپ چپ نگاهم کردند که نخیر، آن «مدیر برنامه»/PgM (نام گوگلی برای مدیر پروژه) است و نه «مدیر محصول».

در خیلی از سازمان‌ها می‌بینیم که مدیران محصول عملا مدیر پروژه هستند. سعی می‌کنند هفته به هفته به تیم توسعه task بدهند و خروجی بگیرند، یا حتی در یک رابطه ناسالم کارفرما-پیمانکاری فشار بیاورند تا «کارها برسد»! قضیه این نیست که آن PMها سیریش‌اند یا آن مهندسان، تنبل. بلکه آن‌ها هم فکر می‌کنند مدل default همین است. مثلا یک PM صادقانه آمده بود برای مشورت با بنده که چه‌طور می‌توانم از «دولوپرهام» خروجی بیشتر بگیرم. حتی نمی‌پرسد که «آیا» این مدل کاری، خوب است؟

خیلی از مهندسان نرم‌افزار هم همین مدل را پسندیده و به حاشیه‌ی امن‌شان رفته‌اند: به من چه درگیر مدیریت پروژه یا فهم محصول شوم؛ به من task بدهید تا انجام بدهم! ولی مهندسان و رهبران فنی قرار است مسئول own کردن اجرای کار به شکل ۰ تا ۱۰۰، شامل شکستن کار و تعریف وابستگی‌ها و مدیریت taskها و الخ، و بدون نیاز به درگیر شدن PM، باشند. PM در سطح feature درگیر است و نه در سطح task.

متاسفانه مفاهیم بدِ اسکرامی مانند product ownerای هم در نهادینه کردن این وضعِ مریض، نقش داشته‌اند. در حالی که شما اگر PMگری دارید دیگر باید کارهای POگری را بیرون بریزید. چرا؟ این ویدیو از ایمان، به خوبی مقایسه‌شان کرده - کافی‌ست دقیقه ۲۵ تا ۲۹ را ببینید. مفهوم PO، چه به آن PO بگویید و چه صرفا اسمش را PM کنید که عملا همان کار PO را می‌کند، صرفا نقشی برای ایجاد اصطکاک است. آن ۴-۳ دقیقه ویدیو را ببینید؛ ارزشش را دارد.

اگر این مدل ناسالم را مناسب می‌دانید، که هیچ، ولی اگر مایلید بدانید در گوگل و متا و امثال آن‌ها در دره‌ی سیلیکون چه‌شکلی کار می‌کنند: رهبر فنی و رهبر محصولی، همتا/peer هم هستند و با هم در قبال رسیدن و موفقیت یک محصول، مسئول‌اند. PM هزار و یک کار مهم‌تر از مدیریت پروژه دارد.

چرا این مدل که PM برای تیم توسعه، مدیریت پروژه کند، بد است؟ چون کسی که در عمق فنی نیست: چه‌طور می‌تواند بگوید «اول این task سپس این task»؟ چه‌طور می‌تواند بگوید «چرا سه هفته؟ یک هفته‌ای بزنید»؟ مهم‌تر از همه: چه‌طور می‌تواند پاسخگوی چیزی باشد که مسئولیتی در انجامش ندارد؟ نتیجه آن، فقط اصطکاک است.

۲. نقش TPM

اصطلاح TPM را زیاد می‌بینیم که به معنی PMای که فنی است، استفاده می‌شود. دست کم با تعریف گوگلی، TPM یعنی techincal PgM، نه technical PM! در یک شرکت tech، همه PMها قرار است فنی هم باشند، اصلا اصطلاح technical PM جدا نداریم.

نقش technical PgM یعنی PgMای که کمی فنی هم هست (داشبودر می‌سازد و ...). خودِ PgM یعنی program manager یا به اصطلاح رایج‌تر: مدیر پروژه. این نقش در این یادداشت توضیح داده شده (بخش پایانی یادداشت با عنوان «مدیر پروژه/برنامه» را ببینید).

در واقع نکات بخش قبل (درگیری PM در اجرای پروژه) را می‌توان این‌طور خلاصه کرد: نقش PM را با نقش TPM بسیار خَلط شده می‌بینیم، در حالی که PM و TPM هیچ ربطی به هم ندارند جز این که یک پ و م دارند.

۳. چیستی/چرایی‌ها با PM و چگونگی‌ها با dev؟!

این بازی با واژگان را هم زیاد می‌بینیم (به ویژه در لایه‌های مدیریت) که مثلا what ِ کارها با PM و howاش فلان؛ whyاش چی‌چی؛ و این دست. این جملات شاید گاهی برای رساندن کلیّت و «در حوزه یک پروژه خاص» معنی داشته باشند، ولی در حالت کلی (مثلا بگوییم «what ِ کارها»)، صرفا بازی با واژگان است.

هر how یا whyای، یک what در یک scope دیگر است. هم مهندس نرم‌افزار درگیر what و why و how است و هم PM؛ هم مهندس سطح تازه‌کار در هر سه درگیر است و هم راهبر استراتژیست. قطعا scopeهایش فرق می‌کند، ولی از هر سه جنس هست و این‌طور نیست که «یکی درگیرِ what ِ کارها و یکی how» و این بیش‌ساده‌سازی‌ها (oversimplificationها). خیلی درگیر این بازی با واژگان نشویم.

۴. اصطکاک‌های فرساینده

نسخه‌های مختلف این ادعا را از همکاران در بازار ایران زیاد می‌شنویم: «اگر کلا نقش PM را کنار بگذاریم، اتفاق خاصی نمی‌افتد و برای پیش رفتنِ کارها بهتر هم هست». چرا؟ به دلیل بدتعریفیِ نقش مدیریت محصول و تعاملات آن (به زعم بنده).

از یک سو، ادعای بالا کاملا نادرست است: (اگر محصولات کلاسیک مثل نوشتنِ نرم‌افزار حساب‌داری یا اتوماسیون اداری که سر تا تهش مشخص است را کنار بگذاریم) رشد و بالندگی یک «محصولِ زنده» مانند دیوار و دیجی‌کالا و تپسی و الخ، بدون نقش مدیریت محصول اصلا متصور نیست - دست کم در ذهن بنده. منظورم بیش از آن که درباره‌ی نیاز به تیم با «تخصص» مدیریت محصول باشد، نیاز به تیم با «تمرکز» بر کارهای مدیریت محصول است. یعنی مدیریت محصول، کارِ جانبی نیست؛ شهروند درجه اول در مجموعه‌ی کارهای یک محصولِ زنده است.

ولی ا یک سو، نقش PMای که بیش از آن که برای تعالی محصول آورده داشته باشد:

• در دست و پای کارهای روزمره‌ی توسعه نرم‌افزار است و در افق‌های کوتاه‌مدت (مثلا هفتگی) سعی در هدایت می‌کند، یا
• نقش مدیریت پروژه برای پروژه‌ی نرم‌افزاری را برداشته و در سطح task سعی در پی‌گیری پیشرفت پروژه دارد، یا
• صرفا نقش واسطه‌گری (و فاصله انداختن) بین ذی‌نفعان بیزینسی و مهندسان را دارد، یا
• <شما اضافه کنید: کارکردهای نادرست ولی شایع در مدیریت محصول>

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

۵. پس مدیر محصول چه می‌کند؟

تکرار کنم که تعاریفی که از آن صحبت می‌کنیم، صرفا از شرح شغلی/نردبان مدیریت محصول به تعریف یک سازمان خاص (گوگل) و تجربیات شخصیِ محدود، هستند. انتظارها از نقش PM به شکل سرفصل‌وار به این شرح است:

• طراحی محصول و تجربه کاربری، ساخت و مستندسازی نیازمندی‌ها (PRDها) برای محصولات و featureها، خلق design conceptها.
• تعریف نقشه راه محصولی و شکل‌دهی اهداف محصولی، تعریف منزل‌گاه‌ها (milestoneها)، پژوهشِ مسیرساز (formative research) و شناسایی gapها در بازار.
• تعریف متریک‌های محصولی یا بیزینسی، ارائه برنامه برای اندازه‌گیری آن‌ها، ایجاد هم‌سویی با اهداف بیزینسی، اندازه‌گیری آن‌ها.
• اولویت‌بندی محصولی، برنامه‌ریزی منابع، تعیین مسیر پروژه‌ها در همکاری با تیم‌های مهندسی و سایر ذی‌نفعان.
• ایجاد چشم‌انداز (vision) محصولیِ گیرا و جلب نظر ذی‌نفعان برای همکاری (بیزینس، مهندسی، حقوقی، …).
• برنامه‌ریزی ورود به بازار (go-to-market)، تحلیل اندازه بازار و فرصت بیزینسی در هر دو افق کوتاه و بلندمدت، قیمت‌گذاری در فضای رقابتی بازار.
• مدیریت چرخه حیات محصول، تسهیل launchها، تصمیم‌سازیِ داده‌محور برای نگهداری یا بازنشسته کردن محصولات، همکاری با تیم‌های پشتیبانی برای محصولات.
• توسعه استراتژی بلندمدت محصولیِ سازمان، بازبینی مستمر و ریسک‌زدایی از استراتژی‌ها.

همه‌ی کارهای بالا به شکل کامل، از هر PMای در هر سطحی انتظار نمی‌رود، بلکه گستره/scope آن بسته به سطح PM فرق می‌کند. مثلا از یک PM تازه‌کار (junior) انتظار مشارکت در تعریف یک feature می‌رود؛ از یک PM ارشد انتظار تعریف کامل یک محصول؛ از یک رهبر محصولی (+L6) انتظار رهبری کردنِ شکل‌گیری جمعیِ یک چشم‌انداز و استراتژی محصولی.

و اما نکته‌ی مهم‌تر: شاخصه‌هایی در مدیریت محصول هست که موارد جداگانه در لیست بالا نیستند، بلکه در یَک‌یَک موارد بالا بروز می‌یابند. دو تا از کلیدی‌ترینِ آن‌ها:

• انجام پژوهش کاربری (user research) و تحلیل داده و شکل دادن و اعتبارسنجی فرضیه‌ها و این دست. این تخصص‌ها مهم‌اند و قرار است هر PMای در درونش یک data analyst/آماردان هم داشته باشد. حتی ممکن است گاهی کد هم بخواند و بفهمد - و این موارد در شرح شغلیِ حتی PM تازه‌کار هم آمده.
• مدیریت ذی‌نفعان (از فروش و بیزینس و بازاریابی و حقوقی گرفته تا تیم‌های مهندسی نرم‌افزار)، ایجاد همسویی بین انواع واحد‌های درگیر در پروژه‌ها، و انجام همه‌ی هماهنگی‌ها. حجم این کارها در حدی‌ست که بسیاری از رهبران فنی اصلا شاکی‌اند که چرا این‌قدر به زحمت PMها را پیدا می‌کنند.

درگیری در اجرا: تکرار می‌کنم که از جهت درگیری در اجرا و تحویلِ پروژه‌ی نرم‌افزاری، PMای که درگیر اجرا در ریزدانگی روز/هفته/ماه شود، عملا وقتش را تلف می‌کند - و در دست و پای تیمِ توسعه است. مشخصا این ادعا را، به جز تجربه شخصی، با چندین تن از دوستان از شرکت‌های دیگرِ دره‌ی سیلیکون هم به بحث گذاشتم و نگاه‌ها را مشابه یافتم. PM در مقیاس درشت درگیر زمان‌بندی پروژه‌های نرم‌افزاری‌ست (چه چیزهایی در پایان Q1 می‌رسند، چه چیزهایی در Q2) و آن هم برای هماهنگی و نه برای مدیریتِ پروژه. درگیری PM در مقیاس «هفته»، چیزی‌ست که در بازار ایران زیاد می‌بینیم.

متوجه‌ام که بسیاری از ناکارآمدی‌ها، کشمکش بر سر قلمرو و سهم‌خواهی از پروژه‌ها و عملا جنگ قدرت و نفوذ هستند (نه تنها بین نقش‌ها بلکه در هر سطحی) - از جمله در گوگل. ولی در این یادداشت فرض کردیم ساخت‌یافته فکر می‌کنیم، آن مشکلات را جدا کردیم، و با فرض «همه به دنبال تعالی کسب‌وکارِ شرکت هستیم» درباره کارآمدیِ سازمان صحبت می‌کنیم.