Які проблеми виникають в роботі геймпродюсера і як їх долати: досвід спеціаліста

Доброго дня! Мене звуть Юрій, я Executive Producer у Pingle Studio (а також частково Lead Game Designer). В індустрії я вже близько 10 років, починав і працював здебільшого як геймдизайнер. За цей час я брав участь у багатьох проєктах і співпрацював з різними продюсерами. Саме це дало базу для роботи на цій посаді.

Я не буду описувати, хто такий ігровий продюсер, які навички йому потрібні або як їм стати — про це вже є багато матеріалів. В цій статті я хочу висвітлити, з якими проблемами стикається цей фахівець і як їх розв’язує на конкретних прикладах.

І одразу випливає «нульова» проблема, яка стосується не тільки продюсера — NDA. Це важливий інструмент для захисту інтересів партнерів та компанії, але він же призводить до «ми працювали над проєктом [NDA] для компанії [NDA] і там [NDA] з [NDA] і ми [NDA] щоб вирішити це». Це може завадити при спілкуванні з потенційними партнерами й кандидатами, хоча більшість ставиться до таких обмежень з розумінням. Сподіваюсь, ви також пробачите мені більшість прикладів без подробиць та назв.

Отже, завершую зі вступом і переходжу до прикладів. Для цієї статті я виділив чотири основних задачі продюсера і розповів, чому вони важливі. А ще розібрав, з якими труднощами можна стикнутись і як ми з командою їх вирішували.

1 Контроль

Одна з найважливіших задач ігрового продюсера — це контроль процесу розробки, досягнення цілей проєкту, його відповідність початковому дизайну та стандартам якості, а також злагоджена робота всіх напрямів розробки.

Ви можете сказати «Стоп! Для цього ж є проджект-менеджери та ліди напрямків — нащо тут ще й продюсер?!». І у багатьох випадках будете мати рацію — команда професіональних лідів та PMів можуть самостійно вести проєкт, без нагляду окремого внутрішнього продюсера.

Але бувають ситуації, коли навіть такі професіонали можуть втратити загальну картину, занадто зануритися у власні процеси та не помітити вчасно, що проєкт застряг чи пішов не туди. Варто пам’ятати й про замилювання очей, через яке перестаєш помічати деякі речі, та про виснаження, коли хочеться просто здати все чимскоріше.

Один наш консольний проєкт затягнувся через війну, команда була вже достатньо виснажена. І в ньому за кілька днів до відправки на сертифікацію знайшли баг. У трофеїв на PlayStation 5 не було перекладів назв та описів, що неприємно, але не критично для сертифікації.

Але під час перегляду скриншотів я помітив дещо інше: у трофеїв не було іконок. А це вже обов’язковий пункт сертифікації, без якого Sony не пропустить вашу гру. Навіть QA замовника та дві команди зовнішнього QA цього не помітили. А сталося це через те, що через виснаження та стрес команди трохи відпустили процеси таск- та баг-трекінгу. Тож QA-спеціалісти не завели баг місяць тому, бо хтось сказав «не на часі» і «потім виправимо».

Для виходу з цієї ситуації ми оперативно знайшли та імплементували необхідні іконки та переклади, після чого під’єднали лідів напрямків та провели бесіду з командою. Проговорили про важливість дотримання процесів та належного ведення таск-трекінгу, домовились про виділення додаткових QA-спеціалістів для допомоги та повної перевірки білдів. Після чого привели задачу та баг-трекінг до ладу.

На іншому внутрішньому навчальному проєкті, довгий час всі працювали над своїми задачами та не намагалися поєднати в одну гру. З боку лідів все було добре, бо кожна механіка добре працювала в окремому середовищі; PMи були задоволені, таски виконувались, час трекався і весь проєкт наче рухався. Після кількох місяців розробки я наполіг, щоб все зібрали в купу та показали білд. Виявилось, що більшість механік несумісні та в проєкті існують архітектурні помилки, які також не дозволяють все втілити як слід.

Як результат, ми призупинили роботу над новою функціональністю, виділили час лідів на розробку архітектури проєкту й адаптували готові механіки. Частину механік довелось переробляти з нуля, а кілька взагалі відкинути. Але десь через місяць в нас вже був робочий білд і налагоджений процес розробки.

2 Делегування

З попереднього пункту може здатися, що послідовним висновком буде замкнути весь проєкт на собі та контролювати кожен процес, а то й кожного співробітника. І тут ми підходимо до наступної задачі — делегування. Наскільки б професіональним та досвідченим продюсером ви б не були, ви не зможете бути всюди й контролювати все — або десь можете недогледіти чи застопорити процесс, або такий режим зламає вас.

На проєкті Life is Strange mobile я був лід-геймдизайнером, але після змін в компанії мені довелось взяти на себе й обовязки продюсера. Спочатку це дозволило виправити процеси, налагодити комунікації з клієнтом та більш оперативно реагувати на проблеми. Але з часом я зрозумів, що через нові обов’язки з’являється дедалі більше овертаймів, наростає фізичне та емоціональне виснаження. А ще страждає напрям геймдизайну, якому вдавалося приділяти менше і менше уваги.

Тому я обговорив ситуацію з CEO та власниками компанії, і ми вирішили знайти та під’єднати додаткового продюсера. Спочатку це додало роботи — через його введення у проєкт, додаткові комунікації з клієнтом, щоб познайомити та заспокоїти його. Але з часом це дало величезне прискорення проєкту в цілому.

Іншим прикладом може бути згаданий раніше внутрішній прототип: коли з’явилася ідея запуску такої ініціативи всередині компанії, було бажання взяти свою ідею та самостійно вести проєкт. Але розсудливо оцінивши навантаження, я вирішив поставити на проєкт джун-геймдизайнера, а з боку розробки поставили лідом тільки найнятого девелопера. Це, звісно, привело до деяких збоїв, необхідності ручного керування та великої кількості ітерацій та фідбеків. Але згодом все вдалось налагодити, а колишній джун теперь вже навчає нових геймдизайнерів на цьому проєкті.

3 Планування

Це ще одна задача, яка має величезне значення і дозволяє полегшити дві попередні. Планування починається ще до початку проєкту, на етапі перемовин, і закінчується тільки із закриттям проєкту. Ви повинні дуже добре розуміти всі етапи та процеси розробки, знати свою команду та її можливості, а також враховувати потреби замовника (будь то зовнішній партнер, чи стейкхолдери компанії).

Також треба не забувати про ризики та можливі форс-мажори, а протягом проєкту бути готовим корегувати плани та/або команду розробки.

Як приклад, можу згадати, коли одного разу ми домовились зробити дві гіперкежуал-гри на Unity. Ігри були дуже маленькі (як і бюджет), а вся робота, пов’язана з артом, була на боці замовника. Тож проєкт був на два місяці з мінімальною командою. І ми встигли в зазначені терміни, але замовник вирішив, що йому не подобається візуальний стиль проєкту і захотів повністю переробити весь арт, а заодно внести зміни й у геймплей.

Нам довелось довго пояснювати, що це виходить за рамки погоджених задач. Врешті-решт ми змогли домовитись на additional scope (розширення контракту). Але зіткнулись з новою проблемою — головний девелопер вже перейшов на інший проєкт, а новий розробник не встигав розібратись та одночасно внести необхідні зміни в стиснуті терміни. Для розв’язання цієї ситуації ми оперативно під’єднали ліда напрямку, який в короткі терміни зміг виправити ситуацію. Проєкт здали вчасно. Але ми зрозуміли, що як компанія не дуже хочемо працювати з гіперказуальними іграми.

Іншим прикладом, звісно, є війна, яка фактично зупинила життя кожного українця на деякий час. Такий форс-мажор неможливо врахувати, хоча компанія й ухвалила ряд дій на випадок погіршення ситуації ще наприкінці минулого року.

Все одно перші кілька тижнів всі працювала на те, щоб врятувати життя та допомогти співробітникам, їхнім родичам, знайомим та навіть просто людям у скрутній ситуації. І звісно, все це не могло не вплинути на проєкти — фактично всі вони були більш-менш заморожені майже на місяць.

І хоч наші партнери із розумінням поставилися до цієї ситуації, за що ми їм дуже вдячні, — все одно саме нам потрібно було надолужувати час. Для цього ми разом з відділами PM та HR зібрали інформацію по стану співробітників, чи є все для роботи, чи готові команди почати працювати (в тому числі психологічно).

З іншого боку IT-відділ оперативно розвернув необхідну інфраструктуру та відправив необхідне обладнання кожному співробітнику для віддаленої роботи. Разом з PMами та лідами проєктів перерозподілили ресурси, на найбільш критичних проєктах підсилили команди лідами, та скорегували плани для скорочення відставання. У результаті зараз ми не тільки подолали відставання майже на всіх проєктах, а й залучили нові та збільшили команду.

4 Комунікації

І остання задача, яку ми розглянемо сьогодні, це комунікації: як всередині команди, так і назовні. Гарні комунікації можуть полегшити вам життя та перекрити всі попередні пункти, а погані — зруйнувати проєкт. Причому важливо стежити не тільки за тим, як спілкуєшся ти сам, а й за загальною комунікацією на проєкті, її каналами та правильним фіксуванням важливих рішень та домовленостей.

Наприклад, на тому самому Life is Strange, була велика кількість додаткових ланок замість прямої комунікації. Тож на етапі Proof of Concept виявилось, що бачення прототипу з нашого боку та зі сторони замовника кардинально розходились: ми узгоджували, що для демонстрації нового керування ми вручну відтворимо локацію оригінальної гри в Unreal Engine 4, щоб не блокувати розробку інструментарію для переносу контенту з Unreal Engine 3. Але в замовника було бачення, що ця локація вже повинна бути перенесена з оригінального проєкту за допомогою того самого інструментарію.

Оскільки проміжні ланки не передали інформацію коректно і не зафіксували рішення, ми були змушені виконувати додаткову роботу раніше, ніж планували. Після цього ми підняли питання про необхідність прямих комунікацій, а згодом позбулися й зайвих посередників. Завдяки цьому команди порозумілися краще, а розробка пришвидшилась.

На іншому проєкті ми повинні були запропонувати адаптацію інтерфейсу на мобільні пристрої для ПК-гри. Але спеціалісти зі сторони замовника не мали вільного часу на комунікацію, і тому ми робили це наосліп. Через це вибрали обережний підхід, намагаючись максимально зберегти UX-рішення оригіналу. Але виявилось, що вони очікували якраз протилежного — максимальних змін, щоб гра відчувалась, ніби її відразу створювали для мобільних платформ.

Ми домовились про регулярні міти з їх UI/UX-спеціалістами та створення Slack-каналу виключно під ці питання. А я ввімкнувся в активну комунікацію з нашим UI/UX-дизайнером, щоб сфокусуватись на максимальній креативності та спробувати більше різноманітних варіантів в короткі терміни. Як результат, через тиждень ми показали рішення, що не просто задовольнило замовника, а й викликало захоплення й вдячність за зроблену роботу.

Стаття вийшла значно більшою, ніж я очікував, але все одно не покриває всі задачі та проблеми, з якими зіштовхуються ігрові продюсери. Сподіваюсь, вона була цікавою та корисною для вас — якщо так, то можете залишити коментар, наприклад з темою для наступної статті.

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини