Business | System analyst

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

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

Хочу понять, кто застал эпоху перехода на ИИ в работе ИТ

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

📊От основ и внедрения ИИ в аналитическую работу до защиты реального проекта за 136 часов обучения на курсе «Бизнес-аналитик в ИТ». 🎁 Записывайтесь на 3 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам! 1⃣28 сентября, 20:00 мск — «Инструменты ИИ в работе бизнес-аналитика»: разберём, какие ИИ-инструменты применяют в сборе требований и анализе данных, покажем примеры промптов и границы между пользой и риском. 2⃣15 октября, 20:00 мск — «Цели и метрики как одно целое»: разберём связь целей и метрик, инструменты для их согласования и почему ошибки в целях обесценивают даже точные метрики. 3⃣22 октября, 20:00 мск — «Управление изменениями требований»: обсудим, как выстроить процесс управления требованиями, чтобы изменения не разваливали скоуп проекта, и как держать реестр требований в порядке. Записывайтесь ➡ https://clck.ru/3W67dz Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

«Подождём модель поумнее» — не самая грамотная стратегия работы с ИИ, и вот почему Салют! Досмотрела выпуск подкаста «Доверительный интервал» про ИИ в аналитике — там прозвучала мысль, которую я бы распечатала и повесила над монитором каждому, кто мыслит так: «вот выйдет суперумная модель — тогда и начну юзать ИИ». По факту работать со слабыми моделями полезно: на них оттачивается главный навык — чётко объяснять контекст. Если этого навыка нет, умная модель не спасёт. Слабая на плохом контексте просто ошибётся — и ты это заметишь. Умная ошибётся красиво и уверенно — так, что ты ей поверишь.  🧐Поэтому контекст — это не «написать промпт подлиннее» Важно не просто формулировать задачу, а формализировать сам контекст. Это тоже затронули в подкасте — и вот как это выглядит на практике в Яндексе:  1️⃣ База знаний аналитики. Описанные данные, метаданные, методологии расчёта метрик, уже построенные дашборды. Первые ~70% базы наполнила команда внедрения, дальше аналитики сами докидывают свои скиллы и контекст. То есть это живой репозиторий, а не вики, которую один раз написали и забыли. 2️⃣ Golden Set и канонические SQL-запросы. Эталонные запросы и каталог метрик, на которые агент опирается, а не выдумывает с нуля. По сути — ответ на главную боль: «модель написала SQL, который выглядит рабочим, но считает метрику не по нашей методологии». 3️⃣ «Спека» как продукт. В подкасте это сформулировано так: «продукт не финальный, а спека» — то есть результатом работы становится единый документ, описывающий, что нужно от агента. Не дашборд сам по себе, а спецификация, по которой агент его соберёт — сегодня, завтра и после того, как ты ушла в отпуск. 4️⃣ Инфраструктура подключения. Единый интерфейс, который через MCP цепляется к внутреннему репозиторию, трекеру и вики — и новому сотруднику команда «learn» просто устанавливает весь набор скиллов разом. Онбординг аналитика в контекст команды стал скриптом, а не тремя месяцами расспросов коллег. ❗️ Что из этого следует лично для нас Умение работать с агентом — это скилл выписать из своей головы то, что ты держал там годами: какие данные брать, по какой методологии считать, где лежит описанная таблица, а где — бизнес-договорённость, о которой знают два человека в команде. Знакомо? Это ровно то же самое, что ставить задачу джуну или подрядчику. С людьми мы понимаем: «ну он же не телепат, ему надо объяснить». А от модели многие почему-то ждут подобной магии. А вы уже описываете контекст для инструментов — или всё ещё держите его в голове?

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

Нотация C4: полный гайд по моделированию архитектуры с примерами, разбором ошибок и промптом для ИИ ⏳27 мин | 🟤🟤⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA

Салют! Что-то я немного выпала из телеграмной жизни, каюсь 😱 и возвращаюсь)) Сегодня погрузимся в тему sql и я для вас собрала небольшую подборку на тему БД: - SQL для аналитика - SQL для начинающих: 10 запросов, которые нужно знать каждому аналитику - SQL в 2026 для аналитика (с чего начать, где учиться и что реально нужно знать) - Как изучить SQL за ночь или шпаргалка для системного аналитика - Проектирование БД и почему важен SQL для системного аналитика: гайд по улучшению качества требований - Вопросы по SQL для подготовки к собеседованию Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

SQL на собеседованиях спрашивают все. Но зачем он аналитику на самом деле? Салют! Когда я только пришла в профессию, SQL казался мне чем-то из мира разработчиков. Ну запросы и запросы, это же не моё. Я аналитик, я работаю с требованиями и людьми. Потом был проект, где нужно было понять почему в отчёте расходятся цифры. Разработчик занят, дедлайн завтра, заказчик ждёт. Я открыла базу, написала запрос — и нашла проблему за двадцать минут сама. После этого моё отношение к SQL изменилось навсегда. 🧐 Почему его спрашивают на каждом собеседовании Не потому что аналитик будет писать сложные запросы каждый день. А потому что человек, который понимает SQL, понимает как устроены данные — связи между таблицами, почему один показатель может считаться по-разному в зависимости от того как написан запрос. Это не про синтаксис. Это про понимание системы изнутри. ‼️ Где SQL реально нужен в работе (исходя из личного опыта) 1️⃣ Когда цифры не сходятся. Заказчик говорит пять тысяч пользователей, разработчик говорит три тысячи. Без SQL будете ждать пока кто-то найдёт время разобраться. С SQL — проверите сами за десять минут. 2️⃣ Когда хочешь понять как устроена система. Схема базы данных показывает всё — какие сущности есть, как они связаны, что главное а что вспомогательное. Я до сих пор начинаю знакомство с новой системой именно с этого. 3️⃣ Когда пишешь требования к данным. Понимая как хранятся данные, формулируешь точнее. Не "показывать историю заказов", а "выбирать заказы по userId, отсортированные по дате, исключая удалённые". Разработчику не нужно додумывать. 4️⃣ Когда принимаешь задачу. Разработчик говорит "всё сделано". Пишешь запрос и смотришь реальные данные — не через интерфейс который может скрывать проблемы, а напрямую. ✅ Какой уровень нужен аналитику (в основном мне хватало, но сложные задачи никто не отменял) SELECT, WHERE, JOIN, GROUP BY, простые агрегаты — этот набор закрывает 80% задач. Остальное по ситуации. Пример: SELECT u.name, COUNT(o.id) AS order_count FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'active' GROUP BY u.id, u.name ORDER BY order_count DESC Писать хранимые процедуры и оптимизировать запросы не нужно — это работа разработчика. ❓ Почему некоторые говорят что SQL им не нужен Либо они работают там где уже есть готовые дашборды — Power BI, Tableau, Metabase — и данные подготовлены заранее. Такое бывает. Либо просто привыкли по любому вопросу про данные идти к разработчику. И не замечают насколько от него зависят. Это не "SQL не нужен". Это "не пробовала разобраться сама". SQL делает аналитика самостоятельным. Не ждёшь пока кто-то найдёт время ответить — идёшь и смотришь сама. В нашей профессии это и есть ценность. Если было полезно, ставьте реакции Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA