«Система хорошая, фичей на-гора выдаёт много, но это конвейер»

Владимир, куда делся ваш предшественник и что значит для компании смена главы разработки главного продукта?

Предыдущий директор, Милош ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­Йержабек,­ ушёл по причинам личного характера. У команды были с ним теплейшие отношения, и все были расстроены таким его решением. 

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

Сколько человек у вас в подчинении? 

Всего 550 человек, из них около 400 — в Минске, 100 — в Киеве и 50 — в Чехии.

Как взаимодействуют отделы и как принимаются решения в такой большой команде?

В своё время мы создали «танковое» производство, которое действовало по принципу конвейера. Допустим, creative отдел «родил» идею, её отдали в дизайн, потом инженеры разбили её на задачи, их запустили в производство, а в конце собрали всё воедино и проверили, получилось ли то, чего хотели.

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

Чтобы сохранить гибкость и увеличить скорость разработки, три года назад мы начали менять старую, инерционную модель. Сейчас мы строим модель, в которой каждый участник разработки является creative сам по себе.

Каждый из 550-и?

Совершенно верно, каждый. В рамках своих возможностей — того, что он может привнести в фичу.

Я как директор разработки осознанно делегирую часть своих полномочий линейному руководителю. Я не снимаю с себя ответственности, но разрешаю человеку вносить изменения в то, что он делает, от моего имени.

То есть разработчик может вносить изменения в бизнес-часть?

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

«Больше не надо заставлять людей работать — они сами хотят»

Это общая проблема больших компаний: люди внизу не понимают, что они делают.

Да. Когда я был руководителем инженерной группы, то спрашивал себя: почему инженеры, работая над функциональностью, воспринимают бизнес-фичу как нечто инородное? В то же время работа над фичами технического характера доставляет им колоссальное удовольствие. И там, и там пишется код, и там, и там принимаются архитектурные решения. Только одно задание он хочет выполнять, а другое — нет.

У меня ответ такой: техническую фичу он хочет делать, потому что понимает замысел и предвидит результат. Почему ему не интересно выполнять бизнес-задание? Наверное, потому, что он его не понимает, и от этого ему некомфортно.

Попробовали поменять отношения в паре команд. Рассказали людям, зачем это нужно, начали спрашивать их мнение. И стали происходить удивительные вещи. Люди, вовлекаясь в задачу на начальном этапе, дальше начинают делать всё сами. Больше не надо заставлять их работать внеурочно — они сами уже завтра хотят всё сдать.

Остаётся просто корректировать движение, убеждаясь, что работа идёт в правильном направлении и укладывается в нужные сроки.

Новая модель повлияла только на мотивацию людей?

Не только. Раньше инженеры, которые делают внутренние инструменты для разработчиков игры, стояли в стороне от процесса производства. Они изготавливают какой-то инструмент, и разработка какое-то время им пользуется, потом приходит пакет изменений, и разработка пользуется уже новым набором. Это в какой-то мере ограничивало свободу художников, им могло не хватить нужного инструмента для реализации замысла.

Сейчас мы продолжаем развивать «двигло» как таковое, сам продукт, тестирование и прочий инструментарий, но при этом мы не ограничиваем художников и людей, работающих с контентом.

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

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

Как предложения «снизу» вносятся на практике? Опишите этот механизм.

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

Бывает, что идея, на которую здравый смысл подсказывает потратить не более 6 месяцев, в реальности требует 3-4 лет. Потому что её для реализации надо что-то переписать в движке, или появляется много неизвестных с точки зрения геймдизайна. Например, есть такая фантазия, чтобы дом можно было прострелить насквозь или вообще развалить его в труху. Но дырка в доме повлияет на геймплэй. Понятно, что в эту дырку все ломанутся, и какие будут последствия? Баланс карты поломается.

Как вы справляетесь со всеми фантазиями? Ведь, если идей тысячи, работа может стать колом.

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

Я работал на разных позициях в компании, и мне проще доносить до людей, что имеет смысл, а что — нет.

«Фича может быть выгодной, но разрушительной для проекта»

Ошибки на миллионы случаются?

Это вопрос, на который нет ответа. Что значит «ошибки на миллионы»?

Вы что-то выпустили, потратили ресурсы, время, а фича не сработала. Игроки ушли, и компания потеряла деньги.

Ок. А это точно из-за этой фичи? Гипотетически вся наша деятельность направлена на извлечение прибыли. Мы делаем большое количестве тестов, но всё же не застрахованы от ошибки, и тут важно иметь возможность исправить ситуацию. Например, вывели новинку в релиз, увидели, что это не то, и приняли решение её остановить.

Да, финансовые показатели отдельно взятой фичи — это важный критерий, но ещё важнее то, как новая функциональность повлияет на принятие аудиторией продукта в целом.

Сама по себе фича может быть очень выгодной, но она будет разрушительной для проекта. Можно заставить людей один раз заплатить, а потом они уйдут.

Как «пощупать» результаты нового, «демократического», подхода к работе? На примере карты Минска можно показать эти изменения?

Карта Минска отчасти иллюстрирует изменения в нашей работе, отчасти — нет.

Не иллюстрирует, потому что с точки зрения командного взаимодействия она несложная.

Самый наглядный пример — обновление World of Tanks 1.0. Если бы не было изменений в работе, то не было бы этого релиза. Объём проделанной работы сравним с релизом танков вообще, мы фактически переделали игру. Причём сделали это, имея серьёзные ограничения: нельзя было изменять базовые механики, впечатление о танках должно было остаться, а игра – поменяться. Если бы команда осознанно не приняла эту задачу и не захотела её выполнить, то ничего бы не было.

А карту Минска мы хотели создать давно. И арт-директор делегировал право команде делать так, как она считает нужным. Раньше бы разработчикам дали чертёж, эскизы, фото: «Ребята, делайте вот так. Вам нужно 150 домов, 85 типов травы. — Есть, господин директор». И пошли фигарить! Потом собрали всё на карту — и порядок.

Сейчас подход такой: «Мы хотим сделать карту Минска. Что вы на ней хотите «рассказать»?»  Разработчики, понимая, как карта будет интегрирована в продукт, сами выбирают контент. Всё-таки эта карта про Минск, её делает минская команда, хочется, чтобы о городе осталась хорошая память. 

Не жалко вам пускать танки по улицам родного города?

Это же история. Вы будете ехать по Минску, будете видеть этот город. Но вы ничего не сможете разрушить, максимум — разобьёте цветочные горшки. Да, были концепции карт, которые в процессе игры можно было бы «раскатать». Технически возможно всё. Но нужно ли это? Мы в этом вопросе пока замерли.

Так что мы не изготавливали мишень в виде близкого сердцу города, мы никого не хотели обидеть. Это всего лишь декорация сражений.

«Кучу всего перепробовали — вспомнили про Targetprocess»

Мы слышали, Wargaming недавно перешёл на Targetprocess. Почему отказались от Jira?

Мы от Jira не отказались. Jira была и остаётся, она используется как инструмент контроля за производством. Все задачи выполняются в Jira, плюс это один из инструментов, который позволяет нам отслеживать историю развития продукта и историю принятия решений.

Но примерно год назад мы интегрировали в свою работу Targetprocess. Его мы используем как индикатор высокоуровневого состояния проекта. В этой системе у нас зарегистрированы все заявки и фичи, над которыми мы работаем и планируем работать. Там нет детализации – только топики, общее описание фичи и фамилии людей, которые будут заниматься этой работой. Постепенно задача обрастает подробностями, и тогда появляется детализация в Jira.

Почему нельзя было все задачи решить в Jira?

К сожалению, Jira не настолько гибкая. Только в танковой команде работает полтысячи человек, каждый день люди вносят в проект какие-то изменения, и всё это задокументировано в Jira. Если систему нагружать дополнительной функциональностью, она тормозит.

То, что Targetprocess находится в Минске, повлияло на выбор?

Нет. Мы кучу всего перепробовали — Confluence, Microsoft Project – и вспомнили про Targetprocess. В «бородатые» годы Wargaming уже работал с этой системой. Сначала я подумал: да ну, ерунда какая-то, мы же оттуда ушли, а потом увидел, что это уже другой продукт, который хорошо, гибко кастомизируется.

Так мы установили Targetprocess и попытались планировать. Первый подход провалился. Мы не смогли использовать систему для планирования на ежедневной основе. Когда трёхлетний план мы попытались расписать с точностью до дня, решить конфликты ресурсов, то получилось, что  строим систему, по сложности и инструментарию сравнимую с Microsoft Project.

Мы этого хотим? Нет. Мы хотим планы на три года понимать на высоком уровне. В итоге Targetprocess мы используем как индикатор состояния проекта на сегодня и в обозримом будущем, до 2020 года. А свои предложения разработчики, используя дашборд в Тargetprocess, могут генерировать в любой программе, вплоть до Exel.

Таким образом, Jira – это про сегодня и вчера проекта, Targetprocess — это про сегодня и завтра.

«Мне нравится, что разработчик и издатель — в одной компании»

Каково руководить разработкой продукта, когда издатель находится в той же компании?

И сложно, и просто. Допустим, я занимаюсь аутсорсом, и издатель — на стороне. Он заказал, я отгрузил, он опубликовал. Либо я – автор идеи, отгрузил продукт и дальше его не контролирую. С одной стороны, это удобно, с другой – так себе. Я не управляю результатом своего труда, не влияю на то, как он будет позиционироваться на рынке.

Если разработчик и издатель в одной команде, я понимаю, как система работает и могу на неё повлиять. Больше гибкости, но и ответственности тоже больше. Мне нравится так, как сейчас.

А был другой опыт?

Да, когда Wargaming разрабатывал Order of War, и издателем была компания Square Enix. Та модель была менее гибкой. Допустим, передали продукт, прошёл «жирный» процесс тестирования, подготовили маркетинговые материалы, выпустили диски. И тут разработчики спохватываются: ой, мы такую штуку нашли! А всё, уже ничего не поделаешь. Чтобы внести исправление, надо «распечатать» новые диски. Конечно, когда появился интернет, работать стало проще, но всё равно, это другой механизм разработки.

«Заметил, что сын бросил играть, и напрягся…»

Вы сами играете в «танки»? Сколько часов в неделю тратите на игру?

В последние месяцы играю меньше. А так, к сожалению, уходит до 15-20 часов в неделю.

В нерабочее время?

Конечно.

Как жена к этому относится?

С пониманием.

А ваши дети играют?

Дочке — 10 лет, она не играет, сыну — 19, и он играет с малолетства. Можно сказать, что я сыном пользуюсь в «корыстных целях». Одно время он играл, потом заскучал и перестал. Я напрягся: что такое? Сын высказал свои замечания к игре. С прошлого года, смотрю, опять стал поигрывать. Недавно снова бросил, я снова напрягся: что опять не так? А сын сейчас — студент. Говорит: папа, если я начну играть, то «подсяду» и не смогу к сессии готовиться. 

Какой у вас сознательный сын. А как сами относитесь к игровой зависимости? Не стыдно, что подсаживаете людей? Бывает, от этого и семьи распадаются.

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

На днях подвозил батюшку, разговорились. Он спрашивает: «А чем вы занимаетесь»? Я отвечаю: «Вот, танками». — «А что это такое?» — «Игра компьютерная». — «А, понятно. Я в игры не играю… А вы только ради денег это делаете?». Я объясняю, что не только, что хочу, чтобы люди удовольствие получали, плюс компания занимается благотворительностью, вокруг проекта много добрых дел. Батюшка на это говорит: «Вот! Вот это правильно».

 

Фото: Андрей Давыдчик