Теперь предстоит самое важное – показать себя в живом разговоре. Здесь не помогут аккуратные таблицы навыков и выученные формулировки: проверяют не только знания, но и то, как вы мыслите и общаетесь.

Только не бойтесь!

Я и моя команда экспертов школы системного анализа провели десятки собеседований с кандидатами. Мы видели, какие ошибки совершают даже сильные специалисты, и какие детали решают исход встречи. В этой статье я расскажу, как представить себя HR-у и будущему руководителю с лучшей стороны – чтобы выбрали именно вас.

Перед собеседованием: системная подготовка

Подготовка к собеседованию – это уже проявление системного мышления. Вы должны не просто выучить «что отвечать», а понять, как устроен сам процесс интервью. У него, как у любой системы, есть цели, роли и связи.

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

Перед встречей я рекомендую сделать короткий анализ контекста:

Важно! Интервьюер мгновенно чувствует, когда кандидат не изучал компанию. Даже два предложения про продукт показывают, что вы умеете готовиться. Для аналитика это обязательный навык.

Во время интервью: как говорить и как слушать

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

Говорите спокойно, без спешки. Если вопрос сложный, сделайте паузу и структурируйте ответ:

1. Контекст – «На прошлом проекте мы…»
2. Действие – «Я проанализировала процесс и нарисовала схему…»
3. Результат – «Это помогло бизнесу сократить время согласования».

Такой ответ читается как мини-кейс и сразу показывает, что вы мыслите системно. Если вопрос звучит неясно, уточняйте. Например:

«Правильно ли я понимаю, речь о функциональных требованиях или о взаимодействии с пользователем?»

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

О чем чаще всего спрашивают

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

Технический

На этом этапе интервьюер оценивает, насколько уверенно вы работаете с инструментами системного анализа: UML, BPMN, REST, SQL и другими. Вас могут попросить объяснить, как описать интеграцию CRM с ERP или спроектировать API.

Кейсовый

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

В данном кейсе, например, следует помнить, что покорное согласие с запросом заказчика — не всегда верное решение. Если есть наилучший вариант — аргументируйте и продвигайте его: так вы покажете, что заинтересованы в конечном результате проекта.

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

Поведенческий

Этот блок показывает, как вы реагируете на неопределенность и стресс. Вас спросят о конфликтах, ошибках или сложных коммуникациях в команде. Например: «Как вы действуете, если разработчик не согласен с вашим решением?» Здесь важно показать спокойствие, способность слушать, аргументировать и искать решение, а не победу в споре.

Вот краткий ориентир:

Как производить впечатление зрелого аналитика

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

Неверно: «Я всегда правлю требования, если считаю их некорректными.»

Верно: «Если вижу противоречие, я сначала обсуждаю его с заказчиком и фиксирую решение.»

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

Важно! Хороший аналитик – это человек, который умеет оставаться логичным даже в неловких ситуациях. На собеседовании это проявляется сильнее, чем в любом тестовом задании.

После собеседования: что сделать обязательно

Если встреча прошла успешно – поблагодарите интервьюеров. Если нет – все равно поблагодарите и проанализируйте опыт. Это не просто вежливость, а профессиональный подход: вы фиксируете результат итерации и формируете обратную связь, как после ретроспективы проекта. Даже краткое письмо вроде «Спасибо за уделенное время, разговор был полезен» оставит о вас впечатление зрелого специалиста.

Советую вам сразу после интервью записывать три пункта:

• Какие вопросы вызвали затруднение;
• Что удалось особенно хорошо;
• Что стоит пересмотреть в следующем ответе.

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

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

Вместо заключения

Собеседование – это мини-модель будущей работы. Здесь, как и в проекте, есть цель, участники, артефакты и неопределенность. Если вы умеете уточнять, структурировать и держать разговор логично – вы уже действуете как системный аналитик.

Я часто повторяю своим студентам: «Не нужно казаться идеальным кандидатом. Достаточно быть тем, кто умеет думать.»

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

Кому это будет нужно:

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

Откуда растёт проблема

Прежде чем описывать решение, давайте поймем контекст.

Перед релизом любой фичи команда готовит поставку: у разработчика — code review, у аналитика — ревью документации. Весь процесс идёт по workflow в Jira, и один из обязательных этапов — Docs review.

За этот этап отвечают платформенные аналитики: они дежурят по очереди и проверяют поставки. Их задача — убедиться, что документация написана по стандарту и отражает все новые изменения по продуктам. Хранится всё в едином Confluence-пространстве платформы, и порядок там очень нужен: документацию читают не только аналитики разных команд, но и саппорт.

Звучит адекватно. Но на практике вылезают три проблемы:

1. Задержки. У платформенного аналитика помимо ревью куча других задач. Когда поставок много — Docs review начинает тормозить весь процесс подготовки к релизу.
2. Усталость ревьювера. Большой поток однотипных проверок выматывает даже самого внимательного, поэтому риск нужно было сократить.
3. Человеческий фактор. Несмотря на наличие стандарта, разные ревьюверы могут расставлять акценты по-разному. Аналитик продуктовой команды никогда не знает наверняка, на что обратят внимание в этот раз.

Всё это бьёт по времени поставки и непонятно растягивает подготовку к релизу — особенно когда релизиться нужно быстро.

Что пробовали раньше

Прежде чем идти в сторону AI, рассмотрели два очевидных варианта.

Вариант 1: убрать ревью совсем.

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

Вариант 2: алгоритмическая автоматизация без AI.

Теоретически можно написать набор проверок на if-else. Но у документации нет синтаксиса, как у кода — каждый аналитик пишет немного по-своему. Поддержка такого алгоритма со временем станет дороже, чем просто делать ревью руками.

Почему AI-агент

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

Вот конкретные факты, которые мы собрали внутри команды:

• LLM умеет понимать суть написанного, а не только искать точные совпадения, если документация написана по-разному — для нейронки это не проблема.
• Когда требования меняются, в большинстве случаев достаточно поправить промпт. Аналитик справится сам, без участия разработчика.
• У агента одна задача — ревью, он делает её сразу, не надо ждать, пока освободится дежурный аналитик.
• Агент интегрируется в существующий Jira-workflow. Для команд ничего не меняется — агент работает в фоне.
• У агента понятный набор инструкций.

Архитектура агента

Desmond — экосистема агентов. Desmond Docs Reviewer — task-oriented AI-агент для автоматизации ревью внутренней документации на платформе Альфа-Онлайн.

Стек:

• Язык: Java 21 + Spring AI
• Инфраструктура: Docker + Kubernetes во внутреннем AI-кластере банка
• Модель: gpt-oss-120b — внутренний продукт банка AlfaGen, развёрнутый локально
• Интеграции: Jira (webhook + REST API + Kafka), Code Review Agent (A2A через MCP), LLM API

Точка входа — webhook из Jira. Задача переходит в нужный статус → триггерится webhook → агент получает событие и начинает работу.

На входе агент имеет три сущности:

• описание изменений (фича)
• ссылку на документацию в Confluence
• ссылку на Pull Request разработчика

Дальше — четыре шага.

Как агент решает задачу пошагово

Посмотрим на работу агента со стороны процесса и распишем детально каждый.

Шаг 1. Нужна ли вообще проверка?

Первое, что делает агент — определяет, техническая это доработка или бизнесовая. Если изменения затрагивают только код и не меняют бизнес-логику — документацию обновлять не нужно, а значит и проверять нечего.

Агент анализирует описание задачи и diff PR. Смотрит на примеры из промпта и выдаёт решение: техническая доработка или нет, плюс короткое обоснование — не больше 30 слов.

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

На реальных задачах получили 89,7% корректных ответов (27 из 30). Для старта приемлемо, но будем улучшать.

Если доработка техническая — агент пишет комментарий в задачу и переводит её в следующий статус. Дальше не идёт.

Общий сценарий в коде выглядит так:

Шаг 2. Есть ли в документации описание фичи?

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

Отдельно проверяется раздел «7. История изменений» — изменение должно быть там зафиксировано.

Проблема с токенами. Документация бывает большой — и она не влезает в контекст целиком. Решение: разбить на чанки и анализировать по частям.

Стратегия нарезки простая — равномерно по количеству символов, семантическое деление по разделам здесь не критично: мы ищем одни и те же фрагменты вне зависимости от их положения в структуре.

Чтобы не терять контекст на границах, используем перекрытие (overlap): к каждому чанку добавляем хвост предыдущего и заголовок его раздела. Размер чанка рассчитывается по формуле с коэффициентом, подобранным эмпирически — с запасом на колебания длины токенов.

Смысл её в том, чтобы заранее рассчитать максимально допустимое количество символов на чанк (C_chunk), включая резерв под перекрытие (C_dup) и заголовок. Коэффициент r был подобран эмпирически — с запасом, чтобы учесть возможные колебания в длине токенов.

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

Пример ответа, когда описание фичи найдено:

Пример ответа, когда описание фичи не найдено:

Шаг 3. Соответствует ли документация стандарту?

Это самая сложная часть — со звёздочкой. Нужно пройтись по каждому разделу документа и сверить его с требованиями стандарта. Документация структурирована: шапка, основная информация, предусловия, постусловия, сценарии использования, алгоритм, подробное описание, история изменений.

Возьмем кусочек стандарта, описывающий шапку страницы:

Стандарт для LLM — это не то же самое, что стандарт для людей

Когда мы первый раз запустили проверку, скормили агенту существующий стандарт как есть. Результат нам не понравился: LLM интерпретировала одни и те же требования по-разному, часть пунктов игнорировала, часть выполняла непредсказуемо.

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

Вот типичные вопросы, на которые у стандарта не было ответа:

• Ссылка на команду — это Confluence, Notion или Jira?
• Jira-ссылка — это макрос или обычный URL?
• Как проверить корректность ссылки на репозиторий?
• Всегда ли обязательна эта таблица, или бывают исключения?

Переписали стандарт в LLM-читаемый формат, руководствуясь простыми принципами:

• Каждое требование сформулировано явно и однозначно.
• Для каждого поля приведены примеры правильного и неправильного заполнения.
• Никаких «подразумевается» и «как правило».

Вот как выглядит фрагмент переписанного стандарта для шапки документа:

Кусочек 2

Кросс-раздельные проверки

Часть требований касается не одного раздела, а согласованности между несколькими. Например: все сервисы, упомянутые в колонке Git Middle шапки, должны иметь ссылку на документацию в разделе «Основная информация».

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

Один из примеров кросс-проверок:

Chunking strategy

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

Дано:

• LLM-читаемый формат, разбитый по разделам
• Документация, также структурированная по разделам

Решение:

1. Разделяем на чанки документацию. 1 чанк = 1 раздел.

2. Разделяем на чанки стандарт. 1 чанк = 1 требование.

3. Сопоставляем чанки стандарта и документации между собой:

Проверка оформления:

1 чанк (раздел) документации ~ 1 чанку стандарта (требование к разделу).

Кросс-проверки:

1 чанк кросс-проверки (отдельный раздел с кросс-проверками) ~ n чанкам (разделам) документации.

4. Отправляем в LLM запросы на проверку по каждому соответствию.

5. Собираем в единый отчет.

Примеры:

Проверка оформления

• 1 чанк стандарта

• 1 чанк документации (представлено графически для наглядности. В реальности данные передаются в LLM в HTML-формате)

Кросс-проверка

• 1 чанк стандарта:

• 2 чанка документации:

Чанк 1

Чанк 2

Итоговый промпт:

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

Как выглядит код:

Мы видим, что при использовании чанков LLM перестала пропускать требования, проверки стали стабильнее, ответы — содержательнее.

Пример ответа LLM до чанкования в свободном формате:

Пример ответа LLM после чанкования в JSON-формате. Приведу пример анализа только одного чанка (раздел Алгоритм), т.к. в сумме по чанкам получается тот самый объёмный текст длиной в 200-250 символов.

А что если раздел слишком большой?

В таком случае мы используем chunking strategy из шага 2 и агрегируем результаты с помощью немного сумасшедшего 💊, но работающего промпта.

Агент отправляет запрос на проверку по каждому соответствию, затем собирает всё в нормальный отчёт. Изначально отчёт выходил на 200–250 строк — неудобно читать, мы добавили отдельный шаг финального саммари — сократили до 50 строк без потери содержания.

Технические грабли

Нестабильность ответов LLM

Одна из первых проблем — LLM отвечала в произвольном формате. Иногда JSON, иногда текст, иногда что-то среднее. Решение: Structured Output в Spring AI. Ответ всегда приходит в заданной структуре — никакой самодеятельности.

Лимит токенов

Встречается на обоих шагах, но по-разному. На шаге поиска фичи — документация слишком большая целиком. На шаге проверки стандарту — в контекст не влезают и документ, и стандарт одновременно. В обоих случаях решение — chunking с правильно рассчитанным размером и overlap.

Скрытые элементы Confluence

Confluence отдаёт HTML, и часть контента скрыта в элементах, которые не видны при обычном просмотре страницы. Агент работает напрямую с HTML, в котором остаются только нужные для обработки теги — это позволяет не терять данные, которые визуально не отображаются

Долгое время обработки

Первые версии работали медленно: несколько запросов к LLM шли последовательно. Переключились на Java Virtual Threads — параллельная обработка чанков сократила медианное время ревью с 1:20 до 0:26.

Как это выглядит в коде:

Что конкретно упростилось

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

Ограничения

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

Что дальше

Идеи в работе и на горизонте:

• Автоматический аппрув документации, если все проверки прошли успешно.
• Подключение проверок документации по микросервисам, не только фронтенд.
• Проверка полноты документации через код — что позволит закрыть ревью почти полностью, за исключением нестандартных кейсов.

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

1. Первая волна (1950-1970): автоматизация вычислений и зарождение системного анализа

Технологический ландшафт:

• Мейнфреймы и перфокарты.

• Языки программирования низкого уровня (COBOL, Fortran). Первые базы данных (IBM IMS, 1966)

Требования рынка:

• В эту эпоху IT был уделом узких специалистов — инженеров, способных «общаться» с машинами на их языке. Ключевым требованием было глубокое понимание аппаратной части и умение оптимизировать крайне ограниченные вычислительные ресурсы.

IT-рынок труда:

• Крайне узкий сегмент, доступный только специалистам с инженерным образованием.

• Практически отсутствует конкуренция за рабочие места — спрос значительно превышает предложение.

• Зарплаты в 2-3 раза выше средних по экономике (аналогично современным «золотым воротничкам»).

Появление аналитиков:

• Прообразом современных аналитиков стали «системные аналитики», которые переводили бизнес-задачи на язык машинных инструкций. Их роль была технической — декомпозиция задач для программистов. Анализ ограничивался оптимизацией алгоритмов и распределением памяти.

• Пример: В банковском секторе системные аналитики проектировали схемы обработки транзакций, сократив время операций с дней до часов.

2. Вторая волна (1970-1990): децентрализация и первые корпоративные системы

Технологические прорывы:

• Персональные компьютеры
• Электронные таблицы (VisiCalc)
• Прообразы CRM (ACT! 1987)
• Начало ERP-систем (SAP R/2)Требования рынка:
• Умение адаптировать технологии для бизнес-пользователей
• Развитие интерфейсов «человек-машина»
• Понимание основ бизнес-процессов
• IT-рынок труда:
• Появление массового спроса на IT-специалистов в бизнесе
• Формирование «рынка кандидата» — компании конкурируют за ограниченное число специалистов
• Зарождение IT-рекрутинга как отдельного направления
• Начало гендерного дисбаланса — доля женщин в IT падает с 30-40% до 15-20%
• Выпускники компьютерных специальностей получали 2-3 оффера до окончания вузаЭволюция анализа:
• Появление «бизнес-аналитиков» как моста между IT и менеджментом
• Аналитики начинают работать с требованиями стейкхолдеров
• Возникает необходимость в первичной документации процессов
• Формируются первые методики сбора требованийПример: Внедрение Excel потребовало от аналитиков не только технических навыков, но и понимания финансовых моделей, что сократило ошибки в расчетах на 90%.

IT-рынок труда:

• Появление массового спроса на IT-специалистов в бизнесе
• Формирование «рынка кандидата» — компании конкурируют за ограниченное число специалистов
• Зарождение IT-рекрутинга как отдельного направления
• Начало гендерного дисбаланса — доля женщин в IT падает с 30-40% до 15-20%
• Выпускники компьютерных специальностей получали 2-3 оффера до окончания вуза

Эволюция анализа:

• Появление «бизнес-аналитиков» как моста между IT и менеджментом
• Аналитики начинают работать с требованиями стейкхолдеров
• Возникает необходимость в первичной документации процессов
• Формируются первые методики сбора требованийПример: Внедрение Excel потребовало от аналитиков не только технических навыков, но и понимания финансовых моделей, что сократило ошибки в расчетах на 90%.

3. Третья волна (1990-2010): интернет-революция и комплексные системы

Ключевые технологии:

• CRM (Salesforce)
• WMS (Manhattan Associates)
• Полноценные ERP (SAP R/3)
• Веб-технологии

Требования рынка:

• Требования рынка:
• Интеграционные компетенции
• Понимание сквозных бизнес-процессов
• Управление сложными проектами
• Работа с большими объемами данныхIT-рынок труда:
• Взрывной рост спроса на веб-разработчиков (до +400% за 1995-2000 гг.)
• Формирование глобального аутсорсинга (Индия, Восточная Европа)
• Появление «звездных» зарплат в Кремниевой долине (первые миллионные пакеты)
• Начало «войны за таланты» — компании внедряют реферальные программы и опционыРасцвет аналитиков:
• Аналитики становятся архитекторами бизнес-процессов
• Появление специализаций: бизнес-аналитики, системные аналитики, data-аналитики
• Критическая важность моделирования процессов и данных
• Развитие UML и других стандартов визуализацииПример: Внедрение WMS в Amazon сократило время сборки заказов с 3 часов до 30 минут благодаря глубокому анализу логистических цепочек.

IT-рынок труда:

• Взрывной рост спроса на веб-разработчиков (до +400% за 1995-2000 гг.). Формирование глобального аутсорсинга (Индия, Восточная Европа).

• Появление «звёздных» зарплат в Кремниевой долине (первые миллионные пакеты).

• Начало «войны за таланты» — компании внедряют реферальные программы и опционы.

Расцвет аналитиков:

• Аналитики становятся архитекторами бизнес-процессов.

• Появление специализаций: бизнес-аналитики, системные аналитики, data-аналитики.

• Критическая важность моделирования процессов и данных.

• Развитие UML и других стандартов визуализации

• Пример: Внедрение WMS в Amazon сократило время сборки заказов с 3 часов до 30 минут благодаря глубокому анализу логистических цепочек.

4. Четвертая волна (2010-2020): Big Data и гиперавтоматизация

Технологические тренды:

• Облачные CRM.
• AI в WMS.
• RPA (UiPath).
• Платформы аналитики

Требования рынка:

• Работа с неструктурированными данными.
• Навыки предиктивной аналитики.
• Интеграция AI/ML в бизнес-процессы.
• Управление цифровыми продуктами.

IT-рынок труда:

• Острейший дефицит Data Scientists (соотношение вакансий к кандидатам 5:1).

• Массовый переход на удаленный формат (до 60% IT-специалистов работают удалённо).

• Резкий рост зарплат в AI/ML (до $300-500 тыс. в FAANG). Появление «цифровых кочевников» — глобальная конкуренция за топ-специалистов.

• Забавный факт: в 2019 году 43% IT-специалистов меняли работу ежегодно ради 20-30% прироста зарплаты

Трансформация аналитики:

• Аналитики осваивают Data Science.

• Появление «цифровых двойников» бизнес-процессов.

• Активное использование имитационного моделирования.

• Смещение фокуса на customer journey и UX.

• Пример: ИИ-аналитика в CRM повысила точность прогноза продаж на 40% благодаря работе аналитиков с алгоритмами машинного обучения.

5. Пятая волна (2020-наше время): Agentic AI и автономные системы

Современные технологии:

• Автономные ИИ-агенты.
• Генеративный ИИ.
• Квантовые вычисления.
• Гиперсинтетические данные.

Требования рынка:

• Требования рынка:
• Управление ИИ-системами
• Этика искусственного интеллекта
• Работа в гибридных (человек+ИИ) командах
• Непрерывная адаптация к меняющимся технологиям.

Текущее состояние рынка:

• Резкое охлаждение: в 2023-2024 массовые увольнения в Big Tech (Meta -11%, Google -6%).

• Конкуренция на позиции Junior: 8 резюме на 1 вакансию (против 1:3 в 2021).

• Снижение зарплат на 30% для новых сотрудников.

• Критический спрос на AI/ML-специалистов (+40% вакансий в 2024). При общем спаде, 72% компаний испытывают сложности с наймом senior-специалистов.

Роль аналитиков сегодня:

• Аналитики становятся «тренерами ИИ», формируя промпты и обучающие наборы. Критически важны навыки валидации решений ИИ.

• Управление «цифровой экологией» — балансом между автоматизацией и контролем. Разработка онтологий для Agentic AI.

• Инсайт: по данным исследований, 72.3% команд уже активно используют ИИ в тестировании, а ESB-платформы с low-code инструментами сокращают потребность в junior-разработчиках на 50%.

Будущее (2025-2030): что потребует рынок?

Прогнозируемые тренды:

1. Полная автономность: ИИ-агенты будут самостоятельно проводить анализ требований и адаптировать системы, но потребуют «наблюдателей» из числа аналитиков.
2. Живая аналитика: системы реального времени с прогнозными возможностями станут стандартом, увеличивая спрос на аналитиков-интерпретаторов.
3. Этическая автоматизация: возникнет новая специализация — аудиторы алгоритмов и цифровых процессов.
4. Гибридные навыки: аналитики будущего будут сочетать технические компетенции с психологией и философией.
5. Персонализация в масштабе: как отмечают эксперты, в 2025 году маркетинговая аналитика достигнет уровня, когда контент будет динамически адаптироваться даже под настроение пользователя.

Роль аналитиков в 2030:

• Архитекторы цифровых экосистем: проектирование взаимодействий между автономными агентами
• Кураторы данных: обеспечение качества информации для ИИ
• Послы цифровой этики: контроль за соблюдением моральных норм в автоматизированных системах
• Трансляторы смыслов: интерпретация решений ИИ для человека

Будущее (2025-2030): прогнозы по рынку труда

1. Поляризация спроса: сокращение junior-позиций на 50% из-за low-code/AIРост потребности в senior+ на 35% (центры компетенций).
2. Сокращение junior-позиций на 50% из-за low-code/AI.
3. Рост потребности в senior+ на 35% (центры компетенций).

Новые профессии:

1. Новые профессии: Промпт-инженеры (ожидается 1 млн вакансий к 2027)AI-аудиторы (законодательные требования).
2. Цифровые этики (контроль bias в алгоритмах).
3. AI-аудиторы (законодательные требования).

Геополитический фактор:

• Локализация IT-кадров (снижение офшоринга на 25%).

• Рост региональных хабов (Казань, Новосибирск, Екатеринбург). Локализация IT-кадров (снижение офшоринга на 25%).

• Рост региональных хабов (Казань, Новосибирск, Екатеринбург).

• Экспертная оценка: «Рынок переходит от количественного роста к качественному отбору — востребованы будут только T-shaped специалисты».

Аналитический вывод: цикличность рынка

История показывает три ключевых паттерна:

1. Каждая технологическая волна сначала создает дефицит кадров, затем их избыток.
2. Автоматизация сокращает рутинные позиции, но многократно увеличивает ценность экспертизы.
3. «Золотой век» любой IT-специальности длится 7-10 лет, требуя постоянного переобучения
4. Рекомендация для специалистов — фокусироваться на развитии:

• Гибких навыков (критическое мышлени, креативность)
• Доменной экспертизы (глубокая отраслевая специализация)
• Навыков работы с AI-инструментами

Вместе с экспертами Kursfinder я изучила около 40 вариантов обучения и отобрала 28 лучших курсов. В начале рейтинга представлена основная подборка из 10 образовательных программ. Далее вы найдете дополнительный список, который может быть полезен, если ни один из первых вариантов вам не подойдет. В завершение статьи я собрала бесплатные материалы и практики по системному анализу для начинающих. Полный перечень курсов по системной аналитике доступен в каталоге на сайте.

ТОП-10 лучших курсов системного аналитика в 2026 году

1. Системный аналитик от Нетологии — объемный курс с гарантией трудоустройства.
2. Системный аналитик с нуля до PRO от Eduson Academy — программа обучения с несколькими тарифами.
3. Системный аналитик PRO от Нетологии — изучение расширенного технологического стека системного аналитика.
4. Системный аналитик буткемп от Яндекс Практикум - интенсивное обучение с большим количеством практики и индивидуальным подходом.
5. Профессия Системный аналитик от Skillbox — большое количество практических заданий из трех направлений.
6. Системный аналитик от Яндекс Практикум — профессиональная поддержка в трудоустройстве от HR-экспертов.
7. Системный аналитик PRO от Skillfactory — параллельное изучение системной и бизнес-аналитики с нуля.
8. Профессия Системный аналитик от GeekBrains — разработка проектов в профессиональной среде PyCharm.
9. Системный аналитик от Otus.ru — ускоренное обучение системной аналитике до уровня Middle+.
10. Системный аналитик. Advanced от Otus.ru — практический курс с доступом к закрытой базе вакансий от крупных IT-компаний.

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

Онлайн-курсы системного аналитика

1. Системный аналитик | Нетология

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

• Стоимость: от 155 000 за курс (или от 6 458 рублей в месяц)
• Длительность: от 10 месяцев
• Формат обучения: видеолекции, онлайн-вебинары, практические задания, обратная связь от экспертов
• Сертификат: есть

Кому подойдет: начинающим аналитикам; IT-специалистам из смежных сфер; людям, которые хотят построить карьеру в IT.

Преимущества:

• две траектории обучения на выбор - для быстрого старта в профессии или карьерного развития;
• 75% программы - практические задания с проверкой;
• семь масштабных проектов для портфолио;
• стажировка у партнеров курса для лучших студентов;
• помощь с поиском работы после выпуска;
• доступ к профессиональному коммьюнити для общения и обмена опытом.

Недостатки:

• ограниченное количество практики и изучаемых инструментов в базовом тарифе.

Программа обучения:

• Жизненный цикл программного обеспечения
• Моделирование бизнес-процессов
• Разработка прототипов пользовательских интерфейсов
• SQL в аналитике данных
• Знакомство с архитектурой приложения
• Документооборот в IT-проектах
• Развертывание и тестирование ПО
• Анализ данных с помощью языка Python
• Профессиональный уровень аналитики в SQL

Ознакомиться с полной программой >>>

2. Системный аналитик с нуля до PRO | Eduson Academy

Практический курс, с помощью которого вы сможете с нуля разобраться в системной аналитике без специальной подготовки и навыков программирования. В процессе обучения вы научитесь: собирать и анализировать требования к ПО, контролировать процесс разработки и тестирования, работать с базами данных через SQL, проектировать пользовательские интерфейсы и управлять проектами с помощью Scrum и Agile. В расширенном тарифе PRO предусмотрено комплексное содействие в трудоустройстве. Вы узнаете, как составить цепляющее резюме, получите доступ к закрытым базам вакансий, которых нет на hh.ru, и потренируетесь в прохождении технических собеседований.

• Стоимость: от 13 060 рублей в месяц
• Длительность: 6 месяцев
• Формат обучения: теоретические материалы, практикумы, обратная связь от кураторов
• Сертификат: есть

Кому подойдет: опытным специалистам из разных сфер профессиональной деятельности; людям, которые хотят освоить системную аналитику с нуля.

Преимущества:

• минимум теории и усиленная практика;
• поддержка личного куратора в течение года;
• доступ к учебному контенту и обновлениям навсегда;
• два тарифа - для новичков и опытных специалистов;
• помощь с поиском работы и гарантия возврата денег.

Недостатки:

• высокая стоимость рассрочки, особенно в расширенном тарифе.

Программа обучения:

• Знакомство с профессией системного аналитика
• Разработка требований к программному обеспечению
• Моделирование процессов и систем данных
• Основные навыки программирования
• SQL в работе с данными
• Проектирование и тестирование пользовательских интерфейсов
• Архитектура приложений
• Принципы и практики DevOps-инженерии
• Работа с документооборотом
• Развитие soft-skills и основы проектного менеджмента

Ознакомиться с полной программой >>>

3. Системный аналитик PRO | Нетология

Экспертная программа обучения рассчитана на новичков и опытных специалистов в системной аналитике. Содержание курса предусматривает комплексное изучение продвинутых инструментов системного анализа для решения сложных задач. Вы получите полный перечень профессиональных навыков, включая: сбор требований заказчиков с помощью User Story и User Case, моделирование процессов в UML и IDEF, обработка больших массивов данных через SQL, разработка структурированных технических заданий и другие. К концу обучения в вашем портфолио будет семь масштабных проектов, которые вы сможете использовать при трудоустройстве. В поисках работы вам помогут специалисты образовательной платформы - они составят резюме, проведут тестовые собеседования и подберут подходящие вакансии.

• Стоимость: 140 000 рублей за курс (или 5 833 рублей в месяц)
• Длительность: 10 месяцев
• Формат обучения: видеолекции, практические задания, онлайн-вебинары с преподавателями
• Сертификат: есть

Кому подойдет: начинающим и практикующим системным и бизнес-аналитикам; разработчикам и IT-специалистам.

Преимущества:

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

Недостатки:

• долгая обратная связь.

Программа обучения:

• Специфика работы в проектной команде по Agile
• Разработка моделей бизнес-процессов
• SQL и работа с базами данных
• Внедрение систем и документационное сопровождение API
• Проектирование DWH и архитектур ПО
• Документооборот в IT-проектах
• Английский язык в работе системных аналитиков

Ознакомиться с полной программой >>>

4. Системный аналитик буткемп | Яндекс Практикум

Интенсивный курс в формате буткемпа с повышенной нагрузкой, быстрой обратной связью и индивидуальным подходом. За три месяца вы получите перечень навыков, которые необходимы для профессионального развития в системной аналитике. Вы освоите продвинутые инструменты, включая UML, BPMN, DFD, GUI, Figma, SQL и другие. В течение курса сделаете пять учебных проектов и испытаете свои силы в реальной рабочей среде IT-специалиста.

• Стоимость: 141 000 рублей за курс (или от 49 500 рублей в месяц)
• Длительность: 3 месяца
• Формат обучения: теоретические материалы, интерактивные задания, онлайн-встречи с ментором, учебные проекты
• Сертификат: нет

Кому подойдет: практикующим специалистам из сферы финансов, инвестиций, страхования, IT и др.

Преимущества:

• большое количество практики на интерактивной платформе;
• пять проектов для портфолио;
• помощь с поиском работы в течение семи месяцев после выпуска;
• регулярные онлайн-воркшопы с наставниками;
• возможность попробовать обучение бесплатно.

Недостатки:

• интенсивный формат обучения на буткемпе может показаться сложным для новичков без опыта.

Программа обучения:

• Введение в профессию системного аналитика
• Создание требований
• Моделирование процессов и систем данных
• Работа с пользовательскими интерфейсами
• Техники Agile
• Проектирование программных интерфейсов
• Реализация готовой системы
• Техническое обслуживание и мониторинг результатов
• SQL в работе системного аналитика

Ознакомиться с полной программой >>>

5. Профессия Системный аналитик | Skillbox

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

• Стоимость: 6 662 рублей в месяц
• Длительность: 8 месяцев
• Формат обучения: видеоуроки, практические задания с проверкой и обратной связью, проектные работы
• Сертификат: есть

Кому подойдет: практикующим системным и бизнес-аналитикам; специалистам из смежных сфер; желающим развиваться в IT-направлении; студентам технических ВУЗов.

Преимущества:

• работа над кейсами из трех популярных сфер;
• девять масштабных проектов для портфолио;
• развернутая обратная связь от спикеров по домашним заданиям;
• бесплатный курс по Business Studio и ChatGPT.

Недостатки:

• долгая обратная связь от спикеров, особенно в периоды повышенной учебной загруженности.

Программа обучения:

• Сбор требований к программному обеспечению
• Разработка бизнес-требований
• Подготовка спецификации
• Подготовка к разработке программного обеспечения
• Основы аналитики данных с использованием SQL
• Знакомство с Business Studio
• Продвинутый уровень Excel

Ознакомиться с полной программой >>>

6. Системный аналитик | Яндекс Практикум

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

• Стоимость: от 110 000 рублей за курс (или от 14 000 рублей в месяц)
• Длительность: 9 месяцев
• Формат обучения: теоретические материалы и практикумы в интерактивном учебнике, воркшопы с экспертами, проектные работы
• Сертификат: есть

Кому подойдет: людям, которые хотят построить карьеру в системной аналитике с нуля.

Преимущества:

• базовый и расширенный тариф на выбор;
• изучение расширенного технологического стека - UML, JSON, SQL, Postman и др.;
• практика в каждом блоке и пять проектов для портфолио;
• актуализация программы каждые шесть месяцев;
• помощь с поиском работы в течение семи месяцев после выпуска.

Недостатки:

• высокие ежемесячные платежи, особенно в расширенном тарифе.

Программа обучения:

• Специфика профессии системного аналитика
• Основы разработки технических требований
• SQL в аналитике данных
• Моделирование процессов и баз данных
• Работа с пользовательскими интерфейсами
• Построение архитектуры системы
• Внедрение техник Agile в рабочие процессы

Ознакомиться с полной программой >>>

7. Системный аналитик PRO | Skillfactory

Онлайн-курс, посвященный двум ключевым аспектам профессии системного аналитика - внедрению инноваций и решению бизнес-задач. За семь месяцев обучения вы получите полный перечень профессиональных навыков IT-специалиста: освоите бизнес-моделирование процессов, научитесь определять технические требования и расставлять приоритеты, разберетесь в специфике UX/UI и узнаете, как составить продающее резюме. Завершив программу, вы станете востребованным IT-специалистом по проектированию и интеграции продвинутых систем анализа рабочих процессов в бизнесе.

• Стоимость: от 5 335 рублей в месяц
• Длительность: 7 месяцев
• Формат обучения: онлайн-вебинары с экспертами, домашние задания с проверкой и обратной связью
• Сертификат: есть

Кому подойдет: начинающим системным аналитикам; junior-разработчикам; экспертам из сферы предпринимательства; практикующим специалистам разных профилей.

Преимущества:

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

Недостатки:

• индивидуальные консультации с ментором доступны только в расширенных тарифах.

Программа обучения:

• Основы профессии системного аналитика
• Анализ требований к разработке
• Проектирование архитектуры IT-системы
• Разработка, тестирование и интеграция готового проекта
• Сопровождение и утилизация системы

Ознакомиться с полной программой >>>

8. Профессия Системный аналитик | GeekBrains

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

• Стоимость: 7 188 рублей в месяц
• Длительность: до 9 месяцев
• Формат обучения: теоретические материалы, практические задания, онлайн-занятия с преподавателями
• Сертификат: есть

Кому подойдет: новичкам, желающим построить карьеру в системной аналитике; людям, которые хотят научиться проектировать и анализировать IT-проекты с нуля.

Преимущества:

• несколько форматов практики - домашние задания, мини-кейсы, интерактивный тренажер;
• проектные работы в профессиональной среде PyCharm;
• персональная обратная связь по практикумам;
• регулярные онлайн-встречи с преподавателями-практиками;
• комплексная помощь с трудоустройством.

Недостатки:

• небольшое количество проектных работ.

Программа обучения:

• Азы современного программирования
• Введение в базы данных
• Принципы моделирования бизнес-процессов
• Построение диаграммы состояний
• Основы проектирования
• Роль системного аналитика в команде разработчиков ПО
• Знакомство с контролем версий
• Введение в программирование на Python
• Особенности веб-технологий

Ознакомиться с полной программой >>>

9. Системный аналитик | Otus.ru

Курс в формате специализации поможет вам погрузиться в системную аналитику с нуля и получить навыки, соответствующие уровню Middle+. Программа разделена на две ступени - Junior и Middle. На первом этапе вы научитесь понимать требования к разработке ПО, составлять техническую документацию и тестировать готовые цифровые продукты. На втором этапе узнаете, как формализовать потребности заказчика в виде требований, проектировать и тестировать сервисы SOAP и RESTFul API, а также комплексно разберетесь в процессе разработки. После обучения вы сможете получить доступ к вакансиям компаний-партнеров и рекомендательное письмо с печатью OTUS.

• Стоимость: 221 000 рублей за курс (или от 22 100 рублей в месяц)
• Длительность: 13 месяцев
• Формат обучения: интерактивные вебинары, практикумы, проектные работы, обратная связь от экспертов
• Сертификат: есть

Кому подойдет: людям, которые хотят получить востребованную профессию с нуля до уровня Middle+.

Преимущества:

• два онлайн-занятия с преподавателями каждую неделю;
• две проектных работы для портфолио;
• ревью и развернутая обратная связь от эксперта по домашним заданиям;
• комплексная система поддержки с трудоустройством;
• активное сообщество студентов и практиков для общения и обмена профессиональным опытом.

Недостатки:

• долгий процесс обучения - более года.

Программа обучения:

• Системный аналитик базовый уровень
• Системный аналитик продвинутый уровень

Ознакомиться с полной программой >>>

10. Системный аналитик. Advanced | OTUS.ru

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

• Стоимость: 128 000 рублей за курс (или от 12 800 рублей в месяц)
• Длительность: 6 месяцев
• Формат обучения: онлайн-трансляции с преподавателями, домашние задания с проверкой, проектная работа
• Сертификат: есть

Кому подойдет: IT-специалистам; аналитикам данных; дата-сайентистам; бизнес-аналитикам.

Преимущества:

• вступительное тестирование для оценки навыков;
• прямые трансляции для живого общения с преподавателями;
• крупный проект для портфолио - продвинутая система работы ресторана;
• карьерные мероприятия в сообществе;
• доступ к закрытым вакансиям от партнеров образовательной платформы.

Недостатки:

• программа обучения не подойдет новичкам без опыта.

Программа обучения:

• Роль системной аналитики в разработке программного обеспечения
• Обследование и работа с требованиями
• Проектирование приложения и API
• Основы аналитики данных
• Работа с SQL
• Сопровождение процесса разработки ПО

Ознакомиться с полной программой >>>

Еще 11 дополнительных курсов системного аналитика

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

• Системный аналитик и бизнес-аналитик от OTUS.ru. Комплексное погружение в два направления профессиональной деятельности - системную и бизнес-аналитику. В ходе обучения вы разберетесь в терминологии современных информационных технологий, освоите продвинутые инструменты для решения аналитических задач, научитесь составлять структурированные ТЗ и следить за их выполнением. В конце курса вас ждет интенсивная практика под руководством эксперта, результатом которой станет полноценный проект для портфолио.
• Системный аналитик. Team Lead от OTUS.ru. Практико-ориентированная программа, на которой вы освоите современные принципы и инструменты построения архитектуры систем и научитесь эффективно управлять командой аналитиков. Образовательный процесс проходит онлайн в формате интерактивных вебинаров - вы сможете пообщаться с экспертами напрямую и перенять опыт их профессиональной деятельности. Уже к концу обучения вы сможете: проектировать структурированные архитектуры систем, анализировать готовые коды, эффективно управлять командой аналитиков и обеспечивать документационное сопровождение аналитических процессов.
• Аналитик систем управления и организации от Русская Школа Управления. Двухдневный курс системной аналитики, с помощью которого вы сможете разобраться в современной практике управления бизнес-процессами компании и их адаптации в соответствии с изменениями рыночных условий. Программа обучения предусматривает комплексный подход к аналитике, моделированию и оптимизации рабочих процессов. Вы научитесь: выявлять точки потенциального роста, разрабатывать стратегии по увеличению доходов, контролировать ключевые аспекты коммерческой деятельности и оценивать эффективность работы персонала, задействованного в реализации стратегических проектов.
• Аналитик данных от Финансовый Университет. Образовательная программа, нацеленная на подготовку специалистов по сбору, анализу и визуализации данных с помощью SQL и Python. На курсе вы научитесь проектировать модели Machine Learning и использовать продвинутые аналитические инструменты в решении бизнес-задач в области маркетинговой и клиентской аналитики.
• Системный аналитик от Специалист. Экспертный курс для практикующих IT-специалистов, которые хотят расширить перечень своих компетенций и углубиться в разработку программного обеспечения и цифровых продуктов. В процессе обучения вы научитесь: проектировать и описывать бизнес-процессы, оптимизировать работу IT-подразделений, составлять структурированные технические задания, использовать актуальные стандарты документирования и мотивировать работу персонала. Изучить программу можно в очном или дистанционном формате.
• Системный аналитик от Softline. Программа повышения квалификации с очным и онлайн обучением поможет вам с нуля разобраться в методиках системной аналитики в работе IT-компаний. На курсе вы изучите принципы анализа и автоматизации бизнес-процессов, научитесь создавать технические задания, тестировать программное обеспечение и составлять подробные аналитические отчеты. Завершив обучение, получите государственное удостоверение о профессиональной переподготовке.
• Системный аналитик — Профессиональная переподготовка по всей России от АПОК. Профессиональная переподготовка с государственным дипломом предлагает три формата обучения: базовый, продвинутый и премиум. С ее помощью вы в короткие сроки сможете освоить востребованную IT-специальность и научиться решать задачи с использованием продвинутых аналитических инструментов. На онлайн-курсе вы узнаете о принципах администрирования информационной системы, разберетесь в управлении доменными и локальными учетными записями, углубитесь в объектно-ориентированное программирование. Полученные знания вы сможете применить в процессе работы в среде AllFusion ERwin Data Modeler и IBM Rational Rose.
• Системный и бизнес-анализ в разработке ПО от Level Up. Онлайн-курс интенсивного обучения системных аналитиков в IT-сфере, разработанный экспертами-практиками прогрессирующих компаний. Вы научитесь работать с техническими требованиями заказчиков, моделировать и интегрировать аналитические проекты в бизнес, а также получите полный перечень навыков и знаний, необходимых для работы на позициях системного и бизнес-аналитика. Все занятия проходят в формате онлайн-сессий на платформе Zoom.
• Системный анализ от IBS. Программа ориентирована на специалистов, которые занимаются сбором, анализом и описанием технических требований к программному обеспечению. На курсе вы научитесь документировать ТЗ в двух форматах - в текстовых спецификациях и визуальных моделях, а также детально разбираться в исследуемых объектах. Знаний и навыков, полученных в ходе обучения, будет достаточно для карьерного развития в области системной аналитики.
• Системный аналитик — профессиональная переподготовка по всей России от ЭКОДПО. Онлайн-курс, цель которого - предоставить слушателям профессиональные знания и навыки, необходимые для анализа бизнес-процессов и моделирования стратегий развития компании. Вы узнаете, какие методики используются для оценки требований к автоматизированным информационным системам, освоите алгоритмы интеллектуальной обработки данных, а также разберетесь в принципах разработки тактических и стратегических планов. По окончании курса вы получите несколько вариантов для трудоустройства и сможете пойти работать в государственные учреждения, некоммерческие компании или в IT-бизнес.
• Системный анализ от IT Expert. Программа, разработанная в соответствии с актуальными профессиональными стандартами, нацелена на подготовку компетентных специалистов в IT-сфере. В ходе курса вы узнаете, как создать продукт в соответствии с целями заказчика, какие результаты работы системного аналитика считаются эффективными, и как использовать сложные инструменты для решения продвинутых задач. С помощью практических заданий уже к концу обучения вы разработаете несколько аналитических диаграмм: предметной области, последовательностей, прецедентов и другие.

Бесплатные курсы системного аналитика

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

1. Как начать карьеру системного аналитика от Яндекс Практикум

Видеокурс от Яндекса, спикеры которого рассказывают, как построить успешную карьеру в системной аналитике. Вы узнаете, чем занимается IT-специалист и какие задачи решает, разберете несколько вариантов трудоустройства в крупные компании и получите экспертные рекомендации по составлению качественного резюме.

Главное о курсе:

• все о профессии системного аналитика;
• разделение видео на тайм-коды для удобной навигации.

2. Системный аналитик: открытое собеседование от Яндекс Практикум

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

Главное о курсе:

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

3. Системная аналитика от Лекториум

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

Главное о курсе:

• 20 видеолекций по основам системной аналитики с проверочными тестами;
• электронный сертификат после успешного завершения курса.

4. Системный анализ от ИНТУИТ

Объемный курс, в котором рассматриваются основные разделы системного анализа: статический анализ, эволюция и функционирование систем, деградация и распад и так далее. Помимо лекций, в каждом учебном блоке представлены тесты разной сложности. В конце обучения вас ждет итоговый экзамен для комплексного закрепления знаний.

Главное о курсе:

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

5. Демо занятие курса «Системный аналитик. Advanced» от OTUS

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

Главное о курсе:

• изучение профессии системного аналитика с позиции трудоустройства и карьерного развития;
• интерактивная презентация для лучшего понимания материала.

6. Системный аналитик: первые шаги к профессии от Нетология

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

Главное о курсе:

• неограниченный доступ к учебным материалам;
• практические задания и проектная работа;
• поддержка, общение и обмен опытом в учебном сообществе.

7. Курс по системному анализу от Контур

Объемный курс, авторы которого учат определять и структурировать проблему, собирать метрики и составлять подробные технические задания для разработчиков. Программа включает 11 учебных модулей, в каждом из которых есть практикумы для отработки навыков. Помимо домашних заданий, вы также будете работать над индивидуальным проектом. Вам предстоит определить проблему и предложить ее эффективное решение. У самых успешных студентов есть возможность попасть на оплачиваемую стажировку к партнерам площадки.

Главное о курсе:

• 11 учебных блоков с теорией и практическими заданиями;
• масштабный выпускной проект;
• возможность попасть на оплачиваемую стажировку после курса.

Профессия системного аналитика

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

• Анализ бизнес-процессов с целью выявления проблем.
• Совершенствование бизнес-процессов.
• Разработка подробных требований к информационным системам, их внедрение в компанию и оценка результатов.
• Обучение сотрудников работе с интегрированными IT-системами.

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

Как долго учиться?

Сроки получения профессии системного аналитика зависят от выбранного формата обучения. На онлайн-курсах можно изучить основы IT-специальности и получить компетенции, необходимые для работы над реальными задачами, меньше чем за полгода. В специализированных ВУЗах период обучения может составлять несколько лет.

Требования для системного аналитика

Требования, предъявляемые работодателям к соискателям на позицию системного аналитика, можно разделить на hard-skills и soft-skills. Профессиональные навыки:

• Базовый уровень владения языком SQL;
• Техническая грамотность;
• Основы UX/UI;
• Грамотный русский язык (на некоторые позиции требуется средний уровень английского языка).

К софтскиллам системного аналитика относят:

• Системное мышление;
• Навыки коммуникации;
• Внимательность и умеренный перфекционизм;
• Хорошая память.

Сколько зарабатывает системный аналитик?

По данным hh.ru, уровень заработной платы системного аналитика зависит от позиции и опыта работы.

• Начинающие специалисты зарабатывают от 70 000 рублей ежемесячно.
• Аналитики с опытом работы от одного года могут зарабатывать 130 000 рублей и более.
• Профессионалы на позиции Senior с опытом более трех лет получают более 250 000 рублей в месяц.

Что нужно для системного анализа?

Единого алгоритма для проведения системного анализа не существует. Однако есть основные процессы и задачи, без которых выполнить анализ не получится. К ним относятся:

• Определение и обоснование ошибки;
• Постановка задачи и разработка структурированного плана ее решения;
• Реализация решения, подготовка и презентация технического задания пользователям.

Есть большое количество инструментов и методик проведения системного анализа. Рассмотрим наиболее популярные из них:

• Нотация BPMN - система условных обозначений для описания бизнес-процессов в виде схем.
• UML - унифицированный язык для моделирования аналитических проектов.
• SQL - язык для работы с большими массивами информации и базами данных.
• Стандартный пакет офисных программ, Miro, Draw.io, Camunda и другие инструменты.

Заключение

Курсы по системному анализу помогут вам сменить профессию и освоить востребованную и высокооплачиваемую специальность с нуля. Для обучения в сфере IT не требуются предварительные знания или навыки программирования — достаточно обладать системным мышлением и умением структурировать информацию. По окончании образовательной программы вы сможете быстро найти работу с начальной зарплатой от 70 000 рублей на позиции junior. Дальнейший уровень дохода будет зависеть от вашего опыта, сложности выполняемых задач, а также стремления к профессиональному росту и развитию навыков.

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

Всем привет, меня зовут Александр Попков, я работаю системным аналитиком в компании IT_ONE. В данной статье я хочу поделиться своим взглядом на профессию, в которой я уже около 8 лет, и рассказать, с каким ожиданиями мне приходилось сталкиваться на своем трудовом пути, классифицировав их по разным направлениям.

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

Кейс #1 — Системный администратор баз данных

Итак, проходит первое знакомство с HR, все хорошо, вскользь среди типовых обязанностей упоминается необходимость писать хранимые процедуры на PL/SQL.

Я абсолютно согласен с тем, что системному аналитику нужно уметь работать с реляционными базами данных, вытаскивать из них информацию, понимать схему данных в таблицах, проектировать, создавать витрины и дашборды. Но написание бизнес-логики на стороне БД кажется мне довольно странным ожидаем от кандидата. Сам по себе данный подход к разработке в современных реалиях вызывает вопросы (вот, например, дискуссия на реддите). Здесь же, по сути, компания искала разработчика, а не аналитика.

Кейс #2 — devSAOps

Другое собеседование — на этот раз технический этап. Интервьюер как из пушки стреляет вопросами на тему unix-команд и ключевых особенностей kornshell. Я, к сожалению, глубоких знаний на эту тему не имею и интервью не прохожу. Однако меня до сих пор мучает вопрос — чем же в итоге занимается системный аналитик, который в итоге устроился на эту позицию? Готов поспорить, что его работа не похожа на все, с чем мне приходилось сталкиваться.

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

Кейс #3 — Системный математик

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

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

Кейс #4 — Немного бухгалтер

Снова возврат к личному опыту интервью. На одном из собеседований в финтех-проект меня начали расспрашивать на тему бухгалтерского дела. Чем дебет отличается от кредита? Какие счета являются активными, а какие пассивными? Как составить проводку со счетом … хотя ладно, кажется, так далеко не заходили 🙂.

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

Кейс #5 — Вообще-то еще и писатель

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

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

А на самом деле?

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

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

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

• Огромная корпорация перешла на микросервисную архитектуру, штат разработчиков растет как снежный ком, бизнес постоянно придумывать новые хотелки? Зовите системного аналитика.
• Разработчики хотят больше заниматься кодом и меньше переговорами? Зовите системного аналитика.
• Непонятно, как подойти к большому проекту, декомпозировать и оценить его? Зовите системного аналитика.

Вот такая вот минутка рекламы в конце 🙂.

Согласны ли вы что приведенные ожидания от системных аналитиков являются перекосом или, напротив, они вполне справедливы? Поделитесь вашим мнением. Может быть, и у вас были кейсы с необычными собеседованиями системных аналитиков? Буду рад узнать что-то новое для себя.

Для нового выпуска мы спросили про итоги недели Кирилла Мокевнина – автор YouTube и тг-канала «Организованное программирование», разработчик-преподаватель и сооснователь онлайн-школы Хекслет.

Кирилл делится своим опытом разработки системы для Хекслет Колледжа, реакцией на релизе СhatGPT Omni и советами по продуктивности.

Как прошла неделя? Над чем работаешь в последнее время?

Активно участвую в разработке небольшой системы, для работы с абитуриентами в Хекслет Колледже. Это система, которая упрощает работу по приему документов и оплаты обучения. Сейчас самая активная стадия набора и я доводил эту систему до ума, упрощая и ускоряя процесс поступления

Какая из последних IT новостей запомнилась тебе больше всего? Почему?

Релиз ChatGPT Omni. То как он работает с картинками это просто что-то. Еще понравился софт, который через себя пропускает звонки в поддержку и делает речь спокойной, если на той стороне ведут себя агрессивно. Спасет кучу нервов людям, которые работают в саппорте.

Вообще все что происходит вокруг ИИ не может не радовать. Я слежу за интересными проектами в этой сфере и активно встраиваю их в мои личные процессы и процессы Хекслета.

С какой сложной задачей ты столкнулись в последнее время? Какой простой совет можешь дать, чтобы решить

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

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

Совет тут простой, описание такой системы хорошо ложится в модель конечного автомата, вот их мы и применили.

Что слушал на неделе: трек или подкаст

Недавно открыл для себя группу Джейло. Слушаю на репите.

Что советуешь почитать и посмотреть

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

Из того, что советую посмотреть. Мне очень понравилось интервью известного уборщика в тренажерном зале. Рекомендую всем, кто так или иначе задумывается о том, чтобы начать блоггерскую деятельность.

Твой топ-3 приложений

• Telegram
• X (twitter)
• Amazon

Если говорить про работу, то по сути два: Slack и Notion

Как планируешь проводить выходные и что посоветуешь другим попробовать

Куда-нибудь пойдем с детьми. Ну и обязательно спорт, я катаюсь на роликах, рекомендую попробовать wizard skating. Очень красиво и получается зарядиться на работу.

Как итог — любимый IT-мем недели!

Следите за новыми выпусками «Ретроперспективы недели» на Tproger — будет ещё больше интересного! Если у вас есть идеи, кого бы вы хотели видеть в следующем выпуске, дайте нам знать!

В Газпромбанке подход немного другой. У нас есть деврел (от англ. - Development Relationship), которые запускают и развивают сообщества, есть актив этого сообщества, состоящий из наиболее вовлеченных участников, и есть Head of profession — лидер, который отвечает за развитие профессиональных компетенций внутри структуры (например, среди представителей определенной профессии ИТ блока розничного бизнеса).

Далее подробно разберем процессы на примере нашей команды — Head of profession системных аналитиков.

Кто такой Head of profession?

Это senior-специалист в своей сфере. У него достаточно знаний по теме, большой опыт, есть определённые успехи, он уже запускал какие-то крупные продукты.

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

Основных задач у лидера компетенций несколько:

• сформировать концепцию и разработать стандарты профессии;
• выстроить процесс найма и оценки персонала;
• мониторить и внедрять новые практики и технологии.

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

Кроме того, Head of profession работает по специальности, в нашем случае — системным аналитиком. Нормальное разделение нагрузки — 50/50. Потому что если лидер компетенций будет уделять почти всё своё время системному анализу, то просто не успеет закрыть свои задачи. А если полностью уйдёт в менторство — то через год, максимум два, отстанет от профессии и перестанет быть экспертом.

Как стать Head of profession?

В первую очередь нужно пройти собеседование у руководителей Центра экспертизы. Оно непростое: рассказать видение профессии, ее ценность в процессе производства ПО и перспективы развития. Бонусом можно рассказать план захвата мира.

Сложно ли быть Head of profession?

Да. Когда в твоей группе 300–350 системных аналитиков, со своими вопросами, болями, проблемами, голова разрывается. Приходится очень быстро прокачивать собственные софт и хард скилы (я, кажется, никогда не росла так быстро, как в роли хэда), чуть ли не каждую неделю осваивать что-то новое.

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

А что тогда хорошего?

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

Как работает Head of profession — на примере системного анализа

Мы дорабатываем процессы, внедряем много нового, в какой-то мере меняем представление о системном аналитике как о специалисте. Дальше подробнее расскажу о том, что мы сделали.

Ушли от «Водопада»

Первое, что мы рассказываем нашим аналитикам: необходимо минимизировать документацию. А ещё уйти от waterfall, где анализ, разработка, тестирование происходят последовательно, и параллелить работу разных специалистов для сокращения time-to-market.

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

Объяснили всем, что аналитик — это не переводчик

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

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

Превратили аналитика в инженера

В нашем понимании, аналитик — такой же инженер, как разработчик или тестировщик. Он должен так же переходить в Git, работать в IDE и прочих «разработческих» инструментах, а не «гуманитарных», таких как Jira, Confluence.

Что мы уже начали использовать как инженеры:

• API First. Это подход, когда аналитик пишет спецификацию в YAML и передаёт её в разработку. И программисты на её основе генерируют код, минуя «табличное описание».
• Doc-as-Code. Мы сделали свою версию — Doc-from-Code, когда аналитику не приходится делать текстовые описания вручную, а итоговая документация генерируется сразу по скриптам, комментариям в коде, процессам BPMN. Пока этот подход используется лишь в некоторых командах и есть трудности во внедрении — но это нормально.

Для аналитиков это сложно, многие воспринимают новые процессы в штыки, потому что приходится превращаться из senior-аналитиков в junior-разработчиков. Но мы стараемся до них донести, что эти трудности поднимают их ценность на рынке. И помогаем: организуем митапы, показываем инструменты, отвечаем на любые вопросы в чате, заполняем свою Wiki и так далее.

Мы даже сделали мем с котиками про стадии принятия — и все системные аналитики, которые становятся инженерами, их проходят. От «нашего продукта это не коснётся» до огромных эмоциональных сообщений в чатах сообщества и, наконец, конструктива.

Какие результаты мы получили

Сообщество системных аналитиков сформировалось больше года назад, и за это время мы создали артефакты (какие-то с нуля, какие-то — на базе уже имевшихся документов).

Карта компетенций

Она состоит из трёх блоков:

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

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

Ассесменты

Они же — оценка персонала. Сейчас она специфичная для аналитиков. Эксперты:

• собирают и обрабатывают обратную связь от команды;
• проводят техинтервью;
• составляют подробное заключение с комментариями;
• контролируют составление индивидуального плана развития.

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

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

Наём персонала

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

И сейчас сближаемся по формату с IT1 — компанией, куда сейчас трудоустраивается большая часть наших ИТ-специалистов: прописываем похожие вопросы и критерии. И «сближаем» техинтервью на наём и на ассесмент, потому что хотим сделать оценку персонала на разных этапах единообразно.

Онбординг

Пока готов только типовой профиль пользователя (набор инструментов, программ и всего-всего, что нужно человеку на входе) и инструкции для новичков. В планах — распространить наш подход с автоматической установкой актуального софта не только на новых, но и на старых сотрудников.

Техрадар

Техрадар — это карта инструментов, языков, практик, которые мы рекомендуем и НЕ рекомендуем внедрять и использовать (чем ближе к центру, тем предпочтительнее; в середине то, что мы используем на регулярной основе). Пока у каждой специальности свой техрадар, но мы планируем сделать общий для всех инженеров.

В идеале техрадар должен постоянно меняться, чтобы соответствовать рынку. Например, в сентябре мы поместили doc-as-code и doc-from-code в «песочницу», но сейчас они используются в проде на некоторых стримах, поэтому мы обновим схему.

Cook Book

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

Что ещё сказать

Мы разобрали, кто такой Head of Profession, поговорили про его роль и навыки. И обсудили на примере системных аналитиков, как он меняет процессы в компании. Надеюсь, это станет для вас полезным и, возможно, вдохновит при выборе трека развития.

Статья сделана по подкасту «Техно.Логично». Переходите по ссылке, чтобы послушать полную версию. Кстати, там эксперты Газпромбанка обсуждают еще много интересных тем.

В современных командах роль системного аналитика снижается

Она появилась как типичная часть заказной разработки, когда заказчик формулировал требования, а подрядчик их выполнял. Добавить что-то после подписания контракта, где оговорены сроки, сумма, объем работ, было дорого и сложно. Этого старались избежать, поэтому и появились системные аналитики, которые очень подробно прорабатывали ТЗ.

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

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

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

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

Документация — ТЗ в том числе — в привычном виде уже не так важна

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

Мы в команде практически отказались от такой документации. Расскажу подробнее.

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

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

С одной стороны, мы привыкли, что после реализации фичи у нас остается документация в виде ТЗ, в которую люди из разных команд могут зайти, почитать, разобраться в продукте/системе. Но с другой, в одной из систем есть, например, BPM-схема Camunda, которая сама по себе является документацией. Внутри нее есть сервис-таски и юзер-таски, в которых мы оставляем комментарии. Есть комментарии в коде и так далее. Почему бы не использовать?

Так, мы с ИТ-лидом стрима начали продумывать план технических задач, которые помогут отказаться от тяжеловесной документации. На текущий момент мы восстановили все спецификации AsyncAPI сервисов, сделали рефакторинг всех BPM-схем Camunda, добавив к каждому элементу схемы дополнительное описание, наполнили БД всех сервисов комментариями к атрибутам и таблицам. Процесс еще идет, но эта идея уже позволила нам отказать от полномасштабной документации.

В целом мы бы хотели в большинстве случаев видеть именно такую документацию — максимально близкое к коду или генерируемое из кода. В большинстве случаев исчерпывающие файлы в Confluence/Word может заменить генерируемая из кода документация на основе комментариев.

Еще мы сейчас тестируем PlantUML — один из инструментов Docs as Code. Делаем небинарный файл, кладем в систему контроля версий и работаем, как с кодом. Так, аналитики вносят изменения в IDE, которая поддерживает плагин, делают пуш, ставят пул реквест. И в ближайшем релизе разработчики заливают их на прод вместе со своим кодом. Все это остается лежать в репозитории, рядом с кодом сервиса. И каждый может зайти и познакомиться с описанием функционала системы.

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

Из-за этого работа системного аналитика становится более технологичной

Расскажу, как профессия меняется у нас, в Газпромбанке

Еще недавно спецификации: OpenAPI, AsyncAPI и прочее — писали только разработчики (если писали), А сейчас мы в компании полным ходом в это погружаемся. Например, активно внедряем API First. Его суть в том, что мы изначально пишем спецификацию в YAML или JSON и передаем разработчикам поставщика и потребителя сервиса. Любая команда может взять ее за основу и сгенерировать код.

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

Из-за всего этого аналитики, которые работали много лет, должны снова становиться джунами, например, в части работы с Git: делать первый коммит, пул реквест, выяснять, как это все работает. Это может быть очень страшно и некомфортно. Мне самой было сложно, но я просила помощи и получала ее.

Из-за смещения роли аналитика ближе к коду, меняются и требования к кандидатам. Растет порог входа в профессию, и мы, как наниматели, рассчитываем, что у системного аналитика будет примерное понимание того, что такое архитектура, что такое API, как формировать простые SQL-запросы. Рассчитываем, что он готов к трансформациям и интересуется смежными ролями (разработчика, архитектора и так далее). А со своей стороны предлагаем обучение нужным техническим скилам.

Аналитики боятся, что станут совершенно не нужны, и их уволят. Но будущее у профессии есть — и классное

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

Про далекое будущее сказать сложнее. Может быть, будет некое объединение бизнес-аналитиков, системных аналитиков, UX-аналитиков, продуктовых аналитиков, и мы получим неких универсальных аналитиков, которые смогут решать большой спектр задач. А может быть, наша роль станет совсем иной. Станем писать только запросы для нейросетей: загружать задачи из бэклога и получать готовый код.

Но перспективы у профессии в любом случае есть.

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

Путь от технического
писателя до старшего аналитика занял около 3 лет. Чтобы освоить новую
специальность, мне пришлось не только овладеть профессиональными навыками и
изучить теорию, но и серьезно поработать над собой.

Об этом я бы хотела рассказать в данной статье.

Творческая профессия

Я по образованию инженер — закончила магистратуру Московского технического университета связи и информатики по направлению «Радиотехника». Еще в институте познакомилась с программированием. Во время магистратуры работала и писала диплом в центре робототехники. После окончания вуза, оценив свои навыки, поняла, что могу быть техническим писателем в ИТ. Так, я устроилась на эту должность сначала в одну ИТ-компанию, потом во вторую, где почти 3 года набиралась знаний и опыта, а потом перешла в IT_ONE.

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

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

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

Поэтому для такого специалиста одинаково важны как профессиональные навыки, так называемые hard skills, так и личностные качества, иными словами soft skills: умение легко находить подход к людям, координировать участников команды, проводить презентации.

Обучение в процессе работы

В компании поддержали мое желание — о том, что я хочу развиваться как аналитик, я рассказала еще на собеседовании. Постепенно руководители команды стали подключать меня к выполнению простых аналитических задач. Так я начала осваивать новую профессию прямо во время работы.

Так как разрабатываемая система не имела графического интерфейса, разбиралась как выполнить простые запросы через Postman/Dbeaver и посмотреть процесс обработки в логах через Kibana. Параллельно штудировала теорию на дополнительных курсах — погружалась в подходы к процессу сбора и структурирования требований, изучала построение визуальных моделей с помощью UML-диаграмм, проектирование интеграций между системами через REST-интерфейс и топики Apache Kafka.

Проектирование REST API и построение UML-диаграмм особенно важно для системного аналитика, из общения с коллегами я вижу, что сейчас это используется повсеместно.

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

То, что я постоянно находилась в
сообществе профессионалов, сыграло ключевую роль в моем становлении как
системного аналитика.

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

Сложности

REST, UML и другие незнакомые слова и аббревиатуры давались непросто, но самым сложным на пути к профессии мечты для меня оказалось вовсе не освоение новых навыков или изучение теории, а способность к профессиональной коммуникации. Приходилось каждый день обращаться к большому количеству коллег с вопросами — и это не так просто, как может показаться. Много времени и энергии приходилось тратить на то, чтобы правильно сформулировать вопрос и осознать ответ. Особенно много сил отнимали масштабные встречи с коллегами или заказчиками.

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

Сложности с запросом обратной связи тоже были. Я не сразу поняла важность обратной связи, и в первое время проявляла мало инициативы. А ведь в новой команде и новой специальности обратная связь особенно важна. Как минимум, чтобы понять, делаешь ли ты то, что ожидают от тебя коллеги и что можно было бы сделать лучше, а что и так хорошо.

Важность баланса

Погружаясь в новую профессию, приходилось справляться с сомнениями, неуверенностью в себе и даже отчаянием в моменты неудач. Хорошо эффективен такой способ самопомощи: устанавливая точки отсчета, отмечать постепенный прогресс, пусть даже небольшой, но стабильный. Лучше всего это делать не в своих мыслях, а, например, на бумаге/наговаривая на диктофон. Так можно посмотреть на ситуацию со стороны, что будет легче для мозга, если он привык обесценивать усилия. Кроме того, я не регулярно, но все же запрашивала обратную связь у коллег, чтобы убедиться в правильном направлении своего профессионального развития.

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

К примеру, я пыталась параллельно проходить курс программирования на Kotlin, но проводить еще 2 часа за обучением после окончания работы для меня оказалось непосильным. Поэтому я пока взяла из курса то, что смогла приложить к своей текущей работе: навыки чтения кода и работы с системой управления версиями Git.

При выборе обучения важно опираться, прежде всего, на реальные потребности. Часто нет смысла углубляться в знания, если этого не требуется для реализации рабочих проектов. Например, среди навыков системных аналитиков часто упоминается умение составлять SQL-запросы к базам данных. Я ознакомилась с этим направлением на базовом уровне, чтобы понимать, как это работает. Но на практике пока не использую этот инструмент, поэтому не вижу смысла изучать его глубже.

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

Стандарт был создан для того, чтобы повысить безопасность и надёжность кода в том случае, когда от его качества зависит жизнь человека. К примеру, MISRA используют в автомобильной отрасли.

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

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

MISRA C определяет правила, которым разработчикам следует следовать при написании кода. Каждый год количество правил, по своей сути — запретов, только растёт:

• В MISRA-C:1998 указаны 127 правил: 93 обязательных и 34 рекомендательных.
• В MISRA-C:2004 указано 141 правило: 121 обязательное и 20 рекомендательных.
• В MISRA-C:2012 указаны 143 правила и 16 директив.

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

Как появился MISRA

Стандарт MISRA был разработан ассоциацией MISRA (Motor Industry Software Reliability Association) в 1994 году в Великобритании. Изначальная цель стандарта — повысить безопасность и надежность ПО для автомобилей.

В начале 1990-х годов количество электроники в автомобилях неуклонно росло. Стало очевидно, что некачественный код может быть опасен для пассажира: к примеру, ошибка ПО во время движения может стоить водителю жизни. Чтобы обезопасить пассажиров, и была создана ассоциация MISRA.

Первый выпущенный стандарт назывался “MISRA Guidelines for the Use of C in Vehicle-Based Software”. Его опубликовали в 1994 году. Он определил правила для использования языка Cи в автомобильном ПО.

Помимо общих правил вроде оформления кода, первый стандарт включал в себя:

1. Правила для управления типами данных, которые запрещали преобразование типов.
2. Рекомендации для обработки исключительных ситуаций (exceptions). Рекомендации по использованию операторов try-catch, исключений и т.д.
3. Запрет непортативных (non-portable) функций и конструкций, которые могут привести к неправильному поведению или ошибкам при переносе кода на другие платформы или компиляторы.
4. Рекомендации и требования к валидации кода и процессу разработки.

В последующие годы стандарт обновлялся и дополнялся. В 2004 году был выпущен стандарт “MISRA C:2004”, а в 2012 году – стандарт “MISRA C:2012”.

В 2023 году стандарт снова обновился

Где используется MISRA

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

1. Автомобильная промышленность: BMW, Ford, General Motors, Honda, Toyota и Volkswagen.
2. Авиационная промышленность: Airbus и Boeing.
3. Медицинская техника: Siemens Healthineers, Philips Healthcare и Medtronic.
4. Промышленные системы: Schneider Electric и Rockwell Automation.

Что запрещено в MISRA

Вот несколько примеров того, что запрещено в стандарте MISRA:

1. Фрагменты кода не должны быть закомментированы.
2. Базовые типы char, int, short, long, float и double не должны использоваться.
3. Операнды логических операторов && или || должны быть первичными выражениями.
4. Оператор goto не должен использоваться.
5. Заголовочный файл и функция setlocale не должны использоваться.

К примеру, вместо char, int, short, long, float и double нужно использовать директиву typedef.

Неправильный код:

Правильный код:

Операнды && и || должны быть одиночными переменными, константами или выражениями в скобках.

Неправильный код:

Правильный код:

С полным списком правил на русском языке можно ознакомиться по этой ссылке.

Как проверять код на соответствие MISRA

На рынке есть несколько анализаторов кода, которые проверяют соответствие стандарту MISRA.

1. PC-lint/FlexeLint — один из самых популярных инструментов статического анализа для языка C и C++. PC-lint/FlexeLint поддерживает проверку соответствия нескольким версиям стандарта MISRA C, включая MISRA C:1999, MISRA C:2004 и MISRA C:2012.
2. Polyspace — анализатор от MathWorks также поддерживает проверку соответствия стандарту MISRA C. Он помогает отслеживать проблемы вроде неопределенного поведения или использования небезопасных функций.
3. Klocwork — ещё один популярный инструмент статического анализа, который поддерживает проверку соответствия стандарту MISRA C.
4. Cppcheck — бесплатный и открытый инструмент статического анализа для C и C++. Изначально он не настроен на проверку соответствия стандарту MISRA, но Cppcheck помогает обнаружить некоторые нарушения.

Также есть пара компиляторов.

1. IAR Embedded Workbench — один из наиболее известных компиляторов, который предоставляет мощный статический анализатор для поиска нарушения правил MISRA и предлагает решения для их исправления.
2. MULTI IDE — интегрированная среда разработки (IDE) с компилятором, поддерживающим стандарт MISRA C. MULTI IDE включает в себя инструменты статического анализа, покрывающие правила MISRA и помогающие в обнаружении потенциальных ошибок.

Заключение

В заключение, стандарт MISRA C — важный инструмент для повышения качества и безопасности кода, который включает рекомендации и правила для написания надежного и поддерживаемого ПО.

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

Соблюдение стандарта MISRA C — это только один из инструментов при разработке безопасного ПО. Он должен быть использован вместе с другими методологиями и практиками вроде тестирования или обзора кода.

Надеюсь, статья оказалась интересной и полезной. Если вы работаете, к примеру, в разработке ПО для автомобилей, расскажите в комментариях, используете ли вы MISRA в работе. Может быть, есть и другие стандарты, которые на практике популярнее MISRA?

Опираясь на опыт коллег, представленный на международной конференции AnalystDays/16, я хотела бы поделиться «Практической магией взаимодействия System Analyst & UX-designer», потому что на своём же примере знаю, что можно столкнуться со сложностями.

Когда возникают конфликты

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

1. Аналитик сам всё спроектировал, принёс дизайнеру, чтобы тот «красиво и удобно» нарисовал.
2. Дизайнер нарисовал только то, что сказал аналитик, без дополнительных исследований.
3. Аналитик постоянно отклоняет различные «хотелки» дизайнера, улучшающие пользовательский опыт, ввиду различных технических причин.
4. Дизайнер имеет типаж «я художник, я так вижу», его интересует только UI, без технических подробностей.
5. Дизайнер имеет типаж «мне аналитик не нужен, я сам знаю, что «логично», а что нет для пользователей».

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

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

1. Недостаточное взаимопонимание

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

2. Недостаток или избыток информации

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

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

3. Различные цели и приоритеты

Системный аналитик может больше сосредотачиваться на функциональности и технической реализации, в то время как UX-дизайнер будет ориентироваться на пользовательский опыт и интерфейс. Это может привести к разногласиям и конфликтам в их взглядах.

4. Ограниченные ресурсы и временные рамки для полноценного взаимодействия и совместной работы.

5. Недоверие друг другу.

6. Аналитик полагается только на свой опыт, дизайнер полагается только на исследования.

На какие группы можно поделить проблемы и как их решать

Проблема сбора требований

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

Решение

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

Проблема распределения обязанностей

Сейчас знания и требования к UX возросли, технологии шагнули вперёд, появились дизайн-системы, и теперь дизайнер может отрисовывать UI только 40% своего времени и внимательнее работать над пользовательским опытом. Тем самым самостоятельно собирать требования с пользователей в рамках исследований и прототипировать функционал. Аналитики при этом всё ещё выполняют те же функции, в связи с чем возникает конфликт обязанностей.

Решение

Нужно установить, какие задачи и области работы относятся к каждой роли. Это поможет устранить путаницу и неопределённость в распределении обязанностей.

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

Любые изменения в распределении обязанностей нужно осуществлять с общим согласием и пониманием между друг другом.

Проблема подхода к продукту

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

Решение

Необходимо учитывать все стороны «табуретки Нормана» — технику, бизнес и пользовательский опыт, идти навстречу друг другу, держа в голове общую цель — качественный продукт.

Проблема дисбаланса экспертизы и данных

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

Решение

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

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

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

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

Аналитик имеет неплохой опыт не только в системном, но и в бизнес-анализе, и даже в архитектуре. А дизайнер умеет исследовать, собирать пользовательские требования и проверять макеты на UX-тестах. Отсюда следует следующее разделение операционного поля: дизайнер занимается функционалом, а аналитик — архитектурой.

Как выглядит эффективное взаимодействие

1. Появляется задача.

2. Составляется её описание по выбранному шаблону.

3. Проводится совместное исследование и определение открытых вопросов.

4. Далее и аналитик, и дизайнер разбираются со своим набором вопросов. При этом взаимодействие не прекращается, оно имеет параллельно-совместный характер.

Системный аналитик предоставляет функциональные требования, бизнес-процесс и архитектуру, а UX-дизайнер проектирует UX, отрисовывает UI и проводит UX-тесты. Затем они синхронизируются и обсуждают прогресс.

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

5. PBR с командой.

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

Подводим итоги

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

Качественное взаимодействие между системным аналитиком и UX-дизайнером принесёт преимущества для всей команды. Продукт становится качественнее, привлекательнее для пользователя, при этом отвечает бизнес-целям, требованиям и возможностям системы.

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

Бизнес также получит выгоду: повысится уровень удовлетворённости пользователей, улучшится эффективность разработки, инкременты с качественным UX и прогнозируемым выходом в прод, снизятся затраты на исправление ошибок, перепроектирование старых систем не только AS IS, но и сразу с улучшением пользовательского опыта.

В этой статье подробно разберём теорию того, кто такой аналитик, обсудим, чем он на практике занимается в большой компании, такой как банк.

Из чего состоит работа аналитика

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

Более подробно про профессию лучше рассказать по книге «Разработка требований к программному обеспечению», которую написал достаточно известный на Западе айтишник Карл Вигерс. Итак, аналитика состоит из нескольких составляющих:

Цель

Это то, ради чего работаем. Чтобы правильно её определить, лучше всего многократно уточнить, к чему мы хотим прийти. Один из любимых способов — задать «пять почему» или «А зачем ты это делаешь?/Что хочешь получить в результате?». Только точно понимая цель можно сформулировать оптимальное решение и отбросить всё лишнее.

Требования

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

• Полнота и корректность — требование должно полностью отражать, что заинтересованное лицо хочет получить (корректность), быть грамотно сформулированным и не иметь смысловых пробелов (полнота).
• Осуществимость — требование должно быть возможно выполнить. Это подтверждается разработчиками.
• Необходимость — требование должно согласовываться с целью задачи, ожиданиями заинтересованных лиц и возможными ограничениями/правилами.
• Проверяемость — выполнение требования должно быть возможно проверить. Это свойство для тестировщиков.

и другие.

Определённые свойства есть и у наборов требований. Например, они должны быть согласованы и не противоречить друг другу.

Требования делятся на несколько слоёв:

• Требования бизнеса. Они чаще всего выражаются через деньги, время, другие ресурсы — что-то, что можно пощупать, максимально конкретизировать. Также это могут быть бизнес-правила, по которым живёт организация, в нашем случае это, например, ограничения Центробанка.
• Пользовательские требования. Это то, чего ждут от вас заинтересованные лица, которые будут в итоге работать с продуктом напрямую. Важно удовлетворять такие требования максимально точно, потому что пользователи очень хорошо понимают, чего хотят — и, как правило, реагируют на качество продукта, который получают. В большей степени это справедливо для клиентов Банка, для внутренних пользователей есть достаточно большое количество ограничений от курирующих их методологов.
• Функциональные требования. Это описание того, как должна себя вести система, какие ключевые задачи выполнять, как выглядеть и так далее. Иными словами, это поведенческие характеристики, которые мы закладываем в продукт.
• Нефункциональные требования. Они определяют, насколько хорошо должна работать система, на какую нагрузку рассчитана и так далее. И очень важны для принятия архитектурных решений. Нефункциональные требования критически важны для полного осознания функциональных требований, с ними обязательно нужно считаться. Если их постоянно игнорировать, в какой-то момент можно получить весьма существенные проблемы.

В итоге все требования собираются в так называемые спецификации, которые и являются той самой поставленной задачей для разработчика.

Работа с требованиями протекает постепенно:

1. Аналитик собирает и изучает информацию.
2. Структурирует и осмысляет её.
3. Фиксирует и утверждает требования.
4. Передаёт требования разработчикам и тестировщикам .

Цель работы с требованиями заключается в том, чтобы сократить затраты такого ресурса как время разработчика и прийти к цели в кратчайшие сроки и с качественным результатом.

Интеграции

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

В чём разница между бизнес- и системным аналитиком

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

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

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

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

У нас, когда системный аналитик всё проработал, задача передаётся в разработку.

Что в итоге?

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

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

Кто такой системный аналитик?

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

Какие сертификации необходимы?

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

Нужно ли иметь опыт?

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

Каковы карьерные перспективы?

Перспективы очень широкие. По данным SuperJob cредняя зарплата системного аналитика в Москве составляет 100 000 рублей, в Санкт-Петербурге 80 000 рублей, в регионах 50 000 – 60 000 рублей в месяц. Далее возможен рост в системного архитектора либо в менеджера проектов.

Кому имеет смысл идти в системные аналитики?

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

Если вам интересна сфера IT и в то же время хочется взаимодействовать с бизнес-заказчиками, разбираться в их процессах и проектировать крупные системы, то присмотритесь к системному анализу.

На основе статьи «How to Become a Computer Systems Analyst»