Business | System analyst

ТЗ в 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

Стать аналитиком данных всего за 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

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

Зрелость управления данными: предлагаю простую методику оценки ⏳ 23 мин | 🟤🟤⚪️  Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA

📊 90% провалов в IT-проектах — из-за плохо собранных требований аналитиком. Научим собирать их правильно на курсе «Системный и бизнес-анализ» 🎁Записывайтесь на 2 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам! 5 августа, 20:00 мск — «MVP глазами бизнес-аналитика: от идеи до первых функций»: разберём, что такое MVP и как развивать первые наработки продукта, рассмотрим примеры удачных MVP и инструмент User Story Mapping для формирования его границ. 17 августа, 20:00 мск — «Строим модель в нотации BPMN с помощью ИИ»: разберём, как с помощью LLM построить модель процесса в BPMN, почему ИИ не создаёт графику напрямую и как обойти это на деле. Разберём примеры генерации диаграмм и другие способы применения ИИ в процессах. Записывайтесь https://clck.ru/3UzDJx Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Как аналитик выживает между бизнесом и разработкой Салют! Есть шутка в профессии: аналитика не любят ни бизнес ни разработка. Бизнес считает что ты на стороне IT и тормозишь. Разработка считает, что ты на стороне бизнеса и генеришь бесконечные хотелки. А ты стоишь посередине и пытаешься сделать так чтобы все были живы. Я провела в этой позиции двенадцать лет. И да, первые несколько лет это реально выматывало. Потом поняла несколько вещей которые изменили отношение к этой роли. Ты не переводчик. Ты модератор конфликта интересов Долгое время я думала, что моя задача — переводить с языка бизнеса на язык разработки и обратно. Технически это так. Но если смотреть глубже — аналитик работает в точке где сталкиваются два мира с разными целями. Бизнес хочет всё, быстро и желательно вчера. Разработка хочет чёткие требования, стабильный скоуп и время сделать нормально. Эти желания почти никогда не совпадают полностью. Главная ловушка — пытаться угодить всем. Это невозможно. И попытка усидеть на двух стульях приводит к тому что не доверяют ни те ни другие. Баланс который я нашла: моя лояльность не людям, а результату. Я на стороне проекта — не бизнеса и не разработки. Звучит просто, но внутри перестроиться непросто. Что реально помогает Не передавай требования — объясняй контекст Худшее что может сделать аналитик — принести разработчику список требований без контекста. “Бизнес сказал сделать вот так.” Всё, ты стала почтальоном. Разработчик должен понимать зачем это нужно, какую проблему решает, что будет если сделать иначе. Когда человек понимает зачем — он предлагает решения лучше тех что придумал бизнес. И это победа для всех. Не ходи к разработке с сырыми требованиями Прежде чем идти к команде я сама прохожусь по требованиям и задаю себе неудобные вопросы. Что будет если пользователь сделает вот так? А если данных нет? А если два пользователя одновременно? Какой сценарий если что-то пошло не так? Лучше найти дыры самой, чем услышать их на разборе задач с командой. Разработка это запомнит — в хорошем смысле. Когда бизнес и разработка конфликтуют — не исчезай Самый плохой сценарий: бизнес и разработка начинают выяснять отношения, а аналитик тихонько выходит из чата. Я так делала. Казалось что конфликт не мой. Мой. Потому что в основе почти любого конфликта между бизнесом и разработкой — неточные или противоречивые требования. Разруливать это всё равно придётся, только потом и с большими потерями. Сейчас я захожу в такие конфликты первой. Не чтобы встать на чью-то сторону, а чтобы вытащить на поверхность в чём реальное расхождение. Часто оказывается что люди спорят об одном и том же просто разными словами. Фиксируй решения принятые не тобой Бизнес принял решение которое технически сомнительное. Разработка приняла архитектурное решение которое ограничивает функциональность. Ты была на встрече, слышала, высказала мнение — но решение не твоё. Фиксируй письменно. Не чтобы потом сказать “я же говорила”. А чтобы когда через три месяца это аукнется — был контекст почему так получилось и кто был в курсе. Это защищает всех, не только тебя. Не бери на себя ответственность за чужие решения Это отдельный пункт потому что он про границы. Аналитик отвечает за качество требований и за то что все стороны правильно поняли друг друга. Аналитик не отвечает за бизнес-решения заказчика и за технические решения разработки. Граница тонкая, но важная. Когда её нет — выгораешь быстро. Про эмоциональную сторону — это тоже важно Позиция между двумя огнями эмоционально затратная. Тебя могут обвинять с обеих сторон, иногда несправедливо. Бизнес говорит что не понимаешь их боль. Разработка говорит что приносишь нереализуемые хотелки. Я долго принимала это на свой счёт. Потом поняла: большая часть этих претензий — не ко мне лично, а к позиции. Аналитик по определению находится в точке напряжения. Это не баг профессии, это фича. Именно там где интересы сталкиваются — нужен человек который удерживает общую картину и не теряет голову. Не бизнес, не разработка. Аналитик. Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

Как брать интервью у производственников — это совсем другая игра Салют! Сегодня у нас разбор интервью производственников)) Первый раз я пришла на интервью к начальнику смены на установке с ноутбуком, красивым шаблоном вопросов и уверенностью что всё пройдёт как обычно. Через десять минут поняла — ничего как обычно не будет. Он смотрел на меня как на человека который пришёл отнять у него время. Отвечал односложно. На вопрос “расскажите как вы работаете с данными по выходу продукта” — пожал плечами и сказал “ну, смотрим”. Я вышла с того интервью почти с пустым блокнотом. И пошла думать что сделала не так. Почему стандартный подход не работает 🧐 На офисных проектах люди в целом готовы говорить. Они привыкли к встречам, к обсуждениям, к тому что их мнение спрашивают. У производственника другая картина мира. Его день — это смена, регламент, ответственность за процесс. Встреча с аналитиком из IT — это помеха в этом ритме. Не потому что он плохой человек. Просто у него реально другие приоритеты. Плюс есть негласная установка: “скажешь лишнее — потом переделывай”. Люди на производстве умеют молчать. Это навык выживания в большой организации. Что изменила в своём подходе❗️ 1️⃣ Никакого ноутбука в начале Ноутбук на столе — это протокол, это фиксация, это официально. Человек закрывается. Я стала приходить с блокнотом и ручкой. Иногда вообще без ничего — просто поговорить. Записи делала после, по памяти. Да, это сложнее. Но люди говорили в разы открытее. Сначала про работу, потом про систему Ошибка которую я делала в начале — сразу спрашивала про будущую систему. “А как вы хотите чтобы это работало?” Человек не знает. Он никогда не думал в этих категориях. Правильный порядок: сначала полностью понять как устроена работа сейчас. Только потом — осторожно — переходить к тому что можно улучшить. Вопросы которые реально работают:

— Покажите как вы это делаете прямо сейчас
— А что происходит если вот это пошло не так?
— Откуда вы узнаёте что нужно действовать?
— Кому вы передаёте эту информацию дальше?
Никаких “а как вы видите идеальный процесс”. 

Производственник не обязан думать об идеальных процессах — это наша работа. 2️⃣ Идти на рабочее место, а не звать в переговорку Переговорка — чужая территория. Человек там скован. Когда я начала приходить прямо к установке, к рабочему месту — всё менялось. Он в своей среде, уверен, может показать руками. “Вот смотри — вот этот показатель, вот журнал, вот куда я смотрю когда что-то идёт не так.” Один такой визит заменял три переговорки. И информации было в разы больше. Не спорить и не умничать Если технолог говорит что-то что кажется нелогичным — не спорить. Уточнять. “Правильно я понимаю что вы делаете вот так потому что…?” Часто за нелогичным на первый взгляд решением стоит опыт десятилетий и несколько аварийных ситуаций которые этот человек пережил лично. Найти союзника внутри На каждом производственном проекте я искала одного человека который понимает зачем всё это нужно и готов помочь. Не обязательно руководителя — иногда это молодой инженер которому интересно. Такой человек помогал договориться о встречах, объяснял коллегам что я не враг, и переводил с технологического на человеческий когда я совсем не понимала о чём речь. 3️⃣ Отдельно про документацию которой нет На производстве часто слышишь: “Да всё написано в регламенте”. Берёшь регламент — а там описан процесс образца 2009 года который давно работает по-другому. Просто никто не обновлял. Реальный процесс живёт в головах людей и в неофициальных инструкциях которые передаются от старшего к младшему устно. Задача аналитика — вытащить именно это, а не переписать регламент который и так все игнорируют. И главное Производственники — одни из самых ценных экспертов с которыми мне приходилось работать. Они знают свой процесс до деталей которые ни в каком документе не найдёшь. Просто язык у них другой. И подход нужен другой. Когда перестаёшь приходить как “человек из IT который сейчас всё улучшит” и начинаешь приходить как человек который хочет разобраться — всё меняется. Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

Можно ли аналитику в 2026 году положиться на ИИ и агентов или ещё нет? ⏳ 15 мин | 🟤🟤⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA