Управление импровизацией

Разработка и запуск онлайн-игр без изначальных установок

Задача
Создать развлекательный программный продукт с возможностью последующего развития для социальной сети.

Решение
Применить процессно-ориентированную схему менеджмента, исключающую «вертикаль власти», и жесткие плановые показатели.

Илья Курылев, креативный директор Flexis Games, Москва

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

ДАВАЙТЕ ПОИГРАЕМ
Обычно разработчиков онлайн-игр приложений ищут так: мониторят социальные сети, выбирают интересные успешные проекты, а потом выходят на их авторов. В нашем случае все было по-другому. Мои знакомые, основатели компании-издателя «TVX Медиа», попросили подсказать, кто мог бы заниматься играми в социальных сетях. В то время я, не будучи сотрудником Flexis Games, давно предлагал им сделать игру, где вы¬ступил бы в роли гейм-дизайнера. Так получилось, что в основе проекта «Наемники» лежал не скрупулезный бизнес-расчет, а человеческий интерес — попробовать сделать хорошую игру с теми, кто никогда раньше играми не занимался. Стороны встретились, сверили интересы, обсудили возможности, оценили перспективы. Обсудили бюджет. Договоренности были такие: мы работаем за себестои¬мость, но имеем долю прибыли от проекта. Игру решили делать несложной, но с возможностью дальнейшего развития. И, что важно, понятной и красивой — чтобы в начале игры была ясна ее суть, чтобы она была привлекательна для аудитории. Дальнейшие доработки архитектуры игры и всей ее концепции должны только больше заинтересовывать, способствовать росту вовлеченности лояльных пользователей и привлечению новых. Для этого как нельзя лучше подходил жанр коллекционной карточной игры.

СОБИРАТЕЛИ БОЕВЫХ КОЛЛЕКЦИЙ
Коллекционные карточные игры возникли в 1993 г., когда математик Ричар Гарфилд (Richard Garfield), придумал «Маgiс: the Gathering» — очень сложное и глубокое развлечение. Представители жанра формально напоминают обычные карточные игры, но здесь, помимо правил, описанных в инструкции, каждая карта имеет свои особенности.

Для наших задач коллекционная карточная игра подходила оптимально. Компания-производитель может усложнять ее и подогревать интерес пользователей самыми простыми методами: например, вводя новые карты. Для социальных сетей коллек¬ционная игра подходит, потому что игрок сам составляет свою колоду, покупая стандартные наборы, приобретая отдельные карты и открывая по ходу игры доступ к новым комплектам. Также мы добавили в игру элемент социальности, позволив игрокам нанимать друзей в свою колоду и самому наниматься к друзьям — отсюда и название «Наемники». Такие друзья-наемники намного эффективнее обычных карт, но за наем друзьям нужно платить зарплату.
Мы стремились сохранить два важных качества коллекционных игр — глубину и сам процесс «собирательства»: игроку недоступно абсолютно все сразу, он может выбирать пути развития, исходя из собственных интересов. Фактически он строит для себя свою уникальную армию из разных компонентов — карт, собирая коллекцию. При этом любой человек, в том числе и сам игрок, представляется в виде карты со своими параметрами: уровнем, силой, здоровьем.

ВРЕМЯ И ДЕНЬГИ
Принимаясь за работу, мы руководствовались всего двумя требованиями заказчика — масштабируемость игры и жесткое соблюдение сроков по ее запуску (ровно три месяца). Последний пункт объяснялся привязкой к началу новогодних праздников. Конечно, изначально была и некая концепция, написанная вместе с заказчиком за несколько дней до запуска проекта. Однако времени на написание подробной документа¬ции не было, то есть не было четкого списка функционала, который нужно реализовать. Были примерные планы, работа началась оперативно, в процессе расставляли приоритеты, пересматривали концепцию игры, фактически все время уточняли требования.
Маркетинговые исследования мы не проводили. Это в игровой индустрин не очень принято: в большинстве случаев специалисты, занятые в ней, сами во все играют, а потому понимают и чувствуют рынок «естественным образом», изнутри. Также мы не занимались продвижением продукта, это взял на себя заказчик. Бюджет проекта включал только оплату труда участников команды. Оплата происходила по этапам: на каждый отводилось две недели, после чего он закрывался актом, его подписывали обе стороны, и на наш счет поступали деньги.

УПРАВЛЕНИЕ ПРОЕКТОМ
За основу управления проектом мы приняли гибкую методологию Scrum. Она позволяет концентрироваться на актуальных задачах и подстраиваться под постоянно меняющиеся требования заказчика. Нам понадобилось составить общий список требуемого функционала. Задачи по его разработке ранжировались по приоритетам, а весь срок работы над проектом разбивался на небольшие временные отрезки — ите¬рации. Они в нашем случае составляли две недели. В начале каждой итерации из общего списка задач согласно приоритетам совместно с заказчиком составлялся конкретный объем работ на ближайшие две недели.
Схема предусматривает пошаго¬вую разработку проектов, которая завершается, когда заказчик считает, что все готово. Это позволяет быстро получить рабочий прототип системы, после чего постепенно ее улучшать. Интересно, что заказчик может потратить столько времени и денег, сколько сам хочет: финансировать, скажем, две итерации или четыре. А может после третьей сказать: «ОК, меня все устраивает, я больше не буду ничего улучшать, и вам, соответственно, не плачу». Мы планировали три месяца потра¬тить на тестовую версию, выпустить ее и дорабатывать дальше на тех же условиях итеративно — с сохранением изначального состава рабочей команды. В нашем случае это было очень эффективно. У нас не было времени писать подробное техническое задание на весь проект, а заказчик не был готов его предоставить. Пришлось бы отвести на это две недели или даже месяц. А этого времени просто не было. Не получалось даже сделать небольшую временную «сдвижку», чтобы параллельно с текущей итерацией готовить описание задач, которыми программисты займутся на следующей. Да и вообще в играх очень многое становится понятно только в процессе работы, во время плей-тестов.

ПЯТИЛЕТКУ — В ДВЕ НЕДЕЛИ!
Схема, по которой мы работали, изначально учитывала риски недоработок. В основном они относились к функционалу. Поэтому все задачи мы ранжировали по приоритетности. При возникновении проблемы в ходе выполнения работы высокой степени важности мы продолжали ее решать до победного конца. При этом, конечно, вынужденно откладывали заранее запланированные, но менее приоритетные работы. И все заранее были с этим согласны.
Понятно, что именно от идеи и от решения частных вопросов зависит стоимость проекта. Но мы пошли по непривычному пути: решили фиксировать затраты, а не функционал. Нас ограничивали сроки. Суммарная стоимость проекта оставалась неизменной, хотя объем реализованного функционала мог варьироваться. Впрочем, такая неопределенность не порождала неясностей в отношениях с заказчиком. Ведь мы участвовали в прибыли с проекта, а значит, были не менее заинтересованы в его качественном выполнении.
Кроме стандартных затрат на каждую итерацию, в перечень расходов были заложены лимитированные бюджеты: например, на художников, которых не было у нас в штате. И заказчик понимал, что каждый час, все его деньги были потрачены с пользой — ровно на то, что он считает правильным в этот момент. Все ответы на креативные вопросы возникали по ходу действия.

ИГРАЯ, УЧИМСЯ
Конечно, практически любой заказчик всегда немного склонен к перфекционизму. И в начале работы он часто оказывается излишним. Особенно это касается визуальной части — того, что делают художники. За первые две итерации, за месяц, не было принято практически ничего из множества предложенных художниками вариантов. Бесконечные правки и переделки нервировали иллюстраторов. Мы понимали, что не укладываемся в сроки.
Ведь графика — это не функционал, ее не выкинешь «просто так» и не оставишь «на потом»: для запуска игры нужен определенный ее объем.
В итоге, конечно, мы сумели подстроиться друг к другу: заказчик перестал придираться, а художники научились делать то, что нравится нам и заказчику. Свою ошибку мы поняли не сразу: к решению специфических задач, в частности к разработке игровых интерфейсов, мы пытались подключить людей, которые раньше играми не зани¬мались. В компании Flexis были «интерфейс-ники», но не было опыта дизайна игровых интерфейсов. Приглашенный гейм-дизайнер как идеолог мог убрать некоторые не¬понятности, объясняя обычному дизайнеру, как работать с игрушками. Но уровень исполнителей, их владение графикой не позволяли на должном уровне выполнить задачу.
Выводы мы сделали. Например, поняли, что для разработки интерфейса требуемого качества нужен не дизайнер по интерфейсу, а художник по интерфейсу. И мы взяли настоящего художника.

ВЗАИМОДЕЙСТВИЕ СТОРОН
Большинство сотрудников, занятых в проекте, работали удаленно (таблица). Основным средством коммуникации был Skype: один митинг со всей командой для синхронизации в день, в 12 часов. Участники проекта встречались в онлайне, обсуждая, что делали вчера, какие были проблемы и что будут делать сегодня. Занимало это около пяти минут – зато все в курсе общих проблем, процесса в целом: например, все вовремя узнают, что программисты уже подбираются к тем задачам, где что-то потребуется от художников. В течение дня общение продолжается в общем чате Skype. Выбранная схема взаимодействия позволила избежать серьезных цейтнотов. Она оказалась оптимальной для проекта, в котором множество частностей были изначально неизвестными. Вопросы «куда ты положил такие-то картинки?» или «что произойдет при нажатии вот этой кнопочки?» в условиях чрезмерной заорганизованности могут усложнить работу. В нашей ситуации – при сжатых сроках и множестве неопределенностей – умение задавать простые вопросы оказалось полезнее, чем тонны заранее заготовленной формальной документации. Взаимодействие с клиентом также упрощалось: его представитель всегда был в курсе происходящего, поскольку читал общий чат, участвовал в еже¬дневных собраниях.

НА СТАРТЕ
В сроки мы уложились. А самым значительным, неожиданным затруднением оказалось, как ни странно, общение с социальной сетью: прежде чем запустить приложение, они должны были убедиться, что оно соответствует их требованиям, в том числе по безопасности. Из-за этой задержки открытие проекта для основной массы игроков произошло не 24, а 30 декабря.
Запуску приложения предшествовал этап тестирования. Игра была открыта для ограниченного круга пользователей в сокращенном функционале — например, они не могли платить за дополнительные опции. Для тестирования мы использовали так называемые «тестовые забеги»: объявили о запуске тестового варианта, предупредив пользователей, что все результаты впоследствии будут обнулены.
Мы наблюдали за действиями людей на первых уровнях игры (это самый важный этап), делали выводы, совпадает ли это с нашими ожиданиями, правильно ли работают механизмы монетизации. При этом игра должна оставаться игрой: пользователи даже могут не знать, что они выступают тестерами. Правда, нескольких игроков мы все ты. просили активнее использовать те или иные новые возможности.

ИГРАЮТ ВСЕ!
Успех проекта стал очевиден сразу. После запуска начался динамичный естественный рост приложения (фактически это показатель качества — игроки приглашают своих друзей). Позже он перестал быть заметен на фоне роста, генерируемого рекламной кампанией.
С первых дней начались платежи. Некоторые пользователи начинали игру сразу с платежей, в первый же день: с хорошими картами и начинать интереснее. Через два месяца после запуска к «Наемникам» присоединились более 200 тысяч игроков. В самый пик посещаемости было до 70 тысяч игроков в день, некоторые из них ежедневно платили до 7000 рублей. Сейчас в игре «Наемники» в сети «ВКонтаке» участвуют около 500 тысяч человек. Ядро аудитории составляют молодые люди 18-24 лет из Москвы и Санкт-Петербурга. Однако характеристики играющих гораздо шире: это представители всех возрастов, обоих полов, из разных городов.
Мы считаем, что сумели доказать: слаженная команда может быстро сделать качественный продукт и без менеджера, без планов и диаграмм Ганта. Что с заказчиком можно дружить и разрешать ему вникать во все, во что он хочет вникнуть. А самые лучшие тестеры — конечно, сами пользователи, которые даже могут не знать, что за ними при¬стально наблюдают.

Команда проекта
Функции и роли