Analyst IT

Как перейти от монолита к микросервисам без лишнего риска?

🎥 6 октября в 20:00 МСК на открытом уроке разберём практические подходы к переходу от монолита на микросервисы: как определить границы сервисов, выбрать стратегию миграции и не остановить разработку.

На примере покажем, как работать со strangler pattern, декомпозировать систему по доменам, организовать работу с данными и транзакциями и избежать главной ловушки «распределённого монолита».

🔔 Урок проходит в преддверии старта курса «Микросервисная архитектура» и будет полезен backend-разработчикам, архитекторам, техлидам и DevOps-инженерам, которые работают с большими системами и планируют их эволюцию.

Зарегистрируйтесь и разберитесь, как переходить от монолита к микросервисам поэтапно без остановки бизнеса и дорогих архитектурных ошибок: https://clck.ru/3WEKez

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

ИИ уже анализирует данные. Но умеет ли он делать это правильно? Нейросеть может быстро обработать таблицу, найти закономерности и подготовить выводы. Но без правильной постановки задачи легко получить ошибочные расчеты, неверные гипотезы и выводы, которым нельзя доверять.

На открытом уроке 30 сентября в 20:00 МСК разберем, как применять ИИ в анализе данных: от подготовки запроса и очистки данных до поиска аномалий, проверки гипотез и создания аналитических выводов. Вы узнаете, какие задачи можно передать нейросети, как проверять ее результаты и превращать данные в рекомендации для принятия решений.

Урок пройдет в преддверие старта курса «Аналитик данных». Занятие подойдет аналитикам, системным и бизнес-аналитикам, которые хотят сократить рутинные задачи и эффективнее работать с данными.

Освойте практический подход к анализу данных с помощью ИИ и используйте новые инструменты в работе: https://clck.ru/3W43qk

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Как найти причину сбоев внешнего API и исправить её до того, как интеграция попадет в прод

⏳ 7 мин | 🟡🟡⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Не отставайте от рынка — учитесь со скидкой 16%

Если чувствуете, что стоите на месте, и хотите освоить востребованную профессию, — сейчас хороший момент начать.

Потому что до 30 сентября на все курсы Практикума действует скидка 16%. 

Выбрать курс

Вы сможете:

— получить актуальные навыки;
— освоить ИИ-инструменты для работы;
— перенять опыт экспертов, которые двигают индустрию;
— попасть в сообщество выпускников, где можно попросить совета и, возможно, найти будущих коллег.

Просто выберите курс, начните учиться бесплатно и получите скидку 16% — она автоматически появится в личном кабинете. 

Учиться!

Erid: 2SDnjeTSaSP
Название: ООО "ЯНДЕКС"
ИНН: 7736207543

Салют! Что-то я немного выпала из телеграмной жизни, каюсь 😱 и возвращаюсь))

Сегодня погрузимся в тему sql и я для вас собрала небольшую подборку на тему БД:

- SQL для аналитика

- SQL для начинающих: 10 запросов, которые нужно знать каждому аналитику

- SQL в 2026 для аналитика (с чего начать, где учиться и что реально нужно знать)

- Как изучить SQL за ночь или шпаргалка для системного аналитика

- Проектирование БД и почему важен SQL для системного аналитика: гайд по улучшению качества требований

- Вопросы по SQL для подготовки к собеседованию

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Укрощение зоопарка сервисов: как системный подход одной команды повышает надёжность и скорость разработки

⏳ 16 мин | 🟡⚪️⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Аналитика начинается не с дашборда: как понять, какое решение должен поддерживать отчёт

⏳ 6 мин | 🟡⚪️⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Токсичная команда — кто бывает токсичнее всего и как с этим жить

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

1️⃣“Разработчик который считает аналитика лишним звеном”

Классика жанра. Человек искренне убеждён что требования — это лишняя бюрократия и он сам прекрасно разберётся что нужно заказчику. Задачи берёт напрямую, документацию игнорирует, на встречи по требованиям приходит с видом “зачем я здесь”.

Самое неприятное — иногда он технически сильный специалист. И это делает его позицию в команде устойчивой.

Что помогало: не воевать и не доказывать ценность словами. Доказывать делом — находить противоречия в требованиях до того как они станут его проблемой на этапе разработки. Когда человек несколько раз избежал переделок благодаря нормальной аналитике — отношение меняется. Не всегда, но часто.

2️⃣ “Коллега-аналитик который тянет одеяло”

Бывает когда аналитиков на проекте несколько. И один из них активно присваивает чужие идеи, подрезает зоны ответственности, на встречах с руководством говорит “я сделала” там где правильнее было бы “мы сделали”.
Это особенно больно потому что предаёт человек со стороны — тот кто должен быть союзником.

Что помогало: фиксировать своё авторство письменно и своевременно. Отправила предложение — в письме, с датой. Провела анализ — задокументировала с именем. Не из паранойи, а как рабочая гигиена. И никогда не выяснять отношения публично — только один на один и спокойно.

3️⃣ “Саботажник”

Внешне лояльный, на встречах молчит или соглашается. А потом тихо делает всё чтобы изменения не прижились. Затягивает согласования, находит бесконечные причины почему “сейчас не время”, распускает слухи что проект бесполезный.

Это самый сложный тип — потому что его токсичность невидима. Формально не к чему придраться.

Что помогало: выяснить причину. Саботаж почти всегда про страх — потерять влияние, привычный процесс, статус. Один честный разговор тет-а-тет иногда решал больше чем месяц борьбы. Не всегда — но попробовать стоило всегда.

4️⃣ “Вечно негативный”

Любая идея встречает “это не сработает”. Любое решение — “мы уже пробовали, бесполезно”. Любое изменение — “опять за своё”.
Сам ничего не предлагает. Но чужие инициативы топит с завидной регулярностью.

Такой человек особенно опасен на этапе сбора требований — его скептицизм заражает остальных и убивает открытость которая нужна для честного обсуждения.

Что помогало: не спорить на общих встречах. Задавать вопрос: “Хорошо, это не сработает — а что по-вашему сработает?” Переводить энергию скептицизма в конструктив. Иногда получалось — оказывалось что за вечным негативом прячется человек с реальным опытом и болью от прошлых неудачных проектов.

5️⃣ “Звезда”

Технически сильный, это знает и регулярно напоминает окружающим. Чужое мнение не интересно, на ревью документов снисходит — с видом одолжения. Если что-то идёт не так — виноваты все кроме него.

С такими людьми сложно потому что они часто правы технически. Это даёт им уверенность что можно не считаться с остальными.

Что помогало: апеллировать к их же логике. Не “ваш подход неправильный” а “помогите понять — вот этот сценарий ваш вариант покрывает?” Звёзды любят демонстрировать экспертизу — используйте это. Пусть объясняют. В процессе объяснения часто сами находили слабые места.

Кто токсичнее всего — если честно

Из всего опыта самым разрушительным для команды был не громкий конфликтный человек — а тихий саботажник. Потому что с открытым конфликтом можно работать. Тихое сопротивление незаметно разрушает доверие и атмосферу — и к моменту когда это становится видно урон уже нанесён.

А с какими токсиками работали вы? Или может кто-то ту сам токсик?

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Как ИИ изменил собеседования для аналитиков — и что теперь с этим делать

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

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

Я поняла о чём она. ИИ изменил собеседования — причём с обеих сторон стола.

Что изменилось со стороны кандидата

Раньше подготовка к собеседованию занимала недели. Нужно было вспомнить методологии, освежить термины, прогнать в голове кейсы. Сейчас 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

Синдром самозванца в профессии аналитика — как я с этим жила

Салют! Расскажу про то, о чём в профессиональных каналах обычно не пишут. Не про инструменты, не про методологии. Про внутреннее состояние которое преследовало меня несколько лет и которое, как выяснилось, знакомо большинству аналитиков.

Синдром самозванца. Ощущение что ты недостаточно компетентна, что тебя вот-вот разоблачат, что остальные знают что-то важное чего не знаешь ты.

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

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

Спойлер: не должен. Но тогда я этого не понимала.

Характерные симптомы которые я у себя замечала:
— Боялась задавать “глупые” вопросы на встречах
— Переписывала письма по десять раз прежде чем отправить
— Когда что-то получалось хорошо - думала что просто повезло
— Когда что-то шло не так - была уверена что это только моя вина
— Сравнивала себя с коллегами и всегда была не в свою пользу

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

Что реально помогло

1️⃣ Разрешила себе не знать всего
Звучит банально. Но мне реально пришлось внутренне договориться с собой: я не обязана знать всё про архитектуру, про DevOps, про финансовую модель заказчика. Я обязана знать своё дело хорошо и уметь задавать правильные вопросы нужным людям.
“Не знаю, давайте разберёмся вместе” — это не слабость. Это профессиональная честность.

2️⃣ Начала вести список того что сделала хорошо
Не для резюме. Для себя. Буквально блокнот где я записывала: вот здесь я нашла противоречие в требованиях до того как оно стало проблемой. Вот здесь помогла разрулить конфликт между командами. Вот здесь заказчик сказал что это лучшая документация которую он видел.
Когда накрывало сомнениями — открывала и перечитывала. Работало.

3️⃣ Поговорила с коллегами
Оказалось что опытные аналитики которым я завидовала — чувствовали то же самое. Просто не говорили об этом вслух. Один разговор по душам с коллегой которая была в профессии семь лет снял с меня какое-то внутреннее напряжение которое я носила месяцами.
Мы все притворяемся что знаем больше чем знаем. Это нормально. Ненормально думать что ты одна такая.

4️⃣ Перестала сравнивать себя с чужими достижениями
Соцсети и профессиональные каналы показывают лучшее. Никто не пишет “сегодня я провалила встречу и не смогла ответить на половину вопросов”. Все пишут про успехи, про крутые проекты, про сертификаты.
Я сравнивала свою внутреннюю кухню с чужим парадным фасадом. Это заведомо проигрышная игра.

Что поняла спустя двенадцать лет

Синдром самозванца не исчезает полностью. Он просто меняет форму. Сейчас я могу провести сложнейшее интервью с производственниками, написать архитектурное описание интеграции, выступить перед советом директоров — и всё равно иногда поймаю себя на мысли “а вдруг я что-то важное упустила”.
Разница в том что раньше эта мысль меня парализовала. Теперь я её замечаю, киваю ей и иду делать своё дело.

❗️Если вы аналитик и узнали себя в этом тексте — вы не одни. И то что вы сомневаетесь в себе скорее всего означает что вы достаточно вдумчивы чтобы видеть собственные пробелы. Это не слабость. Это качество хорошего специалиста.

Если было полезно, ставьте реакции 😉

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Замороженная работа: метрика, которая считает непринятые решения

⏳ 9 мин | 🟡🟡⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Что в работе аналитика поменялось за пять лет, а что только в вакансиях

⏳ 5 мин | 🟡⚪️⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Как аналитик выживает между бизнесом и разработкой

Салют! Есть шутка в профессии: аналитика не любят ни бизнес ни разработка. Бизнес считает что ты на стороне IT и тормозишь. Разработка считает, что ты на стороне бизнеса и генеришь бесконечные хотелки. А ты стоишь посередине и пытаешься сделать так чтобы все были живы.
Я провела в этой позиции двенадцать лет. И да, первые несколько лет это реально выматывало. Потом поняла несколько вещей которые изменили отношение к этой роли.

Ты не переводчик. Ты модератор конфликта интересов

Долгое время я думала, что моя задача — переводить с языка бизнеса на язык разработки и обратно. Технически это так. Но если смотреть глубже — аналитик работает в точке где сталкиваются два мира с разными целями.
Бизнес хочет всё, быстро и желательно вчера. Разработка хочет чёткие требования, стабильный скоуп и время сделать нормально. Эти желания почти никогда не совпадают полностью.
Главная ловушка — пытаться угодить всем. Это невозможно. И попытка усидеть на двух стульях приводит к тому что не доверяют ни те ни другие.
Баланс который я нашла: моя лояльность не людям, а результату. Я на стороне проекта — не бизнеса и не разработки. Звучит просто, но внутри перестроиться непросто.

Что реально помогает
Не передавай требования — объясняй контекст

Худшее что может сделать аналитик — принести разработчику список требований без контекста. “Бизнес сказал сделать вот так.” Всё, ты стала почтальоном.
Разработчик должен понимать зачем это нужно, какую проблему решает, что будет если сделать иначе. Когда человек понимает зачем — он предлагает решения лучше тех что придумал бизнес. И это победа для всех.
Не ходи к разработке с сырыми требованиями
Прежде чем идти к команде я сама прохожусь по требованиям и задаю себе неудобные вопросы. Что будет если пользователь сделает вот так? А если данных нет? А если два пользователя одновременно? Какой сценарий если что-то пошло не так?
Лучше найти дыры самой, чем услышать их на разборе задач с командой. Разработка это запомнит — в хорошем смысле.
Когда бизнес и разработка конфликтуют — не исчезай
Самый плохой сценарий: бизнес и разработка начинают выяснять отношения, а аналитик тихонько выходит из чата. Я так делала. Казалось что конфликт не мой.
Мой. Потому что в основе почти любого конфликта между бизнесом и разработкой — неточные или противоречивые требования. Разруливать это всё равно придётся, только потом и с большими потерями.
Сейчас я захожу в такие конфликты первой. Не чтобы встать на чью-то сторону, а чтобы вытащить на поверхность в чём реальное расхождение. Часто оказывается что люди спорят об одном и том же просто разными словами.

Фиксируй решения принятые не тобой

Бизнес принял решение которое технически сомнительное. Разработка приняла архитектурное решение которое ограничивает функциональность. Ты была на встрече, слышала, высказала мнение — но решение не твоё.
Фиксируй письменно. Не чтобы потом сказать “я же говорила”. А чтобы когда через три месяца это аукнется — был контекст почему так получилось и кто был в курсе. Это защищает всех, не только тебя.

Не бери на себя ответственность за чужие решения

Это отдельный пункт потому что он про границы. Аналитик отвечает за качество требований и за то что все стороны правильно поняли друг друга. Аналитик не отвечает за бизнес-решения заказчика и за технические решения разработки.
Граница тонкая, но важная. Когда её нет — выгораешь быстро.

Про эмоциональную сторону — это тоже важно

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

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Можно ли аналитику в 2026 году положиться на ИИ и агентов или ещё нет?

⏳ 15 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

4 ошибки в A/B‑тестах, из‑за которых случайный шум выглядит как эффект

⏳ 8 мин | 🟡🟡⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Как работать с требованиями которые меняются — без нервов и переработок

Салют! Помню проект, где требования менялись так часто, что я перестала распечатывать документацию — смысла не было. Разработчики смотрели на меня с немым вопросом, я смотрела на бизнес с тем же вопросом.

❗️Тогда поняла: проблема не в том что требования меняются. Они всегда будут меняться. Проблема в том как ты выстраиваешь работу с ними.

Сразу честно: ни один инструмент не спасёт если в компании хаос на уровне управления. Но даже в таких условиях правильный подход помогает выжить с меньшими потерями для себя и команды. И это тоже результат.

Почему требования меняются — без прикрас

— Бизнес не знал чего хочет до конца. Это нормально — люди часто понимают что им нужно только увидев первый результат
— Изменился контекст: рынок, конкурент, законодательство, новый руководитель с другим видением
— Требования были размыты с самого начала — вот это уже наша зона ответственности

Злиться на второй пункт бессмысленно. Над третьим работать — полностью в наших силах.

Что реально помогает (или помогало в моем случае):

1️⃣Фиксируйте договорённости сразу

Любое решение с встречи — в письмо в тот же день. Люди искренне забывают что говорили три недели назад, это не злой умысел.
Иногда такая фиксация воспринимается в штыки: “ты мне не доверяешь?” Я на это отвечала спокойно: “Доверяю, просто у меня плохая память” — обычно разряжало обстановку.

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



2️⃣Спрашивайте “зачем”, а не “как”

Это работает всегда и везде — просто здравый смысл.
Приходит менеджер: “Хочу менять цвет строк в таблице”. Спрашиваю зачем. Оказывается — хочет видеть просроченные заказы.
Реальное требование: автоматически подсвечивать просрочку. Другая задача, проще и полезнее.
Половина изменений при правильном вопросе превращается в уточнение исходного требования, а не в новую задачу.

3️⃣ Показывайте стоимость изменения

Когда бизнес приходит с правкой, говорю прямо: “Эта правка затрагивает три модуля, сдвигает сроки на неделю. Готовы?”
Важна подача. Не “это дорого и мы не будем делать”, а “давайте я покажу что затронет эта правка — и вы примете решение”. Некоторые заказчики всё равно воспримут это как отказ помочь — но большинство после такого разговора спокойно отправляют правку в следующий релиз.

4️⃣ Приоритизируйте, не складывайте в кучу

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

Честно: в компаниях где всё “срочно и важно” по умолчанию — эта таблица работает плохо. Но даже там она помогает хотя бы начать разговор о приоритетах.

5️⃣ Договоритесь о правилах на берегу

В начале проекта проговариваю с заказчиком: как обрабатываем изменения, когда правка идёт в текущий релиз, а когда в следующий, кто финальный ЛПР.
Сложность в наших реалиях: ЛПР часто недоступен, меняется или принимает решения в коридоре после планёрки. В таком случае фиксирую хотя бы того кто есть — пусть не идеально, но лучше чем ничего.

❗️И про внутреннее состояние — это важно

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

🧐 Если было полезно, ставьте реакции, буду делиться больше такой информацией))
___________

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Как использовать Kafka на собеседовании по System Design

⏳ 17 мин | 🟡⚪️⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT