Визуализация, которая показывает шаги в SCRUM-процессе.

А вот визуальный концепт Kanban-доски.

Хочу поделиться с вами записью выступления Симо Ахавы на конференции Go Analytics 2019.

Симо Ахава - Analytics Developer из Финляндии, эксперт по Google Analytics и Google Tag Manager.

На выступлении он рассказал о важности коммуникации команды на проекте (как я уже говорил, коммуникация - одна из главных составляющих Agile) и data quality. Здесь он на примере построения data-пайплайнов показал, как проблемы в коммуникации влияют на качество данных и дальнейшую аналитику.

Очень актуальный и полезный доклад. Рекомендую:)

Ребята, всех с наступающим Новым годом! 🎄

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

Спасибо, что читаете, я это очень ценю)

Ещё в конце лета посмотрел отличный вебинар Романа Бунина, на котором он рассказал про алгоритм проектирования дашборда в рамках образовательной платформы Data Learn.

Роман руководит командой визуализации в Яндекс Такси, и мне очень понравился его методичный и системный подход. Нетехническим пользователям по большому счёту всё равно, какие сложные ETL-процессы вы используете или какой DWH используете (т.е. весь back-end аналитического решения), они в этом как минимум мало разбираются. Им главное своевременно получать достоверную информацию, которую они увидят на дашборде, чтобы этот дашборд был визуально приятным и удобным. Поэтому к разработке BI-решения нужно подходить системно и со всей серьёзностью к процессу.

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

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

В общем, для BI-разработчиков и всех, кто работает с инструментами визуализации - must have для просмотра. Остальным также рекомендую в качестве data literacy)

P.S. В описании вебинара найдёте ссылки на презентацию и на доску в miro с дашбордом canvas, где визуально представлены шаги алгоритма.

А теперь вебинар от меня, который я провёл в конце ноября тоже в рамках Data Learn.

На вебинаре я пошагово разобрал кейс построения сквозной аналитики для маркетинга на Google Cloud.

Если вы владеете базовыми навыками SQL и пишете простые ETL-скрипты на Python, то после просмотра сможете тоже построить такую инфраструктуру.

Примерно такое же решение можно сделать на Amazon Web Services и Microsoft Azure.

Будут вопросы - задавайте)

P.S. Интересно услышать, кто с каким облаком работает и какие преимущества для себя нашёл. Пишите в комментариях.

Архитектура решения, про которую я рассказываю на вебинаре.

Думаю, мы максимально подробно (насколько это возможно) разобрали 2-й фактор эффективности работы с данными - "Процессы".

Мы неплохо познакомились с пирамидой потребностей Data Science, с философиями / методологиями ведения проектов, и я привёл пару вебинаров, которые касаются системного подхода работы с данными.

Пора приступать к 3 фактору - "Структура".

И появилась у меня такая идея: сделать 1 или 2 поста на эту тему в формате интервью с несколькими опытными специалистами, которые поработали в компаниях разных размеров. Узнать, из каких ролей состоит команда по работе с данными в их компаниях и какие функции они выполняют.

Как вам такой формат?

Начинаем нашу серию постов о 3 факторе эффективности работы data team - "Структура".

Подумал, что лучше всего будет провести мини-интервью с опытными специалистами, которые поработали и работают в компаниях разных размеров. Чтобы они рассказали, из каких ролей состоит их команда по работе с данными, и какие функции они выполняют. Пока написал около 6-7 человек. Возможно, ешё кому-то напишу и пообщаюсь:)

Серия постов будет в формате 1-2 мини-интервью на пост, чтобы не было каши.

Первым человеком, с которым я пообщался на эту тему, был Дмитрий Аношин - Role Senior Data Engineer в Microsoft (до этого 5 лет работал в Amazon). Дима дал краткую сводку по тому, на каких проектах он работал в Amazon, над чем сейчас работает в Microsoft, какие роли были в командах проектов и с какими проблемами в структуре он столкнулся.

Цитирую:
"Смотри: Amazon:
1) Amazon Marketplace: Role BI+Data Engineer, работал с BIE
В качестве BI:
- установка Tableau Server
- Миграция SQL+Excel отчетов на Tableau
- Self-Service implementation
- Office Hours + Training (Adoption of BI)

В качестве Data Engineer:
-Миграция on premise Oracle DW + PL/SQL ETL на Amazon Redshift, работал с DBA, SDE
-Поиск и выбор Cloud ETL -> Matillion ETL и миграция всего с PL/SQL на ETL + переработка бизнес логики
-Использование AWS EMR+Spark (PySpark) для решения задачи с обработкой веб логов, так как ETL+DW просто не вывозили объем. Результат Spark был в Parquet в S3 (по сути озеро данных) и доступ к нему был через Athena и Redshift Spectrum
- Streaming данных из DynamoDB в real-time через DynamoDB Streams + Kinesis Firehose + Glue

2) Amazon Alexa BI: Role Data Engineer, работал с Product Managers, SDE и BIE
- Внедрение ETL Matillion ETL
- Создание тестовой/боевой системы в ETL и DW (Amazon Redshift)
- Оптимизация Tableau Data Sources (в среднем по 150млн строк было в одном data source)
- Разработка новой платформы для Alexa c названием Sputnik. С использованием новых нод Redshift RA3. Объем данных планировался 120ТБ в год.
- Работал вместе с Data Science над созданием Alexa Churn модели; моя задача была масштабировать модель и подготовка данных на AWS SageMaker

3) Amazon Customer Behaviour Analytics: Role Data Engineer, работал с ML, Data Science + Product Managers
- создание Big Data системы для ML модели. По сути задача системы была - feature engineering, нужно было процедить 700ТБ данных за год (clickstream + backend). Использовали EMR+Spark, логика была на SparkSQL и иногда Scala.
- моя задача была автоматизация всей этой истории, ее безопасность, privacy (GDPR и тп), и качество данных через Spark библиотеку deeque
- Дальше они уже сами брали данные через GPU EC2 instance и строили нейронную сеть (deep learning)

4) Microsoft Xbox game studios: Role Sr. Data Engineer, работаю с BIE, ML, Producers (вместо Product Managers), Artists (designers) и инженерами (SDE).
-моя задача создать новую платформу под новую игру, планирую делать Delta Lake на Databricks (активно изучаю)
-сейчас пока все на HDInsight+Hive (процессинг сырых данных) + SQL Server (dimensional model)
-дашборды в Power BI (который я не люблю после Табло)
-также для операционной аналитики Azure Data Explorer (аналог Splunk и Elastic Search)
-активно используем Azure DevOps (Git + Pipelines) и Microsoft Visual Studio в качестве IDE. Разбираюсь в CI/CD, очень крутая тема конечно, но надо время, чтобы въехать."

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

В дополнение видео от Димы о его 5-летнем опыте работы в Amazon.

Продолжаем нашу серию мини-интервью со специалистами по работе с данными.

Сегодня у нас 2 мини-сводки по структуре data teams от Антона Брызгалова и Адиля Хаштамова.

Мне очень понравилась статья Антона на Tproger о том, как он построил решение для стриминга данных на Yandex Cloud и по факту сделал собственный трекер событий для сайта и чат-ботов. Как оказалось, Антон - очень опытный специалист, который успел поработать в Яндексе и сейчас работает в роли Senior Data Engineer в компании KaiOS Tech.

Адиль - опытный разработчик и data engineer, автор Telegram-канала об инжиниринге данных, который я с удовольствием читаю и всем рекомендую. В последнее время был техническим лидом команды автоматизации маркетинга в компании Playrix.

Вот, что ребята рассказали про структуру команд в их компаниях:

Антон Брызгалов

"Ответить на вопрос проще через хронологию развития команды. Когда компания задумывается об извлечении пользы из данных, сначала нанимают аналитика (Data Analyst) или датасаентиста (Data Scientist). Эти специалисты могут самостоятельно сконвертировать данные в инсайты. Обычно работа этих специалистов business-driven: они выполняют прямые заказы бизнеса, не тратя время на переиспользование результатов работы — это дает гибкость и повышает скорость доставки результатов.

DA/DS как ремесленники: каждый из них талантлив в ручном труде, но чтобы поставить производство на поток, нужен инженер. Когда у данных появляется много пользователей, приходит время наращивать обороты «бизнеса данных» внутри компании. Тогда и появляется Data Engineer, который генерализует наработки аналитиков и датасаентистов, организуя платформу для работы с данными.

DA/DS + DE — это основной набор ролей. Чем больше становится нужда в генерализации подхода, тем больше специалистов появляется: тимлид (Team Lead) для управления командой дата-инженеров как командой разработки, проектный менеджер (Project Manager) для организации процессов, архитектор хранилища данных (роль часто совмещается с тимлидом) для принятия решений о модели данных и технической платформе, системные аналитики (System Analyst) для проектирования сущностей и поддержки знаний о домене, специалисты по Business Intelligence и разного рода аналитики с углубленной экспертизой в каждой отдельной области бизнеса.

Команда данных — это предприятие внутри компании. И оно проходит все стадии от кустарного производства до конвейеров и разделения труда.

Самая крупная аналитическая команда, в которой я работал, была в Яндекс.Такси. На момент, когда я ушел, у нас было 15 инженеров, включая архитектора (тимлида) и системного аналитика, и около 30 аналитиков данных, распределенных между разными направлениями: бизнес, маркетинг, продукт, CRM и пр. Насколько мне известно, сейчас в службе аналитики ЯТ около 100 человек."


Адиль Хаштамов

"Playrix - компания большая, в ней четко выделяются 2 направления касательно анализа данных:

1. Игровая аналитика
2. Маркетинговая аналитика

Для решения задач этих направлений существует департамент IT куда входят команды BI разработчиков, дата инженеры, full stack разработчики.

BI отдел визуализирует данные, создавая множество сложных и не очень дэшбордов. Основной инструмент Tableau.

Команда дата инженеров занимается построением дата пайплайнов, data modeling и отвечет за эффективную работу с данными. Периодически внутри компании проходят т.н. knowledge sharing презентации для улучшения коммуникации, т.к. все работают удаленно.

Full stack разработчики создают внутренние сервисы для автоматизации процессов, закрытые внутренние продукты для игровой и маркетинговой аналитики."

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

Рекомендую подписаться на канал "Data online events & Moscow meetups". Он посвящен мероприятиям по Big Data, Machine Learning, Data Science, Data Engineering, BI/DWH и другим направлениям, связанным с данными. Мероприятия проходят в Москве и онлайн.

Предложить свой ивент можно, написав @NikolayKrupiy, @Ajvol

👉🏻 Подписаться на t.me/data_events

Всем привет.

Продолжаем мини-интервью с опытными специалистами по работе с данными. Своим интересным опытом поделились Олег Агапов (Data Analyst в GOG.com), Николай Валиотти (руководитель компании Valiotti Analytics) и Алексей Макаров (Product Manager в Яндекс Практикум, в прошлом Product Analyst в CoMagic). Немного слов о наших гостях:

Олег Агапов начал писать фундаментальную книгу о data-инжиниринге на GitHub. В ней уже есть 2 главы. Контент действительно достойный и заслуживает внимания. Ещё и на английском:)Также Олег оставил контакт, если кто-то захочет обсудить профессиональные моменты.

Про Николая и его компанию я узнал из выступления на Матемаркетинг 2020, где Николай рассказал про кейс построения end-to-end аналитики на Amazon Web Services с использованием ClickHouse и Kafka. Очень классный кейс, который можно позаимствовать при построении аналитики для мобильного стартапа. Также было интересно услышать от него о структуре его команды, как от руководителя. Ещё Николай ведёт интересный канал про данные и аналитику LEFT JOIN.

Про Алексея я узнал, подписавшись на его крутой канал, где он пишет про анализ данных с использованием языка Python. Если вы аналитик и хотите выйти на advanced уровень, то вам обязательно стоит на него подписаться.

Теперь переходим к самим интервью.

Олег Агапов:
"У нас в команде:
- 3 аналитика включая меня (отчеты, метрики, дашборды)
- 2 дата инженера (поддержка и настройка инфраструктуры и тулзов)
- 1.5 архитектора (создание инфраструктуры, создание внутренних инструментов)

Команда молодая, только прошлым летом набрали аналитиков и инженеров, до этого всё делал в основном сам. Мы набирали в команду фул-стек аналитиков, которые могут всё (почти) если понадобится. Поэтому чёткого разграничения по обязанностям нет, аналитики могут писать агрегации, инженеры могут делать дашборды.

Из проблем. У нас пока нет чёткого тим лида, кто будет авторитарно решать куда будет развиватся команда. Авторитарного именно в плане стратегии, а не тактики типа "будем всё писать на R".

Из достоинств. Намечаются доменные области, которые могут быть закрыты конкретным человеком. Например, есть спец по Табло и бизнесу, есть спец по определенным продуктам компании, тп. Это помогает экономить time-to-deploy (сколько проходит времени от постановки задачи до её выполнения)."

Николай Валиотти:
"В основном мы работаем с различными digital и мобильными стартапами, помогаем им выстроить end-to-end аналитику.
Другими словами, мы работаем со спектром задач от проектирования хранилища / озера данных, построения процессов инжиниринга данных до построения отчетности и иногда даже некоторых моделей машинного обучения.
Персонально я успел поработать в ряде крупных организаций и занимался анализом данных с разнообразным стеком решений, однако в последние годы перед стартом своей компании работал в стартапе, который уже тогда начал работать с так называемым modern data stack. Меня это невероятно увлекло и вдохновило на то, чтобы и другие компании могли компетентно использовать современные облачные решения и получать максимальную пользу от собственных данных.
Мы в некотором смысле стартап (по духу), хотя, конечно, больше развиваемся как традиционная консалтинговая компания. У нас небольшой штат сотрудников и соответствующих ролей, о которых речь пойдет дальше.
Поскольку работаем параллельно с несколькими проектами одновременно бОльшая часть команд кросс-функциональна, что означает, что в каждом проекте есть выделенный сотрудник, который лидирует по проекту, а другие коллеги функционально помогают ему в достижении поставленной цели.

Среди наших сотрудников имеются:
Data Engineer - работы с построением архитектуры хранилища, среди инструментов Kafka, Airflow, среди СУБД: BigQuery, Redshift, Clickhouse, Redshift, Vertica, MySQL, разумеется, SQL и Pythoh.
Analytics Engineer - работы с инструментов dbt, построение моделей данных в Looker, работа с Python для обработки данных, естественно, SQL
2x Data Analyst - мы используем ряд инструментов в зависимости от потребностей и возможностей заказчика: Tableau, Looker, Redash, PowerBI и Metabase, ребята умеют работать в этих инструментах и естественно используют SQL. Ряд задач, например, построение классификационных моделей мы строим с использованием Python, используем Jupyter, в некоторых случаях Collab.
2x Junior Data Analyst - помогают более старшим аналитикам и решают более маленькие кусочки задач с тем же стеком технологий.

В будущем планирую выстраивать организационную структуру, поскольку найм сотрудников горизонтально все-таки невозможен бесконечно и система из более 7 человек будет работать неэффективно"

Алексей Макаров:
"Сейчас я работаю в Яндекс.Практикуме, тут я продакт на факультете данных и занимаюсь развитием программы обучения, а с непосредственно аналитикой пересекаюсь не много

Ну у нас в CoMagic была очень небольшая команда по работе с данными. По факту аналитики нанимались под определенные функциональные направления. Например, отделу маркетинга нужен аналитик — они нанимали себе аналитика, который занимается маркетинговой аналитикой или подготовкой каких-то маркетинговых материалов на основе данных. Также и с продуктовой аналитикой — созрела необходимость в поддержке принятия решений среди продукт-менеджеров, нанимают продуктового аналитика. Единой аналитической команды таким образом не формируется, нет Head of Analytics, скорее каждый Head of Something нанимает себе отдельного аналитика. В этом плане аналитическая культура в CoMagic была слабоватой, так как не обеспечивается обмена знаниями

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

Были также чуваки, которых называли базистами. Это что-то типа DBA с крутыми скиллами разработки. У нас в основном везде был PostgreSQL и вот эти чуваки занимались его шардированием, ускорением запросов, подготовкой запросов под какие-то продуктовые задачи и т.д."

Сегодня у нас ещё одно интересное мини-интервью с Романом Буниным - руководителем команды визуализации данных в Яндекс Go.

Роман рассказал про структуру команды и как устроена работа с данными. Получилось интересно)

У Романа есть сайт и телеграм-канал, где он делится лайф-хаками визуализации данных, пишет про развитие BI-систем и, в частности, про Tableau. Рекомендую всем BI-разработчикам и всем, кто работает с визуализацией данных. Научитесь продуктовому подходу к построению дашбордов.

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

Яндекс имеет сильную data-driven культуры, поэтому в Go мы обслуживаем более 800 бизнес-пользователей, которые используют данные для принятия решений.

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

Чтобы помогать им работать с «технической» частью есть инфраструктурные команды: команда Data Management Platform, команды внутренних инструментов и моя команда по визуализации:
— DMP создает инструменты по работе с данными и новые низкоуровневые витрины данных. В их рядах дата-инженеры, партнеры по данным и системные инженеры.
— Команды внутренних инструментов разрабатывает библиотеки для питона, модели и инструменты прогнозирования, платформы для проведения A/B-тестов и системы аналитики в реальном времени. Здесь очень много разных ролей — от фронт-энд разработчиков до ML-инженеров.
— Моя команда помогает аналитикам делать правильные дашборды — мы обучаем и консультируем по работе с Табло, создаем темплейты и стайлгайды, налаживаем процессы управления контентом и делаем самые важные и большие отчеты. У нас в команде BI-разработчики и менеджер продукта.

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

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

И сегодня у нас последнее мини-интервью с Сергеем Брылем - Chief Data Science Officer в MacPaw. У Сергея есть телеграм-канал @analyzecore и блог https://www.analyzecore.com, где он в основном пишет про анализ данных, Data Science и визуализацию с использованием языка R.

Сергей Брыль:
"MacPaw мультипродуктовая компания, в текущем портфеле есть 10 продуктов, которые представлены на различных платформах. Поэтому, продуктовая аналитика для нас является ключевой экспертизой, а продуктовые аналитики - ядром команды аналитики.

На данный момент мы развиваем 6 направлений, которые входят в структуру Data Science Department. Важность и независимость аналитической функции в компании обеспечивается через то, что я представляю ее интересы на уровне Executive team.

Product Analytics. Мы пришли к выводу, что продуктовая аналитика должна быть глубоко интегрирована в продуктовую команду. С самого начала аналитики должны помочь разработать показатели успеха продукта, измерять прогресс и помогать выявлять риски и области роста для бизнеса. Более того, их понимание, основанное на данных, должно быть постоянным вкладом в разработку продукта. Функционально они подчиняются Chief Data Science Officer, а линейно - соответствующим продуктовым менеджерам.

Такой тип организационной структуры дает нам возможность:

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

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

С другой стороны, такая структура предполагает достаточно высокие требования к продуктовым аналитикам как в hard, так и soft skills.

Другие направления построены на специализированной глубокой экспертизе и в организационной структуре представлены в виде сервисов (или экспертных центров).

DataHub - тут сосредоточена наша data инженерная экспертиза. Команда DataHub делает возможной тонко-настраиваемую аналитику с помощью кастомных технических решений и интеграций с продуктами и сервисами.

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

AI Lab. Миссия команды повышать эффективность процессов и ежедневных решений с помощью Machine Learning.

Этот сервис отвечает за два вектора развития:

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

Market & Customer/User Research - сервис, который дает нам аналитику из внешнего мира о:

- рынках и аудиториях, их особенностях
- пользовательском опыте

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

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

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

Что касается организационной структуры направления, мы достаточно гибкие и готовы к быстрым изменения. Постоянно проверяем все ли работает как мы задумывали и, при необходимости, внедряем изменения."

Всем привет. На этих выходных хочу закончить разбор всех 4-х факторов эффективности работы компании в целом и data team, в частности.

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

Исходя из всех интервью можно сделать такие выводы:
- Структура команды зависит от 2-х главных факторов: уровень развития data-driven культуры и размер компании. Именно в такой последовательности, так как без культуры работы с данными большие компании не будут уделять должное внимание аналитической функции и структуре.
- Команда по работе с данными - это предприятие внутри предприятия. Т.е. подразделение, отвечающее за данные и аналитику переживает такие же стадии развития, как обычное предприятие (при условии развития, конечно): сначала оно имеет в своём штате небольшое количество сотрудников-универсалов, назовём их full-stack аналитиками, которые самостоятельно могут собрать данные, обработать их, визуализировать, проанализировать и сделать выводы из них. По мере развития компании, увеличивается количество бизнес-процессов и данных. Необходимо использовать более сложные технологии, в которых нужно иметь глубокую экспертизу. Становится очень проблематично одному специалисту быть экспертом во всех сферах (инжиниринге, аналитике и data science). Поэтому команда плавно расширяет штат и переходит к разделению труда.
- Работа с данными стала мейнстримом сравнительно недавно, поэтому сложно сказать, какая структура команды наиболее эффективная. Многие компании довольно гибкие в этом плане и методом проб и ошибок, экспериментами нащупывают наиболее подходящую под их бизнес-нужды структуру.

Получилась очень классная рубрика. Думаю, в будущем сделаем интервью и на другие темы)

P.S. Завтра опубликую пост о последнем факторе и начнём двигаться уже к техническим концепциям и конкретным инструментам.

Заканчиваем цикл постов о 4-х факторах эффективности работы компании и подразделения по работе с данными, в частности. И сегодня пост посвящён последнему 4 фактору - "Система единых взглядов и ценностей".

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

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

Из этого всего я сделал один вывод: людей недостаточно раскрывают на собеседованиях. Компания попросту теряет деньги, выплачивая им зарплату на испытательном сроке, и весь процесс найма сотрудника нужно начинать сначала. При этом коллеги уже загибаются от нагрузки и начинают выгорать от работы. В общем последствия неправильного найма могут быть очень неблагоприятными.
Безусловно, не будет такого, что в 100% случаев вы будете нанимать нужных вам людей, для этого и даётся испытательный срок, чтобы удостовериться в сотруднике. Но определённо нужно стремиться к уменьшению % сотрудников, которые не проходят ИС. Это очень важный процесс, который определяет эффективность и экспертизу рекрутинга в компании и её менеджмента.
Поэтому, я считаю, даже к junior-специалистам нужно предъявлять высокие требования по софт-скиллам и постараться их раскрыть на собеседованиях, насколько это возможно. Дообучить человека, который не владеет каким-то конкретным инструментом, можно в относительно короткий срок (при наличии базовых знаний). А вот изменить способ мышления - это долгая и кропотливая работа, которая, в первую очередь, зависит от самого человека. У вас, как руководителя, есть заботы по улучшению качества продукта и процессов. И уделять кучу внимания изменению способа мышления и характера сотрудника, как минимум странно.

Теперь о том, как по моему мнению можно усовершенствовать процесс найма.

Можно выделить 4 основные ценности, которым стоит следовать компаниям, отдельным подразделениям и отдельным сотрудникам для эффективной работы:

1) Бизнес-ориентированность
2) Честность между людьми внутри компании
3) Проактивность
4) Постоянное стремление к саморазвитию

Как по мне, можно строить процесс собеседования кандидатов, опираясь на эти 4 ценности.