Business | System analyst

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

Синдром самозванца у опытных — это уже не страх, это кое-что похуже Салют! Когда говорят про синдром самозванца — обычно рисуют образ новичка который боится открыть рот на встрече. Узнала себя, подросла, прошло. Но у опытных специалистов синдром самозванца не исчезает — он мутирует. Становится тише, незаметнее и от этого гораздо опаснее. Я поняла это когда поймала себя на нескольких привычках которые казались абсолютно нормальными. Оказалось — не очень. Проявление 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

Когда заказчик говорит “сделайте как раньше” — а раньше уже не работает Салют! Есть особая категория проектов, о которых в учебниках по системному анализу не пишут. Это автоматизация на производстве. Не стартап, не интернет-магазин — ЗАВОД. Со своей культурой, своими людьми и своим отношением к любым изменениям. Несколько лет я работала на проектах автоматизации производственных процессов. Нефтепереработка, цеха, технологи у которых за плечами по 20-30 лет стажа. Это был совершенно другой мир по сравнению с офисными проектами. И он многому меня научил. 1️⃣ Первый урок: эксперт в предметной области — не ты В обычных проектах аналитик быстро разбирается в предметке. Бухгалтерия, логистика, HR — за несколько недель погружаешься и уже можешь говорить на одном языке с бизнесом. На производстве это не работает. Технолог который обслуживает установку первичной переработки нефти знает её так, как ты никогда не узнаешь. И он это чувствует. Первое время я пыталась быстро вникнуть в технологические процессы — читала регламенты, смотрела схемы. Потом поняла: моя задача не стать экспертом в нефтепереработке. Моя задача — правильно упаковать знания эксперта в требования. Как только перестала делать вид что разбираюсь — люди начали говорить открыто. Простой вопрос “объясните мне как будто я первый раз это слышу” творит чудеса. 2️⃣ Второй урок: “сделайте как в Excel” — это не хотелка, это сигнал Классическая история. Приходишь автоматизировать процесс, а там — огромная Excel-таблица которую технолог ведёт вручную уже восемь лет. Вся логика в ней, все расчёты, весь опыт. Первый инстинкт: переписать в нормальную систему, убрать ручной труд, сделать красиво. Стоп. Прежде чем автоматизировать — нужно понять почему Excel выглядит именно так. Каждая колонка, каждый цвет, каждая формула — это чьё-то решение, принятое по какой-то причине. Иногда причина устарела. Но иногда в ней зашита бизнес-логика которую никто не догадался задокументировать. Я научилась задавать один вопрос: “А вот эта колонка — зачем она? Что вы с ней делаете дальше?” И половина интервью уходила именно на разбор таблицы. 3️⃣ Третий урок: сопротивление изменениям на производстве — это не каприз Когда офисный сотрудник сопротивляется новой системе — обычно это про привычку или про страх что станет сложнее. Когда технолог на заводе говорит “я не буду работать в новой системе” — за этим может стоять кое-что серьёзнее. Люди несут реальную ответственность за процессы. Цена ошибки на производстве — это не “клиент недоволен”, это остановка установки или хуже. Поэтому недоверие к новому инструменту здесь — абсолютно рациональная реакция. И продавить его административно можно, но система будет саботироваться тихо и методично. Что работало у меня: брать самого скептичного человека в команду пилота. Не самого лояльного — самого скептичного. Если он найдёт проблемы раньше запуска — это подарок. Если в итоге скажет “ну, работает” — остальные поверят быстрее любой презентации. 4️⃣ Четвёртый урок: требования живут в головах людей предпенсионного возраста И это не проблема — это факт с которым нужно работать. На производственных проектах я несколько раз сталкивалась с ситуацией: единственный человек который знает как работает процесс — уходит на пенсию через полгода. И никаких документов нет. Вообще. В таких случаях интервью превращается в спасательную операцию. Сидишь, записываешь, уточняешь, рисуешь схемы прямо на встрече и просишь подтвердить. Иногда по три раза возвращаешься к одному и тому же человеку. Это медленно. Но это единственный способ не потерять знания которые потом не восстановить. Производственные проекты изменили меня как аналитика больше, чем любые курсы и книги. Там не получается работать по шаблону — слишком высокая цена ошибки и слишком живые люди с которыми приходится работать. Если у вас был опыт автоматизации на производстве — очень интересно услышать. Уверена, у каждого своя история 👇 Ставьте реакции, если понравилась тема)) ___________ Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

Как использовать Kafka на собеседовании по System Design ⏳ 17 мин | 🟡⚪️⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Думаете, что знаете все про LLM? Тогда мы идем к вам ⏳ 27 мин | 🟤⚪️⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA

Как я готовился к сертификации по LLMархитектуре и понял, что три года путал промпты с архитектурой ⏳ 5 мин | 🟤⚪️⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA

Сказ про Лукаса-героя да про Postgres и Timescale: SA и его необычная задача ⏳ 4 мин | 🟤⚪️⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA

Как работать с требованиями которые меняются — без нервов и переработок Салют! Помню проект, где требования менялись так часто, что я перестала распечатывать документацию — смысла не было. Разработчики смотрели на меня с немым вопросом, я смотрела на бизнес с тем же вопросом. ❗️Тогда поняла: проблема не в том что требования меняются. Они всегда будут меняться. Проблема в том как ты выстраиваешь работу с ними. Сразу честно: ни один инструмент не спасёт если в компании хаос на уровне управления. Но даже в таких условиях правильный подход помогает выжить с меньшими потерями для себя и команды. И это тоже результат. Почему требования меняются — без прикрас — Бизнес не знал чего хочет до конца. Это нормально — люди часто понимают что им нужно только увидев первый результат — Изменился контекст: рынок, конкурент, законодательство, новый руководитель с другим видением — Требования были размыты с самого начала — вот это уже наша зона ответственности Злиться на второй пункт бессмысленно. Над третьим работать — полностью в наших силах. Что реально помогает (или помогало в моем случае): 1️⃣Фиксируйте договорённости сразу Любое решение с встречи — в письмо в тот же день. Люди искренне забывают что говорили три недели назад, это не злой умысел. Иногда такая фиксация воспринимается в штыки: “ты мне не доверяешь?” Я на это отвечала спокойно: “Доверяю, просто у меня плохая память” — обычно разряжало обстановку. Договорились: ... Следующий шаг: ... Жду подтверждения до [дата]. 2️⃣Спрашивайте “зачем”, а не “как” Это работает всегда и везде — просто здравый смысл. Приходит менеджер: “Хочу менять цвет строк в таблице”. Спрашиваю зачем. Оказывается — хочет видеть просроченные заказы. Реальное требование: автоматически подсвечивать просрочку. Другая задача, проще и полезнее. Половина изменений при правильном вопросе превращается в уточнение исходного требования, а не в новую задачу. 3️⃣ Показывайте стоимость изменения Когда бизнес приходит с правкой, говорю прямо: “Эта правка затрагивает три модуля, сдвигает сроки на неделю. Готовы?” Важна подача. Не “это дорого и мы не будем делать”, а “давайте я покажу что затронет эта правка — и вы примете решение”. Некоторые заказчики всё равно воспримут это как отказ помочь — но большинство после такого разговора спокойно отправляют правку в следующий релиз. 4️⃣ Приоритизируйте, не складывайте в кучу Приоритет / Критерий Срочно и важно / Блокирует работу прямо сейчас Важно, не срочно / В следующий спринт Хотелка / В бэклог Честно: в компаниях где всё “срочно и важно” по умолчанию — эта таблица работает плохо. Но даже там она помогает хотя бы начать разговор о приоритетах. 5️⃣ Договоритесь о правилах на берегу В начале проекта проговариваю с заказчиком: как обрабатываем изменения, когда правка идёт в текущий релиз, а когда в следующий, кто финальный ЛПР. Сложность в наших реалиях: ЛПР часто недоступен, меняется или принимает решения в коридоре после планёрки. В таком случае фиксирую хотя бы того кто есть — пусть не идеально, но лучше чем ничего. ❗️И про внутреннее состояние — это важно Я долго воспринимала каждое изменение как личную неудачу. Значит плохо собрала, не так спросила, недоработала. Потом поняла: идеальных требований не бывает. Иногда проблема вообще не в аналитике — а в том что решения принимаются спонтанно на самом верху, и никакой инструмент это не исправит. Наша ценность не в том чтобы зафиксировать всё раз и навсегда. А в том чтобы управлять изменениями так, чтобы команда не сходила с ума и бизнес получал то что реально нужно. 🧐 Если было полезно, ставьте реакции, буду делиться больше такой информацией)) ___________ Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

Системный аналитик 2026: вы всё ещё пишете документацию, но теперь её читает только LLM ⏳ 5 мин | 🟤🟤⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA