چگونه یک PM می‌تواند تولید هنر را متحول کند: یک مطالعه موردی در بازی‌های AAA

سلب مسئولیت

در طول کار به عنوان مدیر پروژه، اغلب نظراتی مانند این می‌شنیدم: "چرا اصلاً به مدیران پروژه نیاز داریم؟ واقعاً چه کاری انجام می‌دهند؟ فقط صحبت می‌کنند و بس." این یک نظر نسبتاً رایج است.

بنابراین مقاله‌ای درباره این‌که مدیر پروژه واقعاً چه کاری می‌تواند انجام دهد (همراه با تیمش) و این کار چقدر می‌تواند برای یک پروژه تاثیرگذار باشد، آماده کردم. همان‌طور که ما مدیران پروژه و تولیدکنندگان دوست داریم — با اعداد، جداول و نمودارها. سه بخش درباره خط تولید هنری، بهینه‌سازی مسیر روزانه و آداب JIRA وجود دارد.

این مورد از تجربه شخصی من می‌آید و بر روی این تمرکز دارد که چگونه یک بخش لوازم آرایشی را از ابتدا در یک پروژه AAA ساختیم و در نهایت تولید هنری را بهینه کردیم، با سرعتی 3.3 برابر بیشتر.

بسیار متشکرم. از خواندن لذت ببرید.

خط تولید هنری

مورد

زمانی که به عنوان مدیر پروژه وارد تولید شدم با یک مأموریت: ساخت بخش لوازم آرایشی که اسکین‌ها (و موارد بیشتر) را برای پاس‌های نبرد و رویدادهای درون بازی تحویل دهد.

در همان زمان، ما از قبل یک بخش هنری کاراکتر داشتیم. آن‌ها هشت کاراکتر در مراحل مختلف تکمیل و یک اسکین سطح بالا با تغییرات هندسی ایجاد کرده بودند. تولید آن اسکین منفرد 16 ماه برای هنرمند طول کشید.

وظیفه من ایجاد یک خط تولید کارآمد و برآورده کردن کامل نیازهای ناشر تا تاریخ انتشار بود: 21+ اسکین با هندسه جدید و 40+ تغییر رنگ. پس از آن، باید هر ماه 7+ اسکین از انواع مختلف منتشر می‌کردیم — و سال بعد، این اعداد را دو برابر می‌کردیم.

کار

ابتدا تجربه قبلی و سرعت تولید فعلی مش‌ها (کاراکترها و یک اسکین) را تحلیل کردم. با استفاده از داده‌های Jira و تن‌ها صفحات اکسل، چندین نقطه ضعف را شناسایی کردیم.

نقشه راه تولید هنری

هیچ نقشه راه ساختاریافته‌ای برای تولید هنر کاراکتر به طور کلی و لوازم آرایشی به طور خاص وجود نداشت. مش‌ها بخشی از خط تولید توسعه کاراکتر در نظر گرفته می‌شدند، و تمام کارهای مرتبط با آن‌ها در سه مرحله بزرگ قرار داشت — L0، L1، L2 — از نمونه اولیه تا نسخه نهایی صیقلی شده. هر یک از این وظایف بزرگ می‌توانست نه فقط دو چرخه بلکه گاهی سه یا حتی چهار چرخه از طول اسپرینت فراتر رود.

فقدان استاندارد

هر مش به عنوان یک ویژگی تحقیق و توسعه در نظر گرفته می‌شد. وقتی مراحل L0/L1/L2 را در موارد مختلف مقایسه کردیم، کشف کردیم که زمان‌های کاملاً متفاوتی طول کشیدند — هم زمان خالص (ساعات ثبت شده) و هم زمان کثیف (شکاف بین ایجاد تسک، انتقال آن به "در حال انجام" و علامت‌گذاری آن به عنوان "انجام شده"). حتی تعداد وظایف برای انواع یکسان مش‌ها به طور قابل توجهی متفاوت بود، و برخی از آن‌ها توضیحاتی داشتند که درک آن‌ها تقریباً غیرممکن بود.

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

فقدان شفافیت فرآیند

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

تعداد تکرارها

حتی از تاریخچه وضعیت اولیه واضح بود که وظیفه به بررسی می‌رفت، سپس دوباره برمی‌گشت، سپس دوباره به بررسی می‌رفت و سپس دوباره به کار برمی‌گشت. و این بدون در نظر گرفتن فقدان کامل نظراتی است که توضیح دهند چرا وظیفه به کار برگردانده شد و سپس دوباره ارسال شد — حتی یک کلمه نه.

ما با دایره کوچک ایلومیناتی خودمان جمع شدیم — خودم (به عنوان مدیر پروژه)، هنرمند اصلی، و سرپرست هنری — و شروع به کار کردیم.

راه حل

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

درجه‌بندی را معرفی کردیم

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

قانون "یک اسکین = یک اپیک = یک شاخه"

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

این نقطه شروع ما بود. از آنجا، کل گردش کار را بازسازی کردیم.

از L0-L1-L2 خلاص شدیم

در عوض، تولید را بر اساس منطق تولید واقعی تقسیم کردیم: طراحی ← هندسه ← بافت‌ها ← پیاده‌سازی.

هر مرحله به مراحل منطقی کوچک‌تر تقسیم شد، به عنوان مثال: \n مفهوم: مودبرد – طرح 2D – طرح 3D (در صورت نیاز) \n هندسه: وضوح پایین – وضوح بالا – وارد کردن فایل FBX \n پیاده‌سازی: Rig – راه‌اندازی GD – بررسی هنری – QA

خود اسکین نیز به سه بخش تقسیم شد: بدنه، سلاح و ماژول‌ها. به این معنی که از آن پس می‌توانستیم سه وظیفه جداگانه داشته باشیم، مانند: \n بدنه – هندسه وضوح پایین، \n سلاح – هندسه وضوح پایین، \n ماژول‌ها – هندسه وضوح پایین.

این کار آنچه را که قبلاً یک بلوک عظیم و واحد از کار بود به یک سازنده شبیه لگو تبدیل کرد که می‌توانست بسته به حجم کار بین هنرمندان توزیع شود. حالا امکان ردیابی دقیق این‌که تولید در حال حاضر در کدام مرحله است وجود داشت.

نقشه راه جدید تولید هنری

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

قالب‌بندی یکپارچه برای اپیک‌ها و وظایف

اپیک اکنون فقط شامل وظایف مرتبط دقیقاً با درجه اسکین بود — هیچ چیز اضافی نداشت.

هر اپیک شامل مفهوم اسکین در توضیحات خود و همچنین معیارهای پذیرش از تولیدکننده بود.

این امر سردرگمی را کاهش داد و به هنرمند درک واضحی از آنچه در هر مرحله انتظار می‌رود، داد. (بعداً توضیحات وظایف را بیشتر اصلاح کردیم، اما این مربوط به موضوع روتین روزانه است که بعد می‌آید.)

همچنین یک بخش جداگانه در Confluence با یک بورد Mira راه‌اندازی کردم که در آن تمام این توضیحات برای هر وظیفه فهرست شده بود، همراه با نظرات برای مدیر پروژه که توضیح می‌داد چه زمانی و چه وظیفه‌ای باید ایجاد شود، همراه با فرمول Jira که به سادگی می‌توانست کپی و در بدنه وظیفه جای‌گذاری شود.

برآوردها

سعی کردیم وظایف را طوری تقسیم کنیم که برنامه‌ریزی آن‌ها آسان باشد. پروژه از اسپرینت‌های دو هفته‌ای استفاده می‌کرد، بنابراین هدف ما یافتن یک ساختار مشترک بود: بدون تجاوز بیش از حد از مرزها در حالی که هر وظیفه یک نقطه تکمیل منطقی داشته باشد.

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

حالا هنرمند می‌توانست ببیند چقدر زمان برای هر وظیفه دارد و چقدر به اتمام آن نزدیک است. با ارتباطات مناسب، این به یک ابزار پشتیبانی تبدیل شد. اگر یک هنرمند می‌دید که سه روز برای یک وظیفه باقی مانده اما می‌فهمید که موفق نخواهد شد — می‌توانست به طور فعال به من بگوید.

این بدان معنا بود که من نیازی به "کنترل" توسعه‌دهنده نداشتم؛ آن‌ها همه ابزارها را برای کمک به من و بالا بردن پرچم قرمز در جایی که ممکن بود ضرب‌الاجل را از دست بدهیم، داشتند.

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

نتیجه

مستقیماً به نکته. فقط اعداد.

این مورد است.

\ \ \