Имитационное моделирование: что это такое и с чем его едят

⏳ 5 мин | 🟡⚪️⚪️

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

💙 Analyst IT | 💬 Analyst IT

Как ИИ изменил собеседования для аналитиков — и что теперь с этим делать

Недавно разговаривала с коллегой которая проводит технические интервью в крупной компании. Говорит:

“Мы перестали задавать вопросы на знание инструментов — бессмысленно. Все приходят подготовленные одинаково хорошо и одинаково поверхностно.”

Я поняла о чём она. ИИ изменил собеседования — причём с обеих сторон стола.

Что изменилось со стороны кандидата

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

Я видела это на собеседованиях, когда сама выступала в роли интервьюера. Человек красиво рассказывает про Event Storming — но когда спрашиваешь “а как вы справились когда ключевой эксперт отказывался участвовать?” — пауза. Потому что ИИ даёт теорию, а живого опыта за ней нет.

Что изменилось со стороны интервьюера

Умные компании это поняли и перестроили формат.

Вот что я вижу сейчас:

1. Меньше вопросов на знание — больше на мышление
“Что такое Use Case?” уже никто не спрашивает. Спрашивают: “Вот размытое требование от заказчика — что будете делать?” Или дают реальный противоречивый документ и смотрят как человек с ним работает.
Знание можно нагуглить. Мышление — нет.

2. Кейсы вместо теории
Всё больше компаний дают домашнее задание: реальная или приближённая к реальной ситуация, которую нужно разобрать. Не “расскажите про BPMN” а “вот процесс — опишите его, найдите проблемы, предложите решение”.
ИИ может помочь с оформлением — но думать за кандидата всё равно не будет. Точнее будет, но интервьюер это увидит.

3. Глубокие вопросы про опыт
“Расскажите про сложный проект” стало стандартом. Но теперь идут вглубь: “А что конкретно вы сделали когда заказчик отверг ваше решение?”, “Как вы убедили разработчиков что требование важное?”, “Что бы вы сделали иначе?”
На такие вопросы ИИ не даст готового ответа — потому что ответ должен быть про вас, а не про аналитика вообще.

🤔 Что это значит для тех кто готовится к собеседованию

ИИ как инструмент подготовки — отлично. Освежить теорию, прогнать термины, подготовить список вопросов которые стоит задать самому — всё это работает.

Но есть вещи которые ИИ не заменит:

1. Реальные кейсы из практики. Если опыта мало — берите учебные проекты, pet-проекты, волонтёрские задачи. Что угодно реальное где были настоящие решения и настоящие проблемы.

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

3. Честность про пробелы. “Я с этим не работала, но вот как бы я подошла к задаче” — это сильный ответ. Гораздо сильнее заученной формулировки которая рассыпается при первом уточняющем вопросе.

‼️ И про другую сторону — как ИИ меняет требования к аналитику

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

Источник: @analysis_it

💙 Analyst IT | 💬 Analyst IT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5️⃣ “Звезда”

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

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

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

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

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

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

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Аналитика начинается не с дашборда: как понять, какое решение должен поддерживать отчёт

⏳ 6 мин | 🟡⚪️⚪️

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

💙 Analyst IT | 💬 Analyst IT

Укрощение зоопарка сервисов: как системный подход одной команды повышает надёжность и скорость разработки

⏳ 16 мин | 🟡⚪️⚪️

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

💙 Analyst IT | 💬 Analyst IT

Салют! Что-то я немного выпала из телеграмной жизни, каюсь 😱 и возвращаюсь))

Сегодня погрузимся в тему sql и я для вас собрала небольшую подборку на тему БД:

- SQL для аналитика

- SQL для начинающих: 10 запросов, которые нужно знать каждому аналитику

- SQL в 2026 для аналитика (с чего начать, где учиться и что реально нужно знать)

- Как изучить SQL за ночь или шпаргалка для системного аналитика

- Проектирование БД и почему важен SQL для системного аналитика: гайд по улучшению качества требований

- Вопросы по SQL для подготовки к собеседованию

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Как найти причину сбоев внешнего API и исправить её до того, как интеграция попадет в прод

⏳ 7 мин | 🟡🟡⚪️

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

💙 Analyst IT | 💬 Analyst IT