Разработка в Spotify. Как управляют командами в самом популярном музыкальном сервисе в мире

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

Привет, я Юля. Я сейчас в Швеции. Я работаю инженерным менеджером в компании Spotify. Моя команда занимается бэкендом для авторизационных ландшафтов Spotify, для внутренних разработчиков и экстернал-юзеров.

А ты сказала авторизационных ландшафтов? Что это такое?

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

А, ничего себе, круто. Это самая, получается, такая штука про безопасность.

Да, то есть абсолютно все пути ведут к нам. У нас один из самых больших бэкенд-микросервисных ландшафтов в Spotify. И как бы вы не хотели зайти в Spotify, вы будете заходить через наши сервисы.

Юля, а попала … занималась до этого?

в БГУИР. Это государственный университет информатики и радиоэлектроники. У нас было довольно много грантов. Мне посчастливилось попасть в компанию, которая называется IBA. И это дочерняя компания IBM. И мы работали с немецкими заказчиками, которые пытались установить ERP-шную систему, называется SAP.

ERP— это Enterprise Resource Management, да?

Да.

Так, чтобы люди понимали, SAP— это самая крупная ERP-система. И эта штука стоит как крыло от самолета, а скорее, наверное, как целый самолет, и внедряется годами.

Да.

Я слышал какие-то ужасные истории про то, что…

Вот, про Agile— это совсем не про SAP.

Ты упомянул слово Agile. И то, что IBM, это совсем не про Agile. Давай попробуем вместе сформулировать, какие вообще методы управления разработкой существуют. Потому что вот то, как Spotify управляет разработкой, это такой священный грааль. Все инженерные менеджеры, мне кажется, про это знают, все программисты про это слышали. Но какие вообще бывают методы?

Ну, самый первый— это, наверное, был waterfall, либо метод водопада. IBM очень много про это. То есть есть какие-то планы, которые могут быть пятилетними, десятилетними, двадцатилетними, и нет никаких точек между этими проектами.

То есть, подожди, люди начали делать и потом закончили, и всё? А между этим просто 10 лет?

Да.

Это ты сейчас серьёзно говоришь?

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

Подожди, пожалуйста, но ведь в Waterfall'е, вот в этом методе водопада, там водопад, ну почему водопад? Потому что там такие прямоугольные блоки слева направо и сверху вниз идут, как водопад течёт. Сначала планирование, потом разработка, потом тестирование, потом интеграция, потом внедрение и поддержка. То есть всё такое вроде поэтапно. Так же, как строители здания строят, они там сначала чертёж делают, потом всё строят, а потом сдают в эксплуатацию.

Это, по-моему, вторая improved stage waterfall. В первой части waterfall, мне кажется, заказчик никогда не мог решить, куда ему двигаться дальше, потому что мы уже достигли какой-то конечной точки проекта, и ей либо ему нужно инвестировать огромную кучу денег для того, чтобы заимплементировать что-то новое. В IBM, вот на моем примере, когда мы работали с установкой SAP, у нас была такая классическая модель, то есть планирование занимало, может, 2-3 месяца, имплементация занимала, наверное, 3-4 года, и потом внедрение еще где-то полгода.

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

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

И к чему это приводило вообще, как это выглядело изнутри?

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

Обалдеть. Ты можешь хотя бы порядок назвать? Сколько людей работало над проектом? Какое время? И сколько это примерно стоило?

Да, то есть наш весь проект, он растянулся в 7 лет. А изначально это все должно было закончиться в 3 года. По деньгам я ничего сказать не могу, но там было очень много нулей в конце по количеству людей. То есть вот была у нас немецкая команда, где было около 70 человек. Команда в США, где было около, наверное, 120 человек. Команда в Минске, наверное, из 20 человек. И команда в Индии.

То есть 250 человек работали 7 лет, а потом в мусорку?

Да. Класс!

Я просто слышал такие истории про то, как американские военные, по-моему, заказывали систему, её строили там, типа, должны были построить за 4 года, строили 15 лет, а потом тоже выкинули. Но я их слышал только, типа, читал про них. А тут ты рассказываешь, что ты в 2000 каком году в этом всём участвовала?

Ну, я присоединилась, мы уже были на году, наверное, пятом. Я присоединилась в 2010 году.

Мы сейчас обсудили Waterfall, одну из самых популярных систем управления разработкой. Вторая популярная система— это Agile. Можешь про неё рассказать? Как она появилась и чем отличается от Waterfall?

И, по-моему, где-то в 90-х начались появляться эти аджайловые манифесты, и довольно много айтишных компаний, они стали двигаться в плане fail fast, move fast, то есть начали задумываться о том, как можно нам поменять нашу разработку и начать двигаться в каких-то маленьких шажочках, которые будут давать нам очень много фидбэка от юзеров, и каждый фидбэк будет эвалюировать наш продукт.

Короче, нужно собирать обратную связь для того, чтобы понять, правильно мы движемся или нет.

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

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

продуктовых owner'ов, инженерных менеджеров, разработчиков, UX-дизайнеров.

Юлия, а почему основная сложность не в том, чтобы написать код? Ведь конечный результат нашей работы – это программа, которая работает. Это же код, по сути.

Это, наверное, природа человечества. Самое сложное, что мы можем делать,— это разговаривать друг с другом. То есть намного проще сесть и делать то, что тебе хочется, чем спросить у 10-15 людей, а что на самом деле нужно, и пытаться понять, что они хотят этим донести. И самое интересное, в Agile практиках есть такой ритуал, как ретроспектива. И мне кажется, ретроспектива— это очень крутой тул для того, чтобы команда самосовершенствовалась сама по себе. То есть её никто не толкает, они сами обсуждают, что мы можем сделать лучше из своих только сил. А в Waterfall'е это всё нагнетается с лидерской части, то есть никто не решает это на нижнем уровне, Лидеры приходят и говорят, вот тебе нужно делать это, нужно делать это для того, чтобы следующие наши проекты стали лучше. И никто не делает работы над ошибками, к сожалению.

Мне кажется, что классная аналогия, она про то, что Waterfall— это такая классическая музыка, в которой изначально есть ноты, и все сидят, весь оркестр играет по плану. А Agile— это такой джаз, такая джаз-импровизация. Как ты попал в Spotify?

Да, я вот работала в IBM, и после этого мой проект закончился. Моему молодому человеку предложили работу в Швеции, и я начала искать работу, и Spotify меня позвал на работу.

Ясно. Была инженерная культура в IBM, в которой ты работала, и вот ты переходишь в новую компанию. С чем ты встретилась? С чем ты столкнулась? Какие у тебя были чувства? Ты помнишь?

Ну, во-первых, чувства. Я помню, я когда работала в IBM, у меня всегда был менталитет, что мне нужно вот до последнего сидеть, копаться. И поскольку мы работали в разных тайм-зонах, ну, не всегда можно было спросить кого-то. Я вот прихожу в команду свою в Spotify, я пытаюсь разобраться, как у нас наша database построена.

Баз данных.

В базе данных, да. И я сидела до 10 вечера, и это, наверное, была моя третья неделя. После этого меня мой менеджер вызывает на разговор и говорит, «Юля, что ты творишь? Люди видят, что ты сидишь вечером и работаешь. Ты понимаешь, что ты подрываешь здоровье нашей команды? Они смотрят на тебя, и им нервозно от того, что им придётся так работать». И я такая, «Господи, куда я попала?» И когда я менеджеру сказала, я вот сидела там копалась, потому что мне хотелось узнать, что происходит. На следующий день три моих коллеги сказали, вот мы будем тебя менторить, давай садись вместе со мной, всё, что тебе непонятно. И мы там сидели копались в нашей базе данных, как все таблицы построены, какие там взаимосвязи.

Юля, как называется формальная система управления Spotify? Это называется Spotify Model, да?

Это называлось Spotify Model, но мы сейчас называем это Spotify Rhythm.

Ритм?

Да, Spotify Rhythm. Ну, то есть вот классическая модель, про которую все знают, про которую наши agile-коучи рассказывали, это как раз-таки Spotify модель. А то, что у нас сейчас, это многие-многие итерации усовершенствования этой модели. То есть мне кажется, что Очень многие люди, они не знают, что мы довольно много чего поменяли, и они до сих пор ссылаются на нашу самую первую модель, про которую было очень много видеороликов, и которую как раз таки называли Spotify Model.

Знаешь ли ты, что было с Spotify до этой модели?

До нее был Даниэль Эк и Мартин Лорентзон, которые сидели дома у себя в квартире и кодили очень много. И была одна команда.

А, ты имеешь в виду, что у меня была одна команда разработки, типа меньше 10 человек?

Да.

Окей. И вот эти хитрые штуки, они появились тогда, когда стало больше одной команды?

Да. Я когда пришла в Spotify, я была, по-моему, пятисотым сотрудником или что-то такое. Сейчас нас пять тысяч с чем-то, то есть вот за шесть лет мы выросли там на тысячу процентов.

Пять тысяч?

Даниэль Эк позвал одного из своих знакомых, который занимался agile практиками в Швеции, как консультанта. Этот консультант пришел, он посмотрел, как мы работаем, какие у нас структуры, и порекомендовал вот эту вот спетифайскую модель. Модель, которая будет направлена на agile практики, и скейлиться она будет из команд. То есть, в чем основополагающие практики в той модели? То, что каждая команда, которую мы называли Squad, она мини-стартап, который существует автономно, у которого есть какое-то количество систем, которые принадлежат этой команде. И эти системы— это ответственность этой команды. То есть это формирует очень большое чувство принадлежности к системам, и люди пытаются всячески эти системы улучшить, работать над технической составляющей. И когда они «on call», они знают, как систему вернуть из состояния падения.

То есть это такие дежурные, которые могут поднять, если что-то упадет.

Да, то есть вот термин SRE очень довольно популярный.

То есть SRE – это Site Reliability Engineer – это человек, который может не только программу написать, но еще поднять сломавшуюся систему в продакшене, то есть то, чем люди пользуются.

У нас все разработчики, часть их обязанности – это быть SRE.

Подожди, ты хочешь сказать, что любой разработчик Spotify может поднять свою часть продакшена?

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

Офигеть. Например, в Google SRE, мне кажется, это типа пятая часть всех программистов, или, может, даже десятая, то есть гораздо меньше, чем просто программистов. Им гораздо больше платят, и это считается гораздо более штучным товаром. Такие программисты считаются более элитные. Да.

В Google SRE это отдельная функция, в Spotify эта модель другая, поскольку мы пытались привить любовь к системам и сделать автономное такую маленькую команду, сквот, каждый разработчик, он мини-SRE.

Обалденно. Сколько людей в таком сквозе?

Считается, что самый оптимальный размер— это 5-7 человек. Иногда команды могут скейлиться, и там может быть больше человек, но это тогда знак для того, чтобы команда должна разделяться.

А вот 5-7 человек ты можешь назвать персоналей, то есть какие люди?

Да, моя команда— это бэкэнд-разработчики, то есть у меня 6 бэкэнд-разработчиков, один веб-инженер и UX-ресерч, дизайнер интерфейсов и продуктовый owner (продакт-оунер) и я. А сколько таких команд? В Spotify? Да. Ой, я даже не могу это ответить. Ну, там должно быть, наверное, около тысячи, наверное.

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

Да. Playback— это отдельная команда. Существует куча команд, которые связаны с интеграциями, с различными партнерами. То есть, например, у нас есть аппликейшн, который имбедится в машины. То есть если есть у тебя Tesla или Audi, можно заэмбедить Spotify, и можно его слушать, и можно этим всем заниматься, покуда ты едешь. Отдельная команда занимается этим. Отдельная команда занимается работой с Google Home, Amazon и т.д. и т.п. И наша вся архитектура в Спотифае, она также разделена на несколько таких логических блоков. То есть у нас есть блок консюмеров— это наши юзеры, которые покупают подписку в Спотифае и слушают музыку. Есть часть, которая отвечает за артистов. Любой музыкант может использовать Spotify как платформу для общения со своими фанатами. Любой музыкант может зааплоудить свою музыку, посмотреть графы, аналитики, в каком флейлисте им лучше всего свою музыку продвигать. У нас есть очень много тулов, которые помогают. именно промоутить музыку на нашей платформе и составляют аналитику, как фанаты того либо иного артиста, они могут слушать что-то. Потом у нас есть часть, это довольно новая часть, которая начала работу, называется «Подкасты».

Это я слышал, когда люди как на радио разговаривают, да?

Да, вот как мы сейчас разговариваем.

Я понял, 999 команд как бы не просто так получают зарплату. Ты рассказывала, как устроена система в целом. Вот есть сквод команды.

Да. Возвращаясь к наших моделях, есть сквод. И какое-то количество скводов, оно может организовываться в департамент на русском. На английском мы используем термин tribe.

Племя.

Племя, да. И вот этот вот департамент, он занимается какой-то такой большой частью нашего аппликейшена. То есть, пример. Я рассказывала, что есть довольно много команд, которые занимаются работой с стратегическими партнерами, как там машины, колонки и так далее. И вот tribe, который их объединит, называется PPX, и они, чтобы перевести PPX на русский, я даже не знаю. Partner Experience.

Ну, отношения с партнерами.

Да, то есть вот какое-то большое количество скводов, по-моему, если я не ошибаюсь, около 20, они все живут вот в этом трайбе, и у трайба есть дирекция, и эта дирекция, она направлена на повышение каких-то метрик. Почему мы используем такие слова? Потому что идея за этой всей стояла как эволюция цивилизации, то есть мы пришли, у нас было племя, скводы и все такое, и вот мы эволюционируем и используем вот эти вот все интересные слова.

Прикольно. А в каком трайбе твой сквод?

Мой сквод называется Authenticates, и мы в трайбе, который называется User Platform.

User and platform. То есть это типа такой catch-all на самом деле. Все, что нельзя выделить, оно все там, скорее всего, да?

Да.

А сколько всего трайбов?

Около 50.

Господи, как же это сложно!

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

Какие еще есть миссии?

У нас есть Money & Analytics, Creator, Audio, Free Premium Platform. То есть платформ у нас, по-моему, около 10. И над всем этим стоит, мы называем ее команда D, это команда лидов наших миссий. и наши основатели, которые формируют план на следующий год. То есть вот они собираются, и они говорят, вот мы верим, что подкасты— это следующая крутая фича, которая поможет нам вывести Spotify на новый рынок и позволит нам справиться с нашими конкурентами. И они говорят, вот, скорее всего, если мы заинвестируем в подкасты, это принесёт нам прибыль. Они нам дают просто direction, то есть это не является каким-то проектом или чем-то таким. И потом это всё распространяется на вот эти миссии, трибы, скводы. И в конечном итоге, когда мы планируем наш год вперёд, мы пытаемся сделать что-то, чтобы мы подвинулись ближе к вот этой вот дирекции.

Direction, типа направление. На каком уровне есть ответственность за продуктовые метрики? Это не на уровне миссии, это, наверное, слишком высоко, да? Видимо, на уровне трайба, да?

Метрики есть на всех уровнях, включая сквод, трайб, миссию и команду лидов.

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

Метрики у нас в компании разделяются на такие, я бы сказала, три глобальные категории. Первая— это технические метрики, то есть это все наши P99, P75 и все наши latency. Это вся ответственность лежит на команде. Потом у нас есть продуктовые метрики, которые создаются продуктовым owner и data insights function.

То есть это количество лайков, например?

Да, то есть мы, например, можем заранить эксперимент, где мы изменили положение лайка на 15 миллиметров в какую-то сторону, и посмотреть, как это engagement юзеров меняется в зависимости от этого эксперимента. И потом продуктовый уонер говорит такое, ой, все хорошо у нас идет, давайте имплементить это в production, и вот они двигаются в этих продуктовых метриках. На уровне Трайба у нас метрики, это такие больше KPI-овские метрики, то есть я могу привести пример моего Трайба. Одним из таких метрик был, сколько, например, человек сегодня пришло к нам в платформу, сколько людей смогли заавторизироваться через, скажем, веб. Сколько заавторизировались через мобильный продукт. На уровне миссии один из примеров, которые я могу привести, это больше метрики о том, как Как мы мигрируем наши клиенты? То есть вот, например, один из наших проектов, которым мы занимались, это мы переводили все наши дата-центры в продукты Гугла, GCP. То есть у нас весь клауд— это гугловский, и метрика на уровне миссии будет показывать, сколько команд из всех трайбов в этой миссии они замигрировали в GCP.

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

У нас обычно в каждом трайбе есть Data Scientist, и иногда в командах есть Data Engineers.

Ты говорила, что раньше у вас был Spotify Model, а теперь Spotify Rhythm. В чем отличие Spotify Model?

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

есть они объединяли... То есть типа главный фронтендер.

Да, они объединяли, например, 10 людей из этого трайба, которые занимаются веб-разработкой, либо 10 людей, которые занимаются бэкэндом, либо 10 людей, которые занимаются андроидом. И что изначально мы думали, что это поможет лидеру не ссувать нос в такой day-to-day таски, то есть не будет никакого очень сильного влияния на людей в плане их каждодневной работы, когда они занимаются своим девелопментом с лидерами. И лидеры могут смотреть на то, что происходит в различных скводах, и применять какие-то тактики. И в самом скводе находится продуктовый онер, то есть продуктовый онер, он часть всех ритуалов команды, стендапов и так далее и тому подобное, и agile coach. Agile coach занимается тем, что пытается двигать команду к знаниям agile и давать очень много фидбэка на том, как они работают с agile практиками.

Юля, одна команда, один коуч или один коуч на много команд?

Одна команда, один коуч.

Нифига себе.

Да. И в какой-то момент мы поняли, что у нас невероятное количество agile-коучей.

Им скучно.

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

То есть продукт-оунер становился, по сути, менеджером.

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

А это как раз самые опытные чуваки, которых терять ни в коем случае нельзя.

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

А, раньше не было инженерного менеджера.

Нет, были чаптер лиды.

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

Да.

Третье ты сейчас сказала. За технологию тоже ты?

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

Слушай, ну это практически технический ветр стартапа, на самом деле. Ты отвечаешь и за людей, и за...

Да, то есть это мини-стартап, мини-СТО.

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

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

SLA, я должен для мамы сказать, что это service level agreement, это просто гарантия качества. То, что, типа, мы будем работать 99.999% времени.

Да.

Как мне вырасти? Это один из самых таких больных вопросов у программистов, потому что мало какие компании умеют это хорошо и правильно делать. Как вы это делаете?

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

Биржа труда.

Да, мини-биржа труда. Кроме этого, каждый разработчик в Spotify может двигаться в направлении сеньора-разработчика, то есть двигаться в плане усовершенствования своей технической части. Они могут двинуться в направлении продуктовых оннеров, либо инженерных менеджеров. Как это всё происходит? То есть есть у тебя менеджер. У нас каждую неделю проходит один на один. И, например, вот мой разработчик говорит мне, Юля, я хочу стать продуктовым онором. И я говорю, ой, какая хорошая идея. Мы разговариваем об этом всём, обсуждаем, когда человек хочет стать продуктовым онором, и пытаемся построить взаимопонимание, чего этому человеку не хватает, чтобы быть хорошим продуктовым онором, например. И очень часто чего не хватает, это вот таски, реальные таски, которые бы могли этому инженеру дать понять, нравится ли ему быть продуктовым онлером или нет. И в таких случаях, что мы делаем, мы даем возможность этому разработчику драйвить какие-то проекты и стать продуктовым онлером частично с помощью реального продуктового онлера либо команды. Это всё согласовывается, мы начинаем обозначать временные рамки, работаем очень много с фидбэком, то есть фидбэк происходит не только от инженерного менеджера, но и от всех членов команды. Потом мы решаем в конце, этот человек может перейти в продуктовую часть или нет. Внутри вот этих всех переходов и внутри каждой экспертизы есть еще очень много ступеней. То есть вот инженер в их карьерном развитии можно передвинуться по 7 ступеням, от интерна до CTO.

Вот эти грейды от 1 до 7 у программистов, зарплата прямо на них завязана или нет?

Да-да-да. То есть с каждым промоушеном инженер переходит в новый грейд и новую ступень, и там другая категория денежная.

Это вилка или это точная сумма?

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

А как измеряется перформанс?

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

Как часто получается фидбэк?

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

У нас сейчас идёт второй сезон, в сезоне 15 эпизодов, и в первом сезоне у нас была всего одна девушка-герой. Ты – второй герой-девушка в нашем подкасте. С одной стороны, немножко неудобно из-за всего этого, из-за того, что у меня, типа, один к пятнадцати соотношение гендерное. С другой стороны, найти героя-мужчину в тысячу раз легче, чем герою-женщину. В связи с чем у меня вопрос. Задумываетесь ли вы о гендерном балансе Spotify? Делаете ли вы для этого что-то специально?

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

Означает ли это, что если тебе подали заявку 500 мужчин и 50 женщин, то до этапа интервью все равно дадут 50 мужчин и 50 женщин?

Да, скорее всего.

Потому что мужчин отсеют просто потому, что их слишком много?

Мне очень тяжело сейчас сказать, что их отсеют или нет. Я не думаю, что есть какая-то дискриминация по уровню CV.

Ну, я понимаю, это легко, наверное, аутсорситься. У вас же, наверное, есть компании, которые вам уже поставляют кандидатов, и вы им просто говорите, принесите нам 50 мужчин и 50 женщин-программистов.

И это на самом деле очень сложно, потому что… Я могу сейчас сказать, давайте все компании диверсифицируем своих работников, но это невозможно по очень многим критериям. Первое – это то, что… количество девушек, которые поступают на IT-профессии, оно исторически было такое же, как и наш рынок сейчас – 95 мужчин и 2 женщины. И попытаться выдвинуть эти две женщины во все компании – это довольно проблематично.

можно, но их всего две.

Да, и проблема у Spotify, она была довольно такая лакшери, потому что мы могли таргетить людей из других стран, мы могли хайрить людей из других компаний, но общий IT-рынок, например, в Швеции, он не диверсифицирован. То есть Spotify сейчас в такой стадии, когда они поняли, мы не можем сделать полные метрики 50 на 50, Мы делаем как можно больше, чтобы достичь какого-то показателя. То есть мы там треком, у нас, мне кажется, сейчас по всей компании у нас 30% женщин и 70% мужчин.

Офигеть, это очень высокий процент.

Да, но это уже понятно, что мы не сможем достичь 50 на 50, например, в следующем году, потому что это была очень большая работа проделана.

Ну и вы сейчас пропылесосили рынок на самом деле просто.

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

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

Именно.

Ты так улыбнулась, ты там участвовала сама в этом?

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

Как это работает? Вы в школу приходите, просто уроки даёте для всех детей или только для девочек?

Нет, для всех детей. И это очень важно, потому что не должно быть того, что дети думают, что вот только мне это дано. То есть это круто то, что и мальчики, и девочки, они занимаются одними тем же, и это даёт им возможность понять, что между ними нет большого дисбаланса, и они должны вот с этой мыслью идти вперёд. Есть еще официальный менторинг. У меня есть две девочки, которых я менторю и помогаю из университета. Одна из них в Польше, а другая в США. И мы с ними занимаемся в течение полугода. И если они заканчивают это менторство хорошо, и мы добиваемся наших целей, для них есть возможность стать интерном в Spotify.

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

Это всё неподтверждённые данные, и это только мои наблюдения, собственно, в плане, кого СИВИ я видела, но я считаю, что очень большой кластер есть в Индии женский, в Бразилии и в Китае. остальные кластеры, они не такие значительные, и это, может быть, связано тоже с уровнем населения, то есть в Китае там такое количество людей, возможно, поэтому я вижу намного больше CV оттуда, чем из России, например.

Да, очень неожиданно, интересно. Всё, я задал все вопросы, это было дико интересно. Спасибо тебе огромное. Это подкаст студии Либо-Либо, и мы его сделали вместе с сервисом онлайн-образования Яндекс Практикум. Над подкастом работали редакторы Юлия Яковлева и Андрей Борзенко, продюсер Павел Боровков, звукорежиссеры Ильдар Фатахов и Павел Цуликов. За джингл спасибо Алексею Зеленскому.