Analyst IT

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

Fuckup Night от создателей Trisigma, Ares и karpov.courses Согласитесь, ивенты, где все делятся только своими успехами, уже поднадоели. Хочется реальных историй, где что-то пошло не по плану, но в итоге ошибка стала ценным опытом. Поэтому команда Trisigma собирает Fuckup Night 26 августа — без записи и красивых цифр. Истории расскажут: 🔸 Виталий Черемисинов (Trisigma) 🔸 Роман Нестер (Ares, Arteus LLM и Segmento) 🔸 Валерий Бабушкин (British Petroleum) 🔸 Беслан Курашов (plevako.ai и karpov.courses) Встречу проведут онлайн, поэтому подключиться можно из любой точки и всем, кто принимает решения на основе данных. ⚡️ Важно! Записи не будет, поэтому приходите на эфир. Главное — не забудьте зарегистрироваться.

Как ИИ изменил собеседования для аналитиков — и что теперь с этим делать Недавно разговаривала с коллегой которая проводит технические интервью в крупной компании. Говорит:

“Мы перестали задавать вопросы на знание инструментов — бессмысленно. Все приходят подготовленные одинаково хорошо и одинаково поверхностно.”

Я поняла о чём она. ИИ изменил собеседования — причём с обеих сторон стола. Что изменилось со стороны кандидата Раньше подготовка к собеседованию занимала недели. Нужно было вспомнить методологии, освежить термины, прогнать в голове кейсы. Сейчас ChatGPT выдаёт список типичных вопросов для аналитика за тридцать секунд и тут же даёт развёрнутые ответы на каждый. Результат: кандидаты приходят технически подготовленными лучше чем раньше. Но эта подготовка часто поверхностная — заученные формулировки без реального понимания за ними. Я видела это на собеседованиях, когда сама выступала в роли интервьюера. Человек красиво рассказывает про Event Storming — но когда спрашиваешь “а как вы справились когда ключевой эксперт отказывался участвовать?” — пауза. Потому что ИИ даёт теорию, а живого опыта за ней нет. Что изменилось со стороны интервьюера Умные компании это поняли и перестроили формат. Вот что я вижу сейчас: 1. Меньше вопросов на знание — больше на мышление “Что такое Use Case?” уже никто не спрашивает. Спрашивают: “Вот размытое требование от заказчика — что будете делать?” Или дают реальный противоречивый документ и смотрят как человек с ним работает. Знание можно нагуглить. Мышление — нет. 2. Кейсы вместо теории Всё больше компаний дают домашнее задание: реальная или приближённая к реальной ситуация, которую нужно разобрать. Не “расскажите про BPMN” а “вот процесс — опишите его, найдите проблемы, предложите решение”. ИИ может помочь с оформлением — но думать за кандидата всё равно не будет. Точнее будет, но интервьюер это увидит. 3. Глубокие вопросы про опыт “Расскажите про сложный проект” стало стандартом. Но теперь идут вглубь: “А что конкретно вы сделали когда заказчик отверг ваше решение?”, “Как вы убедили разработчиков что требование важное?”, “Что бы вы сделали иначе?” На такие вопросы ИИ не даст готового ответа — потому что ответ должен быть про вас, а не про аналитика вообще. 🤔 Что это значит для тех кто готовится к собеседованию ИИ как инструмент подготовки — отлично. Освежить теорию, прогнать термины, подготовить список вопросов которые стоит задать самому — всё это работает. Но есть вещи которые ИИ не заменит: 1. Реальные кейсы из практики. Если опыта мало — берите учебные проекты, pet-проекты, волонтёрские задачи. Что угодно реальное где были настоящие решения и настоящие проблемы. 2. Умение думать вслух. На современных собеседованиях важен не только ответ но и то как вы к нему пришли. Тренируйтесь проговаривать ход мыслей — это навык который нужно качать отдельно. 3. Честность про пробелы. “Я с этим не работала, но вот как бы я подошла к задаче” — это сильный ответ. Гораздо сильнее заученной формулировки которая рассыпается при первом уточняющем вопросе. ‼️ И про другую сторону — как ИИ меняет требования к аналитику Это отдельный разговор — но скажу коротко. Рутинные части нашей работы автоматизируются. Генерация шаблонов, базовые описания процессов, первичная структура документов — всё это ИИ делает уже сейчас. Это не страшно. Это значит что ценность аналитика смещается туда куда ИИ не дотянется: живая работа с людьми, понимание контекста, умение вытащить неочевидное требование, управление конфликтами интересов. Источник: @analysis_it 💙 Analyst IT | 💬 Analyst IT

Имитационное моделирование: что это такое и с чем его едят ⏳ 5 мин | 🟡⚪️⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Самый ценный специалист в ИТ и бизнесе Если разработчик пишет код, а тимлид управляет задачами, то кто решает, как вообще должна быть устроена компания и её ИТ-инфраструктура, чтобы бизнес достигал своих целей? Корпоративный архитектор. Он создаёт единый механизм, в котором ИТ, стратегия, процессы и данные не противоречат друг другу и приносят компании реальную прибыль. Отсюда — прямой выход на собственника и доход от 500 000 ₽ в месяц. Вырастите из технаря в стратега за 4 месяца на курсе «Корпоративный архитектор» от Академии Эдюсон. Это комплексная программа для смены роли — с упором на практику, работу с метриками и новыми инструментами. После курса вы сможете реально влиять на бизнес: • Спроектировать единую ИТ-архитектуру по международным стандартам (включая TOGAF и ArchiMate). • Интегрировать нейросети в процессы и автоматизировать работу компании. • Защищать ИТ-решения перед топами на языке денег — с упором на метрики, финансы, оргдизайн и стратегию. Также получите шаблоны и инструкции для решения задач + удостоверение о повышении квалификации в финале. Оставьте заявку с промокодом АРХИТЕКТОР — заберите курс с персональной скидкой. Реклама. ООО «ЭДЮСОН» ИНН 7729779476. erid: 2W5zFJ5e73F

Мы забыли, что такое кодить, и тебе советуем Потому что рост грейда и зп зависит НЕ от этого уж точно! Попытка превратиться в программиста в 2026 - самый долгий и мучительный путь к офферу на 350k+ Чтобы вывозить реалии рынка, нужно знать архитектуру. Вакансий с этим требованием всё больше, на собесах спрашивают постоянно, а сами архитекторы - никакие не сверхлюди. Это просто те, кто решил забрать контроль в свои руки. Они влияют на продукт и бизнес, принимают решения и берут ответственность. А взамен получают уверенность в завтрашнем дне и чек, который часто в два раза выше тех самых 350+к. 13 августа в 19:00 (МСК) проведем бесплатный веб «Архитектура без кода: как стать аналитиком, которого слушают разработчики и бизнес» На вебе на примере заказов, REST, Kafka и баз данных разберем влияние аналитика на архитектуру без единой строчки кода: покажем грамотную связку сервисов, разберем частые ошибки новичков и ответим на ваши вопросы в прямом эфире Регистрируйся по ссылке Erid: 2SDnjepKPPR Название: ООО "СТЕП БАЙ СТЕП" ИНН: 0800013217

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

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

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

В распределённых системах надёжность обмена данными — не опция, а необходимость. Потеря сообщений, нестабильные очереди и сложности масштабирования способны поставить на паузу даже самый перспективный проект. 3 августа в 20:00 OTUS проводит открытый урок «Использование брокера сообщений Apache Kafka в распределённых очередях» — в преддверии старта курса «Микросервисная архитектура». На вебинаре вы разберёте архитектуру Kafka, освоите принципы работы распределённых очередей и лучшие практики интеграции. На практике развернёте кластер Kafka в Docker и проработаете сценарии обмена сообщениями между сервисами. Урок ориентирован на fullstack‑ и backend‑разработчиков, DevOps‑инженеров, архитекторов ПО и администраторов систем — на всех, кто проектирует масштабируемые решения. Регистрируйтесь сейчас — чтобы занять место и получить напоминание в день вебинара. https://clck.ru/3V5hod Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Замороженная работа: метрика, которая считает непринятые решения ⏳ 9 мин | 🟡🟡⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

#📊От основ до практики в реальных проектах на курсе «Системный аналитик». 🎁Записывайтесь на 3 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам! 4 августа, 20:00 мск — «Как аналитику работать с рисками»: кто должен предусматривать риски — аналитик или менеджер, можно ли предугадать «черного лебедя» и что делать, если избежать риска не удалось. Жизненный цикл, классификация и методы оценки рисков. 11 августа, 20:00 мск — «Практическое собеседование системного аналитика»: решим задачу от потребности до UAT, разберём выбор решений и проверим навыки анализа требований. Как проходят собеседования на роль аналитика в 2026 году. 25 августа, 20:00 мск — «Создаём ИИ-ассистента для системного аналитика за 1 час»: с нуля соберём ИИ-агента, который превращает сообщения из чатов в готовые задачи с приоритетом и критериями приёмки. Записывайтесь https://clck.ru/3V2AjV Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Что в работе аналитика поменялось за пять лет, а что только в вакансиях ⏳ 5 мин | 🟡⚪️⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

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

🔥 Приглашаем на бесплатный открытый урок курса «Корпоративный архитектор / Enterprise Architect»: «Будущее корпоративного архитектора: навыки, тренды, технологии» 🗓 Когда: 4 августа, 19:00 (мск) Роль корпоративного архитектора стремительно меняется, чтобы оставаться востребованным в ближайшие годы, нужно понимать, какие навыки, технологии и подходы будут определять профессию до 2030 года. 📚Что будет на вебинаре: - Как меняется роль корпоративного архитектора в эпоху новых технологий - Ключевые навыки архитектора ближайших лет (hard & soft skills) - Основные тренды в корпоративной архитектуре до 2030 года - Технологии, без которых архитектору будет сложно работать - Как выстроить собственный план профессионального развития 💡В результате вы: - Узнаете, какие технологические тренды реально меняют корпоративную архитектуру - Получите набор ключевых навыков, которые станут базой для архитектора будущего - Поймёте, как работать в мире DevOps-культуры, data-driven подхода и AI-native архитектур - Научитесь выстраивать свой план развития в эпоху быстрых изменений 👉 Зарегистрируйтесь https://clck.ru/3Uv4NF Бесплатное занятие приурочено к старту курса «Корпоративный архитектор / Enterprise Architect», на котором вы системно освоите TOGAF, ArchiMate, разработку дорожных карт и управление архитектурой предприятия. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

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

4 ошибки в A/B‑тестах, из‑за которых случайный шум выглядит как эффект ⏳ 8 мин | 🟡🟡⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Компании ценят специалистов, которые разбираются как в технической стороне продукта, так и в потребностях бизнеса. Перекрёстные навыки часто встречаются в вакансиях. Нетология объединила две профессии в один курс — «Системный и бизнес-аналитик». На занятиях своим опытом поделятся эксперты из Qiwi, М.Видео — Эльдорадо и Bolt. За 12 месяцев вы научитесь: - использовать гибкие методологии Agile и Scrum; - разбираться в нотациях моделирования: UML, BPMN, IDEF; - описывать user story и use case; - создавать прототипы приложений и сервисов; - работать с АРІ и проектной документацией. Сейчас на курс действует скидка 50%, а с промокодом IT10JULY цена станет ещё на 10% ниже. Плюсом подарим курс о развитии карьеры при покупке до 31 июля. Записаться Реклама. ООО “Нетология” ОГРН 1207700135884 Erid: 2VSb5xr3MGE

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

Договорились: ...
Следующий шаг: ...
Жду подтверждения до [дата].

2️⃣Спрашивайте “зачем”, а не “как” Это работает всегда и везде — просто здравый смысл. Приходит менеджер: “Хочу менять цвет строк в таблице”. Спрашиваю зачем. Оказывается — хочет видеть просроченные заказы. Реальное требование: автоматически подсвечивать просрочку. Другая задача, проще и полезнее. Половина изменений при правильном вопросе превращается в уточнение исходного требования, а не в новую задачу. 3️⃣ Показывайте стоимость изменения Когда бизнес приходит с правкой, говорю прямо: “Эта правка затрагивает три модуля, сдвигает сроки на неделю. Готовы?” Важна подача. Не “это дорого и мы не будем делать”, а “давайте я покажу что затронет эта правка — и вы примете решение”. Некоторые заказчики всё равно воспримут это как отказ помочь — но большинство после такого разговора спокойно отправляют правку в следующий релиз. 4️⃣ Приоритизируйте, не складывайте в кучу

Приоритет / Критерий
Срочно и важно / Блокирует работу прямо сейчас
Важно, не срочно / В следующий спринт
Хотелка / В бэклог

Честно: в компаниях где всё “срочно и важно” по умолчанию — эта таблица работает плохо. Но даже там она помогает хотя бы начать разговор о приоритетах. 5️⃣ Договоритесь о правилах на берегу В начале проекта проговариваю с заказчиком: как обрабатываем изменения, когда правка идёт в текущий релиз, а когда в следующий, кто финальный ЛПР. Сложность в наших реалиях: ЛПР часто недоступен, меняется или принимает решения в коридоре после планёрки. В таком случае фиксирую хотя бы того кто есть — пусть не идеально, но лучше чем ничего. ❗️И про внутреннее состояние — это важно Я долго воспринимала каждое изменение как личную неудачу. Значит плохо собрала, не так спросила, недоработала. Потом поняла: идеальных требований не бывает. Иногда проблема вообще не в аналитике — а в том что решения принимаются спонтанно на самом верху, и никакой инструмент это не исправит. Наша ценность не в том чтобы зафиксировать всё раз и навсегда. А в том чтобы управлять изменениями так, чтобы команда не сходила с ума и бизнес получал то что реально нужно. 🧐 Если было полезно, ставьте реакции, буду делиться больше такой информацией)) ___________ Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

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

Переход с 1С: УПП на 1С:ERP: этапы, стоимость и риски ⏳ 6 мин | 🟡⚪️⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT