Что, на ваш взгляд, самое странное может сделать кандидат на собеседовании?
Вы когда-нибудь задавали себе вопрос, в чём главное отличие дата инженера от "обычного" аналитика?
Знаете, в чём основная разница между опытным сотрудником и тимлидом?
Слышали истории о том, как можно с нуля вырастить и поддерживать на плаву полноценный департамент работы с данными?

На эти и многие другие вопросы я разговаривал с Михаилом Водолагиным. Он очень долго руководил командами дата саентистов и аналитиков, строил команды с нуля, внедрял аналитические системы. CDO (chief data oficer) для него - уже пройденный этап.

Кроме того, Миша обладает уникальной эмпатией, которая позволяет ему видеть проблемы с разных сторон:

• аналитика и заказчика,
• кандидата и собеседующего,
• любителя или противника мемасиков на работе

Надеюсь, вам будет интересно

- Ты как-то дал шикарное обобщающее определение всей аналитике. Сможешь его сейчас сформулировать или сказать откуда ты его вытащил?
- Я не помню, откуда его вытащил, наверняка не со своего мозга это взялось, наверняка я его где-то прочитал, но где сказать не могу к сожалению. Задача очень большого числа людей (например разных менеджеров) состоит в том, чтобы принимать решения. И во всех нормальных рабочих ситуациях они принимают решения в условиях неопределенности. Они что-то знают, имеют кучу своего опыта, но много чего - не знают. И задача аналитики – это снизить уровень неопределенности, желательно так, чтобы увеличить вероятность правильного ответа.
Правильный ответ по-разному определяется. Часто в современном мире решение вообще не принимает человек. Это решение может принимать система.
Например, давайте соптимизируем ставку на рекламу, там тоже принятие решений есть, просто они принимаются автоматикой. И там такое снижение неопределенности настолько совершенно четкое, что в детерминизм сваливаемся.
- Но при этом мы можем определить неправильно.
- Аналитика тоже ошибается, бывает. Может быть, плохое решение, но чем оно тем лучше, чем чаще, чем больше она снижает эту неопределенность.
- Смотри, из этого следуют сразу два следствия. Одно простое, другое вроде посложнее. Первое следствие. Если какие-то действия не приводят к принятию решений в принципе, то это либо ненужная аналитика, либо вообще не аналитика. Так получается?
- Это развлечение. То есть это может быть аналитика, но это аналитика ради развлечения. Здесь тоже бывает работа ради знания, например. Очень часто людей отправляют набивать шишки. Здесь эффект - это не то, что у нас появилась аналитика, а то, что человек научился в табличке лучше данные поворачивать. Тоже приятно, но то ли это, чем хотел.
- Но платят не за это?
- Иногда и за это. RND-шки разные бывают.
- Это часть жизни, от этого никуда не денешься. Правильно я понимаю?
- Тут у меня есть привычка такие штуки трактовать максимально широко. Принятие решения - это шире, чем просто выбор А или Б. Например, часто бывает задача, о том что нам нужна красивая картинка показать на презе клиенту. Это тоже аналитика для принятия решения. Просто она вот такая вот черезжопная чуть-чуть. Мы помогаем клиенту принять решение, что мы хорошие, потому что смотрите, какие у нас понтовые аналитики, как они красиво смогли графики отрисовать. Ну, то есть это не то, что мы действительно покопались данных и что-то нашли. Это такое вот шоу. Оно тоже приводит к решению.
- Смотри, может быть же такое, что человек принял решение, но хочет себя подстраховать. Скорее всего, решения после получения аналитики менять не будет. Он просто хочет, чтобы оно выглядело лучше.
- Для себя или для других?
- Хороший вопрос. Это уже какой-то психоанализ начинается. Неужели у тебя никогда такого не было, что нужно подогнать под уже принятые решения какое-то аналитическое обоснование?
- Это было именно в формате презентации. То есть это о том, что давайте запнем человека в ответ. И это же тоже снижение неопределенности. Просто вот здесь как раз начинается часть условно плохой аналитики, что может быть мы не снижаем неопределенность. Странно это называть аналитикой чуть-чуть, это такое очень широкое размытие терминов.

- Очень хорошо, как раз подвел ко второй части, которую хотел спросить. Получается, что аналитика - это не обязательно про данные. Мы сейчас рассмотрели пример. Там же ничего про данные, ничего про какие-то структуры, связи, решения. Ну и вообще, путей для снижения неопределенности может быть достаточно много. Например, подождать.
- Смотри, я согласен со всем, кроме одного слова. Ничего про решение - вот это странно. И это как раз та аналитика, которая мне всегда меньше всего нравилась, даже если там есть данные, связи, таблицы, все прочие, все такие признаки аналитики. Если человек не понимает, какие решения на основе его аналитики будут сделаны, аналитика имеет очень большой шанс промахнуться. И вот добавление этого знания, добавление понимания о том, кто будет читать эту аналитику и зачем она ему вообще сдалась, и что надо сделать, улучшает работу. Помимо того, что оно его упрощает, оно ещё очень сильно улучшает. И поэтому полезно. В аналитике, с моей точки зрения, решение должно быть всегда. Понимание, какое это решение. Это может быть интуиция, неоформленное, что-то ещё. Может быть человек возьмет и повернет в голове какую-то конструкцию. Например, вот он считал, что у нас мало больниц в стране, а узнает, что у нас много больниц в стране. То есть он не пойдет ничего сразу с этим делать, он не возьмет в руки молоток, не начнет строить новые больницы или рушить существующие. Но у него изменятся знания. Это такое тоже шаговое решение. Которое влияет на поведение в итоге.
- Да, я понял. Ну то есть в целом аналитика без данных вполне возможна?
- Без данных ничего невозможно. Ну то есть все в мире - это данные. Как человек посмотрел на экран - это тоже данные, просто это не оцифрованные данные. Без оцифрованных данных аналитика возможна. Например, вы вышли со встречи и спросили у всех вокруг, как они эту встречу восприняли, это вот тебе данные. На основе которых можно строить аналитику и потом делать вполне далеко идущие выводы о том, что мы хотим с ними работать, не хотим с ними работать, нас обманули, нас не обманули, куда смотреть, что копать. Это тоже аналитика, вот такая буквально на пальцах раскиданная сразу после митинга. Ни одного числа в процессе не было. Компьютера в процессе не было, даже тетрадки не было. Аналитика произошла.
- Смотри, пример такой. Какому-нибудь директору по маркетингу показали несколько рекламных креативов, и он выбрал тот, который более красивый.
- Это на данных, это аналитика. Вопрос качества данных. Здесь данные - это опыт.
- Нет, нет, подожди, он не на CTR посмотрел, а на картинки.
- Да, и у него есть предыдущий опыт. У него есть предыдущий опыт. Вот это его данные: его предыдущий опыт, его знания, его чувство стиля, чувство красоты, как угодно. Если он маркетинг-директор, то, скорее всего, эти данные довольно полезные и довольно хорошие. Очень классно их подменять на реакцию от рынка, потому что реакция от рынка всегда гораздо более правдива. Но если реакции от рынка нет или если мы хотим очень быстро, то опыт - это хорошая прокся. Экспертная чуйка хороших экспертов – это всегда довольно хорошая практика.
- Несмотря на то, что это в принципе нельзя никак оцифровать.
- Это можно оцифровать. Я знаю проекты, как оцифровывают сознание конкретного человека. Да, мой любимый проект здесь – это цифровой двойник Грефа. не уверен, насколько это штука непублична, но, наверное, не очень, раз я это знаю. Там взяли вполне конкретных менеджеров, оцифровали у них экраны телефонов, всё, что они видят, всю информацию, которая у них есть. А решения, которые в Сбере принимаются, они и так оцифрованы с хорошей долей качества. Как считают люди, которые это делают. И все. И вот намапали одно на другое, вот у нас есть мультимодальный вход, вот у нас есть результаты решений, где-то корректные, где-то некорректные. Можем привязать численную оценку. И всё, вперёд, вот они данные. То есть оно как-то оцифровывается. У людей оцифровывается просто трек в 10 лет принятия решений. Уже неплохо. Можно, наверное, глубже.
- И там какая-нибудь хорошая точность?
- Я не знаю, какая там точность. Тем более не знаю, насколько я ей верю.
- Ну ладно, действительно, почему бы нет. Почему бы это не сделать.
- Люди пытаются это сейчас усилить с тем, что семантика определяет сознание, и если мы построим LLM-ку и как-то ее дообучим на основе сообщений. Это вот пока звучит как херомантия откровенная во всех смыслах этого слова. Но вдруг когда-то что-то получится. То есть там прям крест на оцифровке ставить я бы не стал.
- Я не хочу сказать, что это принципиально невозможно. Но есть более простые способы посчитать и предсказать CTR и другие похожие метрики.
- Способы с одной стороны простые, с другой стороны, они дорогие как минимум по времени, а часто и по деньгам тоже. У человека один хороший способ оцифровать опыт, который я знаю, это как раз трек принятых решений в прошлом. Например, если человек в четыре прошлых раза угадал с результат АБ-теста, хорошая причина поверить в него в пятый.
- Особенно, когда вариантов с АБ нет.
- Варианты обычно есть, но зачем? Опять-таки, это как раз тот человек, которому мы должны помогать принять решение аналитикой. Он принял решение, для него было достаточно определенности, нафиг ему не нужна никакая аналитика. Ну и принял решение, отлично. Принять быстрое решение часто полезнее, чем принять правильное решение.

- Ты собирал и не один раз достаточно большую команду, которая вот прямо по классике на данных решает без интуиции снижает неопределённость бизнеса. В этой команде были люди разных специализаций: ETL-инженеры и ML-щики, классические аналитики и BI-щики, технические писатели и скрам-мастера. Кстати, а дата-стюарды у тебя были?
- Они были не у меня, а немного сбоку.
- Короче достаточно много разных ролей. Скажи мне, есть у тебя ощущение что это действительно разновидности какой-то одной дата-профессии? Они между собой как-то друг друга дополняют? Или, всё-таки, BI-щик, такой классический BI-щик, он ближе к UX-дизайнеру, чем к ML-инженеру?
- В этих всех профессиях есть очень сильный налет элитизма. Не то, что забыли об истоках, но здесь, конечно, есть разные профессии. Data Engineer и Data Analyst — это сильно разные роли, прежде всего по hard skills. Код в тетрадке и код в ETL-процессе не совершенно обязаны быть одинакового качества. Обычно это даже вредно. У аналитиков данных есть очень сильное внутреннее ощущение элитарности, например, над Excel-аналитиками. А там на самом деле по функционалу оно довольно близко. Там менее серьезные по hard skills ребята, менее автоматизированные работа, но они вполне справляются отвечать на вопросы бизнеса в Excel. Не в том смысле, что давайте тут бухучет соберем и посмотрим, кто больше всех тратит, а на абсолютно нормальные, адекватные, большие вопросы. Потом в какой-то момент люди обнаружили, что всё то же самое можно сделать в BI, и оно выглядит красивее и убеждает лучше всех вокруг, включая себя самого. А потом они обнаружили, что за это платят в три раза больше. И всё! В этот момент включилась элитарность. Да, технический стэк добавился, технически это становится сложнее, когда добавляется сначала BI, потом Python, R, MATLAB, что-то ещё. По сути и по задаче это в том же направлении, как минимум. Профессии дробятся сейчас больше, становится больше специализации, это часто полезно. Вплоть до того, что там аналитика пользовательская и аналитика маркетинговая, это довольно разные звери сейчас. Из-за масштабов, из-за традиций, из-за много чего ещё. Из-за знаний инструментов в том числе. ML-щики - вообще дикие звери очень разных пород. Я же на самом деле не из аналитики вышел, я из ML-щиков вышел, то есть из квантов, ML-щиков, вот всей этой штуки.
- Давай чуть-чуть приземлю вопрос. Там разные люди всяике треугольники навыков строят, на основании этого пытаются понять, куда тебе ближе. Тем есть такие вещи, как понимание бизнеса, умение писать код, умение выстраивать процессы, что-то ещё. Если у тебя одно сочетание навыков, тебе лучше быть BI-щиком, в другом случае тебе лучше быть ML-щиком.
- Но это всё имеет смотреть только в том случае, если тебе интересны даты профессии как таковые. Или если ты хочешь переквалифицироваться, ты хороший разработчик в java script, но вот решил пойти в дату профессии. Куда тебе идти, тебе нужно исходить из какого-то набора навыков.
- Скажи мне, сама такая постановка вопроса нормальная? Или надо чуть-чуть смотреть шире? Может быть, есть просто дизайнеры, инженеры, аналитики, а какие они конкретно, это уже определяется по стеку, по качествам и по требованиям рынка. Или в дата-профессиях есть что-то общее, например, дата-инженер настолько сильно отличается от обычного разработчика, что это сейчас разные профессии.
- Мне здесь очень сильно порядок операндов не нравится. Про то, что сначала мы смотрим на то, какие навыки приобрелись по ходу жизни, а потом мы уже смотрим на то, что нравится. Я всё-таки в вопросе именно смены или переезда вбок, начинал с того, что нравится, потом добирал навыки. Потому что, особенно лет в 25, сформированный набор навыков - это во многом результат случайных кубиков просто. Человек поработал с этими проектами, у него был хороший учитель по питону, друг заточил в C#, там очень прикольный курс по Go был, и вот получился франкенштейн. Это не значит, что он сильно любит какой-то из этих языков, это тем более не значит, что он сильно любит главную область применения какого-то из этих языков.
А вот то, что человеку нравится программировать или человеку нравится разбираться в взаимосвязях, нравится понимать, как вообще были приняты бизнес-решения, это, во-первых, более стабильная штука, она не меняется тем, что я почитал книжку два месяца, а во-вторых, она еще важнее в будущей работе.
- Хорошо. Давай мы заменим навыки на предпочтения и интересы. Может быть такое, что от одного набора предпочтений ты выбираешь одну специализацию, в другом случае - другую. А по факту сейчас ты можешь работать вообще в третьей, потому что так сложились обстоятельства и рынок.
- Я бы сказал, что это скорее неверно для ETL-щиков, девопсов и подобных людей. Там есть очень много других backend-профессий технических, которые близки по своей сути, близки по своему функционалу. То есть это не то же самое, что front-end development, конечно. Там вбок довольно много чего есть похожего, что с данными напрямую не связано. С другой стороны, очень мало есть программирования, которое умудряется никак не потрогать данные. Везде где-то надо байт пересылать, и как ты без этого вообще справишься.
А с аналитиками меньше вольности. То есть там тоже есть специализация. На мой взгляд, он больше похожа на выбор, хочешь ли работать в стартапе или в корпорате. Тебе ближе МакКинзи-стайл про то, что давайте всё аккуратно посчитаем и сделаем, или тебе ближе стайл из палок и клея про то, что нам кажется, что здесь есть экстремум, давайте сюда попрем, может быть, потом передумаем. Это не выбор профессии, это выбор уже чего-то глубже, культура, что-то такое. И отдельно есть ML-щики, которые вообще растеклись капитально и сейчас опять пересобираются из-за того, что NLP сдохла из-за LLM. И там еще академия просто добавляется как отдельное большое, мощное, нужное направление, и там еще больше выбора, еще больше непонятных взаимосвязей. Кого-то ещё я не затронул?
- BI-щики, например.
- BI-щики. Я очень мало, честно тебе скажу, работал с BI-щиками, которые не являются аналитиками. То есть почти все BI-щики, с которыми я работал, особенно BI-щики, с которыми я любил работать, были на самом деле аналитиками, которые при этом очень любили пользователей и старались сделать, чтобы пользователю было удобно. То есть BI-щиков, которые там условные фронты, которые просто собирают дашборд, чтобы он пахал быстро и соответствовал ТЗ-шке, я встречал довольно мало. Они при этом есть, они при этом хорошо работают. С ними, наверное, приятно работать.
- Нет-нет, подожди! Я бы скорее заострял на другом. Датавиз, датасторителлинг, когда ты хочешь рассказать конкретную историю, и ты всё свое внимание тратишь именно на это. При этом, возможно, ты не можешь полностью соответствовать техпроцессу, получаешь готовую методологически правильную витрину от кого-то еще. Но когда витрина у тебя есть, из нее ты делаешь конфетку так, что человек может и пользоваться ей, и воспринимать информацию максимально быстро. Это не дашборд по ТЗ, это именно фокус на хорошей подаче информации.
- Это аналитик. Это как раз аналитика есть. То есть я не верю, что там бывает фокус просто на подаче информации и всё, потому что тогда возникает вопрос, с какого же темного места ты вытащил историю, которую ты рассказываешь, почему ты ей веришь внезапно. Но после этого, да, это начинается аналитик. Задача аналитика всё еще помочь другому человеку снизить уровень неопределенности. Он должен думать о том, как его прочитают, результат его работы.
- Но может же быть аналитик, который может хорошо разобраться в вопросе сам, который может снизить эту неопределенность для себя, но при этом ему хочется рассказать эту самую историю через какую-нибудь здоровенную Excel-табличку, через наборы приростов и так далее. Все его тезисы правильные, хорошие и замечательные. Просто не будут восприниматься лицом, принимающим решения. Или вообще никем.
- Это звучит, как будто у человека сильная просадка по одному из важных хардов. Я очень хорошо умею складывать и делить, но вот вычитать не получается. Ну, бывает, но лучше починить, наверное.
- То есть ты считаешь, что это прям важный скилл, который прокачивается?
- Оно точно прокачивается. До хорошего уровня оно прокачивается абсолютно точно. То есть до великолепного уровня, может быть, надо, чтобы у человека не было паники толпы и прочих вещей. До хорошего уровня оно прокачивается абсолютно точно. Особенно теперь, когда GPT-шки умеют приемлемые тексты писать. Очень хорошо можно сделать средний хороший уровень.
- И нет никакого конфликта между этими хардами? Если человек умеет хорошо объяснять большому количеству людей какие-то простые вещи, делать какие-то визуализации, значит у него не так хорошо прокачан навык поиска локальных минимумов или чего-нибудь ещё такого?
- Здесь есть классический конфликт про то, что это довольно разные скиллы, Вполне можно вкачать один и не вкачать второй. Это штука есть. Это не прямой конфликт, это конфликт времени, конфликт энергии, которую удалось вложить в обучение. Так есть, но когда оно существует, лучше перекос выправлять. Очень сильно помогает всем вокруг.
- Представим, что ты себя в какой-то момент осознал как специалист, нашел свои слабые и сильные стороны. Получается, лучше подтягивать слабые стороны, чем докачивать до предела сильные?
- Здесь типичная последовательность, которую я пытаюсь сделать с людьми, которые в моих командах происходят. Сначала докачиваем сильную сторону до какого-то сильно хорошего уровня, чтобы было понятно, что она действительно сильная. Потом берем все остальные важные, докачиваем до нормального и дальше бухаем в увеличение экстремума. Продолжаем до тех пор, пока человеку самому это комфортно, конечно же. Я знаю несколько пар, которые работают прям хорошо вместе: один хорошо считает, второй хорошо рассказывает. Или один хорошо пишет, второй хорошо продает то, что первый пишет. Но такое происходит редко. Такие пары поддерживать дорого. Лучше, если ты хотя бы на каком-то нормальном уровне умеешь всё важное. Это снижает риски.
- Бас-фактор, вот это всё, да?
- Это и бас-фактор, это и просто самим людям тоже очень некомфортно, что они друг от друга очень сильно зависимы. Начинают драться про то, кто важнее, кто нужнее. Нафиг надо.
- Есть такое понятие, как разделение труда. Говорят, повышает эффективность.
- Оно не всегда повышает. Оно повышает эффективность в рутинных процессах. Вот это вот утверждение истинно почти всегда. В рутинных процессах эта штука повышает эффективность часто больше, чем просто множитель количества людей. В творческих, интеллектуальных процессах это часто просто уступка ограниченности количества часов в сутках. То есть нам надо разделиться не потому, что ты лучше в одном, а я лучше в другом. Гораздо чаще нам надо разделиться, потому что мы должны вдвоем это пилить, иначе слишком медленно.

- Можно сказать, что увеличение количества дата-профессий - это фактор рутинизации процесса.
- Увеличение количества дата-профессий - это бог знает что. Как и со всеми остальными профессиями, это инфляция титулов. Давайте назовем человека дата-инженером, тогда ему не надо зарплату повышать. У него бейджик красивый. Эти профессии - это не что-то новое что появилось, внезапно придумали в 2025 году, раньше никогда не было. Они все были.
- Они всегда были как роль. А теперь под эту роль выделяют отдельного человека.
- Я бы не сказал, что явное переназначение цеолых людей на роль внезапно упрощает процесс. Скорее наоборот, это мешает. Теперь никто не понимает, что же это всё такое. Data Engineer - это довольно часто человек, который SQL-запросы в базу пишет на добычу данных. Не всегда, но, увы, бывает. Разбираться, что именно тебе придётся делать, когда устраиваешься в новую компанию, всё равно надо.
- Но тем не менее, если есть хороший процесс и хороший Data Engineer, то это всё очень сильно освобождает руки аналитику.
- Любой хороший человек очень сильно освобождает руки. Мы говорили про баланс двух скиллов, которые важны именно в аналитике. Аналитик, который не умеет презентовать свой результат и не умеет объяснить, что он вообще сделал, с моей точки зрения, это довольно редкое явление, которое непонятно, как получилось вообще. Это значит, что человек дошел до высокого профессионализма в аналитике, не сумев получить обратную связь на свою работу до этого, потому что он никому не объяснял свою работу.
- Или был переводчик.
- Ну вот, что-то странное произошло. Как будто был переводчик в обе стороны, это звучит ещё менее вероятно. Надо же ещё и переводчику объяснить. Например, человек, безусловно, не обязан уметь оформлять налоговые транши. Лучше, если это будет уметь бухгалтер. Многие скиллы полезны декаплить. В том числе программирование, как я там в начале сказал, что программирование и код в тетрадках не должны быть одного качества, это не полезно. ETL-инженер поэтому помогает. Переводчик с технического на человеческий помогает гораздо реже. Я в программировании это не очень люблю. Роль системного аналитика и бизнес-аналитика, особенно когда обе этих роли есть в одной команде. Эта цепочка с испорченным телефоном начинает очень сильно угнетать всех вокруг. Чем меньше передаточных звеньев, тем лучше становится. На Data инженерах это тоже бывает. Кто-то взял, потер нолик, потому что почему нет, и там всё поехало. Это боль. Чтобы правильно класть данные в базу, чтобы правильно инжектить новые данные надо, чтобы на них посмотрел и аналитик тоже. Это часть правильного процесса.
- Ты ставишь на большие команды относительных универсалов которые выручают друг друга.
- Не совсем, я всё ещё совмещаю экстремум. Считаю, что есть какая-то норма, нормальный минимум, который у человека должен быть. И там вполне могут образовываться симбиозы, когда команда вместе отлично закрывает всё, потому что там вот экстремумы хорошо как раз разделились. Отлично. В команде есть человек по каждому из экстрамов отличный. Помимо того, что у меня получается оптимальная команда, в ней людям комфортнее в таком состоянии жить, они не чувствуют, что они зависимы слишком сильно, они не чувствуют, что без второго человека они бесполезны и бездарны. Это и так не было правдой, но когда человек может сам закрыть все штуки, он и понимает других лучше, и самомнение у людей повышается в правильную сторону, и вообще всё хорошо происходит.
- А когда из команды убывает человек, ты нанимаешь просто хорошего специалиста, лучшего из того, что есть на рынке по деньгам, не подстраиваясь под какие-то конкретные наборы навыков, которые будут нужны через полгода?
- Слушай, сильно зависит. Если так можно сделать, если у меня не произошла сильная дыра, то, конечно. Редко такое происходит. Редко такие бюджеты получаются, к сожалению. Чаще там есть более специализированная потребность. Например вот этот человек больше в финансах понимает, больше любит с деньгами работать, он там как раз либо из McKinsey сам вышел, либо хорошо понимает, как финотчётность читать и как компании вообще работают. Это полезная экспертиза. Бывает, что у человека доменная экспертиза есть. Так бывает, и я пытаюсь, конечно, нанять, чтобы эту дыру заткнуть, но не то, чтобы такой отличный рынок был, чтобы я мог себе позволить такой черепикинг. Там хороших-то людей найти уже довольно сложно и долго, а тем более с дополнительными фильтрами. То есть оно гораздо лучше и гораздо надежнее решается через устранение фактора кирпича в момент, когда команда ещё собрана. Вот у нас только один человек-эксперт в доменной области, давайте кто-нибудь из вас у него поучится. Давайте, кому интереснее всего, вызывайся, иди учись, пожалуйста. И это может в индивидуальный план развития запихнуть, куда угодно запихнуть, смотивировать человека, выделить ему свободный день в неделю, где они занимаются именно вот этой штукой, напарником в задачу ставить. Как угодно это можно делать.
- То есть, возможно, на каком-нибудь идеальном рынке можно было бы так, но такого не бывает.
- Совершенно не бывает.
- Говорят, что ты можешь оценить годность кандидата за 30 минут общения.
- Я пытаюсь. За 30 минут могу в негативную сторону. Иногда и за 5 получается. Не то, чтобы я всегда угадывал, что человек плохой. Наверняка я часто угадывал не в ту сторону. Может быть человек не плохой, а просто он не в настроении был или что-то ещё такое. Но рынок труда, он же такой чуть-чуть мерзкий рынок. Там не просто лимоны, а там лимоны, которые остаются гнить.
- Подожди, подожди, подожди. Рынок лимонов, он же со стороны кандидата. Разве нет?
- Он с обеих сторон.
- Почему? Если он с обеих сторон, это уже не рынок лимонов в классическом смысле.
- Давай я объясню, что я имею в виду. Есть некоторое количество людей на рынке труда. Хорошие находят работу быстро, а плохие не находят работу.
- Быстро точно не находят?
- Иногда вообще не находят. И поэтому в любой текущий отдельно взятый момент времени на рынке очень много плохих кандидатов и очень мало хороших. Потому что хорошие приходят, сразу получают офер, а плохие задерживаются надолго. Такую специфику рынка труда я называю рынком гнилых лимонов. Из-за этого, когда ты открываешь найм, через тебя проходит очень много задержавшихся на рынке. Их приходится очень быстро отсеивать.
- А про хороших? В основном 30 минут было именно про отсев плохих?
- Да, 30 минут было именно про это. А про хороших сложно. Там и за 3 месяца испытательного срока не всегда можно надёжно сказать, что всё хорошо. Про то, что человек явно со мной не сработается,тоже очень часто можно за час интервью понять. Байка по 30 минут пошла из-за того, что у меня была цель дговориться с HR, которые любили 8 этапов собеседований. А нам так не нужно. Нам нужен HR-скрининг от вас, будет ли он от вас голые фотки просить.
- Что?!!
- Да, было такое на практике. Нам нужен HR-скрининг и какой-то собес с техническим специалистом, который возьмет и скажет, что да, нормально. Если технический специалист может одновременно culture fit в обе стороны сделать, то есть показать кандидату, как у нас принято, и оценить, насколько он подходит - вообще замечательно, можно сразу после этого offer делать. На линейной позиции так точно получалось неплохо, но при этом приходилось принимать боль про то, что мы будем увольнять с испытательного срока довольно много людей.
- И это глобально выгодно, правильно я понимаю? Если посчитать суммарные расходы на поиск, адаптацию, онбординг.
- В линейных позициях - да. В middle-management уже сильно сложнее, в top-management вообще всё всегда очень плохо. То есть на линейных middle-минус - это совершенно точно оптимально во всех вариантах, которые я знаю. То есть в аналитиках, в прогерах мне так оптимальнее.
- Мидл минус - это включая мидл, да?
- Включая мидл, да. В сеньорах там очень часто как раз встречается требование о том, что я хочу ещё какую-то специализацию закрыть. И за счет этого может быть разумный ещё один этап, где проверят именно специализацию. Знает ли человек доменную область, может ли человек конкретно с вот этим продуктом, который токсичен, как я.
- Давай вернемся к линейному персоналу middle-минус. Скажи, потратил ли ты когда-нибудь на GitHub кандидата больше 5 минут? Многие нанимающие менеджеры и резюме-то не читают. Есть мнение, что GitHub, pet-проекты - это просто поставленная галочка в анкете.
- GitHub точно читают, это точно бывает причиной быстрого отказа. Честно скажу, не стоит, наверное, на показ выставлять какую-то глупость. Коммиты причесать не помешает.
- Всё, что вы опубликуете может быть использовано против вас.
Чаще это, конечно, касается программистов. У аналитиков я редко видел pet-проекты, которые отличны от выполненных курсов. На выполненные курсы не очень полезно тратить много времени.
- Курсы - это что-то из серии Яндекс.Практикум и ему подобных?
- Да. Вот прямо Яндекс.Практикум обычно в репозиториях. А у программистов бывает. Был проект, может, ты помнишь, был проект на 2000+ звезд на GitHub. Конечно, там было интересно почитать, что происходит. Это прям полноценный open-source.
- Если 2000+ звезд на GitHub, то вопросов нет, но такое редко бывает.
- С pet-проектами тоже бывает. Я довольно часто тратил время вместе с кандидатом. Это же хороший код, про который можно поговорить, можно сказать: “вот это твой код, защищай, пожалуйста”.
С аналитикой сложнее. Смотрите, он может график построить, ну, может, отлично. Ну и что? Там скорее как раз статьи на хабре или что-то такое может быть полезнее. Здесь я верю, что если человек сделал какой-то анализ, это может быть не топ-место в Kaggle, на которое любят смотреть ML-щики. Но это может быть просто какой-то интересный анализ, какой-то условно не относящейся к делу вещи. Но при этом я не уверен, что это прям рекомендация мидлу или джуну так идти и делать. Это сложная задача. Здесь гораздо проще себя в ногу выстрелить, чем полезное сделать.

- Использовать LLM для того, чтобы из обычного исследования сделать конфетку - это нормально?
- Нормально, конечно. Нормально и хорошо. Наоборот, это скорее хорошо, потому что человек умеет использовать современные инструменты. Главное в аналитике - наличие мысли, идеи, наличие результата исследования. То, как код написан, который это всё окружает, - это слегка вторично.
- Смотри, на собеседовании, в секции лайфкодинга кандидат написал какой-нибудь, например, SQL-запрос. Сделал его в каком-то виде, проверил, что он запускается. Потом кандидат копипастит его и при тебе швыряет в ChatGPT и просит проверить, заоптимизировать. Твоя реакция?
- Спрашивать такие задачи в современном мире - плохой тон. Я, в частности, никогда не спрашивал сколь-нибудь сложные SQL-запросы, ну, потому что это hard skill, который очень легко качается, если честно. Я спрашивал более простые вещи. Например,напиши list comprehension в python, прямо сейчас у меня на экране. Потому что были люди, которые не умеют python вообще, но наврали в резюме про 20 лет опыта. Такое было, и это бесит. Вот и нужно базовая проверка на вшивость. А SQL-инженер мне не нужен, вроде как эта профессия чуть-чуть сдохла 15 лет назад или 10. Если мне нужен человек, который именно оптимизирует SQL-запросы, в смысле, оптимизирует базу данных, я, наверное, именно про это и спрошу. Расскажи мне, какие индексы там есть, расскажи мне, что это такое. Вот здесь, если я вижу, что мне зачитывают ответ чат-GPT с экрана, я, конечно, чуть-чуть обижусь. В остальном, вопросы на знания чуть хуже, чем вопросы на размышления.
- Не обязательно же просто на знания. Человек не уверен, он сделал какой-то запрос. Он решил проконсультироваться. Или довести его до какого-то уровня, навесить дополнительные флаги, проверки, ещё что-нибудь такое.
- Ну, я к этому никогда не относился плохо. Я иногда заставлял людей объяснить мне, чего он навесил. Вот это было. То есть это типичная проверка. Если ты просто веришь тому, что тебе LLM-ка вернула, не читая, то это часто приводит к плохим последствиям. Но это лично моё впечатление и моё отношение, которое, скорее всего, довольно сильно отличается от рынка. Например, 5 лет назад многие считали моветоном гуглить во время собеседования.
- И сейчас есть такие.
- И сейчас есть такие, ладно. Я никогда не считал это моветоном. Но потому что я не считаю, что вопрос на знание - это сильно важно. Если это можно найти в гугле за минуту, то, наверное, человек сможет в рабочей ситуации это тоже найти в гугле за минуту. Мне иногда приходилось гуглить, что такое CTR, например. Потому что память дырявая, лучше проверить, как расшифровывается.
- Топ-3 инструмента на основе LLM для рутинной работы для аналитиков прямо сейчас.
- Мои рутинные задачи прямо сейчас сильно отличаются от задач аналитика. Но сейчас у меня на ротации следующая тройка: ChatGPT, Copilot, Cursor.
ChatGPT нужен когда мне надо пообщаться про пользовательское восприятие, замокать оппонента, замокать вопросы, что-то ещё сделать, замокать, ну, там, средний набор данных, например.
Copilot — это просто удобный этап на перекладывание JSON-чиков, потому что это вообще счастье, что можно нормально перекладывать JSON-чики.
Cursor лучше на чуть более масштабные изменения кода. Вот здесь неправильный пайвот датафрейма, сделай, пожалуйста, вот так. Отвратительно работает с анализом датафрейма, к сожалению, конечно. С графиками нормально. Но вот на такие сравнительно масштабные изменения кода, о том, что вот если я могу описать в четыре предложения, чем мне надо, то в курсоре это сейчас делается лучше, чем раньше было в ChatGPT.
Но я бы не упарывался безумно во все эти инструменты. Они про уменьшение выгорания гораздо больше, чем про повышение качества. То есть вот про перекладывание JSON-чика по табу, это да, это огонь. Ненавижу про это думать. Очень люблю, когда это само делается. Про какие-то такие довольно рутинные вещи тоже в Cursor нормально. Про то, что объясни мне, что происходит на графике, что это значит. Лучше не надо. Лучше сам подумай.
- А тупо визуализации, например, какие-нибудь?
- Ну, Copilot вот очень хорошо. Я, наконец-то, нормально стал рисовать графики. Потому что он помнит в Matplotlib, как вся эта фигня выглядит. Я перестал это отдавать кому-то ещё. Это помогает, но это про красивость. Это уже про финальную полировку результатов. И у этого тоже есть предел прbменения, потому что получается конструкция на 4 экрана, чтобы у тебя просто маркер поменялся.
- Бывает!
- Бывает. Нет, тем не менее, смотри, у тебя может какой-то конкретный человек может закончить, сказать, что вот эта вот визуализация норм, и потащить ее презентовать. А может эту, которая уже норм, сделай еще красивей, и она, скорее всего, станет красивей. А я люблю персонализированную презентацию под клиента, под читателя. В частности, есть довольно сильное региональное деление и chatGPT больше в американской культуре живет. Это часто влияет. Жирно выделить вывод, подсказать дураку и все прочее, что не очень принято в европейской и российской культуре. Можно так делать всё ещё, но я не уверен, что оно добавляет очень много.
- То есть это как и это последние штрихи в прямом смысле слова, да?
- Последнее или не последнее - не столько важно, сколько то, что если твой график плохо восприняли из-за того, что он некрасивый, наверное, надо было дизайнера звать для тебя. Ну или как минимум дизайнера поверх тебя звать. И так делают, так часто делают. То есть там для питча, для подобных вещей вполне серьёзно приходят люди, которые хорошо в планшетах перерисовывают буквально графики, чтобы они выглядели красиво. Это нормальная практика, но это как раз вопрос о том, что надо персонализировать или не надо.
- Говорят, Собянину в Unity рисуют графики.
- Ну нормально!

- Топ-3 худших визуализации которые ты видел?
- Сложно.
- Тогда назови вредных. Вредные визуализации похожи друг на друга. Согласись?
- Нет. Люди умудряются выстрелить себе в ногу очень по-разному! Там почти всегда главная проблема в том, что человек на неё потратил больше внимания и энергии, чем на то, что надо рассказать. То есть сильно заморочено: смотрите, у нас здесь трёхмерные пироги летают, но мало заморочено на то, кому они вообще и зачем нужны. Это какая-то общая история. То есть штуки, которые прям плохие-плохие, они довольно часто плохие осознанно, но это скорее про искусство обмана.
- Это понятно. Я сейчас именно про просто плохую визуализацию. Она плохая, потому что плохая. Ну, не знаю, 12 графиков на 12 линий на одном линейном чарте.
- Тоже бывает нормально, потому что оно показывает групповую динамику. То есть оно всегда было про то, что показали не то, что хотели показать. Сфокусировали не на том, на чём хотели. Там есть всякие эти любимые штуки про то, что у меня линия не помещается на график, давайте я ее обрежу не в нуле.
- Представим себе, что тебе нужно нанять Data инженера, который создает витрины, с которыми потом работают там аналитики, ml-щики и другие. Какие вещи тебя напрягут больше всего?
- Очень сильное отличие со стеком. То есть дата инженерии, она чуть-чуть развалилась на то, что там есть вот эта апачевская структура, там есть кликхауз и подобное. Там есть классические, есть майкрософтовские, есть люди, которые очень фанатеют от Оракла почему-то.
- Это не переучивается?
- Нет, это переучивается, но вот если я за час собеса понял, что человек фанат Оракла, то это скорее всего плохо.
- А разве это нельзя понять по резюме?
- Не особо. Ну, то есть, я встречал пару резюме, где прямо было о том, что если вы не на Оракле, то вы говно, я не хочу с вами работать. Спасибо людям за честность. Ускоряет процесс. Но нет, обычно такие вот холивары в резюме отсутствуют. Это скорее не про то, что человек плохой, если рисует на Power BI. Это про то, что если мне нужен человек сейчас, то, наверное, он нужен мне под довольно конкретные задачи. И здесь брать на себя всю цену обучения необязательно.
Дальше. Напрягает, если человек заваливается на теории. То есть если человек механически делает, не понимая, зачем и почему он это делает. Это не всегда значит, что он работает плохо, но это часто значит, что он не сможет учиться и развиваться. И это значит, что в момент, когда я захочу поменять стэк, добавить дата хаб, добавить ml-flow, добавить что-то ещё, человек отвалится как минимум от процесса, а может быть от всей компании. Потому что он теоретически вас не понимает. До этого в работе они были не нужны, а вот сейчас надо учиться на чём-то. И это больно становится. Ну а дальше типичная штука про программистов, которые работают в высокой степени формализации, они должны уметь решать конфликты.
- Конфликты не в Git. Ты сейчас говоришь про человеческие, да?
- Человеческие, но они могут быть и Git-е. Это опять про фанатичность. Человек берёт и говорит, что pull request зарубает. Я в 3 ночи встал и сделал pull request, потому что у нас prod лежит, а он его зарубает со словами документации нет. Бывали такие штуки в моем опыте. Более реалистичная версия конфликтов о том, что они просто устроили срач в pull request на 40 комментов про то, что у тебя неправильно переменные называются. Это бывает отношение между людьми, особенно больно, когда это отношение с архитектурой. Человек пришел и сказал, а что это у вас не по звёздочке, я так не хочу. Я вот фанат звездочки и надо разложить по звездочке, иначе я вас даже слушать не буду.
- Давайте событийку из Clickhouse по звёздочкее разложим.
- Да-да! Ну вот, тяжело работать с фанатичными людьми, иногда они полезны, но чаще просто, часто слишком больно.

- Смотри, представим себе, что у нас есть аналитик, который решает все задачи, копает, делает всё по ТЗ, но торопится делать выводы. Ну, например, не проверяет какую-то боковую гипотезу, которую только он и только он увидел, не добавляет метрик. Насколько это критично?
- Это зависит от задачи. Обычно это критично. Можно эти выводы не проверять, но можно о них как минимум оставлять дисклеймер. Вспоминаем, аналитик обычно делает работу для кого-то другого, кто принимает решения. И аналитик при этом, конечно, принимает кучу решений сам по пути о том, что важно, что - не важно, что надо проверять, что - не надо. Если есть сомнения, то оптимальный в моей картине мира вариант звучит так: “если не хочешь решать сам - переложи решение на клиента”. Передай явно прописанный список дисклеймеров, вот здесь может быть косяк, я его не проверял, потому что спешил. Опять-таки бывают люди, клиенты, которые ворчат. Мол, такие дисклеймеры - признак того, что аналитик халявит и не работает. Я таких привык давить уже просто утверждением о том, что если вы начнёте ругать людей за честность, они перестанут быть честными, но не перестанут халявить.
Дальше, обычно, когда человек начинает эти штуки вообще хотя бы выписывать в такой вот список, у него начинает своя чуйка тоже калиброваться. И это существенную часть проблемы убирает.
То есть, окей, он поспешил, но это не про то, что я уже бегу и не вижу, куда бегу, а это про то, что я сделал осознанный выбор в пользу скорости относительно полноты проверки. И у всех, кто принимает результат, есть возможность ему спокойно сказать о том, что мне не нравится твое решение, я бы попросил тебя больше-меньше думать. И это окей. Потому что в другую сторону тоже очень часто бывает, что люди закапываются в аналитике и не вылезают.
- А если наоборот?
- А если наоборот, то хорошо помогают здесь говорить примерные сроки оценки какие-то. Но я редко встречаю эту проблему после джуна. На джунах хорошо помогает, когда им кто-то из старших по людей сказал: “вот смотри, задача тебе скорее всего на два дня. Если ты в конце второго дня почувствуешь, что ещё много, напиши и посмотрим вместе, что у тебя там происходит”. И так происходит, если созвон случается, то люди также выписывают что он на самом деле делает, что он проверяет и калибрует про то что вот так на самом деле было. В следующий раз вот так же выписывай просто в отдельный столбик что ты решил не делать. Довольно универсальный, хорошо работающий способ, чаще всё работает шикарно круто. Мне кажется, я встречал на достаточно высоком уровне людей, которые понимают трудоемкую задачу и принимают решение, что выводов достаточно. Возможно, исходя из той оптики, которую видят. Мне кажется, это вечный поиск баланса между временем решения и степенью детализации, которой ты хочешь добиться, перед тем, как ты готов делать какие-то выводы.
- И, как и любой поиск баланса, это история, в общем-то, бесконечная.
- На любом уровне она проявляется, так или иначе. У меня есть скорее с программирования больше ответ. Хотя я его использовал в аналитике тоже, но я редко кого-то ещё заставлял использовать, потому что больно. TODO-шки выписываются в отдельный файлик, ну или там в отдельную ячейку в ноутбуке, и к ним сразу даётся доступ заказчику. И в момент, когда его клюнет петух в попу, и он пойдёт смотреть, а где ты вообще стоишь, какая у тебя работа, он может взять и скорректировать тебя сразу. Ну а я, как исполнитель, это пушу там каждый день, каждые два часа с высокой периодичностью. Очень хорошо помогает. Очень хорошо помогает ещё при этом доставать его и требовать валидации списков. И, опять-таки, не всегда это решение, которое должен принимать именно ты как аналитик. Ты можешь, но, в конце концов, ты не робот, тебя не поставили на полную автоматизацию, тебя поставили именно на хороший фидбэк с клиентом, на хороший фидбэк с твоей исходной задачей. А дальше чуйка.
- Которую можно бесконечно калибровать?
- Да.

- Но давай тогда обсудим, какое главное отличие тимлида от сеньора в аналитике, в DS-ке.
- Если ты помнишь, что там был как раз финт в моём любимом подходе. В общем, тимлид — это другая профессия.
- Ты настаиваешь на этом?
- Я настаиваю на том, что так лучше работает. Совершенно точно.
В моей картине мира есть три шапки, которые в команде должны быть и кто-то должен их надеть.
Есть шапка человека, который отвечает за мораль команды, за то, что люди довольны, людям нравятся условия работы, как происходит взаимодействие с заказчиками. Человек, к которому можно сходить пожаловаться, и он сможет что-то с этим сделать.
Есть шапка человека, который отвечает за процесс перед заказчиком, за то, что мы сделаем задачу в срок, мы сделаем задачу с хорошим качеством.
А третья шапка о том, что я уверен в результате, я уверен в профессионализме, я уверен во всём этом.
Это people management, process management и как раз hard skills.
Классически Team Lead соединяет все три шапки вместе, то есть в себе. Я часто люблю разнести people management и техническую экспертизу и на одного из двух возложить ещё process management на того, кто лучше подходит.
Потому что сильные технари обычно токсичные и херово управляют людьми. Так очень часто случается. Не всегда. Есть люди, которые совместили, они начинают называться хедами практически сразу же. И уже оскорбляются на название team lead.
Team lead часто может отсутствовать. Иногда он проксируется приходящим Scrum мастером или кем-то ещё. Часто он проксируется хорошим HR-бизнес партнером, например.
Это тоже очень классно работает, потому что вот есть действительно человек, который не HR о том, что кого тут надо за сексистские шуточки отправить на тренинг. А который действительно человек, с которым можно поговорить про то, насколько ты доволен, который сильно заинтересован в том, что у тебя индивидуальный план развития не формальностью был, а чем-то, что тебе действительно помогает.
Это очень часто есть, и это часто хорошо работает, когда не экономят на HR. И тогда team lead может вообще быть не очень сильно нужен. Вот именно эта шапка team lead-а. И тогда всё хорошо, вот там вот есть тех лид, он же, наверное, как-то с организацией процесса справится, ответственность за сроки. И отлично, всё едет. Но если вот поддержки снаружи нету, а мораль команде надо модерировать. Ну, кто-то должен. И ему, такому человеку обычно проще, если ему дают официальные полномочия.
Чуть-чуть странно приходить к начальнику и говорить, знаешь, мне тут вот Петя сказал, что у него клиент говно. Сразу вопрос, а что не Петя ко мне с этим подходит, а ты? А при чем здесь ты вообще? А тут у человека полномочия есть.
- Как вот эти три шапки связаны с непосредственно возможностью выполнять задачи в команде? Насколько это могут быть, должны быть отстраненные люди? И как это зависит от размера команды?
- Tech lead, который отвечает за непосредственную экспертность людей в команде и за корректность их работы, должен быть в команде. Бывает так, что он снаружи, но редко так бывает от хорошей жизни. Это иногда работает. Например, работа архитекторов в более общем программировании. Вот архитектор такую шапку часто надевает, он приходит, проверяет, что система работает правильно. Но, по-хорошему, это всё-таки кто-то именно из людей в команде, на него обычно вешают роли пул-реквестера обязательно или что-то ещё такого.
Гораздо лучше, когда он в команде. Остальные две не обязаны быть в команде, но людям изнутри команды часто кажется, что надёжнее, если они внутри команды. Особенно организацию процессов. Когда он тут сбоку тоже в поте лица трудится, гораздо проще поверить, что он заинтересован, чтобы тебя не перегружали. Чем когда это какой-то приходящий скрам мастер, у которого ещё восемь других команд, и он начинает тебе в уши лить, что всем тяжело, не только тебе, потерпи до релиза.
People management - по-разному. Иногда в команде, наоборот, конфликты происходят и это мешает. Иногда ему действительно видно, что у человека упала производительность, он может по таким условно вторичным признакам что-то поймать. Я видел несколько попыток эту штуку автоматизировать. Давайте в слаке считать количество смайликов, смотреть тон сообщений людей. Попытки поймать усталость и выгорание, дизмораль человека заранее, на ранних стадиях, чтобы успеть его в отпуск отправить, облегчить труд, что-то ещё сделать. Довольно погано работает, к сожалению. По крайней мере, я хороших примеров не видел.
От размера команды. Больше людей тяжелее менеджерить.
Не знаю, где здесь правильные ответы, поэтому я скорее ориентировался на классическое утверждение о том, что 7 человек требуют нормального лида, а 15 человек требуют лида в уровне хэда.
- 15 человек требуют хэда и ещё кого-нибудь нерядового?
- Требуют хэда. А дальше хед сам справится. У хеда уже есть какие-то полномочия назначать лида, делить команды, что-то ещё делать? Ну вот.
- То есть, в принципе, вот эти две шапки, которые кроме техлида, они могут выполняться вообще кем угодно?
- Ты можешь хорошего носителя шапки закинуть вообще в другую команду.
- Человек не знает специфики, но должен справиться. Так?
- Ну да. Классический пример — это Scrum Master. Ещё я отмечу, что я почему-то здесь сразу ограничился на монотехнические команды. Далеко не все команды монотехнические, особенно с аналитиками. Аналитики очень часто являются маленьким куском довольно большой продуктовой команды. То есть вот здесь есть 10 человек, из них только один или два — это аналитики, ещё там есть продукт, ещё там есть дизайнер. Ещё там есть просто программист, который эту софтину пишет. Вот такой датамеш на минималках в более разумном варианте.
- И так тоже бывает. Там всё по-другому, это понятно, да.
- Там не всё по-другому. Там техлид начинает быть проблемой. Там нужен кто-то, кто должен оценивать экспертность, и поэтому там начинают строить всякие институты, вертикали и прочие попытки решить эту задачу. Но при этом тимлидом и человеком, ответственным за процессы, очень часто как раз является совершенно другой для профессии человек. Там продукт в классической команде: вот там продукт оунер или продукт менеджер. Он же отвечает за свою команду прям полностью. За ее deliverable, за ее сроки, за качество работы, за вообще всё.
- Конечно, он не может быть одновременно экспертом в дизайне, разработке и тестировании всего вместе.
- Да. Для этого ему как раз выдаются дополнительные вертикали или инструменты в помощь. Или не выдаются, потому что нет ресурсов. Ну, тогда он как-то по-другому это решает. Зовёт знакомых оценить, какую фигню ему написали.
- На то он и оунер, чтобы искать какие-то решения.
- Да, не всегда, к сожалению. Там редко это хорошо работает.
- Бывают хорошие оунеры, бывают плохие оунеры.
- Хорошие оунеры не задерживаются с одной командой, им ещё дают.
- Это уже другой разговор. Ты говоришь, что хэд может обидеться на то, что его называют тимлидом.
- В основном он обижается на зарплату тимлида.
- Вот оно что! Сразу вспомнился анекдот. Дизайнер: “Прибавь мне зарплату”. Директор: “Я лучше назначу тебя вице-президентом по дизайну”.
- Ну да, с какого-то уровня людям становится довольно плевать, как их называют, рациональность всё-таки побеждает. Им не всегда важны именно деньги, им часто нужен уровень ответственности, уровень полномочий, возможность влияния на результат, что-то ещё, признание в конце концов. Именно титул, он как был старший специалист по ЭВМ, как в трудовой, и всё, и зашибись.

- Но всё-таки на уровне CDO по-другому?
- Думаешь мне титул важен был?
- Всё-таки C-Level предполагает немножко другой уровень. Нет?
- Я не знаю, где C-Level всегда работает правильным чифом. Я пока таких мест не видел. Там всегда есть какие-то HRD или ещё какой-то там Chief of Human Resources, чаще всего, к сожалению. Или ещё какие-то ребята, которых вынуждены сюда были приставить из-за буковки, но они вообще на другом уровне решения принимают.
- То есть никаких качественных отличий между хэдом и CDO не наблюдается?
- Нет, они есть. Вопрос именно в том, потому ли, что это C-Level. Нет, я часто на очень в титуле хеда заседал совершенно нормально. Если это кого-то и смущало, они молчали. Аналогично, я часто в позиции, где был C-уровень, видел, что ребята ничего не делают. Сидят и присутствуют.
- Есть хорошие шефы, есть не очень хорошие.
- Их затыкали! Их затыкали, когда они пытались что-то сказать по делу. Потому что не их уровень. Потому что они здесь, чтобы слушать, а не чтобы говорить. Это сложный вопрос про организацию компании вообще, и меня смущает, как это сейчас в российской культуре принято называть. Смотрите, вот есть Тинькофф, и у нас есть 20 CDO. Потому что у каждого проекта должен быть свой CDO. Зашибись. Очень просто. Вот он, CDO над тремя людьми. Спасибо. А есть еще главный CDO, но он не главный CDO, потому что там есть Chief Architect for Data и ещё как-то вот. То есть нет титула не под инфляцией. Титулы мало чего значат в настоящем мире. А откуда настоящую кадровую иерархию взять, бог его знает. Надо HR-ов просить, они могут тебе что-то поделиться по секрету.
- И, соответственно, из этого вывода, что нужно прокачивать тем или иным ходом, чтобы стать CDO, тоже особо бессмысленно.
- Здесь довольно странная формулировка вопроса. Я бы скорее предложил начать с того, чтобы вопрос обозначить явно.
- Что надо сделать, чтобы начать принимать решения на уровень выше?
- Поговорить с тем, кто тебе может это дать. Вот и всё. Надо, наверное, соответствовать в идеальной картине мира. Спросить у него, что ему надо от тебя, чтобы он тебе это дал. И там будут очень разные ответы. То есть, когда я нанимал CDO в команду, когда я нанимал CDO взамен себя, или потому что я консультировал, там были безумно разные потребности. Давай я буду шеймить людей. Я разговаривал с Самолётом. И там шесть раундов интервью, на седьмом выяснилось, что для них CDO - это тот, кто две 1С-ки сольёт вместе. Спасибо, господа, молодцы, что сказали. Был бы намного более благодарен, если бы на втором собесе это было озвучено, а не на седьмом, а лучше на первом, а лучше в вакансии. Это тоже важное решение. Это важное решение хорошего дата-инженера про то, что у нас есть два базы данных, у нас не получился переезд с одной версии 1С на другую, у нас разошлось. Давайте дата-гавернера плюс хорошего дата-инженера или как его назвать, чтобы это всё слить воедино. Нормальная, честная задача и проект, но нет, это не человек, который будет в борде решать о том, какая у нас политика найма. Наверное, вы его туда не пустите.
Ответ на оригинальный вопрос о том, что придумать, на что на самом деле ты хочешь влиять. Потому что если это прям chief-level, то ты влияешь на компанию уже. И начинай с жаб, наверное. Это мой общий совет про то, что если ты хочешь влезть в довольно сильно другую роль, сначала познакомься с плохим, что в этой роли есть. Посмотри, как у тебя выглядят система заявок на бюджетирование. Смотри, как у тебя выглядят планы на бюджет. Как у тебя политики по найму выглядят? Вот всё вот это вот для меня, по крайней мере, неприятная сторона работы, которую надо делать. Она обязательная. Без неё работать намного хуже. Но надо делать. И обычно, когда идёшь с таким вопросом наверх, там совершенно спокойно дают полномочия. Вот ограниченная на твою команду, вот полномочия. И давай улучшение, пожалуйста. И вообще никаких сертификатов, никаких курсов от тебя не требуют. Покажи, что ты сможешь. И, скорее всего, ты сам через два дня скажешь, что пошло оно на нафиг, это не надо, это не то, что я хочу.
Гораздо более часто я вижу трек в увеличении ответственности, такая чуть более локальная история. Например, давайте я вот не буду CDO-CDO или чем-то ещё таким крупным, Давайте я буду главным внутри проекта. Давайте я не просто буду тащить уже существующие, а, например, буду создавать новые части. Или буду какие-то инновации внедрять. Или возьму на себя большой проект по модернизации, если хочется внутри всё-таки трека на улучшение быть. И это тоже классно. Это увеличение уровня ответственности, которое даётся человеку. Не очень важно, как его за это будут называть, его за это будут больше ценить.
- Звучит шикарно, особенно если это как-то монетизируется.
- Ну, внутри компании это хорошо монетизируется. Наружу компании рассказать про то, что я наконец-то убрал 4 кликауза и оставил только один, продавать уже тяжелее.
- Мне кажется, тоже можно вполне. Особенно если люди столкнулись с аналогичной проблемой и страдали.
- Можно, но потом тебя зовут 1С сплитовать! Это именно тяжело продавать. Это не про то, что это какая-то дурость, про которую нельзя говорить. Тяжело объяснить, в чём была задача, в чем была проблема и почему ты такой классный, что ты смог ее сделать.

- Есть какая-то неочевидная литература, которая могла бы быть полезна аналитикам для развития?
- Почитать про принятие решения в любом виде. То есть все вот эти, как строить стартап, как правильно бюджетировать стартап, какие виды управления бизнесом есть, как раз какие роли есть по МБА, по более современным системам, что приводит компании к успеху. Куча есть книг.
- Такую бизнес-литературу обычно хейтят, потому что она переливание из пустого в порожнее.
- Надо уметь читать быстро. Надо уметь читать по диагонали. Кстати, скорочтение рекомендую просто отдельно как скилл. Он не является обязательным скиллом, но мне сильно помог в свое время. Я всё ещё не умею на полторы тысячи слов в минуту читать, но на 500 вполне спокойно. Видишь воду - пропускай воду, чего тебе мешает. Тем более современные инструменты, summary, пропускай, что хочешь. Там есть просто подкасты на YouTube, которые пересказывают книжку. Мне не заходит такая форма подачи контента, но это тоже вполне себе вариант.
- То есть просто берешь механически и перебираешь книжки, пока не найдёшь?
- Это не очень механически. То есть вот следующий аргумент про почему это хейтят. Это хейтят, когда это берут и пытаются использовать напрямую. Такие книжки часто пытаются рекламироваться про то, что сейчас я тебе дам серебряную пулю, я тебе скажу рецепт, как это сделать. Очень редко они могут это исполнить. Я такие книжки воспринимаю про то, что смотри, как у каких-то чуваков получилось. То есть там вот есть условно биография Икеа или какие-то подобные вещи, которые рассказывают, как становился бизнес. Вот они чуть более художественные, а вот это более техническое. Для меня о том, что смотри, какие-то ребята вот так вот построили свой корпорат, вот так вот построили свою систему принятия решений, и у них получилось в их конкретном кейсе.
- Не пытайтесь повторить это дома.
- Да, может, и не пытайтесь. То есть это точно не стандарт, это фреймворк, отсюда надо задёргать только несколько частей, чтобы понять, какие именно части надо задёргать, надо знать много разнообразного и вот все прочее, что этим составляется, а для аналитики это надо прежде всего, чтобы понимать, как думает клиент. То есть вряд ли у читателей есть большая проблема найти хорошую техническую литературу, которая объясняет, как правильно считать. Там хорошая академия, хорошие учебники есть. А вот как понимать заказчика? Проблема обычно гораздо менее чёткая. И вот здесь мне помогали вот такие штуки.
- Спасибо тебе! Много тем затронули, но как будто могли бы ещё больше.
-Тебе спасибо. А ты заходи ещё!