Business | System analyst

📊От основ и внедрения ИИ в аналитическую работу до защиты реального проекта за 136 часов обучения на курсе «Бизнес-аналитик в ИТ». 🎁 Записывайтесь на 3 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам! 1⃣28 сентября, 20:00 мск — «Инструменты ИИ в работе бизнес-аналитика»: разберём, какие ИИ-инструменты применяют в сборе требований и анализе данных, покажем примеры промптов и границы между пользой и риском. 2⃣15 октября, 20:00 мск — «Цели и метрики как одно целое»: разберём связь целей и метрик, инструменты для их согласования и почему ошибки в целях обесценивают даже точные метрики. 3⃣22 октября, 20:00 мск — «Управление изменениями требований»: обсудим, как выстроить процесс управления требованиями, чтобы изменения не разваливали скоуп проекта, и как держать реестр требований в порядке. Записывайтесь ➡ https://clck.ru/3W67dz Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

«Подождём модель поумнее» — не самая грамотная стратегия работы с ИИ, и вот почему Салют! Досмотрела выпуск подкаста «Доверительный интервал» про ИИ в аналитике — там прозвучала мысль, которую я бы распечатала и повесила над монитором каждому, кто мыслит так: «вот выйдет суперумная модель — тогда и начну юзать ИИ». По факту работать со слабыми моделями полезно: на них оттачивается главный навык — чётко объяснять контекст. Если этого навыка нет, умная модель не спасёт. Слабая на плохом контексте просто ошибётся — и ты это заметишь. Умная ошибётся красиво и уверенно — так, что ты ей поверишь.  🧐Поэтому контекст — это не «написать промпт подлиннее» Важно не просто формулировать задачу, а формализировать сам контекст. Это тоже затронули в подкасте — и вот как это выглядит на практике в Яндексе:  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
WHERE o.status = 'active'
GROUP BY 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 году и зачем ⏳ 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

Лето, ИТ-Пикник и музыка известных артистов уже через несколько дней! 8 августа в Коломенском пройдет ИТ-Пикник. В программе — выступления проекта LAB Антона Беляева, IOWA, Cream Soda, Pompeya, мартина и Совы. А днем — научпоп-лекции, дискуссии об ИИ и больших языковых моделях, мастер-классы и интерактивы. Полезные знакомства и развлечения тоже будут. Зарегистрироваться и узнать подробности можно на сайте мероприятия. В билет входит +1 — можно позвать близких и друзей. До встречи в месте притяжения ИТ.

Лето, ИТ-Пикник и музыка известных артистов уже через несколько дней! 8 августа в Коломенском пройдет ИТ-Пикник. В программе — выступления проекта LAB Антона Беляева, IOWA, Cream Soda, Pompeya, мартина и Совы. А днем — научпоп-лекции, дискуссии об ИИ и больших языковых моделях, мастер-классы и интерактивы. Полезные знакомства и развлечения тоже будут. Зарегистрироваться и узнать подробности можно на сайте мероприятия. В билет входит +1 — можно позвать близких и друзей. До встречи в месте притяжения ИТ.

Синдром самозванца у опытных — это уже не страх, это кое-что похуже Салют! Когда говорят про синдром самозванца — обычно рисуют образ новичка который боится открыть рот на встрече. Узнала себя, подросла, прошло. Но у опытных специалистов синдром самозванца не исчезает — он мутирует. Становится тише, незаметнее и от этого гораздо опаснее. Я поняла это когда поймала себя на нескольких привычках которые казались абсолютно нормальными. Оказалось — не очень. Проявление 1. Гиперподготовка Перед важной презентацией переделывала слайды до часа ночи. Не потому что они были плохими — потому что внутри сидел голос: “а вдруг спросят то что не предусмотрела?” Гиперподготовка маскируется под профессионализм. На самом деле это тревога которая ищет контроль. И она съедает время и энергию которые можно было потратить на что-то реально важное. Проявление 2. Присваивать успех команде, а провалы — себе Проект прошёл хорошо — “ну, команда молодец, повезло с заказчиком”. Что-то пошло не так — “я недоработала, надо было лучше собрать требования”. Это не скромность. Это искажение при котором успех всегда случайный, а неудача всегда твоя личная. Опытные специалисты попадают в эту ловушку особенно часто — потому что видят свой вклад в провалы лучше чем в успехи. Проявление 3. Синдром “ещё одного курса” “Вот пройду курс по архитектуре — тогда буду достаточно компетентна.” “Получу сертификат — тогда смогу претендовать на повышение.” Я однажды посчитала: за два года прошла семь курсов. При этом несколько раз отказалась от интересных проектов потому что “ещё не готова”. Курсы были. Готовность не наступала — потому что дело было не в знаниях. Проявление 4. Преуменьшение своей экспертизы “Ну, я не эксперт конечно, но…” “Могу ошибаться, но…” “Это просто моё мнение…” Когда человек с десятью годами опыта начинает каждый второй тезис с подобных оговорок — это уже не вежливость. Я ловила себя на этом постоянно. Внутри всё знала, снаружи звучала неуверенно. И люди считывали именно неуверенность, а не экспертизу. Проявление 5. Избегание видимости Не брать сложный проект — “там и без меня справятся”. Не предлагать идею — “наверное это всем очевидно”. Не откликаться на вакансию — “я не дотягиваю до всех требований”. Это самое дорогостоящее проявление. Цена здесь вполне конкретная: проекты которые не взяла, идеи которые не высказала, карьерные шаги которые не сделала. ❗️Почему это сложнее лечится чем у новичков У опытного специалиста все эти проявления выглядят как черты характера. Окружающие не видят проблемы — иногда даже хвалят: “такой ответственный человек”, “никогда не хвастается”. А внутри всё тот же голос который говорит что ты недостаточно хороша. Просто научившийся говорить тихо. ✅ Что с этим делать Первый шаг — увидеть конкретные привычки, а не абстрактный диагноз. Второй шаг — разделить тревогу и реальность. “Я недостаточно компетентна” — это ощущение. “Я десять лет успешно веду проекты” — это факт. Верить стоит факту. Третий шаг — действовать не дожидаясь уверенности. Она не приходит до действия. Только после. Это контринтуитивно — но это правда которую я проверила на себе много раз. Если было полезно, ставьте реакции 😉 Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA