Системный анализ тогда и сейчас — профессия изменилась, но не так как все думают

Когда я начинала работать аналитиком, основным инструментом был Word, согласование шло по почте, а UML-диаграммы рисовались в Visio и распечатывались на встречи. Серьёзно — распечатывались, потому что показать экран было не так просто.

Сейчас Miro, Confluence, Figma, Notion, и ИИ который за минуту генерирует структуру документа. Всё изменилось — и при этом самое главное осталось ровно таким же.

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

🏎️ Скорость.
Раньше на подготовку документа уходили дни. Сейчас черновик можно собрать за час — ИИ помогает со структурой, шаблонами, формулировками. Это не хорошо и не плохо — это просто новая реальность. Но она повысила ожидания: если раньше "неделя на ТЗ" было нормой, сейчас заказчик удивляется почему так долго.

👩‍💻 Инструменты совместной работы.
Event Storming в Miro с командой из трёх городов — это обычная история. Пять лет назад это было экзотикой. Удалёнка изменила не только где мы работаем, но и как договариваемся и фиксируем решения.

✅ Доступность информации.
Раньше чтобы разобраться в незнакомой предметной области нужно было найти эксперта или перечитать гору документов. Сейчас можно за вечер получить базовое понимание любой отрасли. Порог входа в новую предметную область сильно снизился.

🤔 Размытие ролей.
Граница между аналитиком, продактом и проектным менеджером стала тоньше. Всё чаще аналитик занимается и приоритизацией бэклога, и работой с метриками, и фасилитацией стратегических сессий. Это расширяет возможности — и добавляет неопределённости.

Что не изменилось — и это важно понимать

👥 Люди не изменились.
Заказчики всё так же не могут сформулировать что хотят. Разработчики всё так же хотят чёткие требования. Конфликты интересов всё так же нужно разруливать вручную.
ИИ не научился вытаскивать из технолога знания которые он сам не осознаёт. Не умеет почувствовать что заказчик говорит одно а имеет в виду другое. Не может выстроить доверие с командой которая сопротивляется изменениям.
Всё что связано с людьми — осталось нашим. И судя по тому что я вижу — останется ещё долго.

Что изменилось во мне как в аналитике

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

Про страх который был и прошёл

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

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

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

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Первые две недели на новом проекте — что делать чтобы не облажаться

Салют! Помню своё первое погружение в большой незнакомый проект. Меня посадили, дали доступы к куче систем, скинули ссылку на Confluence где было триста страниц документации и сказали "изучай". Я изучала. Честно. Три дня читала документы и к концу понимала примерно столько же сколько в начале — потому что читала не то и не в том порядке.

С тех пор у меня есть своя система первых двух недель. Делюсь.

День 1-2. Сначала люди, потом документы

Главная ошибка новичков — и моя в том числе — начинать с документации. Документы врут. Не специально — просто устаревают, не обновляются, описывают как должно быть а не как есть.
Первое что делаю на новом проекте — прошу пятнадцать минут с каждым ключевым человеком. Не полноценное интервью, просто познакомиться и задать три вопроса:

— Чем занимаетесь на проекте?
— Что сейчас самое болезненное?
— Без чего проект точно не взлетит?

За два дня таких разговоров получаю картину которую из документов не вытащить за неделю. И сразу понимаю кто реально влияет на решения, а кто формально в списке стейкхолдеров.

День 3-5. Разобраться в предметной области — но не глубоко

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

Что помогает:

— Попросить кого-то из команды объяснить процесс "как будто я первый раз это слышу". Люди любят объяснять — и в процессе сами замечают что некоторые вещи объяснить сложно
— Найти самый главный объект системы — заказ, пациент, договор, заявка — и понять его жизненный цикл. Вокруг него обычно строится всё остальное
— Посмотреть на схему базы данных если есть доступ. Там видно реальную архитектуру, а не ту которую нарисовали в презентации

День 5-7. Найти где болит прямо сейчас

На каждом проекте есть что-то что горит, раздражает или давно висит нерешённым. Найти это — значит быстро стать полезной.

Не жду пока мне скажут. Спрашиваю напрямую: "Что сейчас мешает команде работать быстрее?" или "Есть что-то что давно хотели разобрать но руки не доходили?"

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

День 7-10. Картина целиком

К этому моменту уже есть кусочки пазла от разных людей. Время собрать их вместе.

Рисую для себя — не для документации, просто для понимания:

— Кто главные участники процесса и как они связаны
— Как выглядит основной сценарий от начала до конца
— Где стыки между системами или командами — там обычно и прячутся проблемы

Этот набросок показываю кому-то из команды и прошу покритиковать. "Я правильно понимаю как это работает?" — один из самых продуктивных вопросов в первые две недели.

День 10-14. Договориться как будем работать

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

Пять минут такого разговора в начале экономят часы разборок потом.

Чего точно не стоит делать в первые две недели

— Предлагать "а вот у нас на прошлом проекте было лучше". Даже если правда. Особенно если правда — Брать на себя задачи раньше чем понял контекст — переделывать дороже чем сделать позже но правильно — Молчать когда что-то непонятно. Вопросы в первые две недели воспринимаются как норма. Через месяц — уже нет

Первые две недели задают тон всему проекту. Не потому что за это время нужно всё узнать и всё сделать. А потому что именно тогда формируется первое впечатление — и репутация которую потом долго менять.

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

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Прошло две недели на новом проекте. И что теперь?

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

Примерно на третьей неделе наступает "провал"

Это нормально - но мало кто об этом предупреждает.

В первые две недели всё понятно: знакомишься, изучаешь, задаёшь вопросы. Все помогают и объясняют. Потом негласно ожидается что ты уже "вошла" и должна работать самостоятельно. А вопросов стало только больше - и задавать их уже неловко.

Не переставайте задавать вопросы. Просто меняйте формулировку. Не "объясните как это работает", а "я понимаю это вот так - правильно?" Разница небольшая, воспринимается совсем иначе.

Подводные камни которые вылезают после двух недель

1️⃣ Неформальные лидеры

В любой команде есть люди которые формально не принимают решения - но фактически влияют на всё. Первые два месяца уходят на то, чтобы понять реальную карту влияния. Это не политика ради политики - это понимание как реально работает система вокруг вас.

2️⃣ Накопленный долг.

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

3️⃣ "У нас так не принято".

Спросите почему. Если конкретная причина — принимаем к сведению. Если "ну, просто так сложилось" — это не ограничение, это привычка. С привычками можно работать — но аккуратно и не с наскока.

Как понять что ты на своём месте

Обычно это чувствуется к концу третьего-четвёртого месяца.

➕ Хорошие признаки: к вам приходят с вопросами сами, на встречах вы уже не просто слушаете, начинаете видеть проблемы чуть раньше чем они становятся кризисом.

➖Тревожные признаки: через три месяца не понимаете кто реально принимает решения, чувствуете что вас терпят но не слышат, каждый день ощущение что делаете что-то не то.

Второй список — не приговор. Но сигнал что нужно поговорить с руководителем напрямую. Лучше неловкий разговор сейчас, чем полгода в тумане.

Про новых людей — и почему их не нужно бояться

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

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

Как понять проект по-настоящему

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

Дискомфорт первых месяцев — это не сигнал, что вы не на своём месте. Это сигнал что вы растёте.

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

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Салют! Расскажите как у вас дела с поиском работы и с прохождением собесов?

Рынок сейчас странный — одни говорят, что вакансий нет, другие вышли за месяц. Хочу понять как дела у вас и понять интересна ли данная тема))

Где вы сейчас находитесь?

Ставьте реакции, если:

🙈 - Отправляю резюме — тишина
Отклики уходят в пустоту, даже автоответа нет

🥲 - Резюме не проходит — до собеса не доходит
HR смотрит и не зовёт, или отказ без объяснений

🤔 - Дохожу до собеса, но заваливаю техническое
Со звонком/HR всё ок, а дальше не идёт. Провал либо на техническом, либо на финальном.

👍 - Прошёл(а) без больших проблем
Процесс был адекватным, вышел(а) / оффер получил(а)

👌 - Пока не ищу
Работа есть, в поиск не выходил(а)

❤️ - Просто интересна тема)


Если есть чем поделиться, то го в комментарии 👇))

Итоги опроса — и что дальше

Большинство из вас ответили:

🥲 - резюме отправляется, до собеса не доходит. HR смотрит — и тишина или отказ.

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

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

Про собеседования я уже писала. А вот про резюме — давно собиралась.

✅ Напишу своё видение: что изменилось в последние пару лет, как сейчас правильно составлять резюме аналитику и что точно нельзя упускать.

Так же поделюсь шаблоном резюме, и мы сможем его с вами разобрать))

Скоро 👇

Вклад системного аналитика оценивают не по качеству постановки задач разработчикам. А как тогда?

⏳ 10 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Как проходит техническое собеседование в IT

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

Автор: Александр Стародубцев

⏳ 6 мин | 🟤⚪️⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Что я поняла за первый год работы бизнес-аналитиком

⏳ 5 мин | 🟡⚪️⚪️

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

💙 Analyst IT | 💬 Analyst IT

Как составить резюме, которое не отправят в отказ на первом экране

Салют! Недавно я проводила опрос по поводу поиска работы, и по итогу стало понятно, что сейчас резюме не проходят даже hr. Сегодня немного моих мыслей на этот счет.

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

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

Есть и ещё один страх: резюме и ответы на собеседованиях всё чаще делает ИИ. Шаблонный текст сегодня узнают быстро, и после него с недоверием смотрят на всё остальное. Это мои наблюдения за рынком, не статистика.

Расскажу случай. К нам на техническое собеседование пришёл парень. На каждый вопрос он сначала немного зависал и делал вид, что думает, а потом отвечал ровным монотонным голосом и ровно так, как написано в словаре. И так на все вопросы. Весь собес он то и дело изображал раздумья. Ответы были правильные, но живого человека за ними мы не увидели. Мы поняли, что ему помогает ИИ. Ни одного рабочего примера, ни одной запинки, ни одного «а вот у нас на проекте было так».

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

🤔 Что просят в вакансиях

Я посмотрела свежие вакансии мидл-аналитиков (из больше всего). Чаще всего там; SQL, REST и SOAP, Kafka или MQ, BPMN и UML, Swagger и Postman, Jira и Confluence, ТЗ с нефункциональными требованиями, проектирование БД и участие в приёмке. Много банков и финтеха.
Если вы с этим работали, пишите теми же словами. Не «занималась интеграциями», а «описала REST-интеграцию, оформила спецификацию в OpenAPI». И читайте текст вакансии, а не только грейд: бывает «Middle, 3–6 лет» в заголовке и «не менее 5 лет» в требованиях.

🔫 Что убивает резюме

• Одно резюме на все вакансии.
• Обязанности вместо результатов: «писала ТЗ, взаимодействовала с командой».
• Нет масштаба: непонятно, что за система и какая команда.
• Общие фразы вроде «ответственная, коммуникабельная, нацелена на результат». Они ничего не говорят и выдают сгенерированный текст.

✅ Как собрать резюме

1. Название: «Системный аналитик (Middle)», без «аналитик / BA / PM» через слэш.
2. Сверху 3–4 строки: сколько лет, какие домены, с чем работаете, основной стек.
3. У каждого места работы сначала строка о проекте: что за система, сколько клиентов или интеграций, размер команды. Потом 3–5 пунктов: что сделали и что изменилось.
4. Цифры только настоящие. Нет точных — пишите масштаб: сколько методов API, сервисов, интервью. Слишком красивые круглые числа читаются как придуманные.
5. В навыках указывайте глубину: «Kafka проектировала с нуля, SOAP работала на готовых интеграциях».
6. Один-два обезличенных артефакта по ссылке: схема, фрагмент спецификации. Такое за вас не сгенерируешь.
7. Telegram для связи или другой мессенджер
8. Перед каждым откликом 10 минут на правки под текст вакансии.

Пример
Было: «Участвовала в интеграции с платёжной системой».
Стало: «Описала интеграцию с платёжным шлюзом (REST, 12 методов): спецификация в OpenAPI, идемпотентность платежей, обработка ошибок и повторных запросов, сценарии приёмки. Вопросов от разработки по задаче стало меньше: с ~15 до ~3».

Цифры условные, подставляйте свои.

🤷‍♀️Как быть, если знакомых в индустрии нет

Не ждите, пока вакансию опубликуют. Напишите бывшим коллегам и руководителям, расскажите, что ищете и какую роль. Часть мест закрывается по рекомендации ещё до публикации. А на собеседовании рассказывайте про свои реальные задачи и ошибки, можно и с запинкой: так видно, что опыт ваш.

Как подготовиться к разным собеседованиям (hr, техническое, финальное) я расскажу в след посте 😉

❗️ Шаблон резюме мидла со всеми формулировками выложу попозже

Если было интересно - ставьте реакции

Если есть, что обсудить - пишите в комментах 👇

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Салют! Недавно был пост про резюме и собесы, где я обещала поделиться шаблоном резюме, пришло время

Шаблон резюме системного аналитика (Middle)

Это пример того, как я бы сегодня собирала резюме, если бы искала работу.
Внутри четыре места работы из разных сфер: производство, IT-компания, стартап и финтех. Если у вас опыт только в одной сфере, структура от этого не меняется.

На что смотреть:
• Над каждым местом работы стоит строка о проекте: что за система, какая команда.
• В опыте результат, а не обязанности. Где можно, есть цифры.
• В квадратных скобках названия ссылок. Туда нужно вставить ссылки на ваши обезличенные схемы, фрагменты спецификаций и примеры запросов.
• В навыках указана глубина: что делали с нуля, а с чем работали на готовом.

Компании и цифры в шаблоне вымышленные. Не копируйте его целиком, подставьте свой опыт и свои цифры. Потом перечитайте вслух: если фразу вы не смогли бы так сказать на собеседовании, перепишите её своими словами.

Если соберёте своё резюме, пишите в комментариях, что у вас получилось. Разберём вместе, если вам так удобно 👇)))

Было полезно, ставьте реакции))

❗️Так же в резюме были указаны ссылки на реальные примеры, которые можно оставлять в резюме, если интересны мои, ставьте 🔥 и я поделюсь ими))

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Первое резюме без опыта: что в него писать

Салют! Если вы только заходите в профессию, пустой раздел «Опыт работы» ещё не приговор. Но и просто перечислять курсы не стоит: такие списки есть у всех. Задача резюме новичка в том, чтобы показать, что вы уже думаете как аналитик.

1️⃣ Учебное оформляйте как проекты

Курсы, хакатоны и учебные кейсы описывайте как работу: задача, ваша роль, инструменты, результат.

Было: «Прошла курс по BPMN».

Стало: «Описала в BPMN процесс оформления заказа для учебного интернет-магазина, нашла три места, где процесс обрывается без обработки ошибки».

2️⃣ Соберите портфолио хотя бы из одной работы

Схема процесса, документ с требованиями, описание API-метода, ER-схема, прототип. Положите в папку в облаке с понятными названиями и дайте ссылку в резюме.

Одна открытая работа убедительнее пяти сертификатов.

3️⃣ Используйте прошлый опыт

Если раньше вы работали в бухгалтерии, логистике, поддержке или продажах, это плюс: вы знаете, как устроены процессы изнутри.

Напишите, какие процессы знаете и какие проблемы в них видели.

4️⃣ Навыки только те, что можете показать

В вакансиях чаще всего встречаются SQL, BPMN, описание API, Jira и Confluence. Если пишете SQL, будьте готовы написать запрос на собеседовании.

5️⃣ Короткая структура

Одна страница: заголовок, 3–4 строки о себе, проекты, навыки, образование, ссылка на портфолио и Telegram. Под каждую вакансию меняйте слова на те, что стоят в её тексте.

⛔️ Чего не делать

Не придумывайте опыт: его проверят вопросами на собеседовании. Не берите готовый текст из нейросети: фразы вроде «быстро учусь, ответственная, коммуникабельная» читаются сразу. Пишите своими словами и конкретно.

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

✅ Если нужен пример такого резюме - ставьте реакции и я выложу документ)))

❗️ Если сейчас собираете первое резюме, расскажите в комментариях, что вызывает больше всего вопросов. Разберу самое частое.

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Салют! В продолжении вчерашнего поста делюсь примером резюме новичка.

Героиня — Оксана: пять лет работает диспетчером в логистике и учится на аналитика.

Что в резюме:

• Проекты. Два учебных проекта, оформленные как работа (задача, роль, результат): BPMN и API для интернет-магазина, SQL-анализ заявок службы доставки. У каждого есть место под ссылку в квадратных скобках.

• Прошлый опыт. Работа диспетчером описана через то, что пригодится аналитику: найденные ошибки в отчётах, чек-лист передачи смены, инструкция для новичков.

• Навыки. Только те, что можно показать, с пометкой «на учебных базах», «читаю макеты».

• Остальное. Одна страница и ссылка на портфолио.
Имя, компания и цифры вымышленные (например, 12% заказов, 14 user story).

Примечаний и инструкций внутри документа нет, только текст резюме. Если нужны мои примеры - ставьте реакции))

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA