Business | System analyst

«Подождём модель поумнее» — не самая грамотная стратегия работы с ИИ, и вот почему

Салют!

Досмотрела выпуск подкаста «Доверительный интервал» про ИИ в аналитике — там прозвучала мысль, которую я бы распечатала и повесила над монитором каждому, кто мыслит так: «вот выйдет суперумная модель — тогда и начну юзать ИИ».

По факту работать со слабыми моделями полезно: на них оттачивается главный навык — чётко объяснять контекст. Если этого навыка нет, умная модель не спасёт. Слабая на плохом контексте просто ошибётся — и ты это заметишь. Умная ошибётся красиво и уверенно — так, что ты ей поверишь. 

🧐Поэтому контекст — это не «написать промпт подлиннее»

Важно не просто формулировать задачу, а формализировать сам контекст. Это тоже затронули в подкасте — и вот как это выглядит на практике в Яндексе: 

1️⃣ База знаний аналитики. Описанные данные, метаданные, методологии расчёта метрик, уже построенные дашборды. Первые ~70% базы наполнила команда внедрения, дальше аналитики сами докидывают свои скиллы и контекст. То есть это живой репозиторий, а не вики, которую один раз написали и забыли.

2️⃣ Golden Set и канонические SQL-запросы. Эталонные запросы и каталог метрик, на которые агент опирается, а не выдумывает с нуля. По сути — ответ на главную боль: «модель написала SQL, который выглядит рабочим, но считает метрику не по нашей методологии».

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

4️⃣ Инфраструктура подключения. Единый интерфейс, который через MCP цепляется к внутреннему репозиторию, трекеру и вики — и новому сотруднику команда «learn» просто устанавливает весь набор скиллов разом. Онбординг аналитика в контекст команды стал скриптом, а не тремя месяцами расспросов коллег.

❗️ Что из этого следует лично для нас

Умение работать с агентом — это скилл выписать из своей головы то, что ты держал там годами: какие данные брать, по какой методологии считать, где лежит описанная таблица, а где — бизнес-договорённость, о которой знают два человека в команде.

Знакомо? Это ровно то же самое, что ставить задачу джуну или подрядчику. С людьми мы понимаем: «ну он же не телепат, ему надо объяснить». А от модели многие почему-то ждут подобной магии.

А вы уже описываете контекст для инструментов — или всё ещё держите его в голове?

Самый ценный специалист в ИТ и бизнесе

Если разработчик пишет код, а тимлид управляет задачами, то кто решает, как вообще должна быть устроена компания и её ИТ-инфраструктура, чтобы бизнес достигал своих целей?

Корпоративный архитектор. Он создаёт единый механизм, в котором ИТ, стратегия, процессы и данные не противоречат друг другу и приносят компании реальную прибыль. Отсюда — прямой выход на собственника и доход от 500 000 ₽ в месяц.

Вырастите из технаря в стратега за 4 месяца на курсе «Корпоративный архитектор» от Академии Эдюсон. Это комплексная программа для смены роли — с упором на практику, работу с метриками и новыми инструментами.

После курса вы сможете реально влиять на бизнес:
• Спроектировать единую ИТ-архитектуру по международным стандартам (включая TOGAF и ArchiMate).
• Интегрировать нейросети в процессы и автоматизировать работу компании.
• Защищать ИТ-решения перед топами на языке денег — с упором на метрики, финансы, оргдизайн и стратегию.

Также получите шаблоны и инструкции для решения задач + удостоверение о повышении квалификации в финале.

Оставьте заявку с промокодом АРХИТЕКТОР — заберите курс с персональной скидкой.

Реклама. ООО «ЭДЮСОН» ИНН 7729779476. erid: 2W5zFGNbRMT

Нотация C4: полный гайд по моделированию архитектуры с примерами, разбором ошибок и промптом для ИИ

⏳27 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

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

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

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

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

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

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

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

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

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

SQL на собеседованиях спрашивают все. Но зачем он аналитику на самом деле?

Салют! Когда я только пришла в профессию, SQL казался мне чем-то из мира разработчиков. Ну запросы и запросы, это же не моё. Я аналитик, я работаю с требованиями и людьми.

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

После этого моё отношение к SQL изменилось навсегда.

🧐 Почему его спрашивают на каждом собеседовании

Не потому что аналитик будет писать сложные запросы каждый день. А потому что человек, который понимает SQL, понимает как устроены данные — связи между таблицами, почему один показатель может считаться по-разному в зависимости от того как написан запрос.

Это не про синтаксис. Это про понимание системы изнутри.

‼️ Где SQL реально нужен в работе (исходя из личного опыта)

1️⃣ Когда цифры не сходятся. Заказчик говорит пять тысяч пользователей, разработчик говорит три тысячи. Без SQL будете ждать пока кто-то найдёт время разобраться. С SQL — проверите сами за десять минут.

2️⃣ Когда хочешь понять как устроена система. Схема базы данных показывает всё — какие сущности есть, как они связаны, что главное а что вспомогательное. Я до сих пор начинаю знакомство с новой системой именно с этого.

3️⃣ Когда пишешь требования к данным. Понимая как хранятся данные, формулируешь точнее. Не "показывать историю заказов", а "выбирать заказы по userId, отсортированные по дате, исключая удалённые". Разработчику не нужно додумывать.

4️⃣ Когда принимаешь задачу. Разработчик говорит "всё сделано". Пишешь запрос и смотришь реальные данные — не через интерфейс который может скрывать проблемы, а напрямую.

✅ Какой уровень нужен аналитику (в основном мне хватало, но сложные задачи никто не отменял)

SELECT, WHERE, JOIN, GROUP BY, простые агрегаты — этот набор закрывает 80% задач. Остальное по ситуации.

Пример:

SELECT u.name, COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o 
    ON u.id = o.user_id
    AND o.status = 'active'
GROUP BY u.id, u.name
ORDER BY order_count DESC

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

❓ Почему некоторые говорят что SQL им не нужен

Либо они работают там где уже есть готовые дашборды — Power BI, Tableau, Metabase — и данные подготовлены заранее. Такое бывает.

Либо просто привыкли по любому вопросу про данные идти к разработчику. И не замечают насколько от него зависят.
Это не "SQL не нужен". Это "не пробовала разобраться сама".

SQL делает аналитика самостоятельным. Не ждёшь пока кто-то найдёт время ответить — идёшь и смотришь сама. В нашей профессии это и есть ценность.

Если было полезно, ставьте реакции

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Пока вы собираете требования в одиночку, кто-то уже руководит целой аналитической командой...
Узнайте, как управлять командой системных аналитиков эффективно за 5 месяцев обучения вместе с OTUS на курсе «Системный аналитик. Управление командой»

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

1️⃣ 8 сентября, 20:00 мск — «Системный аналитик и его ценность глазами компании»: разберём, как грамотная работа аналитика повышает эффективность команды и продукта, и почему бизнес готов платить за эту ценность.

2️⃣ 23 сентября, 20:00 мск — «Как проводить архитектурное ревью и находить риски до начала разработки»: научимся находить узкие места и точки отказа до старта разработки, чтобы архитектура не рассыпалась при запуске продукта.

Записывайтесь ➡️ OTUS.RU

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

Как выстроить репутацию внутри компании — и почему это не про то, чтобы всем нравиться

Салют! Помню, как на третьем году работы мне сказали, что у меня “хорошая репутация в команде”. Я тогда искренне не понимала, что именно я делаю правильно. Просто работала.
Потом наблюдала, как коллеги с похожим опытом и знаниями получали разные результаты. Одних звали на интересные проекты, другие годами сидели на одном месте и недоумевали почему. Стала думать — в чём разница.
Вот что поняла.

🧐Репутация строится не на том, что вы знаете, а на том, как вы себя ведёте

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

Предсказуемость — это валюта доверия. Накапливается медленно, тратится быстро.

Я это поняла, когда один раз подвела коллегу — не сильно, просто забыла передать важную информацию вовремя. Казалось бы, мелочь. Но именно это он вспомнил через полгода, когда меня рекомендовали на проект. Не со злым умыслом — просто так работает память на негативное.

✅Хорошая работа сама себя не продаёт

Это было самым сложным для меня лично. Я из тех, кто считает, что результат говорит сам за себя. Оказалось — нет.

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

Руководство видит проблемы — они громкие. Хорошую работу не видит — она тихая.

Я не стала хвастаться. Но начала делать работу видимой: короткий статус по проекту раз в неделю без запроса, после закрытия этапа — два абзаца, что сделано и что это дало проекту. Маленькие вещи — но руководитель перестал узнавать о моей работе только тогда, когда что-то шло не так.

❌Кризис — лучший момент для репутации

Парадокс, который я поняла на собственном опыте: люди запоминают не то, как вы работаете, когда всё хорошо. Запоминают то, как вы ведёте себя, когда плохо.

У меня был проект, где мы просели по срокам. Частично моя недоработка — не докопалась до одного требования, которое потом вылезло и всё усложнило. Я пришла к руководителю сама, раньше чем он узнал из другого источника. С разбором того, что случилось, и с планом, как выправляем.

Было страшно. Но именно после того разговора отношение изменилось в лучшую сторону — не потому что всё было хорошо, а потому что я не спряталась.

Прятаться, когда плохо — худшее, что можно сделать для репутации. Все это замечают.

🤓Разработчики — недооценённый источник репутации

Мало кто думает об этом целенаправленно. А зря.

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

Я однажды спросила разработчика напрямую: что в моих документах мешает работать? Он опешил — видимо, никто раньше не спрашивал. Потом рассказал несколько вещей, которые я поменяла и которые реально ускорили нашу совместную работу. И стал одним из тех, кто меня рекомендовал на следующий проект.

📈 Горизонтальные связи работают дольше, чем вертикальные

Руководители меняются. Компании реструктурируются. А люди, с которыми вы работали — уходят на другие проекты, в другие компании и берут с собой воспоминание о вас.

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

Это не расчёт. Просто так устроены отношения — люди помнят тех, кто им помог, когда было сложно.

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

Если было полезно, ставьте реакции

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

ТЗ в 2026 году — писать или не писать?

Салют! Теперь я хочу поделиться своим мнением на счет ТЗ на разработку в наших реалиях.

Знаете что меня до сих пор удивляет? Каждый год кто-нибудь обязательно скажет что ТЗ умерло. Agile победил, итерации рулят, зачем писать документ который устареет через месяц.
А потом тот же человек приходит с горящими глазами: “мы сделали не то, заказчик недоволен, кто виноват непонятно”. И знаете что выясняется? Нигде ничего не зафиксировано.

🥺 Я через это прошла. И не один раз.

Почему ТЗ ругают — и в этом есть доля правды

Классическое ТЗ по ГОСТ — это больно. Двести страниц которые пишутся месяцами, согласовываются вечность и устаревают к моменту подписания. Я видела такие документы. Толстые, красивые, абсолютно мёртвые — потому что никто их не читал. Включая тех кто писал.
Но проблема не в самой идее фиксировать требования. Проблема в том что ТЗ превратили в ритуал вместо инструмента.

Где без фиксации становится по-настоящему больно

Расскажу один кейс. Проект без нормальной документации — команда договорилась устно, доверяли друг другу, торопились. Через три месяца разработки заказчик увидел результат и сказал “это не то что я имел в виду”. Разработчики показали переписку — там действительно было сказано именно так. Заказчик был уверен что имел в виду иначе.
Кто прав? Оба. И никто. Потому что нигде не было написано однозначно.
Переделки, потраченные деньги, испорченные отношения. Agile тут ни при чём — просто люди не зафиксировали договорённости.

Что писать в 2026 году — конкретно

Не ГОСТ. Но и не “разберёмся по ходу”.

Хорошая документация сегодня выглядит иначе:

- Короче. Ровно столько сколько нужно для однозначного понимания. Иногда десять страниц, иногда три. Объём не равно качество.
- Живее. Документ который обновляется по ходу проекта в Confluence или Notion лучше замороженного артефакта после подписания.
- Конкретнее. Не “система должна быть удобной” а “пользователь создаёт заявку за три шага”. Не “быстрая загрузка” а “страница открывается не дольше двух секунд”.
- С акцентом на главное. Бизнес-цель, ключевые сценарии, критерии готовности, ограничения. Остальное по необходимости.

Когда без серьёзного документа нельзя

Есть ситуации где я бы не взялась за проект без нормального ТЗ:

- Госпроекты и тендеры - там это требование закона
- Фиксированный бюджет и фиксированный скоуп - нет документа, нет защиты ни для кого
- Интеграции с внешними системами - без чёткой спецификации две команды сделают два разных API и удивятся почему не стыкуется
- Высокая цена ошибки - производство, медицина, финансы
Здесь ТЗ не бюрократия. Это единственный способ не потерять деньги и репутацию.

Когда можно обойтись малым

- Внутренний продукт с гибким скоупом и заказчиком который всегда на связи
- Небольшая доработка существующей системы
- Стартап где всё меняется быстро и документ устареет раньше чем его дочитают

Но даже здесь - ключевые договорённости фиксирую всегда. Хотя бы коротким письмом после встречи. Это занимает десять минут и сколько раз спасало - не пересчитать.

Мой честный ответ после двенадцати лет

ТЗ в классическом виде — да, уходит. Но потребность которую оно закрывает никуда не делась.
Людям нужна общая картина. Нужно понимать что строят, зачем, для кого и как поймут что сделали правильно. Нужна точка к которой можно вернуться когда начнутся споры — а они начнутся всегда.

Называйте как хотите — ТЗ, спецификация, product brief, просто нормальный документ. Суть одна: договорённости должны существовать не только в головах участников.
Потому что головы у всех разные. И каждая искренне уверена что всё помнит правильно.

Как у вас на проектах — пишете или обходитесь?
Если пишите, ставьте - 👌
Если обходитесь, ставьте - 🙈

Если нравится тема и пост, ставьте любую из реакций - 🔥♥️👍

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Стоит ли писать ТЗ на разработку в 2026 году и зачем

«Мы не пишем ТЗ, — гордо сказал мне руководитель агентства. — Мы работаем только по Agile». Хочется порассуждать на тему того, нужно ли в 2026 году писать техническое задание на разработку информационного продукта и в каком виде. Или это все замшелые водопадные технологии, которые уже давно прогрессивным разработчикам и вайбкодерам никуда не уперлись.

⏳ 7 мин | 🟤⚪️⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Как повысить зарплату — когда просить и как аргументировать

Салют! Сегодня у нас тема, которую все хотят обсудить, но почему-то стесняются. Давайте без стеснения — потому что умение говорить о деньгах это такой же профессиональный навык как умение писать требования.

Я несколько раз просила повышения за карьеру. Один раз получила отказ. Остальные — да. Расскажу что работало и что нет.

‼️ Сначала про главную ошибку

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

⏰ Когда просить — это важнее чем кажется

Есть моменты когда просить бессмысленно даже если вы объективно заслуживаете:
— Компания только что объявила об оптимизации расходов
— Проект провалился и все ещё разбирают последствия
— Руководитель сам под давлением и решает свои проблемы
— Конец квартала когда бюджеты уже распределены

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

Момент имеет значение. Один и тот же разговор в разное время даёт разный результат.

✅ Как готовиться — конкретно
Соберите доказательную базу

Не ощущения - факты. Что конкретно вы сделали за последние полгода-год?
— Какие проекты закрыли и с каким результатом
— Где нашли проблему до того как она стала дорогой
— Где взяли на себя больше чем было в вашей зоне ответственности
— Что улучшили в процессах команды
Если вы никогда не вели такой список - начните прямо сейчас. Не для руководителя, для себя. Память избирательна, документы - нет.

📈 Изучите рынок

Это обязательный шаг который многие пропускают. Посмотрите hh.ru, Habr Career, телеграм-каналы с вакансиями — сколько платят аналитикам вашего уровня в вашем городе и формате работы.
Если рынок платит больше чем вы получаете — это аргумент. Спокойный, без угроз, но аргумент.

🔢 Сформулируйте конкретную цифру

Не “хотелось бы побольше”. Конкретная сумма или процент. Человек без конкретики воспринимается как неуверенный. Конкретика показывает что вы серьёзно подошли к вопросу.

Как строить разговор
Попросите отдельную встречу - не в конце случайного созвона и не в коридоре. Отдельное время показывает что тема важная.

Структура, которая работала у меня:
- Сначала контекст. Коротко - что вы сделали, какую ценность принесли. Не хвастовство, а напоминание фактов. Две-три минуты максимум.
- Потом запрос. Прямо и спокойно. “Я хочу обсудить пересмотр зарплаты. Я считаю справедливым уровень Х - вот почему.”
- Потом молчите. Это самое сложное. После того как назвали цифру — не заполняйте тишину. Дайте человеку ответить.

Что делать если говорят “не сейчас”
Не уходить с пустыми руками. Задайте два вопроса:
“Что должно произойти чтобы мы вернулись к этому разговору?”
“Когда мы можем к нему вернуться?”
Зафиксируйте ответы письменно - отправьте короткое письмо после встречи. “Договорились вернуться к вопросу в марте после закрытия проекта Х.” Это не давление - это уважение к договорённостям.
Если через обозначенный срок ничего не изменилось - возвращайтесь с этим письмом. Спокойно, без обид.

🧐 Про офферы со стороны

Реальный оффер от другой компании - самый сильный аргумент на переговорах о зарплате. Это рыночная оценка вас прямо сейчас.
Но здесь важна честность с собой: вы готовы уйти если не повысят? Если нет - не используйте оффер как шантаж. Блеф в переговорах о зарплате раскрывается - и доверие потом восстановить сложно.
Если готовы уйти - говорите прямо и спокойно. Не ультиматум, а факт: “Я получила предложение, оно интересное. Но я хочу остаться - давайте обсудим возможности.”

Если было полезно - ставьте реакции)

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5️⃣ “Звезда”

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

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

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

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

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

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

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Токсичные заказчики — типы которые я встречала и как с ними выживать

Салют! За двенадцать лет я работала с самыми разными людьми. Большинство — нормальные, адекватные. Но были и другие. Те после встреч с которыми хочется закрыть ноутбук и уйти в огород.

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

Тип 1. 🥸 “Я всё знаю лучше”

Приходит не с проблемой а с готовым решением. Любые вопросы воспринимает как некомпетентность. Альтернативы не рассматривает.
Самая большая ловушка — начать спорить. Не работает.

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

Тип 2. 😜“Согласую всё и сразу всё меняю”

На встрече кивает, подписывает протокол. Через три дня: “я подумал и хочу по-другому”.
Дело не в том что плохо объясняешь. Человек просто не умеет принимать решения в моменте.

Что помогало: давать фиксированное время на обдумывание до финального согласования — не просто “посмотрите”, а “посмотрите до пятницы 18:00, после фиксируем”. Без конкретного дедлайна некоторые не возвращаются вообще или возвращаются через месяц с полностью новым видением. Количество разворотов после подписания упало в разы.

Тип 3. ‼️ “Всё срочно и всё важно”

Любая задача с пометкой “срочно”. Письма в 23:00. Звонки в выходные. На вопрос о приоритетах: “всё приоритет”.
Главное что поняла: его срочность — это его тревога, не твоя реальность. Не значит игнорировать. Значит не заражаться паникой.

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

Тип 4. 🤔 “Не знаю чего хочу но это не то”

Требования размытые, на прототип говорит “не то” — но объяснить что именно не может. Это не злой умысел — человек искренне не умеет формулировать.

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

Тип 5. 🧐“Через мою голову”

Договаривается с разработчиками напрямую, ставит задачи в обход аналитика. В системе появляется функциональность которая не согласована и иногда противоречит тому что уже сделано.

Решение только одно — проговорить на старте и зафиксировать письменно: все задачи идут через аналитика. Не потому что хочу контролировать, а потому что иначе правая рука не знает что делает левая. Если не зафиксировать в начале — потом не введёшь.

✅ И про главное

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

Если было интересно, ставьте реакции, вам не сложно, мне приятно)))

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Аналитик, или Туда и Обратно: как мы стали «Google на минималках» в мире контейнерной оркестрации

⏳ 7 мин | 🟤⚪️⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Когда документация заканчивается, системный аналитик начинает читать код

⏳ 28 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Как не захлебнуться в User Stories и не утопить в них команду

⏳ 11 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Синдром самозванца у опытных — это уже не страх, это кое-что похуже

Салют! Когда говорят про синдром самозванца — обычно рисуют образ новичка который боится открыть рот на встрече. Узнала себя, подросла, прошло.
Но у опытных специалистов синдром самозванца не исчезает — он мутирует. Становится тише, незаметнее и от этого гораздо опаснее. Я поняла это когда поймала себя на нескольких привычках которые казались абсолютно нормальными. Оказалось — не очень.

Проявление 1. Гиперподготовка

Перед важной презентацией переделывала слайды до часа ночи. Не потому что они были плохими — потому что внутри сидел голос: “а вдруг спросят то что не предусмотрела?”
Гиперподготовка маскируется под профессионализм. На самом деле это тревога которая ищет контроль. И она съедает время и энергию которые можно было потратить на что-то реально важное.

Проявление 2. Присваивать успех команде, а провалы — себе

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

Проявление 3. Синдром “ещё одного курса”

“Вот пройду курс по архитектуре — тогда буду достаточно компетентна.” “Получу сертификат — тогда смогу претендовать на повышение.”
Я однажды посчитала: за два года прошла семь курсов. При этом несколько раз отказалась от интересных проектов потому что “ещё не готова”. Курсы были. Готовность не наступала — потому что дело было не в знаниях.

Проявление 4. Преуменьшение своей экспертизы

“Ну, я не эксперт конечно, но…” “Могу ошибаться, но…” “Это просто моё мнение…”
Когда человек с десятью годами опыта начинает каждый второй тезис с подобных оговорок — это уже не вежливость. Я ловила себя на этом постоянно. Внутри всё знала, снаружи звучала неуверенно. И люди считывали именно неуверенность, а не экспертизу.

Проявление 5. Избегание видимости

Не брать сложный проект — “там и без меня справятся”. Не предлагать идею — “наверное это всем очевидно”. Не откликаться на вакансию — “я не дотягиваю до всех требований”.
Это самое дорогостоящее проявление. Цена здесь вполне конкретная: проекты которые не взяла, идеи которые не высказала, карьерные шаги которые не сделала.

❗️Почему это сложнее лечится чем у новичков

У опытного специалиста все эти проявления выглядят как черты характера. Окружающие не видят проблемы — иногда даже хвалят: “такой ответственный человек”, “никогда не хвастается”. А внутри всё тот же голос который говорит что ты недостаточно хороша. Просто научившийся говорить тихо.

✅ Что с этим делать

Первый шаг — увидеть конкретные привычки, а не абстрактный диагноз.

Второй шаг — разделить тревогу и реальность. “Я недостаточно компетентна” — это ощущение. “Я десять лет успешно веду проекты” — это факт. Верить стоит факту.

Третий шаг — действовать не дожидаясь уверенности. Она не приходит до действия. Только после. Это контринтуитивно — но это правда которую я проверила на себе много раз.

Если было полезно, ставьте реакции 😉

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Стать аналитиком данных всего за 10 недель — это реально!

Если вы давно смотрите в сторону аналитики или хотите войти в профессию системно, а не одной ногой — сейчас самый подходящий момент.

Симулейтив — школа аналитики, где обучают через практику и реальные кейсы, запускает абсолютно новый курс-буткемп - Профессия «Аналитик данных».

Курс разделен на 2 этапа, за первые 10 недель вы обучаетесь аналитике и доходите до уровня junior-специалиста. А на втором этапе проходит углубленное изучение, где изучаете продвинутые инструменты и новые навыки.

Что вас ждет на курсе:
➖SQL, Python, BI (Metabase + Power BI), статистика, A/B-тесты и продуктовые метрики;
➖Живые занятия с ментором каждую неделю — не записи, а разборы вживую;
➖Подготовка к собеседованиям с первых недель, а не в самом конце;
➖ИИ-инструменты как часть программы — учите работать с ними, а не избегать;
➖Гостевые лекции от аналитиков из Яндекса, Т-Банка, Авито, Сбера, OZON;
➖Официальный диплом о профессиональной переподготовке.

Кому подойдёт:
1. Тем, кто хочет войти в аналитику с нуля — опыт в программировании не нужен;
2. Тем, кто пробовал учиться самостоятельно, но теряет темп без структуры;
3. Тем, кто хочет сменить профессию быстро, а не за год.

🔥ВАЖНО: Симулейтив сейчас дают возможность получить грант на обучение и гарантию трудоустройства своих студентов! Количество грантов, ограничено!

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

🔗 ЗАБРОНИРОВАТЬ МЕСТО

Синдром самозванца в профессии аналитика — как я с этим жила

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

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

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

может я не на своём месте? Может настоящий аналитик должен всё это знать?

Спойлер: не должен. Но тогда я этого не понимала.

Характерные симптомы которые я у себя замечала:
— Боялась задавать “глупые” вопросы на встречах
— Переписывала письма по десять раз прежде чем отправить
— Когда что-то получалось хорошо - думала что просто повезло
— Когда что-то шло не так - была уверена что это только моя вина
— Сравнивала себя с коллегами и всегда была не в свою пользу

Откуда это берётся в нашей профессии
Аналитик работает на стыке всего. Нужно понимать бизнес, технологии, процессы, людей. Область знаний бесконечная — всегда найдётся что-то чего ты не знаешь.
Плюс наша работа во многом невидима. Разработчик написал код — вот результат. Дизайнер сделал макет — вот результат. Аналитик провёл десять встреч, вытащил требования, предотвратил три конфликта — и что? Требования это не код, их не потрогаешь.
Когда результат работы сложно измерить — мозг начинает сомневаться: а была ли вообще ценность?

Что реально помогло

1️⃣ Разрешила себе не знать всего
Звучит банально. Но мне реально пришлось внутренне договориться с собой: я не обязана знать всё про архитектуру, про DevOps, про финансовую модель заказчика. Я обязана знать своё дело хорошо и уметь задавать правильные вопросы нужным людям.
“Не знаю, давайте разберёмся вместе” — это не слабость. Это профессиональная честность.

2️⃣ Начала вести список того что сделала хорошо
Не для резюме. Для себя. Буквально блокнот где я записывала: вот здесь я нашла противоречие в требованиях до того как оно стало проблемой. Вот здесь помогла разрулить конфликт между командами. Вот здесь заказчик сказал что это лучшая документация которую он видел.
Когда накрывало сомнениями — открывала и перечитывала. Работало.

3️⃣ Поговорила с коллегами
Оказалось что опытные аналитики которым я завидовала — чувствовали то же самое. Просто не говорили об этом вслух. Один разговор по душам с коллегой которая была в профессии семь лет снял с меня какое-то внутреннее напряжение которое я носила месяцами.
Мы все притворяемся что знаем больше чем знаем. Это нормально. Ненормально думать что ты одна такая.

4️⃣ Перестала сравнивать себя с чужими достижениями
Соцсети и профессиональные каналы показывают лучшее. Никто не пишет “сегодня я провалила встречу и не смогла ответить на половину вопросов”. Все пишут про успехи, про крутые проекты, про сертификаты.
Я сравнивала свою внутреннюю кухню с чужим парадным фасадом. Это заведомо проигрышная игра.

Что поняла спустя двенадцать лет

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

❗️Если вы аналитик и узнали себя в этом тексте — вы не одни. И то что вы сомневаетесь в себе скорее всего означает что вы достаточно вдумчивы чтобы видеть собственные пробелы. Это не слабость. Это качество хорошего специалиста.

Если было полезно, ставьте реакции 😉

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

И смешно, и грустно 🤣😭