Выпуск #22. Беседа с Владимиром Лагутинским

Опубликовано 24.11.2024

В сегодняшнем выпуске затронуты вопросы, напрямую или косвенно связанные с замещением зарубежного ПО для создания BI-решений, в частности, линейки продуктов SAP для BI-решений.

Какие изменения ожидать консультантам SAP BI в связи с использованием новых инструментов и технологий в их работе? Как формировать и управлять дата-командами тимлидам в новых условиях? Какие тенденции в мире данных сейчас вообще прослеживаются?

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

Полезные ссылки

Контакты Владимира Лагутинского:

Профиль в социальной сети


Слушайте подкаст на любимых платформах

Техкомпод на Apple Podcasts Техкомпод на Яндекс Музыке

Поделитесь подкастом с друзьями и коллегами



Расшифровка выпуска

Владимир Юсупов: Добро пожаловать в очередной выпуск подкаста технического коммуникатора Техкомпод! С вами Владимир Юсупов.

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

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

Поэтому, в первую очередь, скорее всего, выпуск ориентирован на SAP BI-консультантов, дата-специалистов, а также тимлидов дата-команд. Но уверен, что если вы не относитесь к озвученным категориям специалистов, то всё равно почерпнете для себя что-то полезное.

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

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

Сделайте выпуски подкаста интереснее для себя

Ответьте всего на три простых вопроса и уделите одну минуту вашего времени.

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

Владимир Лагутинский: Привет! Спасибо, что пригласил.

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

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

В течение 15 лет я работаю с линейкой продуктов SAP в части создания BI-решений. Вот эти продукты являются неким стандартом практически для всего крупного бизнеса. Это я сейчас только про Россию говорю. SAP с какого-то времени прекратил поддержку клиентов из России, и сейчас на рынке все заняты поиском аналогов или разработкой своих продуктов. Ну и опять же, про сами продукты говорить не будем, это сейчас не столь важно. Наиболее остро стоит вопрос в изменении процессов, в том числе процессов введения разработки. И вот конкретный пример. Небольшой группе товарищей, в которую я также вхожу, и которая состоит из «бивишников», консультантов BW, которых мы называем «бивишники». Нам поручили применить подходы из разработки ПО в процессах создания хранилищ данных и в целом BI-решений. Над поставленной задачей работают две группы. Первая – это упомянутые «бивишники», а вторая – условно назовем ее, подразделение мобильной разработки. Первые ничего толком не знают о процессах разработки или знают на поверхностном, а вторые ничего не знают про хранилище данных и SAP, чтобы понимать, как объяснить первой группе, как теперь должны выглядеть их процессы. В результате никто никого не понимает. Дело идет, мягко говоря, небыстро.

Одна из основных причин, насколько я сам понимаю, это то, что SAP-консультанты долгое время жили в одной парадигме, теперь эта парадигма рушится. Что-то надо делать с этим. Вот с этой целью я предложил тебе побеседовать. Уверен, что твой огромный опыт и знания помогут коллегам, в том числе и мне, разобраться пока еще в несвойственных нам подходах работы в сфере BI и управления данными. Тем более, у тебя есть опыт проектного управления в том числе и SA{-командами. Понятно, что за столь короткое время невозможно все осветить, все вопросы, поэтому, наверное, технические моменты мы не будем сегодня затрагивать. Но, опять же, с чего-то начать надо.

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

Владимир Лагутинский: Да, на самом деле, первое, с чего хотелось бы начать, что, в принципе, вся история, связанная с разработкой хранилищ данных. Она есть в России примерно ровно в таком же виде, в каком она есть за пределами России. И история скорее про то, что какие-то моменты, какие-то подходы отличаются. В частности, отличаются системы, которые используются, тулы (инструменты), которые используются для разных задач. Отличаются, естественно, облака, в которых хранятся и хостятся системы. В общем и целом, я бы сказал, что процессы скорее похожи. Есть некоторые моменты, которые отличаются, и отличаются достаточно существенно. Постараюсь про них упомянуть. Если говорить про роли, какие роли существуют. В принципе, можно сказать, что роли сильно зависят от конкретной компании, потому что, как обычно, это бывает в название должности, оно не говорит ни о чем. Говорят именно задачи, над которыми работает тот или иной человек в команде. Соответственно, я бы выделил, наверное, четыре таких основных роли.

Если начать, скажем так, от бизнеса к технике. Ближе всего к бизнесу находятся дата-аналитики. Они могут специализироваться на какой-то конкретной доменной области. В маленьких компаниях может быть один дата-аналитик, который отвечает за все доменные области. Бывают продуктовые аналитики, которые больше взаимодействуют с продуктовыми командами. Бывают маркетинговые аналитики, которые больше про измерение перформанса маркетинговых активностей. Бывают аналитики supply chain. Опять же, в зависимости от конкретной финансовой политики, в зависимости от конкретной структуры компании, конкретной бизнес-области. Соответственно, в их задачу (задачу дата-аналитиков) обычно входит поддержка принятия решений бизнесом, то есть это ответы на какие-то вопросы, проведение каких-то исследований, рисование дашбордов и вот это все. Чем, допустим, отличается классический пример, грубо говоря, BI-разработчика от аналитика данных, что аналитик данных – это не только тот человек, который рисует дашбарды, а это человек, основная задача которого помогать бизнесу отвечать на вопросы. Если для ответа на какие-то вопросы нужны дашборды, окей, давайте создавать дашборды. Если это какой-то разовый вопрос или исследование, например, у нас падает конверсия на сайте, возможно, для этого не нужны дашборды. То есть это больше про извлечение каких-то знаний из данных и представление этих знаний в каком-то удобном для потребления виде.

Дальше, есть следующая роль, она более техническая, и скорее присуща более большим командам. Скажем так, в командах из одного-двух человек ты вряд ли увидишь такую роль. Называется эта роль аналитикс-инженер, то есть это как бы с одной стороны человек, который понимает бизнес-область, понимает, чего хотят стейкхолдеры, но конкретно со стейкхолдерами он не проводит никакой ресёч (research), он не рисует дашбарды. Он больше, скажем так, про подготовку данных в хранилище для того, чтобы аналитикам было удобно пользоваться. Основные стейкхолдеры для аналитикс-инженера – это аналитики данных. С другой стороны, он не до такой степени технический для того, чтобы, делать какие-то интеграции, подключать новые источники данных. Он больше про то, что у нас где-то лежат уже сырые данные и нам нужно их подготовить в удобном для анализа виде. Соответственно, всё, что связано с разработкой моделей данных, всё, что связано с разработкой всяких витрин и агрегатов, обычно это как раз аналитикс-инженер. Откуда, собственно говоря, эта роль появилась? Есть такой замечательный инструмент, который называется dbt. Компания, которая его производит, собственно говоря, она и стала пропагандировать, что есть специальные люди, которые пользуются их инструментом, и эти люди, основной язык для них это SQL. В dbt можно создавать свои трансформации, пользуясь SQL, все просто и понятно. Вот так и появились эти люди, которые создают dbt-модели. Они (аналитикс-инженеры) находятся между сырыми данными и потребителями данных в виде дата-аналитиков.

Если переходить еще дальше к технике, есть дата-инженеры. Это обычно про по-настоящему, скажем так, техническое, то есть это про инфраструктуру, про интеграцию систем, про загрузку сырых данных, про то, как обеспечить какой-то мониторинг качества сырых данных и тому подобное. В каких-то компаниях, более мелких компаниях, дата-инженер может также выполнять роль аналитикс-инженера и заниматься трансформациями. Но если команда или компания чуть побольше, то обычно есть люди, которые занимаются инфраструктурой, интеграциями, которые знают не только SQL, которые могут писать на Java или Python. То есть это более техническая роль (по сравнению с предыдущими).

Ну, и, соответственно, должен быть человек или люди, которые лидируют либо все, что связано с данными, либо лидируют конкретные направления (дата-инженеров или аналитиков).

Всё очень сильно зависит от компании, размера компании, от ее уровня зрелости и, собственно говоря, от организационной структуры внутри компании. Вот по ролям кратко как-то так.

Владимир Юсупов: Да, я понял, Володь. Получается, что набор этих ролей или соответствующих специалистов может разниться от компании к компании. Если компания побольше, то перечень ролей шире, в компаниях поменьше один (дата-специалист) может выполнять условно все задачи.

Владимир Лагутинский: Более того, я скажу, что с учетом всей волны сокращения в IT за последние 2-3 года и с учетом того, что многие компании сейчас значительно меняют свой подход к IT, проверяют гипотезы. Если у нас раньше было 100 инженеров, то можем ли мы сделать то же самое с 50-ю инженерами? Пострадает ли от этого качество или пострадает ли от этого скорость? Во многих случаях получается, что нет. Соответственно, на дата-командах это тоже сильно отражается. И скорее мы дальше будем видеть тенденцию уменьшения размера дата-команд, что означает уменьшение количества ролей и опять более широкий набор обязанностей у каждой из ролей.

Владимир Юсупов: Да, я уже как-то тоже подмечал этот момент. Если взять просто такой горизонт большой, 10 лет назад, то, один BI-разработчик делал всё – задачи аналитика, весь backend делал и так далее. То есть, всю цепочку (задач BI-решения) выполнял. Потом появилась некая специализация, когда каждый чем-то определенным занимался. Теперь ты говоришь, тенденция такова, что возвращается всё к этому же обратно.

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

Владимир Юсупов: Понятно. Володь. Тем не менее, команды, они останутся. Кому-то что-то делать надо. И этими командами надо управлять. Существуют ли какие-то общие подходы или модели организации, управления и структурирования этих команд? Если рассмотреть в этом ключе парадигму SAP BI-консультантов, то чаще всего это отдельное подразделение, которое оказывает услуги различным бизнес-подразделениям компаний, например, хранилище данных и отчетность для бухгалтерии, отдельное для маркетинга, отдельное для каких-то производственных подразделений и так далее. Если я правильно понимаю, это централизованная модель организации команды. Но это не единственная модель. Какие еще модели организации и структуры или дата команд есть? Или с какими ты сталкивался на своем опыте? И по твоему мнению, какая из них наиболее эффективна как с точки зрения бизнеса, так и с точки зрения продуктивности команды?

Владимир Лагутинский: Да, ты абсолютно прав. Есть разные подходы к построению организационной структуры данных и организационной структуры дата-команд. И здесь нет одного правильного ответа. Всё очень сильно зависит от организационной структуры компании, от ее уровня зрелости с точки зрения того, каким образом данные используются. И в том числе, зависит от уровня зрелости самого этого подразделения, которое занимается данными. Обычно всё стартует с централизованной модели, когда у тебя в одной команде сидят и дата-инженеры, и аналитики, и команда во многих случаях выступает как сервисное подразделение. Ровно то же самое, что ты сказал про SAP BW. У этого есть преимущества, есть недостатки.

Преимущество в том, что с точки зрения управления общими подходами, как строить разработку, как строить модель данных, как организовать процессы тестирования, всё очень просто и понятно. Знания переходят из головы аналитиков в голову разработчиков и в обратную сторону очень легко. У них каждый день есть какие-то свои созвоны, синки и так далее. Все понимают плюс-минус, кто над чем работает, и все могут быстро включаться, если видят какие-то потенциальные проблемы в своей области из-за изменений каких-то, которые делает другой человек. Обычно компании с этого начинают, маленькие компании с этого начинают. Но она очень быстро упирается в лимит пропускной способности. И простой пример. Если у тебя аналитики все сидят в одной команде, обычно есть соблазн не делать специализацию аналитиков по каким-то конкретным областям, а сказать, что есть роль аналитика данных, который, с некоторой степенью пересечения, работает и с продуктовыми задачами, и с маркетинговыми задачами, и так далее. Потому что это гораздо проще с точки зрения утилизации времени людей. Если у тебя сегодня много маркетинговых задач, человек занимается маркетинговыми задачами. Если завтра много продуктовых задач, этот человек может переключиться на продуктовые задачи, а не сидеть просто или придумывать себе самому какие-то задачи. Но может возникнуть ситуация, что у тебя много и маркетинговых, и продуктовых задач. И в этот момент ни маркетинг, ни продуктовая команда не хотят ждать, когда освободится человек. Плюс возникают истории, когда один аналитик или два универсальных аналитика работают со всеми предметными областями. Очень тяжело запомнить все детали, какие нюансы есть в маркетинге, какие нюансы есть в продуктах, какие нюансы есть в supply chain. Скорее это получается человек с гораздо меньшим погружением в предметную область и с большим фокусом на какие-то аналитические подходы и технику. Обычно в этом случае страдает качество поддержки бизнеса в принятии решений. Наверное, последняя нехорошая штука, которая в этом подходе возникает. Если команда сервисная, люди стремятся оценивать ее как сервисную команду. Допустим, как технический саппорт. Тут же возникают какие-нибудь левел агрименты и начинается измерение такое, что у вас задача в среднем отдается за 5 дней, а техподдержка ее сделает за 3 дня, почему так. И вот эти все нехорошие вещи, когда не меряется влияние, насколько заработал бизнес из-за того, что аналитик помог принять решение, а инженеры подготовили данные для этого аналитика. Начинают измерять другие совершенно вещи, там аналитик сделал эту задачу за 5 дней, а мог бы за 4. Соответственно, это в какой-то момент становится дорогой в никуда, когда начинается измерение именно импакта команды.

Здесь обычно возникает история про децентрализацию. В зависимости от того, насколько большая компания, можно, допустим, начать децентрализацию с аналитиков. И вместо того, чтобы 5 аналитиков у тебя находились в одной децентрализованной команде, ты оставляешь одного-двух, которые, допустим, отвечают за какие-то кросс-доменные топики, например, какая-то отчетность по деятельности всей компании. Есть у вас такой дашборд, на который каждое утро смотрят все. Вот, соответственно, у этого дашборда должен быть какой-то один такой владелец внутри централизованной команды. Остальных аналитиков можно отдать в продуктовую команду, маркетинговую команду, в финансы, чтобы они были ближе к стейкхолдерам, понимали, в чем их проблемы, были доступны для этого стейкхолдера все время без пересечения с какими-то другими подразделениями. И такая штука начинает работать гораздо лучше. Дальше в какой-то момент можно упереться в то, что для маркетинговой аналитики, возможно, нужны какие-то специальные данные, допустим, интеграция с какими-то маркетинговыми платформами. По-хорошему неплохо бы иметь и дата-инженера, который будет помогать маркетинговому дату-аналитику. В такой момент ты делишь еще инженерную команду. Таким образом, остается какая-то платформенная команда, которая отвечает за общую инфраструктуру, общие подходы к загрузке данных, общие подходы к трансформации, к тестированию, к диплою и так далее. В то же время есть, допустим, команда, которая занимается маркетинговой аналитикой. У них есть свой дата-инженер, который отвечает только за интеграцию с маркетинговыми платформами. Или в продуктовой команде могут быть какие-то инженеры, которые занимаются загрузкой данных трекинга, то есть обрабатывают какие-то фронт-энд события на сайте, нажатие кнопочек и так далее. Чем больше становится подразделение, тем больше ты его децентрализуешь. Это хорошо с точки зрения скорости принятия решений, доставки каких-то твоих продуктов и результатов аналитики. Но возникают и негативные моменты, связанные с децентрализацией. Уже тяжело понять, кто чем занимается, кто за что отвечает, как изменения в пайплайне, которые сделал маркетинговый аналитик, может сломать что-то у продуктового аналитика. Я сейчас утрирую, но какие-то такие вещи возникают. С точки зрения передачи знаний становится тяжелее, как и в любой большой организации.

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

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

Владимир Лагутинский: Начнем с того, что нет ответа на вопрос, в чьем подразделении должна находиться дата-команда. Здесь, скорее, история о том, что сейчас важно для компании. Обычно что происходит? Если дата-команда находится в подразделении СТО, то всяческие технические вещи будут приветствоваться – сокращение костов на инфраструктуру, как мы круто внедрили какую-то новую систему или сделали иммиграцию. Это классно, но в такие моменты в зависимости, опять же, я не говорю, что это всегда, но могут возникнуть риски того, что эта команда будет считаться чисто техническим подразделением. Лучше, чтобы это было не так, потому что здесь есть все-таки история про бизнес, про принятие решений, про бизнес-результат, а не просто про результат в виде каких-то новых замечательных архитектур. Я видел примеры, когда в зависимости от того, что нужно компании, дата-команда была вплоть до структуры финансов. Если для компании финансы — это наиболее важная вещь, то всё, что связано с планированием, с какими-то прогнозами выручки и так далее, то дата-команду полностью, включая инженеров, можно увидеть в подразделении финансового директора. Это накладывает свои отпечатки. Может быть, если у компании на конкретном этапе больший фокус на маркетинг, на рост, то дата-команда может вообще оказаться в маркетинговом подразделении. Может и в продуктовом (подразделении).. Всё зависит от текущего состояния фокуса компании. Когда команда делится, когда мы переходим к децентрализованной структуре, тогда скорее всего у тебя подразделение, отвечающее за инженерную часть, например, загрузку данных или за платформу, то оно скорее всего будет в структуре СТО. То же самое может быть с аналитиками. Может быть вообще какая-то матричная структура. Например, есть какой-то менеджер по аналитике, у которого не в прямом подчинении находятся все аналитики, а в прямом подчинении они находятся у директора по маркетингу, у директора по продукту и так далее. Здесь нет обычно правильного ответа на вопрос «сделай так и всегда будет хорошо». Здесь скорее про понимание того, где находится компания сейчас и что для компании важно. И от этого строится структура.

Владимир Юсупов: Да, я понял твой главный посыл, что надо исходить из текущего состояния компании и планов каких-то на развитие и так далее. Я, кстати, еще уточню на всякий случай. Я к чему вопрос этот ввел? Как ты считаешь, нужен ли в компании отдельный человек, который возглавляет дата-подразделение? И неважно, это распределенные команды или это какая-то одна общая. Должен ли быть некий человек, дата-лидер общий в компании, который имеет прямую связь с руководством, например, генеральным директором, а не подчиняется, допустим, CTO или CIO, через которых он выходит на руководство. Нужен ли дата-лидер? И если нужен, то в чем преимущество такой структуры?

Владимир Лагутинский: Ответ на вопрос «нужен ли один человек, который отвечает за всё», скорее да, чем нет. Это хорошо, когда такой человек есть. Подчиняется ли он напрямую генеральному директору или он подчиняется кому-то другому из C-Level? Здесь скорее зависит от уровня…

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

Если мы говорим про большие компании и про децентрализацию, то здесь я двумя руками за то, чтобы и такой человек был. Потому что, как я уже сказал, при децентрализации очень легко потерять фокус. Очень легко потерять понимание, куда мы бежим, каким образом у нас знания передаются от одного человека к другому, какие у нас общие правила игры и так далее. По моему опыту, когда в компаниях нет таких людей (дата-лидера), это получается не очень хорошо. Обычно инженеры могут бежать в свою сторону, аналитики – в другую. Все чем-то заняты, у всех полные бэклоги, а бизнес сидит и страдает. Потому что аналитики постоянно говорят: «У нас нет таких данных, которые вам нужны», а инженеры говорят: «У нас уже полно задач, почему вы не пришли к нам три месяца назад, когда было планирование».

Поэтому очень-очень желательно, чтобы был человек, который руководит и отвечает за общую стратегию (в части данных).

Владимир Юсупов: Да, я понял тебя. Володь, раз уж мы затронули тему управления. Среди слушателей подкаста не только, скажем так, рядовые сотрудники – консультанты, инженеры, техписатели – но и тимлиды. Так как мы сегодня про даты-команды говорим… Возможно, тебе встречались, или ты на своем опыте сталкивался, или же просто слышал о типовых распространенных ошибках в управлении именно дата-командами. Можешь поделиться этой информацией по этой теме?

Владимир Лагутинский: Да, я думаю, что стоит начать со следующего. Основная проблема, которую мы сейчас видим в связи с тем, что происходили сокращения и происходят сокращения во многих компаниях, в том числе сокращают дата-команды. Основной вопрос, который возникает – в чем польза от дата-команды? Если 10 лет назад мы могли говорить о том, что мы сделали отчет, который сейчас собирается за минуту, а раньше на него бухгалтерия тратила неделю, то сейчас такими историями никого не удивишь и наличие отчета считается данностью. «У нас появился этот отчет» – не является показателем пользы от команды. Здесь же возникают вопросы: «Как показать эту пользу?»

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

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

И, наверное, самый последний момент, который я часто замечал, что в каких-то случаях дата-команды, уровень инженерной зрелости в дата-командах может быть ниже, чем, скажем, в командах разработки, просто продуктовой разработки. Что я имею в виду? Есть основные процессы – CI/CD, тестирование, каким образом происходят релизы, каким образом мы эти релизы выкатываем на прод, какие среды у нас должны быть. Во многих случаях в дата-командах эта штука страдает, потому что… а зачем? Вплоть до того, что многие тестируют на проде какие-то такие вещи. Здесь из разряда – подготовьте свое рабочее место для того, чтобы вам было удобно. В идеальной ситуации после коммита релиз должен оказываться на проде сам через несколько минут после всяких тестов на то, что он разворачивается и ничего не поломал. Инженер должен быть уверен в том, что он фокусируется только на бизнес-логике, на каких-то оптимизациях или еще чем-то, но он не думает про эту инфраструктурную часть. Ее нужно сделать, потратить на это время и радоваться, потому что в ручном режиме количество ошибок может просто зашкаливать. Я, может быть, говорю какие-то странные вещи для инженеров, которые нас могут слушать, но, к сожалению, почему-то инженерная составляющая в дата-командах иногда страдает.

Владимир Юсупов: Согласен с тобой. Вообще, отличные рекомендации, точнее типизация ошибок. Володь, если возвратиться к главной ценности компании, к людям. По твоему мнению, какими ключевыми навыками должен обладать дата-специалист? Причем здесь не столь важно, какую роль он занимает в команде. Это даже не применительно к технике. Я имею в виду какие-то общие навыки, которыми должен обладать любой дата-специалист. Причем не то, что должен, а, скажем так, две группы – must have и nice to have. Мог бы что-то здесь порекомендовать?

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

Первая штука, которая, на мой взгляд, важная, то, что человек, работающий в дата-команде, это уникальная роль, потому что это большое пересечение техники и бизнеса. Нельзя сказать, что дата – это только про технику, и нельзя сказать, что дата – это только про бизнес. Это всегда всё вместе. Даже у аналитика, который больше на бизнесовой части, всё равно есть SQL, есть BI-системы, есть понимание того, как работают инженеры. Возможно, он не может деплоить какие-то пайплайны самостоятельно, но в любом случае он может открыть и прочитать чей-то код и понять, как что-то работает. Такая же история про инженеров. Несмотря на то, что они заняты решением технических вопросов, они всё равно понимают, каким образом будут использоваться их данные, кто их будет использовать, на какой конкретный вопрос эти данные должны помочь ответить. В зависимости от вопроса данные могут быть представлены совершенно различным образом. Поэтому мне кажется, что основная проблема, что во многих случаях люди фокусируются на технической составляющей этих ролей. Например, что надо для того, чтобы стать аналитиком? Нужно выучить SQL, Python и какой-то BI-инструмент, который сейчас модно использовать. И всё, аналитик готов. Но по факту, на мой взгляд, что позволит стать из просто аналитику хорошим аналитиком, просто инженеру хорошим инженером – умение фокусироваться на бизнесовой части. Каким образом то, что мы делаем помогает бизнесу в достижении стратегических целей компании, тактических целей компании.

Следующая вещь, которая из этого следует ввиду того, что дата команды работают со всеми, то есть обычно стейкхолдеры – это вся компания. Каждый со своим языком, каждый со своими процессами, каждый со своим бэкграундом. Умение находить язык со всеми этими людьми, умение строить партнёрские отношения с ними, чтобы они считали тебя экспертом в какой-то области и видели в тебе пользу для себя. Это прямо один из ключевых навыков. Для этого нужно в том числе уметь коммуницировать с ними на одном языке и не переходить на то, что сейчас, например, «у нас тип данных в этой табличке, в этой колонке varchar, поэтому ничего не знаю, почему у тебя цифры не перемножаются». Это тяжело, потому что, ты работаешь со всей компанией. У каждого свой бэкграунд, у каждого свой словарь. И тяжело держать в голове, допустим, те метрики, которыми оперирует финансовый директор, и при этом после этого встать и пойти навстречу с командой разработки продукта и понимать, что они делают. Но это важно уметь. Одна из вещей, связанных с коммуникациями, это умение объяснять сложные вещи простым языком. Например, есть финансовый директор. Он же не приходит на встречу и не начинает объяснять, в чем была сложность составления последнего квартального отчета, какие там были нюансы и как он их решал. Он приходит показать результат и каким образом этот результат влияет на жизнь других подразделений. С дата-командой такая же история. Вся эта сложность, которая скрывается за тем, что есть источник данных какой-то, к которому тяжело подключиться, какие-то есть проблемы с консистентностью, какие-то проблемы с доставкой, какие-то проблемы с качеством данных, модель данных не нарисовалась очень легко и просто, потому что бизнес-процессы очень сложные. Мы потратили много времени на то, чтобы это дело собрать. Дальше при анализе возникли еще какие-то вещи. Допустим, из-за сезонности мы не можем сравнивать какие-то показатели, какие-то периоды между собой. Или ковид случился. Цифры до ковида, во время ковида нельзя сравнивать с цифрами после ковида. Все эти прочие вещи никому не интересны, как тяжело тебе это было сделать. В этот момент нужно уметь донести простым и понятным для всех языком, какой результат, что получилось, какие рекомендации.

Наверное, последняя вещь, которую я тоже хотел бы отметить – некий уровень педантичности и дотошности. Потому что есть какие-то вещи, я наблюдал какие-то примеры. Я вижу, что какая-то группа клиентов влияет на нашу выручку, но с учетом того, что у этих клиентов 0,2%, я не считаю, что это проблема небольшая и закроем глаза. Тестирование закончено, данные корректные. Как правило, если люди останавливаются в этот момент, они во многих случаях упускают из виду реально потенциально большие проблемы в будущем. Потому что, как правило, в тех странных кейсах, которых мало и никто не хочет ими заниматься, Обычно кроется что-то большое, какие-то большие технические проблемы или какие-то большие проблемы на стороне бизнес-процессов или проблемы с продуктом и так далее. Я не говорю про то, что люди должны добиться 100% качественных данных, на мой взгляд, это недостижимая вещь, это не надо и это очень дорого. Но, как правило, если упускать из внимания вот эти важные детали, просто закрывать глаза, потому что каких-то кейсов мало, каких-то странных примеров мало, то можно упустить что-то действительно большое.

Владимир Юсупов: То есть, если обобщить, получается, что коммуникация, причём на языке твоего заказчика, чтобы он понимал, о чём ты говоришь. Второе.

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

Владимир Юсупов: То есть погружение в предметную область и педантичность – умение уделять внимание деталям, даже мелким багам, которые могут выстрелить в дальнейшем во что-то большое.

Владимир Лагутинский: Да, на мой взгляд, это важно.

Владимир Юсупов: Отлично. Володь, я не хотел касаться техники. Но, если продолжить все-таки тему, какие навыки нужны успешному дата-специалисту. Про софт-скиллы мы сказали. Но о наболевшем… Я ранее говорил, что для SAP BI-консультантов, например, которые сейчас по различным причинам не могут продолжать работу с продуктами и, в принципе, для тех, может быть, молодых специалистов или тех, кто хочет поменять сферу и войти в мир данных. Какие профильные технологии или инструменты, вкратце хотя бы, востребованы сейчас на рынке. И не только на рынке в России, а, возможно, и на глобальном. Какие из этих инструментов и технологий ты мог бы порекомендовать для дальнейшего изучения специалисту, чтобы он развивал свои компетенции?

Владимир Лагутинский: Здесь есть две, грубо говоря, большие религии. Первая религия – это те, кто про, скажем так, более традиционные хранилища, то есть реляционные базы данных или практически реляционные. Реляционные со всякими настройками базы данных и вся инфраструктура вокруг них. На самом деле, если гуглить, то поисковый запрос – это Modern Data Stack. Он уже не модерн, потому что ему уже лет 10-15, наверное, как минимум. Тем не менее, там ты увидишь в качестве хранилища обычные реляционные базы, точнее клауд-реляционные базы. С качества инструмента для трансформации данных будет, скорее всего, dbt будет. В качестве загрузки данных есть разные игроки на рынке, есть всякие Saas решения типа Fivetran, есть какие-то решения open-source, Airbyte. Мы, допустим, используем Meltano для загрузки данных. То есть, погуглить просто Modern Data Stack, ты найдешь, в принципе, все решения, которые существуют для каждого из шагов по загрузке, трансформации, хранению. BI-часть… Там ситуация интересная. Есть много новых open-source продуктов, которые стремятся как-то пошатать первенство больших корпораций, типа Tableau или Google их Looker. В любом случае, для всех этапов загрузки, трансформации, хранения, визуализации и, допустим, отправки данных назад, что называется reverse ETL, отправки данных назад в какие-то системы типа CRM, ERP или еще чего-то. Для всех этих шагов есть некий пул на рынке. Что выбирать? По факту многие из них похожи друг на друга. Я бы здесь, наверное, исходил из такого подхода, что просто открываете вакансии в той локации, которая вас интересует, смотрите, какие инструменты наиболее часто есть в вакансиях и просто разбирайтесь с ними. Это не означает, что вы гарантированно будете работать с ними, но, скорее всего, если вы знаете Airflow, то вам будет достаточно легко освоить какие-то другие вещи. Нюансы, конечно, есть. В любом случае, переехать с одного инструмента на другой гораздо проще, чем начинать всё с нуля.

Еще одна история, которая, может по-разному выглядеть в России и за её пределами. Это всё, что связано с клауд. За пять лет работы в Европе на всех собеседованиях, в которых я участвовал, был только один пример, когда компания хотела хранить данные на их собственном железе. Вернее, на арендованном железе, когда они пользовались сервисами, клауд-сервисами. Все остальные либо используют клауд именно как сервис, либо хотя бы используют просто виртуальные машины где-нибудь в AWS, Google Cloud, и там разворачивают какой-то open source. Это сильно зависит от компании, но вот это общее понимание того, как работают клауды на примере какого-нибудь одного из них, на мой взгляд, полезно. В России есть Яндекс, Сбер. Я думаю, что принципы абсолютно такие же. Надо понимать, надо этого не бояться, быть к этому готовым. При этом, допустим, есть какие-то вещи, какие-то интересные примеры типа Clickhouse, который популярен и в России, и он становится популярен на Западе. У них сильная команда продаж, и они стараются вывести продукт на мировой рынок. Во многих случаях это им реально удается. Для каких-то кейсов они реально конкурируют с такими компаниями как Google, с их BigQuery, или Snowflake.

И, наверное, еще одна история, если говорить про технологии, языки. Для более ориентированной на реляционные базы данных, скорее всего, будут Python и SQL. С точки зрения BI, опять же, как я сказал, целая куча всяких вариантов. Я бы рекомендовал просто выбрать то, что нравится, и начать с него. Потому что, на мой взгляд, все BI-инструменты сейчас находятся на таком уровне, что начать очень легко. А дальше, в зависимости от твоего уровня экспертизы, ты борешься с ограничениями инструмента. Когда какого-то типа графика в инструменте нет, но ты знаешь, как это преодолеть и нарисовать его. Какие-то такие вещи. Поэтому общие принципы надо знать, и мне кажется, этого достаточно для того, чтобы стартовать или переключиться на какой-то такой трек.

Вторая религия, которая существует, это все, что связано, скажем так, со Спарк (Spark) как движком обработки данных. Там немного другие технологии. Основной продукт, который строится на Спарке, это Databricks. Это большой игрок на рынке, у них существенная доля рынка, и они очень быстро растут. От Спарка они ушли достаточно далеко, но там немного другие подходы к тому, как строится архитектура, насколько она открытая или закрытая, насколько целесообразно втаскивание каких-то сторонних инструментов для того, чтобы грузить данные, трансформировать данные. Обычно такие системы как Databricks встречаются в более крупных компаниях, где действительно есть объем данных, где нужно терабайты и петабайты процессить. Но это имеет место быть. Просто немного другой взгляд на жизнь. Немного другие языки. Несмотря на то, что по словам представителей Databricks, Python все-таки победил там, победил Scala, победил Java, но в любом случае, наверное, там есть еще адепты, которые хотят пописать на Scala. Уровень инженерной подготовки немного выше, чем, в том, что называется Modern Data Stack, где Python во многих случаях заканчивается на загрузке данных, а все трансформации делаются SQL. А что касается визуализации данных, BI-часть, она одинаковая и в первом подходе, и во втором подходе.

Владимир Юсупов: Понятно. Спасибо, Володь. Честно говоря, хотелось бы продолжить ещё, потому что у меня тут заготовок с вопросами на несколько листов, но вместо запланированных 40 минут мы с тобой уже больше часа беседуем. Поэтому не буду тебя задерживать. Благодарю тебя за то, что ты уделил время сегодня на беседу и поделился своими знаниями, опытом. Уверен, что слушатели, так же как и я, почерпнули для себя много ценной информации. Очень надеюсь, что это не последняя наша встреча. Хотел бы продолжить с тобой беседу по заявленной теме. В принципе, интересно послушать твоё видение рынка, индустрии. Желаю тебе успеха в твоей работе. Всего тебе доброго! Благодарю тебя!

Владимир Лагутинский: Спасибо большое! Да, спасибо большое, было очень приятно. Надеюсь, это будет кому-то полезно. И да, давай продолжим. С удовольствием. Да, давай, хорошего дня!

Владимир Юсупов: Счастливо, Володь!

Владимир Лагутинский: Пока!

Владимир Юсупов: Благодарю, что прослушали этот выпуск.

Напоминаю, что вы всегда можете ознакомиться с текстовой расшифровкой на сайте подкаста.

Сегодня с вами были Владимир Лагутинский и Владимир Юсупов. Подкаст технического коммуникатора Техкомпод.

До встречи!