Business | System analyst

Системный анализ тогда и сейчас — профессия изменилась, но не так как все думают Когда я начинала работать аналитиком, основным инструментом был Word, согласование шло по почте, а UML-диаграммы рисовались в Visio и распечатывались на встречи. Серьёзно — распечатывались, потому что показать экран было не так просто. Сейчас Miro, Confluence, Figma, Notion, и ИИ который за минуту генерирует структуру документа. Всё изменилось — и при этом самое главное осталось ровно таким же. Что изменилось реально 🏎️ Скорость. Раньше на подготовку документа уходили дни. Сейчас черновик можно собрать за час — ИИ помогает со структурой, шаблонами, формулировками. Это не хорошо и не плохо — это просто новая реальность. Но она повысила ожидания: если раньше "неделя на ТЗ" было нормой, сейчас заказчик удивляется почему так долго. 👩‍💻 Инструменты совместной работы. Event Storming в Miro с командой из трёх городов — это обычная история. Пять лет назад это было экзотикой. Удалёнка изменила не только где мы работаем, но и как договариваемся и фиксируем решения. ✅ Доступность информации. Раньше чтобы разобраться в незнакомой предметной области нужно было найти эксперта или перечитать гору документов. Сейчас можно за вечер получить базовое понимание любой отрасли. Порог входа в новую предметную область сильно снизился. 🤔 Размытие ролей. Граница между аналитиком, продактом и проектным менеджером стала тоньше. Всё чаще аналитик занимается и приоритизацией бэклога, и работой с метриками, и фасилитацией стратегических сессий. Это расширяет возможности — и добавляет неопределённости. Что не изменилось — и это важно понимать 👥 Люди не изменились. Заказчики всё так же не могут сформулировать что хотят. Разработчики всё так же хотят чёткие требования. Конфликты интересов всё так же нужно разруливать вручную. ИИ не научился вытаскивать из технолога знания которые он сам не осознаёт. Не умеет почувствовать что заказчик говорит одно а имеет в виду другое. Не может выстроить доверие с командой которая сопротивляется изменениям. Всё что связано с людьми — осталось нашим. И судя по тому что я вижу — останется ещё долго. Что изменилось во мне как в аналитике Раньше я тратила много времени на оформление. Красивые таблицы, выверенные формулировки, идеальная структура документа. Сейчас это делает ИИ быстрее и не хуже. Освободившееся время ушло туда где ИИ не помогает: глубже разбираться в предметной области, больше времени на живое общение с заказчиком, думать о последствиях решений а не только об их оформлении. Не знаю хорошо это или плохо — но точно интереснее. Про страх который был и прошёл Помню как несколько лет назад в профессиональных чатах активно обсуждали: "нас заменят". ИИ напишет требования, сгенерирует документацию, проведёт анализ. Частично это случилось — рутинная часть работы действительно автоматизировалась. Но профессия не исчезла. Она стала другой. Аналитик который умеет работать с ИИ как с инструментом — стал продуктивнее. Аналитик который умеет только это — стал уязвимее. Потому что инструменты меняются каждый год, а умение думать и работать с людьми — нет. Двенадцать лет назад я не могла представить, что буду обсуждать требования в онлайн-доске с командой из разных городов и проверять черновики с помощью ИИ. Через двенадцать лет профессия снова будет другой — и это скорее интересно чем страшно. Как вы ощущаете изменения в профессии — что стало лучше, что потерялось? Пишите в комментариях 👇 Если было полезно, ставьте реакции Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

📊От основ и внедрения ИИ в аналитическую работу до защиты реального проекта за 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 — можно позвать близких и друзей. До встречи в месте притяжения ИТ.