از وقتی که به خاطر میارم، عاشق بازی‌های کامپیوتری بودم. حس خوب غرق شدن توی یک دنیای فانتزی و پشت سر گذاشتن ماجراهای مختلف، من رو مجذوب می‌کرد و همیشه آرزو داشتم ساختنش رو هم امتحان کنم. تجربه‌های اولم از ساخت بازی و تیم بازیسازی موفق نبود اما چیزهایی که یاد گرفتم بهم کمک کرد تا در استودیوی بازیسازی بلوط‌گیمز به عنوان مدیرمحصول استخدام بشم، روی پروژه موفق سفره‌چی کار کنم و در توسعه بازی جدید به وقت آشپزی همراهی کنم. فقط حدود 8 ماهه که اینجا مشغول شدم، با این حال تصمیم گرفتم درباره این تجربه کوتاه بنویسم تا بازخورد بگیرم و دید وسیع‌تری نسبت به چیزهای مختلفی که برای یاد گرفتن در این حوزه هست، پیدا کنم.
کار من چیه؟
هیچی. از صبح به همه الکی گیر میدم، تو کار همه هم فضولی میکنم. همیشه هم سر اسکرام دعوا دارم. ?
اولین چالش من پاسخ دادن به همین سوال بود. بعضی از وظایف من از اول مشخص بود (مثل نظارت بر اجرای Scrum، برگزار کردن جلسات مرتبط و برنامه‌ریزی هر چرخه‌ی توسعه نرم‌افزار) ولی این‌ها به نظرم برای مدیریت یک محصول کافی نبود و برای همین، باید محصولی که قرار بود روش کار کنم رو خوب می‌شناختم تا خودم رو با اون تطبیق بدم.
1. اولین مرحله، شناختن مدل کسب و کار و درآمد محصول بود؛
این محصول چیه؟ چه اهدافی داره؟ برای چه افرادی تولید شده؟ از چه راه‌هایی درآمد ایجاد میکنه؟ توسعه این محصول شامل چه مراحلیه و چه هزینه‌هایی داره؟ نقش و تخصص هر عضو تیم چی هست؟ چه اطلاعاتی بین چه نقش‌هایی منتقل میشه؟
تلاش برای پیدا کردن جواب این سوال‌ها، ذهنیتم رو تنظیم و من رو برای مراحل بعدی آماده کرد.
2. مرحله بعد، قرار گرفتن در سیستم و تجربه‌ی سیستم
برای شناختن دقیق‌تر مراحل، خودم رو در انجام کارها دخیل می‌کردم و البته حواسم بود که از دادن نظرات غیرتخصصی در اون کارها دوری کنم تا تبدیل به مانع‌تراشی بیهوده برای تیم نشه. این دخیل شدن، هم بهم ایده‌هایی برای درک بعضی فرایندهای نانوشته داد و هم به درک ارتباطات بین اعضای تیم و وظایف هر کدوم از اعضا کمک کرد. فایده‌ی مهم دیگه‌ش این بود که ذهنیت من رو نسبت به سیستم‌های نرم‌افزاری تنظیم کرد؛ در مواقعی انتظار داشتم سیستم‌ها مطابق فرایندی که به نظرم منطقی بود کار کنه، اما طولی نمی‌کشید که هم بفهمم اینطور نیست و هم متوجه بشم که چرا اینطور نیست.
3. مرحله بعد، تحلیل و شناخت ضعف‌ها
طی کردن شناخت اولیه و تجربه‌ی سیستم، حدود 3 ماه اول کاری من بود که منجر به پذیرش من از سمت اعضای تیم و شناخت بهتر من از ظرفیت انجام کارها شد. از اینجا به بعد، حضور خودم رو از روند انجام بعضی کارها کمرنگ کردم و به جاش، روی انجام اون توسط اعضای دیگه‌ی تیم تمرکز کردم؛ یعنی مسئولیت انجام کاری رو به فردی واگذار می‌کردم و روی انجام اون کار نظارت و پیگیری داشتم. این زمانی رو از من آزاد می‌کرد تا کیفیت انجام کارها توسط دیگران، چالش‌های اون و نقاط قابل بهبود رو شناسایی کنم.
4. مرحله بعد، راه حل برای بهبود و هماهنگی
شناسایی نقاط قابل بهبود، خود به خود منابع و ایده‌هایی برای اعمال بهبودها میده اما هرچیزی هم که خوب به نظر میرسه، نباید بلافاصله به عنوان بهبود در نظر گرفت. زمانی که تغییرات ذره ذره اتفاق بیفتن، نتایجشون ملموس‌تره و اعضای تیم پیوسته به اون‌ها مقید میشن. در نظر گرفتن ظرفیت پذیرش تیم و ظرفیت نظارت تیم مدیریتی، به برنامه‌ریزی روند اعمال بهبودها کمک میکنه.
5. تکرار مداوم همین چرخه
با گذر زمان، خواه ناخواه تغییراتی در محصول و تیم به وجود میاد و این یعنی باید مدام در حال شناخت محصول و تیم، نقاط بهبود و راه حل‌های اعمالشون بود.
طبیعیه که کسب «موفقیت» یک هدف ایده‌آل هست. اما، منظور ما از این «موفقیت» دقیقا چیه؟ جمله‌هایی مثل «محصولی موفقه که لذت‌بخش و باکیفیت باشه، کاربرهای زیادی داشته باشه و کلی پول در بیاره» وسوه‌برانگیزن، اما کافی نیستن چون «قابل اندازه‌گیری» نیستن. برای همین، سعی می‌کنیم سنجه‌هایی (Metrics) تعریف کنیم و موفقیت محصول رو با اون‌ها تعریف کنیم. مثلا، دوست داریم در ماه اول بعد از انتشار یک محصول جدید، روزانه هزار نفر اون رو باز کنن و در ماه دوازدهم بعد از انتشار، این عدد به 10 هزار نفر برسه.
هر پروژه‌ی نرم‌افزاری حجم داده‌ی قابل توجهی از کاربرانش جمع‌آوری میکنه. با تحلیل و بررسی این داده‌ها، می‌تونیم تصمیمات بهتری برای جهت‌دهی به محصول بگیریم و مشکلات رو ریشه‌یابی کنیم. مثلا، انتشار یک بازی روی چند استور، به خاطر هزینه بازاریابی و مسائل فنی، ممکنه هزینه‌بر باشه و داشتن معیاری برای اولویت‌بندی استورها، می‌تونه حجم کار رو برای تیم تعدیل کنه. مثلا، مقایسه کاربران استورهای مختلف یک بازی از نظر تعداد نصب، میزان درگیر شدن کاربران و تمایلشون به خرید، به اولویت‌بندی استورها کمک میکنه.
طبیعیه که توسعه چیزهای جدید برای تیم به شدت جذابه و رفع باگ یک کار دست و پاگیر به نظر بیاد، ولی همیشه نباید خواست خودمون رو در اولویت قرار بدیم. اگه اولویت تیم با تجربه‌ی کاربر نهایی نباشه، ممکنه ضربه‌ی جبران‌ناپذیری به محصولمون وارد بشه. البته، نباید به هر نظری اولویت داد و خبره‌های تیم، از متخصص‌های طراحی و UI/UX گرفته تا مهندس‌های برنامه‌نویسی، حرف‌هایی برای گفتن دارن که در کنار نظرات کاربران منجر به ایده‌های خلاقانه‌ای برای بهبود محصول میشه.
توسعه یک محصول تا موفقیت و پشتیبانی از اون، مثل یه سفر طولانیه و داشتن یه نقشه و برنامه‌ی خوب برای این مسافرت واجبه! قرار هم نیست توی این برنامه همه چی رو با جزئیات مشخص کنیم و نباید هر مقصد مسیر رو ایده‌آل انتخاب کنیم. خصوصا اینکه به ندرت همه چیز طبق برنامه پیش میره.
برای رسیدن به مقصدهایی که در نقشه مشخص شدن، لازمه که اون‌ها رو خرد کنیم و کارهایی که باید برای رسیدن به اون‌ها انجام داد رو مشخص کنیم. علاوه‌بر اون، کارهایی برای پاسخگویی و حل مشکلات کاربرها هم در نظر می‌گیریم. به این ترتیب، مشخص میشه که در - مثلا - هفته‌ی آینده چه کسی چه کارهایی رو باید انجام بده و این چه تأثیری در محصول ما داره. البته، ممکنه در حین انجام کارها، اولویت‌بندی عوض بشه یا مسائل مهمی پیش بیاد که نیازمند پاسخگویی سریع تیم به اون‌ها باشه و بنابراین، باید در برنامه‌ریزی تا حدودی انعطاف‌پذیر هم باشیم.
یه تعریف ساده از مدیریت، «انجام کارها از طریق افراد دیگه» هست ولی شاید بهتر این باشه که اجازه ندیم یدک کشیدن کلمه «مدیر» گولمون بزنه. به هرحال، یه محصول از عدم به وجود نمیاد و خودش خودش رو به‌روز نمی‌کنه. یه تیم از افرادی با شخصیت‌های رنگارنگ، توانمندی‌های منحصربه‌فرد و تجربه‌های متفاوت کنار هم جمع میشن و برای خلق یه محصول تلاش میکنن. در نقش مدیرمحصول، می‌تونیم یه هم‌تیمی خوب هم باشیم در عین اینکه برای رسیدن به اهداف تعیین شده و موفقیت پروژه، جدیت به خرج میدیم.
شاید هیچ چیزی مثل بازی‌های ویدیویی وجود نداشته باشه که دانش، مهارت، تجربیات و احساسات بشریت رو یک‌جا جمع کنه تا تجربه‌ای لذت‌بخش و آموزنده خلق کنه. اگر دوست دارین با فرایند تولید بازی و ابعاد مدیریتی و فنی اون آشنا بشین، بازی Game Dev Tycoon رو حتما امتحان کنین؛ یه بازی شبیه‌سازی که در اون صاحب یه استودیو بازیسازی هستین و با سیر اتفاقات تاریخی این صنعت جذاب همراه میشین. مدیریت منابع مالی شما رو وادار به انتخاب مسیرهای جالبی میکنه تا کم‌کم بتونین بازی رویایی خودتون رو بسازین.
من هنوز تازه‌کارم و خیلی چیزا هست که باید یاد بگیرم. ولی تا به اینجا، این درک من از این کار هست:
«مدیریت» یک کلمه هست ولی در عمل، چالش‌های زیادی داره. گاهی لازمه به یه مسئله از چند دید مختلف نگاه کرد تا راه حل خوبی پیدا بشه، گاهی در تعامل با افراد مختلف صبوری می‌طلبه، همه‌چیز همیشه عالی نیست، همه تصمیم‌گیری‌ها آسون نیستن و ممکنه درک علتشون برای همه راحت نباشه، و بعضی تجربه‌ها با هزینه‌ی هنگفتی به دست میان. دایره وظایف یه مدیر محصول هم همیشه مشخص نیست ولی همزمان، مسئولیت خیلی چیزا رو دوششه. اما شاید مهم‌ترینش، خلق ارزش باشه.
ولی خودمونیم، قشنگیش به همیناس :)
What It Takes to Become a Great Product Manager (hbr.org)
The 7 dark sides of being a product manager (and how to deal with them) - Growth Mentor
