Analyst IT

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

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

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

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

«Использование брокера сообщений Apache Kafka в распределённых очередях»

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

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

Что будет на вебинаре:
— Архитектура Apache Kafka: брокеры, топики, партиции, consumer groups и как всё это работает
— Принципы работы с распределёнными очередями и event-driven архитектурой
— Практическая настройка и запуск Kafka-кластера в Docker
— Реальные примеры обмена сообщениями между микросервисами
— Лучшие практики интеграции Kafka в проекты: обработка ошибок, exactly-once, схемы, мониторинг и производительность

👉 Зарегистрируйтесь

Бесплатное занятие приурочено к старту курса «Микросервисная архитектура», на котором вы научитесь проектировать по-настоящему масштабируемые, надёжные и современные распределённые системы с использованием Kafka и других ключевых инструментов.

🎁Бонус при покупке курса - мини-курс от платформы Алгокод с подготовкой к собеседованиям по System design.

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

Low-code на честном слове: что первое сломается на масштабе

⏳ 10 мин | 🟡⚪️⚪️

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

Постанализ юзкейсов, или Как спроектировать непрерывную ABAC-авторизацию UI и API.

⏳ 8 мин | 🟡🟡⚪️

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

Как измерить рост производительности команды от внедрения ИИ. Бесплатный урок курса «Руководитель команд в ИТ»

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

На открытом уроке 3 июня в 20:00 разберём, как руководителю команды подходить к внедрению ИИ не на уровне ощущений, а через измеримые показатели. Поговорим об условиях успешного внедрения, способах оценки производительности команды, поиске эффекта именно от ИИ, а не от случайных факторов, и расчёте экономической эффективности. Отдельно обсудим, какие требования стоит выполнить до внедрения, чтобы потом не гадать, помог ИИ или просто добавил ещё один слой инструментов.

Урок не для тех, кто внедряет ИИ «потому что все так делают», не готов считать эффект и хочет заменить управленческие решения покупкой новых лицензий.

👉 Записаться: https://clck.ru/3TxBZe

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

❓Уровень обычного системного аналитика уже не для вас?
Научитесь управлять архитектурой и командой системных аналитиков на курсе «Системный аналитик. Управление командой»

🎁 Записывайтесь на 3 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам!

Вебинар 1: «C4 для системного аналитика: строим единый язык между бизнесом и разработкой»
⏰4 июня в 20:00 мск

Программа вебинара:
Разберём самую простую и мощную модель визуализации архитектуры, которая позволяет за 4 диаграммы объяснять систему бизнесу, разработчикам и команде.

На практике покажем, как использовать C4-модель, чтобы быстро и понятно объяснять систему на нужном уровне детализации — техническим лидерам, разработчикам и менеджменту и решить головную боль — недопонимание между стейкхолдерами — и сразу сможете применять её в требованиях.

Вебинар 2: «Архитектура информационных систем. Монолиты, SOA и микросервисы»
⏰17 июня в 20:00 мск

Программа вебинара:
1. Как выделять архитектурные слои информационной системы
2. Основные компоненты системы и как рисовать компонентные модели
3. Различия явных признаков хорошей и плохой архитектуры
4. Плюсы и минусы монолитной, SOA и микросервисной архитектуры

Вебинар 3: «Внедрение новой функции системным аналитиком на примере услуги на Госуслугах»
⏰24 июня в 20:00 мск

Программа вебинара:
Разбор процесса внедрения новой фичи системным аналитиком. На вебинаре спикер покажет, как проектируются и выводятся реальные сервисы на портал Госуслуг.
1. Сбор требований
2. Моделирование бизнес-процесса
3. Проектирование интерфейса системы
4. Описание компонентов системы
5. Настройка форм для госуслуг
6. Настройка печатных форм
7. Проектирование базы данных
8. API
9. Интеграция систем

Записывайтесь ➡️ OTUS.RU
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Заметки для новичка: Как провести первую ретроспективу и не облажаться?

⏳ 4 мин | 🟡⚪️⚪️

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

ИИ разработке нужны не спецификации, а полноценная трассировка требований

⏳ 9 мин | 🟡🟡⚪️

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

🦾 Препарируем рекомендательные системы методами машинного обучения

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

Вы не просто послушаете теорию, а соберёте свою первую рекомендательную модель.

👨‍💻🛠👨🏻‍💻 Урок подойдёт тем, кто начинает путь в машинном обучении и хочет разобраться в одной из самых востребованных задач.

Встречаемся 20 мая в 18:00 МСК в преддверии старта курса «Машинное обучение. Специализация».

➡️ Принять участие бесплатно: https://clck.ru/3Ti422

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

«Боргворглер: боргает ворглер», или как сделать действительно полезную документацию к проекту

⏳ 8 мин | 🟡⚪️⚪️

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

Почему проекты превращаются в спагетти даже у хороших программистов

⏳ 4 мин | 🟡🟡⚪️

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

Об организации труда ИИ-агентов

⏳ 32 мин | 🟡🟡⚪️

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