Analyst IT

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

На открытом уроке 20 октября в 20:00 МСК разберем основные возможности SQL на практических примерах. Вы вместе с экспертом напишете реальные запросы, разберете бизнес-кейс и увидите, как аналитик работает с данными.

Урок проходит в преддверие старта курса «Аналитик данных». Занятие подойдет начинающим аналитикам, студентам и специалистам, которые хотят уверенно работать с данными в аналитике продуктов, маркетинге, финансах и отчетности.

Освойте инструменты, которые помогут перейти от таблиц к полноценному анализу данных: https://clck.ru/3WQBpU

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Токсичная команда — кто бывает токсичнее всего и как с этим жить

Салют! Про токсичных заказчиков мы уже говорили. Но честно — иногда заказчик милейший человек, а вот внутри команды такое творится что хочется сменить не проект а город.
Расскажу про типы которые встречала лично. И сразу скажу: токсичность в команде бьёт по аналитику особенно сильно — потому что мы работаем со всеми одновременно и деваться особо некуда.

1️⃣“Разработчик который считает аналитика лишним звеном”

Классика жанра. Человек искренне убеждён что требования — это лишняя бюрократия и он сам прекрасно разберётся что нужно заказчику. Задачи берёт напрямую, документацию игнорирует, на встречи по требованиям приходит с видом “зачем я здесь”.

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

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

2️⃣ “Коллега-аналитик который тянет одеяло”

Бывает когда аналитиков на проекте несколько. И один из них активно присваивает чужие идеи, подрезает зоны ответственности, на встречах с руководством говорит “я сделала” там где правильнее было бы “мы сделали”.
Это особенно больно потому что предаёт человек со стороны — тот кто должен быть союзником.

Что помогало: фиксировать своё авторство письменно и своевременно. Отправила предложение — в письме, с датой. Провела анализ — задокументировала с именем. Не из паранойи, а как рабочая гигиена. И никогда не выяснять отношения публично — только один на один и спокойно.

3️⃣ “Саботажник”

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

Это самый сложный тип — потому что его токсичность невидима. Формально не к чему придраться.

Что помогало: выяснить причину. Саботаж почти всегда про страх — потерять влияние, привычный процесс, статус. Один честный разговор тет-а-тет иногда решал больше чем месяц борьбы. Не всегда — но попробовать стоило всегда.

4️⃣ “Вечно негативный”

Любая идея встречает “это не сработает”. Любое решение — “мы уже пробовали, бесполезно”. Любое изменение — “опять за своё”.
Сам ничего не предлагает. Но чужие инициативы топит с завидной регулярностью.

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

Что помогало: не спорить на общих встречах. Задавать вопрос: “Хорошо, это не сработает — а что по-вашему сработает?” Переводить энергию скептицизма в конструктив. Иногда получалось — оказывалось что за вечным негативом прячется человек с реальным опытом и болью от прошлых неудачных проектов.

5️⃣ “Звезда”

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

С такими людьми сложно потому что они часто правы технически. Это даёт им уверенность что можно не считаться с остальными.

Что помогало: апеллировать к их же логике. Не “ваш подход неправильный” а “помогите понять — вот этот сценарий ваш вариант покрывает?” Звёзды любят демонстрировать экспертизу — используйте это. Пусть объясняют. В процессе объяснения часто сами находили слабые места.

Кто токсичнее всего — если честно

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

А с какими токсиками работали вы? Или может кто-то ту сам токсик?

Источник: @ba_and_sa

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

3 августа в 20:00 OTUS проводит открытый урок «Использование брокера сообщений Apache Kafka в распределённых очередях» — в преддверии старта курса «Микросервисная архитектура».

На вебинаре вы разберёте архитектуру Kafka, освоите принципы работы распределённых очередей и лучшие практики интеграции. На практике развернёте кластер Kafka в Docker и проработаете сценарии обмена сообщениями между сервисами.

Урок ориентирован на fullstack‑ и backend‑разработчиков, DevOps‑инженеров, архитекторов ПО и администраторов систем — на всех, кто проектирует масштабируемые решения.

Регистрируйтесь сейчас — чтобы занять место и получить напоминание в день вебинара. https://clck.ru/3V5iEt

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Как использовать Kafka на собеседовании по System Design

⏳ 17 мин | 🟡⚪️⚪️

Читать статью | @analysis_it

4 ошибки в A/B‑тестах, из‑за которых случайный шум выглядит как эффект

⏳ 8 мин | 🟡🟡⚪️

Читать статью | @analysis_it