Что будет, если команду разработчиков не попросить вовремя умерить аппетиты? А если не взять на работу программиста из Google? Об этом SoftPower рассказал бывший IT-директор компании Elephant Games, а ныне программист ZeptoLab Дмитрий Гаязов.

Справка. Elephant Games — российский разработчик компьютерных игр. С 2003 года компания выпустила больше ста казуальных приключенческих и F2P-игр. Самый известный проект студии — Midnight Castle. Дмитрий Гаязов работал в Elephant Games с 2006-го по 2018-й годы. Сейчас в штате Elephant Games около двухсот человек, главный офис расположен в Йошкар-Оле, филиалы есть в Казани, Пензе, Самаре и Чебоксарах.

Провал при запуске проекта

Семь лет назад у нас возникла проблема с самым успешным проектом компании, Midnight Castle. Уже после запуска мы решили добавить в игру соревновательный элемент. До этого у нас не было такого опыта. Поэтому первую версию продукта мы сделали буквально «на коленке». Внутри игры появились турниры, в которых пользователи могли одновременно проходить задания и постоянно между собой конкурировать. Основным мотиватором было положение участников в турнирной таблице.

Поскольку мы были глупыми и неопытными, то решили каждый раз выдавать игрокам самые актуальные данные об их положении рейтинге. Гейм-дизайнеры решили, что раз таблицы лучше всего мотивируют пользователей, вся информация должна выдаваться мгновенно. Разработчики восприняли задание слишком буквально. В итоге мы добавили такую функцию без предварительного нагрузочного тестирования. И это стало серьезной ошибкой.

После выпуска обновления в игру пришло неожиданно много пользователей, жадных до новых функций. Они обновляли турнирную таблицу каждые несколько секунд без каких-либо ограничений. Разумеется, всё быстро «упало». Пришлось в экстренном режиме решать проблему. В течение месяца мы добавили кэширование данных на сервер, чтобы игроки могли получать доступ к турнирной таблице не чаще, чем раз в минуту.

На пользовательский опыт это почти не повлияло, а я вынес для себя важный урок. Как IT-директору мне нужно было попросить команду умерить аппетиты. Разумеется, требования бизнес-юнита компании необходимо выполнять. И с руководством спорить не надо. Необходимо просто провести нагрузочное тестирование по определенной методике и посмотреть, устроит ли нас результат. Если нет, нужно менять либо требования, либо методику тестирования, либо отказаться от фичи. Всегда лучше выбрать вариант, при котором проект будет отлично работать на 80–90 % от изначальных задач, чем на 100 %, но нестабильно.

Переоценка собственных сил

Однажды мы делали игру, в которой нужно было строить город. Её «фишка» была в том, что она состояла из маленьких кубиков, была красивой и очень динамичной, почти как Minecraft. Это казалось нам простой задачей. Но из-за качества графики и требований к арт-стилю мы столкнулись с техническими ограничениями. Оказалось, что реализовать нужную нам картинку просто невозможно. Для этой игры уже было нарисовано много графики, но она тормозила даже на самых мощных устройствах.

Когда я понял, что проект не получится осуществить с технической точки зрения, то отправился убеждать руководство закрыть его. Но меня не поняли. Пришлось в тестовом режиме масштабировать игру до реальных размеров и демонстрировать проблему, а также признать, что у меня нет решения.

В этом случае загвоздка была в том, что мы начали рисовать контент до того, как были сняты основные технические риски. Нужно было заранее проверить производительность игры с тестовой графикой в реальных масштабах. Когда стало ясно, что мы не можем своими силами реализовать проект технически, художники уже сгенерировали тонны графики и потратили несколько месяцев работы и, соответственно, денег. Поэтому технические риски директор должен снимать как можно раньше и при необходимости тормозить создание контента как можно дольше.

Чтобы этого не повторилось в будущем, нужно заранее ставить себе отсечки. Например, через месяц у нас должен быть работающий прототип. Ещё через месяц у него должны быть определенные функции. И так до тех пор, пока не будут сняты все риски. То есть главный принцип IT-директора: «Fail fast». Умей признать, что облажался, когда на проект потрачен один миллион, а не десять.

Если IT-директор начнет выкручиваться и затягивать ситуацию, будет только хуже. Ещё страшнее, когда он попытается спихнуть на подчиненных собственную неправильную оценку рисков. Это уже не ошибка, а самое настоящее вредительство.

Кадровые ошибки

С последней задачей человек справился, дисциплина была железная. Но толку от неё не было. Всё это превратилось в какой-то карго-культ: тупое следование ритуалам и полное отсутствие понимания. Отдел тестирования начал быстро деградировать: игры менялись, а тестировщики остались далеко позади.

После этой ситуации я сделал вывод: специалист всегда должен одновременно и дисциплинировать отдел, и двигать его вперед. Если у сотрудника нет таких компетенций, эти функции должны выполнять два разных человека. Дисциплина без ума не будет работать, а ум без дисциплины — да. Поэтому всегда нужно отдавать предпочтение тем, у кого есть мозги.

При этом я считаю ошибкой брать на работу гения, просто чтобы коллекционировать «зоопарк»: «Вот у меня чувак из Apple, вот из Яндекса, а этот из Mail.Ru Group». Были случаи, когда к нам хотели устроиться программисты, работавшие в Google. Но я сразу говорил, что в Elephant Games им будет скучно, потому что эти высококвалифицированные специалисты на самом деле хотят работать над проектами совершенного другого масштаба. Кроме того, другие сотрудники на их фоне будут чувствовать себя подавленными.