«Зачем мне нанимать программиста, который хочет стать менеджером?»
Директор по развитию Wargaming Сергей Бережной написал для рубрики «Рынок игр» колонку о своем опыте управления проектами и изменения поведения коллег, а также о культуре разработки в компании.
Обо мне
О себе рассказывать непросто, но я попробую. Если брать сферу управления проектами, то я занимаюсь этим с 2004 года. Сначала я работал в стартапе - правда, тогда таких слов не употребляли, и тем не менее это был стартап. Мы провалили два проекта из трех, а потом я устал от этого ритма и ушел в Global Logic. Потом был Luxoft, тренинги и консалтинг, а последние три года я работаю в Wargaming.
Wargaming подходит мне тем, что я по своей натуре трендсеттер. Мне нравится приходить, что-то менять, настраивать. А вот довести до «операционного идеализма» - это сильная сторона других коллег. Поэтому я рад, что в одной компании мне удалось сделать несколько новых интересных для себя вещей.
Начали настраивать процесс разработки, и я одним из первых принес Agile в его Scrum-понимании - до этого в него никто не верил, все считали, что это хаос. Потом мы стали делать программы, потом продуктовое управление - и все это приносило свои плоды.
Моя должность называется Development Director. В Wargaming я управляю разработкой веб-сервисов, которые помогают игрокам узнать больше об игре, приобрести сувенирную продукцию, пообщаться между собой. Я управляю разработкой части фронтенда Wargaming. Вот пример сервиса - магазин внутриигрового имущества Wargaming. 20 продуктов, которыми я руковожу, находятся на разных этапах жизненного цикла.
Одна из задач, которые меня сейчас мотивируют, - построить процесс продуктового управления, и это, наверное, мой самый большой прорыв за последнее время. Я вижу эту цель в двух конкретных практических вещах:
- комфортная среда для работы менеджеров и инженеров;
- грамотное продуктовое управление внутри компании.
О Wargaming
Wargaming сильно отличается от того, что я видел в других аутсорсинговых и продуктовых командах. Компания развивается с огромной скоростью.
Я застал два периода. Сначала бурный рост и развитие: много денег, много проектов. Стоит поднять голову на 15 минут и сказать, что ты свободен, - тебе всучат 200 проектов (а если не поднимешь, то всего 100). А потом период стабильности и оптимизации. Оба эти периода сопряжены с переменами, изменением процессов и внедрением новых подходов.
Процессы разработки в Wargaming существенно отличаются от «классических» несколькими моментами. Во-первых, это причастность всех участников к результату. Инженеры не просто участвуют в процессе - они реально могут на него влиять. Да, что нам делать, решает менеджер, но инженеры спорят, отстаивают свою точку зрения о том, как это делать. Поэтому есть ощущение, что делаешь собственный проект, для себя - а не для галочки и на словах.
Во-вторых, нереальное признание. Наши проекты очень публичные, здесь я могу поделиться показателями. Мы выпустили новый сайт - на него зашло 4 миллиона посетителей. Первый комментарий на форуме появился через 17 секунд. Когда нашу статью прочитало всего 200 тысяч человек - мы думаем, что мы сделали не так. Огромное ощущение того, что делаешь что-то очень нужное людям.
Для сравнения: население Никосии, где я сейчас живу, - 200 тысяч человек, то есть одним изменением ты затрагиваешь аудиторию нескольких городов. Этот подход к работе хорошо описывает слово exposure: ты что-то создал, и это захватывает мир и умы миллионов людей.
В-третьих, игровая индустрия - нереальный фан. Это очень весело и интересно: это же все-таки игры. Киберспортсмены, соревнования, танки - во всем этом есть атрибутика профессионального спорта, не в той же степени, что у больших соревнований, но ощущение похожее. Инженеры чувствуют себя, как команда, которая готовит к гонкам «Формулу 1».
Все знают, что World of Tanks - уникальный проект, ноу-хау, всем хочется быть причастными к великому проекту. World of Tanks уникальны длинным циклом жизни пользователя, который сравним с LTV других популярных MOBA с элементами RTS. Также ценность игры в том, что ей удалось привлечь аудиторию в возрасте 30+ - платежеспособных людей, готовых тратить деньги на внутриигровое имущество.
Обои, февраль 2015 года (при виде этого снега в кабинете мне становится прохладнее)
О методологиях управления проектами
Подход к планированию в Wargaming отличается высокой вариативностью. В Wargaming есть разные подразделения. В игровых релизах сложно вносить быстрые изменения, там фанатический подход к качеству, а в планировании веб-сервисов и мобильных приложений подход совсем другой.
У менеджеров продуктов большая свобода в выборе методологии. Есть некий горизонт планирования (у игры это полгода-год, у сервисов - от трех месяцев до полугода), и есть понимание результатов, которых мы хотим достичь. А метод менеджер волен выбирать сам: Lean, Scrum или любой другой.
Менеджер понимает, что он делает и когда, а как это делать - его решение. Это позволяет перепробовать разные методы и выбрать более подходящие, поэтому некоторые команды работают по XP, какие-то - по Scrum, а у кого-то есть даже классический Waterfall. Процессы работают для людей, а не люди для процессов.
Я управляю тремя программами, и в моих командах работает около 75 человек. Это сервисы, которые направлены на разные цели: коммуникация с пользователями, монетизация, привлечение новых игроков.
О управлении продуктами
Важный вопрос в любой компании - как понять, что продукт востребован? Как понять, какие его свойства ключевые и когда перестать его разрабатывать дальше? Иногда бесконечное развитие уже не будет иметь такого влияния на пользователей, не вызовет такую вовлеченность аудитории.
Процесс разработки может быть бесконечным, на него можно потратить бесконечное количество денег, и на самом деле инженеры очень хотят делать именно такие продукты. Искусство управления - инвестировать в проект достаточно, чтобы он рос, жил и развивался, но не больше, чем нужно. Вносить изменения только туда, где будет влияние на основные KPI.
Первое правило - привлекать к работе правильных людей
Программисты любят программировать - по крайней мере, мы вместе создаем условия, при которых можем набирать программистов, которые любят программировать. Зачем мне нанимать программиста, который хочет стать менеджером? Когда появляется вакансия менеджера, его очень редко замещает программист.
Если человек хочет, он может сделать карьерный пивот в сторону управления проектами, но это редкость: инженеры любят программирование и не хотят делать ничего другого. Наша культура - стремиться к тому, чтобы каждый был на своем месте.
Второе правило - правильные KPI, индивидуальные для своего проекта
Основная метрика - сколько игроков у нас есть и насколько они вовлечены в игру, и любые сервисы направлены на то, чтобы увеличить привязанность игроков и их количество.
Продукт любого типа имеет свои метрики. Есть медийные проекты, где KPI близки к классическим медиа: охват, размер аудитории, social applauses. Есть площадки для общения, где мы следим, какое соотношение активности у основной аудитории и у новичков. Есть ecommerce-проекты, где классическая воронка с единым Point of Sale и нужно сделать так, чтобы пользователь нигде не споткнулся, пока несет в игру свои деньги.
Третье правило - особый подход к среде, в которой идет работа над проектами
Если смотреть упрощенно, все это представляет собой подход к планированию на основе ценностей. У всех 4000 сотрудников, вплоть до генерального директора, есть главный индикатор - счастливые игроки. Все, что мы делаем, мы оцениваем через это. И если игроки счастливы, то мы найдем способ сделать счастливыми себя.
Разработка продукта происходит в условиях неопределенности. Но чем больше у инженеров определенности, чем четче определены цели и задачи, тем лучше продукт. Задача менеджера продукта - найти баланс, то есть учесть факторы риска и постоянные изменения и в то же время дать инженерам направление и фундамент для правильной архитектуры.
В этом мире хорошо работает Hypotesis Driven Development. Это экспериментальный подход, к примеру, цикл деминга - Plan? Do? Check? Act, после которого мы анализируем успех или неудачу.
Нашим разработчикам мы стараемся доносить уже более конкретные вещи, так как все очень ранимо реагируют на гипотезы и на эксперименты. Экспериментальный подход тяжело внедрять в крупных компаниях, а в Wargaming уже больше 4000 человек.
Об изменении поведения коллег
Структура компании одновременно сложная и динамичная, в разработке продукта сталкивается много интересов разных людей, которые нужно учитывать и удовлетворять.
Когда мы говорим об изменениях и динамике, нужно брать во внимание не только бизнес-процессы и рациональные причины, но и психологию людей, их мотивацию, ценности - то, что ими движет. Одним из полезных открытий для меня стало использование коучинговых практик. Само собой, это не панацея и подходит не всем, но некоторые методы здорово помогли мне в работе с командами и могут быть полезны другим менеджерам.
Про один из методов, «Пирамида нейрологических уровней Дилтса», я расскажу на конференции ITEM. Метод хорош тем, что о нем можно рассказать за 30 минут: он простой, понятный и «про людей». Ты сам решаешь, что нужно делать, ведь это твой скилл. А с помощью пирамиды Дилтса можно понять, как это лучше донести до людей и какие еще аргументы нужно проработать.
Я узнал об этом инструменте, когда мы с коллегой Димой Снисарем (автор блога Itboost) работали над курсом «Эмоциональный Scrum». Мы разбирали коучинговые и психологические методики, которые используются в Scrum (а там их прямо много), и я понял, что «пирамида» - очень крутой инструмент по изменению поведения людей. А раз это моя работа - почему бы не использовать такой классный инструмент.
Дам тизер выступления: одна из причин популярности Scrum в том, что его авторы удачно расставили нужные мотиваторы почти во всех уровнях «пирамиды мотивации». И это, по-моему, самый комплексный подход из всех. Давайте посмотрим, как в Scrum описаны уровни:
- Уровень окружения: какие артефакты тебя окружают, как их использовать, почему они важны, как вы должны сидеть, когда работаете (бэклоги, борды, стикеры).
- Уровень поведения: когда и как нужно проводить встречи (даже они регламентированы и расписаны)
- Уровень знаний и умений: что нужно знать и уметь, чтобы все это делать (инженеры инженерят, владелец продукта управляет бэклогом, Scrum-мастер помогает и обучает).
- Уровень ценностей: что важно для людей, что их мотивирует (Agile Manifesto, концепция chicken and pigs).
Scrum - это только пример. Каждый раз, когда вы будете сталкиваться с проблемой внедрения нового процесса или изменения стратегии, вам придется менять поведение, а иногда даже ценности людей. Изменение ценностей - самый результативный подход к изменению поведения. Правда, не самый простой.
