Кризисное время всегда способствует переменам, в том числе в поиске новой профессии или приобретении опыта. Вот почему мы решили запустить рубрику Next Step о сотрудниках Х5 Tech, которые смогли поменять профессию внутри компании. Михаил Неверов, директор по анализу данных Х5 Tech, специально для нашего блога на Хабре рассказал о кардинальной смене профессии – как он решился на переход из продакта в Big Data, какие сложности пришлось преодолеть, как он справился с синдромом самозванца и каково это – возглавлять и успешно управлять департаментом по анализу данных из 130+ человек.

В X5 я пришёл в 2019 году на роль Head of Product в департамент монетизации данных. Я отвечал за работу над четырьмя продуктами платформы Dialog. Над ними мы с командой работали около года, а когда их запустили, мне предложили возглавить департамент по анализу данных. Бывший руководитель департамента Валерий Бабушкин на тот момент принял решение уйти из компании – он переехал в Лондон в штаб-квартиру Facebook. Надо отдать должное Валере – за время работы в Х5 он собрал команду классных ребят, сильных в инженерной части.

Скажу честно, что предложение возглавить команду по большим данным было для меня немного неожиданным. До этого я работал с данными на уровне product-менеджера, потом на уровне CPO: я разбирался в статистике, немного писал на Python, знал базовые запросы SQL, но это никогда не было моей основной специализацией. Для меня, учитывая, что я всегда занимался продуктами, единицей измерения был продукт. Есть продукт, а есть команда, и они живут своей жизнью, а ты немного помогаешь с точки зрения компетенций.

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

 В новой роли передо мной стояли три глобальные задачи:

1. Интегрировать команду Big Data в бизнес-единицу Х5 Тech. До этого в компании были два отдельных департамента: департамент информационных технологий и департамент по большим данным. Их нужно было объединить в одно направление бизнеса.

2. Быть готовым к увеличению команды. Когда у тебя в департаменте 80 человек, то строить процессы довольно просто. Можно собираться чуть ли не на всенародном вече, чтобы обсуждать и решать вопросы. Однако, когда команда разрастается, компетенций становится настолько много, что человек, который этим всем управляет, уже не может быть специалистом во всех этих областях. Поэтому необходимо было выстроить структуру: отделы, специализации, людей, которые глубоко погружены в какие-то узкие вопросы и процессы.

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

Кроме того, для этого мы чётко прописали уровни специалистов и требования к ним: кто относится к junior, а кто к middle или senior специалистам. Мы рассказывали об этом здесь. Это позволило добиться безболезненной смены проектов. Например, если человеку надоел проект, то он мог перейти в другой, что положительно сказывается на общем стаже работы и мотивации.

Сомнение и борьба с синдромом самозванца

Естественно, в первое время у меня было сомнение в правильности принятого решения и в том, что я со всем справлюсь. Ведь я не являлся глубоким специалистом в области больших данных. Повторюсь, что у меня был накоплен на тот момент хороший опыт в области Product Management, я мог заглянуть в любой в бэклог и понять, что там происходит. Но большие данные не были моей сильной стороной.

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

Но самым тяжёлым на первых порах для меня была борьба с синдромом самозванца. Ситуация, в которой я оказался, была новой для меня. Общаясь с обычным продактом, я мог спросить его: «Старик, почему ты принял такое решение?». Он приводил свои аргументы, я пытался контр аргументировать с позиции человека, который эту работу уже делал больше раз, чем он, и поэтому был уверен в своей правоте.

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

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

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

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

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

Здесь как раз история про то, когда нужно было решить инженерную задачу про увеличение количества А/В-тестов меньшими ресурсами, но решили мы её по-другому за счёт автоматизации типичных А/В-тестов. То есть инженерную задачу мы решали последней.

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

Конечно, мне пришлось обновлять и подтягивать какие-то знания и по данным в том числе. Вот что мне в этом помогло:

• Курс на Coursera «Что такое наука о больших данных?» от IBM. Есть русские субтитры.

• Курс на Stepik «Основы статистики»: первая и вторая части.

• Книга «Теоретический минимум по Big Data», Анналин Ын и Кеннет Су

• Книга «Много цифр. Анализ больших данных при помощи Excel», Джон Форман.

• Книга «Python Crash Course», Eric Matthes.

Мифы, с которыми сталкивается специалист по большим данным

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

Классический пример — это искусственный интеллект и нейросети. Есть достаточно большое междисциплинарное явление как искусственный интеллект, внутри которого есть различные штуки, связанные с машинным обучением. И нейросеть — это один из методов машинного обучения. Но у людей почему-то эти два понятия идут через запятую. И были суперожидания от искусственного интеллекта, фантазии о том, что нас поработят роботы, что мы все будем жить в каком-то другом обществе. А на самом деле это всё иначе выглядит. Это же не какие-то тайные знания, ты можешь открыть Википедию и прочитать, что, например, перцептрон (кибернетическая модель мозга), про который все говорят, был изобретён в 1956 году, и ничего сверхнового тогда не произошло. Из-за того, что люди не углубляются в тему, получается достаточно комичный эффект. Это меня, наверное, больше всего удивило. Я даже на «Неделе российского ритейла» в прошлом году делал большой доклад, где объяснял людям, что это немножко про разное.

Ещё один пример приведу: я думал, что у меня будет больше проектов, связанных с инженерными задачами. Когда я занимался продуктами, то я всегда понимал, что происходит в каждый момент времени. А в реальности оказалось, что можно жить с гигиеническим минимумом знаний по Machine Learning и Big Data. В этом мне помог немного иной взгляд на проблему: если мы рассматриваем ценность Data Science для компании именно как инструмента, напрямую влияющего на бизнес (наравне с логистикой или мерчендайзингом), а не как подхода в целом, то появляется необходимая точка опоры для принятия решений. У меня после этого осознания произошло переосмысление моей работы.

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

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

Советы самому себе

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

1. Люди — это главное. Нужно всегда опираться на людей, взаимодействовать с ними.

2. Не нужно бояться ошибаться. Это звучит просто, но, когда у тебя в подчинении более 130 человек, — на практике это оказывается сложным. Совершенно нормально делать ошибки, если ты об этом честно говоришь людям: «Ребята, я не знаю, как это делать. Давайте вместе обсудим и придумаем решение».

3. Запускать как можно раньше полноценную историю end-to-end со структурой, ориентированной на людей. То есть строить процесс, больше связанный со встречами тет-а-тет, с оценкой мнений людей относительно того, что происходит в их командах, немножко уйти в парадигму именно наработок внутри департамента с людьми, а не с командами, как я работал до этого.

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

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

Помимо этого, нужно понимать, как устроен бизнес в целом, что такое EBITDA, PNL, OPEX, CAPEX и т. д. Это нужно для того, чтобы нормально общаться с людьми вокруг. Твоя же задача не только выступать в роли человека, который управляет командой, но и сделать так, чтобы людям вокруг тебя было понятно, для чего существует департамент, почему мы этим специалистам должны платить столько-то, в эти процессы инвестировать столько-то, а в другие меньше. Для этого нужно разговаривать с ними на их языке.

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

Специалисты Big Data в текущей реальности

Я думаю, что сейчас, по очевидным причинам, все будут оптимизировать траты. Ещё наблюдается тенденция к демократизации. Что это значит? Например, у тебя раньше был айтишник, который умел делать всё: мог 1С настроить, принтер перезагрузить и пр. Потом это развалилось на специализации. Сейчас же, наоборот, идёт тренд на упрощение всего, в том числе и в Data Science: появляются различные ML-спейсы, где-то чуть ли не drag&drop-ом можешь строить модель и деплоить её.

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

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

Тут должно быть заключение, о том, что не нужно бояться пробовать новое и переходить в другую профессию – но вы и сами все поняли. Обсудим?