На кончиках пальцев: как команда из Ульяновска учит битмейкингу пользователей по всему миру

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

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

В этом интервью мы поговорили с Кариной Липняговой, сооснователем и техническим директором Drum Pads 24. С командой мы начали работать в 2020 году: меня удивило, как среди ковидного хаоса нанимающие менеджеры давали подробную обратную связь кандидатам. А ещё интересовала история развития проекта на международном рынке, лайфхаки и сложности на пути — так и появился этот материал.

Расскажи немного про ваш продукт: как появилась идея создания?

Drum Pads 24 — это экосистема приложений для создания музыки. Drum Pads 24, MixMate и Loop Pads подходят для любителей и опытных музыкантов, Rhythms — для обучения новичков, Go Rap — для реперов.

Drum Pads 24 — это первое приложение, которое мы выпустили в 2013 году. Оно предназначено для создания музыки с помощью техники фингердрамминга (прим.ред. finger drumming — отбивание ритмов пальцами). Идея принести фингердрамминг на мобильные устройства появилась еще в 2008 году, но устройства того времени не позволяли достичь нужного отклика тачскрина. В результате идея была отложена до 2012 года, когда Павел, другой сооснователь, начал изучать рынок музыкальных приложений и обнаружил, что существующие решения либо слишком сложные с серьёзным порогом входа, либо слишком простые и не позволяют делать что-то интересное.

У Павла был опыт создания электронной музыки, он хотел создать лёгкий музыкальный инструмент, которым было бы удобно пользоваться. Эта идея и стала одной из ключевых при создании наших продуктов — делать такие приложения для создания музыки, чтобы их могли использовать те, кто никогда не был знаком с профессиональными программами и не имеет музыкального образования. Открыв наше приложение, человек может начать делать музыку сразу, без дополнительной настройки и подготовки, даже пятилетние дети могут создавать треки. Это то, для чего мы постоянно создаем и выпускаем качественный музыкальный контент в виде саундпаков (прим.ред. коллекция звуков, подобранных по определённому принципу). Для этого сотрудничаем с разными продюсерами и саунд-дизайнерами, в том числе зарубежными.

В 2013 году состоялся релиз первой версии приложения Drum Pads 24 на платформах App Store и Google Play. Мы сразу выпускали приложение на английском языке, так что не ограничивались конкретной страной. Несмотря на то, что за нами не стояло известного бренда, приложение быстро получило хороший отклик от начинающих и опытных музыкантов, регулярно находилось в топе музыкальной категории. На сегодня у наших приложений более 75 миллионов установок. В основном — это органика. Основные пользователи — из США и Европы, около 15% — из России. Большинство пользователей — это молодые ребята, хотя есть активные пользователи и в других категориях. Для части аудитории это первый опыт создания музыки.

С какими сложностями вы столкнулись при выходе на международный рынок?

Если у продукта понятная механика, которая интересна и увлекательна для пользователя, с ним можно выйти на любой рынок. У нас с самого начала круто работали рекомендации друзей, когда пользователи делали музыку в нашем приложении в школах, колледжах, на вечеринках, и это привлекало новых людей. Простой и эффектный способ создания музыки вызывает интерес, выглядит не так привычно, как пианино или гитара. Один наш битмейкер из США, Раффи Заки, играл фингердрамминг сет на фестивале Burning Man. После выступления многие интересовались, что за инструмент он использует, и удивлялись, узнав, что это обычный iPad с приложением Drum Pads 24.

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

Даже при переводах текстов нужно учитывать особенности конкретного языка. К прошлому китайскому Новому году мы делали специальную скидку в 88% на подписку для пользователей из Китая, так как 8 у них — это счастливое число. Позже выяснилось, что в Китае число означает не скидку, а то, сколько процентов от оригинальной цены надо заплатить. Так что пользователи могли подумать, что им надо заплатить 88% от исходной цены, что выглядело уже не так привлекательно.

Правильная локализация метаданных приложения в App Store и Google Play (ASO) может выступить драйвером роста. В App Store можно локализовать метаданные на 40 языков. Но не обязательно делать это сразу, так как для многих стран основной язык — это английский. Однако тут есть свои особенности. Например, вы решили сделать ASO для России. UK локаль для России — дополнительная. То есть в этой локали можно прописать дополнительные русские ключи в названии и подзаголовке приложения для увеличения объема поискового трафика из России. Однако в App Store эта UK локаль основная в еще 100+ странах. Это означает, что во всех этих странах название приложения тоже будет выводиться на русском языке. То есть люди будут видеть приложение на непонятном для них языке и вряд ли захотят скачать его. У нас была похожая проблема. Когда мы обнаружили эту особенность и исправили метаданные, у нас увеличились показы и установки во многих странах в 2-3 раза.

Также важной частью локализации для конкретного рынка является адаптация имеющегося или создание нового контента. Так, мы делали подборку саундпаков для Латинской Америки. Мы выбрали стиль Baile funk (прим. ред. музыкальное направление, появившееся в Бразилии в середине 80-х), как один из самых узнаваемых в этом регионе. При создании саундпаков постоянно хотелось усложнить аранжировку, но чтобы передать этот стиль, нельзя было перегружать её большим количеством звуков. Было важно разобраться в его особенностях, чтобы не потерять его узнаваемость. Нужной атмосферы добавили колоритные вокальные партии, которые были добавлены для каждой коллекции звуков в подборке.

Есть еще какие-то рекомендации, кроме локализации, которые пригодятся при выходе в другие страны?

Если приложение нацелено на разные страны и использует рекламу в качестве способа монетизации, то стоит обратить внимание на медиацию рекламных сетей. Существует немало рекламных провайдеров вроде Google AdMob, Facebook Audience Network, InMobi и других. Можно выбрать одного и использовать только его. Но для увеличения доходности лучше подключить нескольких поставщиков рекламы с помощью медиации через SDK одного из провайдеров. Тогда запросы на показы рекламы будут отправляться сразу нескольким рекламным сетям, что позволит увеличить заполняемость и доход от рекламы. Некоторые рекламные провайдеры специализируются на определенном географическом рынке и предлагают более высокие ставки за показы рекламы в этом регионе. Можно настроить медиацию так, чтобы в группе стран или даже в конкретной стране использовался свой набор рекламных провайдеров.

Я видела на сайте и удалённые вакансии, и в городе Ульяновск. Всё таки, где у вас находится основная часть команды?

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

Не могу не спросить: пандемия каким-то образом отразилась на вашей команде или коммуникации внутри?

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

Наши основные рабочие инструменты — это Zoom, Trello, Slack, Bitbucket, Zeplin, Sketch, Google Drive. Подробное описание задач, планирование технической реализации, дробление задач на понятные короткие куски, ревью дизайна и кода позволяют нам большую часть вопросов решать асинхронно. Асинхронная коммуникация, пожалуй, чуть сложнее, чем оффлайн общение в офисе, и требует большей ответственности. Нужно написать сообщение так, чтобы человек, прочитавший его через час, смог сразу дать вам ответ, а не задавать пачку уточняющих вопросов. Для этого ваше сообщение должно содержать необходимые детали и погружать в контекст вопроса. Есть хороший набор советов Tips for Amazon Writers, в котором мне нравится пункт про то, какой ответ стоит ожидать на свой вопрос — «Да” / «Нет” / “<Число>» / “Я не знаю (свяжусь, когда узнаю)». Понятно, что такие ответы можно дать только на хорошо проработанный вопрос. Но бывают и сложные вещи, которые требуют длительного обсуждения. В таких случаях может быть быстрее созвониться в Zoom, а конечное решение зафиксировать в виде комментария к задаче в Trello или в Google документе, чтобы команда имела доступ к нему.

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

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

Сколько человек работает над созданием приложений?

Проект начинался с трёх человек. Павел выступал как дизайнер, маркетолог, продакт-менеджер и саунд-дизайнер. Я занималась разработкой iOS версии приложения Drum Pads 24, занималась бэкендом и поддержкой пользователей. Третий участник команды отвечал за Android версию.

Сейчас команда немного увеличилась. Над iOS приложениями работает несколько специалистов. За бэкенд, включая сайт и API для приложений, отвечает отдельный разработчик. В команде есть человек, который общается с пользователями в социальных сетях, отвечает на отзывы и письма.

Мы сотрудничаем с музыкантами и саунд-дизайнерами — они создают контент для приложений. А ещё мы ведём Youtube-канал, где показываем технику фингердрамминга: наш контент-менеджер выпускает видео для нескольких саундпаков еженедельно.

Достаточно такой небольшой команды для международных амбиций? Какие цели сейчас перед вами стоят?

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

Мы сфокусированы на следующем:

Мы любим простые для понимания, но функциональные продукты. Такие, где пользователь не пугается при виде сложного интерфейса, а сразу вовлекается в ключевую механику. А по мере вовлечения открывает больше фишек и полезного функционала. Такими продуктами мы планируем пополнять экосистему приложений, поэтому в нашей команде всегда рады iOS и Android разработчикам.

Простые и функциональные продукты дают больше возможностей для кастомизации. Так, в 2017 году на Тайване проходила международная Универсиада. С нами связались организаторы с предложением разработать специальную версию приложения для церемонии открытия. Но мы пришли к варианту с кастомизацией существующего приложения и созданием специальных саундпаков на основе их официальной песни. Приложение установили на 400+ планшетах и участники церемонии открытия использовали саундпак Universiade Taipei 2017 для аккомпанемента во время музыкального выступления.

Знаю, что вы тщательно относитесь к интервью с кандидатами. При оценке на собеседовании есть ли какие-то ключевые критерии, по которым вы понимаете, подходит вам специалист или нет?

Собеседования предполагают сравнение: кандидатов между собой или с образом того, кого мы ожидаем увидеть в команде. Принимать решения проще при оценке кандидата не на уровне «понравился/не понравился», а при наличии более формализованных критериев.

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

Во время общения с кандидатом обращаем внимание на последовательность в ответах, отвечает ли он на поставленный вопрос или уходит в пространные рассуждения. Умение выделять главное и объяснять принятые решения важно для разработчика, чтобы делать задачи последовательно, начиная с главного, чтобы объяснять решения на техническом ревью или ревью кода. Мы делим задачи на небольшие подзадачи, которые можно сделать небольшими пул-реквестами. Это помогает мержить чаще и не застревать на одной задаче. Для этого надо уметь выделить основное и дальше нарастить поверх базы другую часть.

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

Другое качество, на которое мы обращаем внимание, — это умение обучаться. Во время собеседования узнаем у кандидата, какие ресурсы он использует для развития, что нового недавно применил. Требовать, чтобы кто-то обучался — невозможно. Если человек хочет это делать, он уже делает это сам, пусть даже и в небольшом объеме.

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

Важно ли для ваших сотрудников иметь музыкальный бэкграунд или интерес к музыке?

Академическое музыкальное образование не обязательно ни для кого. Даже для саунд-дизайнеров, которые создают контент для приложения. Хотя для них важно быть в тренде, чтобы делать саундпаки с современным, актуальным звучанием, интересным для большого количества пользователей.

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

Те люди, для кого написание электронной музыки — хобби, могут лучше понимать проблемы и запросы пользователей и разбираться в тонкостях работы со звуком. Им легче придумать новые фичи и проще воспринимать разного рода музыкальные термины, которые всплывают в нашей работе, например, «1/4 доли», «сетка», «такт», «тональность». Мы не спрашиваем у кандидата, чем отличается питч от питч-шифта, однако если он это знает и может объяснить, это, безусловно, плюс. А людям с академическим музыкальным образованием, в свою очередь, должно быть проще разработать алгоритмы, например, генерации аккордов, работы питча и музыкальных эффектов.

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

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

Основное, на что смотрим в коде, — это его понятность, умение разделять ответственность между классами и отсутствие багов. Мы работаем над своими продуктами, которые развиваем уже несколько лет, поэтому для нас важно, чтобы код был поддерживаемым. Код легко поддерживать, если его легко читать, менять, если он понятный и структурированный, поэтому мы обращаем внимание на чистоту кода в тестовом задании.

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

Посмотрев код, всегда задаю некоторые вопросы в письменном виде и смотрю на то, как отвечает кандидат. Поскольку у нас распределенная команда, то большая часть общения у нас происходит асинхронно: в Slack, в комментариях к пулл реквестам или техническим реализациям, описанным в Google Docs. У нас нет возможности подойти к человеку лично и спросить: «Слушай, ты написал такой код, но кажется есть лучше вариант. Можешь рассказать, почему ты сделал так?» Поэтому на этом этапе оцениваем умение коммуницировать удаленно: отвечает ли человек на поставленный вопрос с нужной полнотой или дает такой короткий ответ без пояснений, который вынуждает задавать уточнения и спрашивать еще раз? Конечно, иногда бывают ситуации, когда возникает недопонимание и в этом случае проще и быстрее созвониться в Zoom и обсудить вопрос голосом. Но количество таких ситуаций можно сокращать, если уметь формулировать свои мысли в текстовом виде.

Какая мотивация помогает не забывать, что фидбэк для кандидата — значимая вещь? Находить время среди других задач на развёрнутую обратную связь?

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

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

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

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

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