مدیرمحصول یا مالک محصول یا مدیرپروژه، مسئله اینست!

در نقش مدیرمحصول، مالک محصول و یا مدیر پروژه شروع به کار کردید، اما نمی دونید تعریف دقیق وظایفتون چیه؟ یا شاید شما فکر می­کنید که می دونید تعریف وظایفتون چیه اما بقیه از اون اطلاعی ندارند یا تفاوت دیدگاههایی بین شما وجود داره که کار رو برای شما و دیگران دچار چالش کرده؟

باید بگم شما تنها نیستید من و بسیاری از همکارانم با همین عناوین شغلی در سازمانهای مختلف مشغول به کار هستیم و همگی با چالش بالا درگیریم.

برای پاسخ دادن به موضوعاتی از این جنس به خودم، مدتیست درحال مطالعه در مورد این نقش­ ها و تفاوتها و شباهتهاشون و حوزه اختیار و عملکردشون هستم، در این مدت تونستم به مجموعه مطالب منتشر شده از منظرهای مختلفی برسم و در نهایت به یک جمع ­بندی منطبق بر خوانده ها و تجارب کاریم در پروژه­ ها و شرکتهای مختلف نزدیک بشم، تصمیم گرفتم اون رو منتشر کنم شاید بتونه سوالاتی رو از هم_چالشی­های خودم جواب بده و کمکی به حل موضوعات ایجاد شده­ ی حاصل از این دست مسائل بکنه.

دو سوال اساسی من این بود؟

– تعریف وظایف مدیرمحصول، مدیرپروژه و مالک محصول چیه؟

– نقش و جایگاه هر کدام از این­ها در ساختار سازمانی کجاست؟

زمانی که به عنوان تحلیلگر در شرکتی نیمه ­دولتی مشغول به کار شدم، هیچ اثری از آثار عناوین محصولی در رده­ های شغلی مرتبط با چرخه تولید نرم افزار نه شنیده میشد و نه دیده میشد. اما به شکلی نرم و ناملموس فرهنگ سازمانی شرکت­ها از ساختارهای مبتنی بر واحد به ساختارهای مبتنی بر محصول تغییر شکل دادند و به تبع اون عناوینی مثل مدیر و مالک محصول بیش از قبل شنیده و به مرور در آگهی های استخدامی و در سازمان ها دیده شد. البته ورود و استفاده از متدولوژی های اجایل مثل اسکرام هم در مدیریت چرخه حیات نرم افزارها در این قضیه بی تاثیر نبوده.

اگر جستجوی ساده ­ای در گوگل در مورد مدیرمحصول و مالک­ محصول داشته باشید، مطالب زیاد و اکثرا مشابه ای رو می­تونید ببینید که بیشتر محتوی اونها شبیه هم هست، نکته ای که لزوم نوشتن این مطلب رو برای من ایجاد کرد جمع­ بندی و مقایسه ای مبتنی بر تجربه کاری در این نقش­ها بود. با این توضیح قصد ندارم مطلب رو خیلی به سمت و سوی جزئیات این نقش­ ها به صورت مستقل ببرم چون در سایر منابع میشه در موردشون مطالعه داشت، اما اگر بخوام شما رو همراه خودم در مسیر رسیدن به پاسخ سوالاتم ببرم باید برای هر کدوم حداقل در یک پاراگراف شرح وظیفه (به تعبیرِ من درست) تعریف کنم:

مدیرمحصول

مسئولیت تعریف، توسعه، بازاریابی، پشتیبانی و اجرای موفق یک محصول به صورت کامل در اختیار یک مدیر محصول هست. همین تعریف چند کلمه ای خودش نشون میده که یک مدیر محصول باید دانش قابل قبولی در حوزه های شناخت بازار و کاربران و فضای رقبا، حوزه های فنی و تکنولوژی های به روزِ مورد استفاده در سازمان (والبته در خارج سازمان)، توانایی پردازش اطلاعات و تحلیل اونها و ارائه استنتاجات مدیریتی در این ارتباط، درک و دانش کامل از کسب و کار و البته تحلیل های مالی و برآورد سود و زیان ده بودن محصول رو داشته باشه (حداقل دانش موردنیاز رو بیان کردم) و در کنار همه ­ی اینها مدیریت زمانبندیِ تولیدِ و فروش محصول رو هم داشته باشه.

ذکر این توضیح رو ضروری می­دونم که یک فرد قرار نیست همه این کارها رو به تنهایی انجام بده و یک تیم در کنار سایرتیم ها از پس انجام این امور بر میاد و من تنها از واژه­ ی مسئولیت و لزوم داشتن دانش برای ایفای مسئولیت استفاده کردم.

مالک محصول

با باز شدن بحث اسکرام به شرکتهای نرم ­افزاری نقش مالک محصول هم بر سر زبانها افتاد، مالک محصول در متدلوژی اجایل و در تعامل با تیم­های توسعه نرم افزار نقش مدیریت بک لاگ ها رو به عهده دارند.

سوال اصلی اینه که ورودی های بک لاگ از کجا تامین میشه؟

اگر نقش مدیرمحصولی در سازمان داشته باشیم ورودیهای این بک لاگها از مرجع مدیرمحصول تعیین و تدوین میشه و اگر نقش مدیرمحصول نداشته باشیم این وظیفه به مالک محصول منتقل شده که پس از تایید مدیرعامل (یا هر نهاد بالادستی) در لیست بک لاگ قرارشون میده.

جنس فعالیتهای مالک محصول که در زیرمجموعه مدیرمحصول قرار می گیره بیشتر از جنس رسوندن محصول از مرحله تعریف نیازمندی تا تحویل محصول از تیم فنی هست.

مدیر پروژه

در ساختارهای قدیمی نقش مدیرپروژه (حداقل اسماً) مساوی با نقش مدیرمحصول بود. در اون شرایط مدیران پروژه علاوه بر مدیریت زمانبندی، وظایفی که در ذیل بخش وظایف مدیرمحصول اسم بردم رو هم به عهده داشتند. اما در ساختارهای جدید که نقش مدیرمحصول و مالک محصول رو داریم، مدیرپروژه عملا یا وجود نداره یا اگر وجود داره در ابعاد همون محصول وظایفی مثل استانداردسازی و کنترل حرکت اعضا در چارچوب استانداردها، زمانبندی و نگهداشت زمان تیم ها و افراد مختلف مرتبط با همان محصول خواهد بود.

تجربه شخصی من در تیم های مدیریت محصول مختلف میگه که حداقل در شرکت های نرم افزاری چنین نقشی به صورت مستقل اگر تعریف بشه، خیلی کارا نخواهد بود. اون هم به دو دلیل، اول نداشتن قدرت (در حد مدیرمحصول) برای جلب همراهی تیم­ها و افراد و دوم نداشتن دانش در حدی که درک کاملی از ابعاد کار داشته باشد. بنابراین عموما این نقش اگر برعهده مدیران محصول باشد همیشه خروجی بهتری عاید تیم محصول و سازمان خواهد شد.

درسازمانها یا ساختارهای کوچک و جور دو و یا هر سه مسئولیت رو یک نفر و بعضا شخص مدیرعامل به عهده می گیره و قاعدتا این موضوع در مورد سازمانهای بزرگ و یا ساختارهای بزرگ جوابگوی موضوعات و مسائل نخواهد بود.

این نکته تکمیلی رو هم بگم که در بحث کلان سازمانی، سازمان ممکن است نیاز به PMO یا دفترمدیریت پروژه داشته باشد که به صورت کلان و در ابعاد شرکت برنامه زمانبندی و یا بودجه و منابع انسانی را کنترل و پایش کند که بحث جدایی است و دراینجا وارد این بحث نمیشم.

اگر نخوام متن رو خیلی طولانی کنم، بسنده می کنم به چارت سازمانی پیشنهادی من با تعاریفی که در بالا بهشون رسیدم و خودش گویای همه چیز خواهد بود:

در این چارت مدیریتی تحت عنوان مدیریت کسب و کار، وظیفه همسوسازی، رفع چالشها، سیاست­گذاری در حوزه محصول، بودجه ­ریزی کلان، زمانبندی و سایر موضوعات تیم­های محصولات مختلف را مدیریت می کند.در ذیل این مدیریت مدیران محصول تعریف و در ذیل این مدیران مالکان محصول جای می گیرند.

ارتباط مدیریت کسب­ و­کار و سایر مدیریت­های هم­سطح از جنس خدمات­ دهی و خدمات­ گیری و به­ صورت ماتریسی است.

و در پایان همون طور که پیتر دراکر در کتاب خودش با عنوان چالش‌های مدیریت در قرن بیست­ ویکم میگه ساختار سازمانی، حقیقتاً حل کننده‌ی مشکلات سازمان نیست. مشکلات فرآیندی و مشکلات پرسنل، هرگز با تجدید و اصلاح یک ساختار سازمانی حل نمی‌شوند و همون طور که همگی می دونیم هیچ ساختارسازمانی یگانه ای برای همه ­ی سازمانها عالی­ترین نیست و این موضوع بسته به رسالت و ابعاد و صنعت فعالیت هر سازمان می­تونه متفاوت باشه. مسئله اصلی این هست در هر سازمانی بهترین ساختار تدوین و براساس اون حرکت بشه و معیارهای موفقیت محصول و به تبع اون معیارهای موفقیت مدیران محصول شفاف و واضح بیان بشه.

سفر در جاده های بی نشان

به این جمله بدیهی آگاهیم که توسعه محصول جدید نیاز به خلاقیت داره… اما آیا به همون بدیهی می پذیریم که خلاق بودن، سفر در جاده های بی نشان است؟


در مسیر توسعه محصولات جدید، بیشترین تصمیمات ما برپایه حقایق شدیدا نادرست یا ناکافی گرفته میشن و نکته جالب اینکه ما می دونیم چه حقایقی رو نیاز داریم و شیوه رسیدن به اونها چطوره اما … اما وقت و پول کافی نداریم!


پس این میشه که در اولین زمان ممکن با حداقل پولِ ممکن برای عقب نموندن از رقبا در جاده های بی نشان شروع به حرکت می کنیم، ماجرا به اینجا ختم نمیشه و شاید از همه اینها بدتر میتونه زمانی باشه که بر پایه حقیقتی دانسته پا در جاده بذاریم و در میانه راه متوجه بشیم که اون موضوع دیگه حقیقت نیست!


بپذیریم خلاقیت، ریسک به همراه داره و پذیرش ریسک رو با درک شهودی و یا همون شمّ درکِ مطلب مخلوط و توشه راهمون در جاده های بی نشان توسعه محصولات جدید کنیم.

اثرهاله ای در محصولات جدید

من هم مثل شما در مورد اثر هاله­ ای (halo effect) در حوزه روانشناسی مطالبی رو خوندم و در موردش کم و بیش فکر کردم و نمونه هاش رو هم در زندگی خودم کم ندیدم.

این اثر چی میگه … میگه که نوعی از سوگیری یا خطای شناختی وجود داره که در اون افراد ویژگی­های مشخصی از یک انسان یا هر پدیده دیگه ای را مبنایی برای قضاوت درباره کل آن قرار می دهند.

حالا چند وقتیه به این موضوع فکر می کنم که اثرهاله ای در حوزه طراحی محصولات جدید هم خودش رو به شکل واضحی نشون میده. کی؟ وقتی که با دیدن محصولِ موفقِ سایرشرکتها به خودمون بگیم اگر ما هم این محصول را تولید کنیم موفق خواهیم شد و بلافاصله دست به کار تولید بزنیم.

دیدن و آموختن از نمونه محصولات موفق حتما مفید و حتی لازمِ، اما نکته اینجاست که آیا خوب و­ دقیق به پیشینه تحقیقاتی، زمان و هزینه ­ی صرف شده برای پیش تحقیق و تولید و پس ­تولید، توان نیروی انسانی موجود و موردنیاز و قابل دسترس، حمایت و در یکراستا بودن مدیریت بالادستی ها و دهها موضوع دیگری که باعث شکل گیری موفقیت محصول اون شرکتها شده هم فکر کردیم؟

چقدر در سازمانهامون پیش اومده که با دیدن محصولِ جدید یکی از رقبا، بدون مکث و درنگ دست به کار تولید زدیم تا به زعم خودمون از گردونه ی رقابت عقب نیفتاده باشیم؟