О том, как работают игровые компании, на Хабре писали не раз и не два. Нюансы индустрии гейминга известны многим. Но о том, как организована работа в компаниях из сферы облачного гейминга, мало кто знает. Эта статья даст представление о внутренней кухне этой индустрии на примере отечественной компании Playkey. Под катом раскрываем нюансы организации рабочих процессов, рассказываем о принципах отбора и реализации идей, коммуникаций в команде, обязанностях разработчиков. Если будут вопросы — задавайте в комментариях.
Чем занимается компания?
Playkey специализируется на облачном гейминге и всем, что с ним связано. Отечественная компания — ветеран облачного гейминга, она начинала еще тогда, когда сама эта сфера была уделом гиков, а не мейнстримом, как сейчас. На всякий случай стоит напомнить, что облачный гейминг — это когда на удаленном сервере выполняется вся тяжелая работа по обработке графики игры, на экран компьютера геймера поступает уже готовая “картинка”. Помимо Playkey представители этой ниши — Google Stadia, GFN, PlayStation Now.
Сколько человек в команде и кто они?
Сейчас команда состоит из 30 человек. Это 10 разработчиков, 3 тестировщика, 2 менеджера по маркетингу, 1 SMM-специалист, 3 системных администратора, 2 продакт-менеджера, плюс финансовый отдел, юрист и еще пара специалистов по другим направлениям.
И да, есть еще Беляшик — бессменный талисман команды проекта, который личным примером показывает, как можно получать удовольствие от жизни на все 100%. Его можно назвать Вдохновителем. Это кот.
От идеи к продукту
Процесс принятия важных решений в Playkey выглядит следующим образом. Все начинается с идеи — новой функции, продукта, партнерства или чего-нибудь еще. Идею может предложить любой сотрудник.
Для того, чтобы ее приняли, идея должна быть аргументированной. Желательны цифры и факты, которые позволяют доказать состоятельность предложения команде, которая принимает решения. В нее входят основатель компании, продакт-оунер и еще несколько человек. Если автору идеи удалось убедить большинство представителей этой команды, то начинается работа над реализацией. В некоторых случаях применяется лайфхак “убедить основателя” — противостоять его обаянию и харизме трудно.
Хороший кейс — реализация проекта распределенного гейминга. Идея состоит в том, что владельцы мощных игровых ПК, майнеры, сдают ресурсы своих машин в аренду другим пользователям Playkey. Плюс в том, что не нужны выделенные сервера, нет необходимости в дата-центрах в разных регионах страны. Когда пользователю хочется поиграть — система подбирает ноды, компьютеры майнеров, которые географически находятся поблизости от геймера. Это позволяет уменьшить пинг и увеличить удовольствие от игры.
Так вот, концепцию распределенного гейминга предложил один из сотрудников в 2017 году. Тогда как раз стала очень популярной тема блокчейна и децентрализованных систем вообще. Идею озвучили и неплохо обосновали. Оказалось, что распределенный гейминг дает возможность снизить расходы на аренду стационарных серверов, а также увеличить количество пользователей — клиентами становились бы геймеры из самых разных регионов, а не только тех локаций, рядом с которыми есть сервера Playkey.
В результате было решено приступить к реализации. Отработка гипотезы заняла длительное время, создание технологии — тоже дело не быстрое. С момента появления первой идеи до тестовой реализации прошло полтора года, и сейчас проект готовится к выходу в открытое бета-тестирование в марте 2020.
От разработки к тестированию
Как и в любой айтишной компании важную роль играют тестировщики, все они — хорошие программисты. Каждый из них может писать код и разбирать, анализировать чужой. Заняты, в основном, функциональным тестированием и разработкой автоматических тестов. Вручную все проверить невозможно, а человек, будь он даже суперпрофессионалом, время от времени допускает ошибки. Поэтому по возможности вводится автоматизация, прогоняются unit-тесты, интеграционные тесты и т.п.
Правда, одних “хард-скиллов” недостаточно. Практика показала, что в компании как-то не очень приживаются те, кто не увлекается играми. Собственно, с играми имеют дело все члены команды, но разработчики и тестировщики — больше других. Понятно, что если игры не любишь, то будет сложно работать в такой нише. Это тот случай, когда работа приносит удовольствие.
Product- и project-менеджмент
Продакты — универсальные солдаты. Они разрабатывают стратегию, разбираются с тем, как продукт должен работать, выглядеть и какое впечатление производить на пользователя. А в случае Playkey еще и выполняют функции аналитиков и проджект-менеджеров.
Playkey представлен на рынке не только как самостоятельный продукт, но и как дополнительный сервис от партнеров, например, от операторов связи (скажем, ТТК). Playkey предлагается клиентам оператора как отдельная услуга или “плюшка” в составе тарифа. При такой схеме работы сервис встраивается в чужую эко-систему. Для нормальной интеграции нужно организовать взаимодействие между компанией и партнером, разработку скоординировать и тестирование, согласовать маркетинговые активности. В таких случаях продакты превращаются в проджектов.
Общение сотрудников и организация работы
У компании два офиса — в Перми и Москве. Кроме того, есть сотрудники, которые работают удаленно. Для связи используется Slack. Есть основной чат, и специальные каналы по отдельным проектам и командам. Структура чатов разветвленная и это удобно — все общаются по делу, причем у Slack есть возможность демонстрации экрана, что часто требуется на созвонах.
Что касается организации рабочего процесса, то около полутора лет использовалась схема с двумя продуктовыми командами. Первая работала над достижением оптимальных параметров для первой сессии и первой покупки. Вторая — старалась увеличить игровое время пользователей, а также занималась улучшением качества игровой сессии.
Сейчас используется иной формат. У всех — общая стратегия по проекту, общая цель. Продакты занимаются поиском идей, постановкой задач и проверкой гипотез, ведущих в достижению целей. Для каждой новой “фичи” собирается собственная команда с набором необходимых компетенций, а после успешного релиза — переформировывается под следующую “фичу”.
Непосредственно в разработке используется комбинация Agile и Scrum, которая показала себя максимально эффективно. Первый этап работы — проектирование. А дальше уже идут ежедневные циклы. Рабочие встречи проводятся как в офисе, так и в онлайне, но чаще все же в офисе, поскольку удаленных сотрудников немного. Хотя вот, дизайнер работает из Испании.
Жизненный цикл технических задач привычный всем, кто знаком с Kanban. Цикл планирования недельный. Сначала проектирование, затем задача сдается в работу, проводится code review, затем — тестирование, подготовка к релизу и сам релиз. Все задачи по разработке разделяются на клиентские, серверные и биллинговые. Каждая из команд оказывает еще и техническую поддержку в своей зоне ответственности.
В качестве инструментов для трекинга задач и накопления знаний используются Jira и Confluence. Благодаря этой связки легко проследить судьбу каждой задачи и найти все необходимые сведения о том или ином компоненте проекта или бизнес-процессе.
Вовлечение в процессы
В компаниях, где работает несколько десятков человек, далеко не все понимают, зачем и для кого выполняется текущая работа. Так было и у Playkey — часть сотрудников из продуктовых команд видели общие очертания проекта и четко знали, какая задача и для чего выполняется. Разработчики же писали свой участок кода и считали работу выполненной. Страдало общее качество продукта, поскольку разработчики просто не представляли, с чем в итоге будет работать конечный пользователь.
Ситуацию исправили введением еженедельных общекомандных встреч. Стали собираться, чтобы обсуждать не только участок работы, но и весь проект в целом. Сейчас ввели «пицца-митинги», которые проходят раз в две недели, по пятницам. Все вкусно едят и заодно узнают, что сделано за две недели, как работает новая функция или приложение, как нововведения повлияли на бизнес-показатели. Каждый в итоге представляет, для чего нужен его участок работы и на что может повлиять или уже повлиял. И да, пицца сильно повысила посещаемость!
(не)Контроль сотрудников
Как такового, контроля нет. Используется лишь подсчет времени на решение задач, но цель — не учет рабочего времени, а оценка сроков решения. Реальный срок сопоставляется с плановым, разбираются причины отличий и в дальнейшем планирование становится точнее.
А в какое время и откуда (из офиса или банановой плантации в Уругвае) ведется работа — вообще второстепенно. Пока бизнес-задачи решаются и взаимодействие между командами и сотрудниками идет эффективно, какой-то дополнительный контроль не требуется. Успех компании обусловлен совокупностью навыков, знаний и связей сотрудников, а не их времени или географического положения. Всем свободы и добра!
