این سری یادداشتها در راستای اشتراک دانش و تجربه در زمینه توسعه بازیهای موبایلی به رشته تحریر درآمدهاند. کوییز آو کینگز بیش از ۱۰ سال پیش توسط شش دانشجو دانشگاه امیرکبیر به نامهای امیرحسین ناطقی، فراز شمشیردار، محمدحسین حیدری، محمد سلیمانیفر (نگارنده این یادداشتها)، محمدعلی ساعتچی و وحید زاهدنژاد تاسیس شد و امروز با گذشت بیش از یک دهه، توسط تیمی جوانتر و مستعد با بیش از ۲۰ میلیون کاربر به مسیر خود ادامه میدهد.
بدیهی است که ذکر برخی از مثالها از مسیر توسعه، برای روشنتر شدن مفهوم کلی بیان میشود و لزوما ارتباط مستقیمی با مجموعه کوییز آو کینگز و یا شکل مدیریت آن ندارند. در واقع بیشتر از جنس تجاربی هستند که در این سالها و در سمت مدیریت فنی کوییز آو کینگز کسب کردم و امیدوارم انتقال آن به دیگر توسعهدهندگان، اندکی مفید باشد.
مورد اول: تعامل با سرمایهگذار
ما چند دانشجوی جوان بودیم و چندان دیدی نداشتیم که سرمایهگذاری چطور روندی دارد، فرایند واگذاری سهام (Vesting) چطور پیش میرود، تعهدات چطوری خواهد بود و اگر کسی به تعهداتش عمل نکند چه باید کرد؟
همین موارد باعث شد تا در مراحلی در ماهها و سالهای ابتدایی توسعه محصول، دچار مشکلاتی شویم. اگر به گذشته برگردم، سعی خواهم کرد تا پروسههای از این جنس را برای محصولی که «وایرال شدن» را تجربه میکند، شفافتر و دقیقتر مشخص کنم و شخصا بیشتر در رابطه با آنها مطالعه کنم. البته که همکاران من و بهطور خاص همموسسان کوییز، همواره تلاششان را کرده و میکنند تا بهترین خروجیها برای محصول رقم بخورد؛ اما میتوان با اصلاح برخی روندها در تجربههای مشابه، فضای رشد بزرگتر و بهتری رقم زد. این فضا هم برای کارمندان آن استودیو صادق خواهد بود، هم برای همموسسان و تیم مدیریتی آن.

سعی کنید تا پروسههای قانونی را بهتر بشناسید، ترجیحا با یک یا چند وکیل و مشاوره حقوقی مشورت و بعد برای پروسههایی مثل جذب سرمایه (آن هم برای محصول موفق) اقدام کنید. بدون شک تجارب و دانش امروز، میتوانست در گذشته به خروجی بهتری برای تیم توسعهدهنده بازی ختم شود.
مورد دوم: ابزار درست!
امروز احتمال اینکه چنین اشتباهی را در تیمهای حرفهای بازیسازی ببینیم، بسیار کمتر از گذشته شده است. با این حال برای ما که چندان به بزرگتر کردن کوییز در گذر زمان (Scale Up) فکر نکرده بودیم و چند دانشجوی کمتجربه بودیم، بهای سنگینی داشت.
ما از زیرساختی استفاده کردیم که اصلا برای یک محصول بازی با ماهیت آنلاین، مناسب نبود! ما کار را با PHP شروع و از فریمورک Symfony استفاده کردیم. در حالی که PHP یک زبان Compile شدنی نیست و همین برای اینکه بگوییم PHP مصرف Resource بیشتر و بازدهی کمتری دارد، کافی بود. اگر الان و امروز بخواهم دوباره همین محصول را بسازم (از منظر مبنا و اندازه پیشرفت)، قطعا از زبان Golang استفاده میکنم. البته که تاکید میکنم، الان.
مورد سوم: تغییر درست در زمان اشتباه
ما مهاجرت به زبان Go را از سال ۲۰۱۵ شروع کردیم، در حالی که آن زمان تعداد توسعهدهنده زیادی که به Go مسلط باشند، وجود نداشت و ما هم در حال یادگیری بودیم. از نظر عملکرد و Performance این زبان فوق العاده است؛ اما کامیونیتی آن در بازهای که سراغش رفتیم، چندان در ایران قدرتمند نبود. این شد که پروسه سوار کردن نیروهای فنی روی پروژه یا بهاصطلاح On-Boarding، زمانگیرتر و البته سختتر از تجارب دیگر ما بود. اگر الان به آن زمان برگردم، برای مهاجرت، زبان Java را انتخاب میکردم. اگرچه قبلتر هم گفتم که امروز بهترین زبان برای چنین پروژهای و با این وسعت بدون شک Go خواهد بود.
مورد چهارم: تغییرات زیرساخت و درسهایی که گرفتیم
- مهاجرت زیرساخت MySQL به Sharded MySQL یا Vitess
ما کاربران زیادی داشتیم و با موجهای وایرال شدن، به سرعت کاربران زیادی جذب کردیم، تا جایی که یک Database تک Node یا حتی Replicated، چندان برای نیازهای ما جوابگو نبود. پس به سراغ روشی رایگان و قابل استفاده در ایران رفتیم و آن هم استفاده از دیتابیس Vitess بود. این زیرساخت امروز توسط خیلی از شرکتها استفاده میشود؛ اما همچنان در ایران و دنیا چندان کامیونیتی پاسخگویی ندارد و از این منظر ممکن است با مشکلاتی دست و پنجه نرم کنید.
این تصمیم باعث شد که ما برای نیروهای DevOps و SRE با سربار جدی در زمینه Onboarding مواجه بشویم. تاکید میکنم که در چنین پروژه و فضایی، بخش SRE مهمترین و حیاتیترین بخش فنی به حساب میآید؛ زیرا باید کیفیت محصول و سرویس را تضمین کند. وقتی شما در این بخش ضعف داشته باشید، کیفیت سرویس مدام دچار اختلال میشود و اعتماد کاربران از دست میرود. فراموش نکنید که به تمامی مواردی که به شکل داخلی با آن دست و پنجه نرم میکنید، ناملایمتیهای دیتاسنترها و بیمسئولیتیهای گاه و بیگاه برخی از آنها را هم اضافه کنید.
مورد پنجم: همزمانی مهاجرتها و مشکلات جدید
مهاجرتهای همزمان از کد و زیرساخت، دردسرهای زیادی برای پیشبرد کارها ایجاد کرد.
ما در سال ششم، بخش PVP Game Sever بازی را از PHP که یک کد Monolithic و اسپاگتی بود به کد Golang Microservice Architecture مهاجرت دادیم؛ اما همزمان با این مهاجرت، دیتابیس را هم از Vitess به Mongo مهاجرت دادیم.
مهاجرت دادن موازی هم زیرساخت و هم کد، سربار تست و سعی و خطای زیادی به ما تحمیل کرد و باعث شد پروسهی مهاجرت به جای شش ماه، یک سال زمان ببرد. در انتها نتیجه مثبت بود و شاهد کیفیت سرویس مطلوبتر و رضایت بیشتر کاربران بودیم؛ اما میشد با مدیریت بهتر این پروسه، کار را بهتر و با فشار کمتری مدیریت کرد. موردی که به تمامی تیمهای جوان توجه به آن را توصیه میکنم: همزمان نشدن پروژههای بزرگ.
مورد ششم: مدیریت بهتر فرآیند جذب و استخدام در هنگام مواجهه با رشد
استخدام پرتعداد نیروهای متخصص بدون در نظر گرفتن زیرساخت لازم برای رشد و توسعه فردی آنها و در ادامه کمک به رشد و توسعه محصول و کسبوکار، بیمعنی خواهد بود. سعی کنید همواره برای مسیر جذب، پیشرفت و حتی جدا شدن نیروها از مجموعه، پروسههایی را تعریف کنید. این مورد باعث میشود تا در هر بازهای از چرخه حضور نیرو در شرکت یا استودیوی شما، همواره برنامهای برای توسعه و بهبود همکاری پیشرویتان باشد.
علاوه بر این، چنین روندی کمک خواهد کرد تا یکنواختی و از دست رفتن حس و حال (Passion) توسعه محصول پیش نیاید و البته پروسه سنجش عملکرد افراد حاضر در کسبوکار نیز سادهتر خواهد بود. ما در کوییز آو کینگز در طول این یک دهه، تجربیات ارزشمندی در این زمینه کسب کردیم و البته لطمههایی هم از فرهنگ دورکاری در دوران کرونا خوردیم. لطمههایی که بدون شک با تجربه بیشتر در موقعیت مشابه، میتوان از آن جلوگیری کرد و به خروجی مطلوبتر و بهینهتری رسید.
مورد هفتم: بهترینها در خدمت مهمترین پروژهها
در این سالها و در طول مسیر توسعه کوییز آو کینگز، افتخار همکاری و کسب تجربه از دوستان زیادی را در این حوزه داشتم. اگر بخواهم یک تجربه از این سالها با شما به اشتراک بگذارم، این است:
«اگر کسی کارش رو درست انجام میده، دلیل نمیشه مدیر خوبی هم باشه».
تواناییهای لازم و مجموعه مهارتهای مد نظر برای پیشرفت مدیریتی هر مجموعه، مواردی هستند که لزوما با موارد مورد نیاز در زمینه فنی مطابقت ندارند. لذا به تعداد بسیار زیاد با نیروهای فنی درجه یکی مواجه خواهید شد که توانایی مدیریتی اندکی دارند و برعکس. بهنظرم شناسایی افراد با توجه به تواناییهایشان و سپس سپردن نقشها به آنها، مهمترین کاری است که یک مدیر بالادست باید در چنین کسب و کارهایی انجام دهد. فراموش نکنید که حال خوب نیروهای شما، ارتباط مستقیمی به روابط آنها با مدیران میانی دارد و به همین خاطر انتخابها در این زمینه اهمیت بالایی دارند.
همچنین پیشنهاد میکنم درست بهمانند سازوکار پروموشن و ارتقا شغلی، سازوکاری هم برای Demote احتمالی و تنزل جایگاه شغلی افراد در صورت عملکرد دور از انتظار در بازههای طولانی داشته باشید. این مورد به ارتباط هر چه شفافتر بین دو طرف کمک شایانی خواهد کرد.
در انتها و بهعنوان جمعبندی اولین یادداشت از این سری، به مرور کوتاه برخی از موارد ذکر شده میپردازیم:
۱- برای شروع کار و انتخاب سرمایهگذار دقت کنید. فراموش نکنید که هر آنچه انجام میدهید، مکتوب و در راستای قوانین کشور باشد تا بتوان در ادامه پیگیریهای مرتبط با آن را انجام داد. همچنین داشتن درصدی از سهام بهعنوان تشویق برای جذب نیروهای خبره، میتواند در طولانی مدت کمک شایانی به شما و رشد کسب و کارتان بکند.
۲- در انتخاب زبان برنامهنویسی و زیرساخت، به مناسب بودن آن و مطابقت با محصولتان توجه کنید. این مورد هم شامل کامیونیتی و پشتیبانی محصول و هم عملکرد و پرفورمنس آن میشود.
۳- در هنگام رشد و بهطور خاص رشدهای افسارگسیخته که نیازمند پشتیبانی محتوایی یا فنی هستند، در پروسه جذب و استخدام نیرو دقت بیشتری داشته باشید. همچنین مراحل همکاری را شفافتر باهم پیش ببرید تا در ادامه سرنوشت آن راحتتر قابل مدیریت باشد.
۴- افراد خیلی مواقع فارغ از ارزشهای انسانی در محیط کار سنجیده میشوند و متاسفانه این حقیقت فضای تجارت است. پس ممکن است افرادی باشند که تعامل با آنها و روند همکاریشان بسیار لذت بخش باشد؛ اما ارزشهای فنی مجموعه شما را به بهترین شکل عملی نکنند. در این چنین مواقعی سعی کنید با پروسههای سنجش کوتاه و میان مدت، عملکرد نیروها را بسنجید و البته برای بهبود و یا قطع همکاری با آنها تصمیم بگیرید.
۵- علاوه بر مکانیزمهای جذب و جدایی نیرو، به فرآیند پیشرفت شغلی (Promotion) و تنزل رده شغلی (Demote) هم فکر کنیم. این موارد در طولانی مدت به سلامت کسب و کار شما و حفظ شادابی محیط کار کمک زیادی میکنند.
source