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

ТЗ на API: что написать, чтобы разработчик не придумывал за вас

Однажды я получила от разработчика готовый эндпоинт, который работал. Технически. Но в таком формате, что фронт не мог его использовать без дополнительного преобразования. Когда спросила почему — пожал плечами: “в ТЗ не было написано как, я сделал как удобнее”.

И знаете что? Он был прав.

С тех пор у меня есть чеклист того, что обязательно должно быть в ТЗ на API. Делюсь.

1️⃣ Название и назначение

Не “создать API для заказов”, а конкретно:

Эндпоинт: Создание заказа
Используется: мобильное приложение, личный кабинет
Контекст “кто вызывает” влияет на авторизацию и требования к нагрузке.

2️⃣ Метод и URL

POST /api/v1/orders

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

3️⃣ Авторизация

Bearer token (JWT)
Authorization: Bearer {token}

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

4️⃣ Тело запроса

Каждое поле с типом, обязательностью и ограничениями:

{
"userId": 123, // integer, обязательное
"items": [...], // array, обязательное, min: 1
"comment": "..." // string, необязательное, max: 500
}

Для необязательных полей — что происходит если не передали? Дефолт? Игнорируется? Напишите явно.

5️⃣ Ответ при успехе

HTTP 201 Created
{
"orderId": 789,
"status": "created",
"createdAt": "2026-06-17T10:00:00Z" // UTC, ISO 8601
}

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

6️⃣ Ошибки — то, что забывают в 80% ТЗ

422 - Не передан обязательный параметр
404 - Пользователь не найден
401 - Нет авторизации
409 - Товар недоступен

Для каждого кода — тело ответа с понятным error code. Договоритесь о едином формате ошибок на весь проект и зафиксируйте один раз.

7️⃣ Бизнес-логика

Самое недооценённое. Структура понятна — но что происходит внутри?

Пишите явно: заказ создаётся только если все товары в наличии, после создания резервируется остаток, уходит email-уведомление. Если этого нет в ТЗ — разработчик придумает сам. Иногда угадывает. Чаще нет.

8️⃣ Нефункциональные требования

Таймаут: не более 2 секунд
Нагрузка: до 100 запросов в минуту

Если нужна защита от дублей — опишите механизм явно через Idempotency-Key в заголовке. Само собой не появится.

Хорошее ТЗ — это не формальность. Это единственный способ получить то, что вы имели в виду, а не то, что разработчик имел в виду за вас 🙂

🧐 Если было полезно, ставьте реакции, буду делиться больше такой информацией))

___________

Источник: @ba_and_sa

🔥 Приглашаем на бесплатный открытый вебинар курса «Микросервисная архитектура»:

«RabbitMQ против Kafka — что выбрать для вашей структуры: сравнение и лучшие практики»

🗓 Когда: 24 июня, 20:00 (мск)

🚀 О чём этот урок? Обзор двух ведущих решений для работы с брокерами — RabbitMQ и Kafka. Разберём их основные особенности, преимущества и недостатки, а также рассмотрим реальное использование ключей. Вы узнаете, как выбрать тот или иной инструмент в зависимости от требований вашей системы, и дадите рекомендации по их внедрению и настройке для повышения производительности и надежности

Что будет на вебинаре:
— Обзор RabbitMq - устройство, принципы работы, отправка и получение сообщений
— Обзор Kafka - устройство, принципы работы, отправка и получение сообщений
— Сравнение этих двух систем

👉 Зарегистрируйтесь https://clck.ru/3UK8ug

Бесплатное занятие приурочено к старту курса «Микросервисная архитектура», обучение на котором позволит освоить микросервисы: Docker, Kafka, API и стать мастером производительных систем.
🎁Бонус при покупке курса - мини-курс от платформы Алгокод с подготовкой к собеседованиям по System design.

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

Плохое ТЗ — это не вина одного человека. Это результат работы команды

⏳ 10 мини | 🟡⚪️⚪️

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

🔥 Приглашаем на бесплатный открытый вебинар курса «Высоконагруженные системы: архитектура и масштабирование»:

«Асинхронная обработка данных в высоконагруженных системах»

🗓 Когда: 16 июня, 20:00 (мск)

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

Что будет на вебинаре:
— Зачем и когда переходить на асинхронную обработку данных в высоконагруженных проектах
— Очереди сообщений, веб-сокеты и другие инструменты асинхронного взаимодействия
— Реальный архитектурный кейс: от веб-сервера до брокера сообщений и базы данных
— Типичные узкие места асинхронных систем и проверенные способы их устранения

👉 Зарегистрироваться: https://clck.ru/3UBpHU

Бесплатное занятие приурочено к курсу «Высоконагруженные системы: архитектура и масштабирование», где вы научитесь проектировать высоконагруженные системы, способные выдерживать экстремальные нагрузки и работать стабильно в любых условиях.

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

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

Теневая система: как компании управляют своим описанием вместо себя

⏳ 10 мин | 🟡🟡⚪️

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