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

В РФ принято использовать сочетание «системный аналитик», но полное название профессии — аналитик-проектировщик (корпоративных) информационных систем. И все части здесь одинаково важны.

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

В статье я разберу несколько вопросов, касающихся сути профессии системного аналитика в ИТ:

• Зачем нужен системный аналитик: 6 основных задач
• Каких умений ждут от системного аналитика компании
• Спрос на профессию в мире и в РФ

Время на чтение статьи: 15 минут
Не любите читать? Посмотрите видео:

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

В целом — сложно поспорить с этим описанием, но предлагаю «вглядеться» в цели профессии чуть глубже. Говоря о миссии, я выделю 6 основных пунктов:

1. Системный аналитик, как и любой аналитик, помогает принимать решения — заказчикам, менеджерам, команде
2. Системный аналитик делает сложное и запутанное — ясным и простым
3. Для этого cистемный аналитик глубоко разбирается в автоматизируемой деятельности, существующих проблемах и ограничениях
4. Системный аналитик не только анализирует, но и проектирует — генерирует, обосновывает и прорабатывает решения
5. Системный аналитик стремится создавать полезные, удобные, эффективные, экономичные и экологичные информационные системы
6. Системный аналитик постоянно изучает новые технологии и методы работы

Давайте детальнее разберем каждый из них.

1. Системный аналитик, как и любой аналитик, помогает принимать решения — заказчикам, менеджерам, команде

Это основное, на что я обращаю внимание при оценке умений системного аналитика.

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

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

2. Системный аналитик делает сложное и запутанное — ясным и простым

Я бы назвал это «неформальной» миссией системного аналитика.

Есть не очень эстетичная, но тем не менее яркая метафора работы аналитика — «гора родила мышь». В проект приходит аналитик, делает много работы, перерабатывает огромное количество информации и получает на выходе 3 страницы.

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

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

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

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

4. Системный аналитик не только анализирует, но и проектирует — генерирует, обосновывает и прорабатывает решения

Если поговорить с заказчиками или командами, то можно понять, что очень часто мало кого интересует сам по себе анализ. Их интересует не сам факт потребности в изменении или его причины, а то, КАК это сделать, КАКИМ ОБРАЗОМ добиться желаемого нового качества или поведения системы.

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

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

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

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

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

Это то, ради чего аналитик вообще что-то делает.

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

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

Важно понимать, что наша индустрия достаточно быстро меняется, быстро развивается. Когда мы с коллегами активно осваивали профессию 15-20 лет назад, нам было достаточно изучить инженерию требований, изучить как работают СУБД, немножко про архитектуру ПО и уже с этим приносить большую пользу командам и компаниям.

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

Давайте посмотрим на то, какие типовые требования предъявляет рынок системному аналитику:

1. Постановка задач разработчикам
2. Разработка требований (включая моделирование системы)
3. Проектирование и описание интеграций (REST API, брокеры)
4. Документирование проектных решений
5. Приёмочное тестирование
6. Моделирование процессов
7. Участие во внедрении, обучении и поддержке
8. Проектирование баз данных
9. Дизайн интерфейсов
10. Проектирование архитектуры

Если смотреть описания вакансий, то этот пункт пока остаётся доминирующим требованием. Давайте разберем контекст.

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

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

Подробнее про форматы постановки задач читайте в статье Михаила Максимова и Дениса Богданова.

В последние годы в agile-проектах принято ставить задачи на разработку в простом и наглядном формате пользовательских историй (user stories). Научиться разрабатывать пользовательские истории (а также в целом определять функциональный состав программного продукта или информационной системы) можно у Сергея Медведева на воркшопе «Основы бизнес-анализа и разработки требований в Agile».

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

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

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

Подробнее про техники работы с требованиями можно почитать в наших статьях про требования, а научиться их разрабатывать — с Евгением Галактионовым и Мирой Карлаш на нашем курсе «Системный анализ и Разработка требований в ИТ-проектах».

Если вы работаете внутри какого-то устойчивого коллектива, то вам, возможно, формальные требования не нужны. Скорее вы будете ожидать каких-то принятых спроектированных решений относительно функций, структуры, поведения алгоритмов и так далее. Их необязательно оформлять в виде канонических требований (смотрите ISO 29148 и INCOSE Requirements Writing Guide) — можно использовать интересные современные форматы. Например, use cases или те же user stories — они заменяют требования и переводят модальность языка с «вы должны» на язык «есть какой-то пользователь, он хочет делать что-то, давай ему поможем». Другими словами: «есть такая задача пользователя, давайте поможем её решить».

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

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

Освоить системное моделирование можно с Диларой Валитовой на курсе «Основы ООП и разработка UML-моделей».

Проектирование и описание интеграций сейчас, в основном, представлены в двух ипостасях: REST API или взаимодействие через брокеров сообщений.

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

Узнать об интеграции систем можно посмотрев видео «Основы интеграции систем».

Научиться проектировать интеграции через API можно на воркшопе по REST, проектировать интеграции через обмен сообщениями через брокеры Kafka и Rabbit — на воршкопе про них.

Также можно пройти более обширный курс, на котором научиться функциональному проектированию интеграций с помощью use cases, регламентов взаимодействия, диаграмм последовательности, схем маппинга данных и познакомиться с классическими паттернами интеграции, а не только с REST и брокерами — «Основы проектирования интеграций ИТ-систем» (кстати, это наш самый популярный курс с 2020-го года).

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

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

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

В качестве хорошего примера современной практики документирования решений можно посмотреть Architecture Decision Records.

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

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

Познакомиться с формой описания приёмочных тестов в Agile-культуре можно в статье «Как разработать критерии приёмки для User Story».

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

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

Если же ему приходится сначала разобраться с тем, как именно работает бизнес, на смену тяжеловесным практикам SADT, ARIS приходят фасилитационные техники и канвасы Event Storming, Model Storming и Value Stream Mapping.

Научиться моделировать процессы в BPMN можно на воркшопе Анны Вичуговой.

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

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

Всё больше компаний хотят от системного аналитика умения проектировать базы данных. Обычно речь идёт о канонической реляционной базе данных. В связи с этим от аналитика могут также ожидать, что он знает основы SQL, например, что такое JOIN, индексы, какие бывают аналитические функции в СУБД.

Однако, сегодня у работодателя возникает потребность найти сотрудника с пониманием И нереляционных баз данных, так называемых NoSQL (Not Only SQL). Из-за популярности микросервисной архитектуры ожидания от системного аналитика вырастают и от вас может потребоваться знание таких NoSQL СУБД, как, например, MongoDB, Redis или Cassandra.

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

В связи с этим всё чаще возникает ситуация некого «симбиоза» системного аналитика с архитектором: аналитик часто выступает помощником архитектора, постепенно вырастая в проектировщика решений.

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

Освоить проектирование реляционных баз данных можно на воркшопе Миры Карлаш.

Более опытным аналитикам чтобы познакомиться с новыми NoSQL-СУБД пригодится статья Дарьи Колесовой и воркшоп Анны Вичуговой.

В некоторых случаях системный аналитик решает задачи, связанные с дизайном интерфейсов. Это может быть:

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

• в ситуации небольшого объема «дизайнерских» задач. Если общую нагрузку по задачам для дизайнера можно оценить примерно на 30 часов в квартал — в таком случае иметь отдельного человека на поддержку интерфейсов также невыгодно.

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

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

Почему-то в ряде вакансий сейчас пишут напрямую, что ожидают от системного аналитика выполнения задач по созданию архитектуры системы. И тут хочется задать закономерный вопрос: но тогда почему позиция называется не архитектор, а аналитик? :)

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

Смотрим HeadHunter (на май 2023 года):

• 2 600 вакансий (БА — 1 600)
• Из них без опыта работы: 70 = 3%
• Из них дистанционно: 600 = 24%

Количество опыта

Обратите внимание: вакансий системных аналитиков много, но только в 3% не требуется опыт работы. Процент вакансий, где готовы рассматривать кандидатов без профильного опыта работы, гораздо выше для тестировщиков или разработчиков: для них эта цифра доходит до 40-50%.

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

Дистанционный формат работы

Формально видно, что 25% вакансий не требует очного присутствия. На самом деле реальная пропорция вакансий, где допустима удаленная работа, даже выше (предполагаю, что не менее 50%), потому что многие компании не указывают это в атрибутах вакансии, а упоминают это в тексте вакансии или готовы об этом договариваться.

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

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

Смотрим вакансии в США и Великобритании:

Indeed.com — США

• systems+analyst — 6 700
• system+analyst — 1 700 (BA — 13 000)

Indeed.com — Великобритания

• systems+analyst — 500
• system+analyst — 100 (BA — 2 500)

На портале indeed.com (работает России только с VPN) по ключевым словам systems+analyst можно найти 8 400 вакансий только в США. Это больше, чем в 3 раза, по сравнению с Россией. При этом население в США в два раза больше, чем в России. Основная причина — высокий уровень автоматизации и значительное количество рабочих мест в ИТ, в частности в среднем бизнесе. В РФ же позволить себе нанять системных аналитиков часто может только крупный бизнес или госструктуры.

Если мы посмотрим на статистику в Великобритании, то увидим 600 вакансии на всё население, а это примерно в 3 раза меньше, чем в РФ.

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

Место профессии системного аналитика в мире

Бюро трудовой статистики США говорит, что в Америке более 500 тысяч человек работает на позиции системного аналитика. Можете сами решить, насколько можно верить цифрам государственных служб, но всё-таки 500 тысяч человек — это не 5 тысяч и не 50, это огромное количество специалистов!

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

Также интересно, что Systems Analyst входит в TOP-100 самых высокооплачиваемых профессий в США (почётное 82-е место) по данным того же indeed.com!

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

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

Помимо продуктовой разработки, в мире есть большой пласт заказной (custom development) и внутренней (in-house development) разработки ИНФОРМАЦИОННЫХ СИСТЕМ, которые решает задачи автоматизации бизнеса и построения именно информационных систем предприятия, а не продуктов и сервисов для открытого рынка и соответственно внутри традиционных бизнесов и компаний заказной разработки наиболее актуальна роль системного аналитика.

Например, одна из медицинских клиник в США нанимает аналитиков, называя их Clinical Systems Analyst. Основная задача таких специалистов — отвечать за формулирование и внедрение запросов на изменение внутренних систем, а также нередко — быть первой и второй линией поддержки системы внутри своей организации.

Примеры актуальных вакансий можно посмотреть, например, на www.simplyhired.com:

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

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

Если мы посмотрим на вилки зарплат по данным HeadHunter за 2023 год, то увидим, что уровень оплаты у системного аналитика очень достойный:

Давайте посмотрим на конкурс профессии. Методика подсчета проста: делим количество вакансий на количество резюме, обновленных в течение последней недели (источник — HeadHunter).

• Вакансий СА — 2 600
• Обновлено резюме СА за неделю — 1 600 (всего 12 000 резюме)
• Конкурс — 2 600 / 1 600 = 0,6 человек / место

Из цифр видно, что на самом деле конкурс не очень большой: всего 0,6 человек на место.

Для сравнения другие ИТ-профессии:

• Тестировщик — 11 000 / 1 100 = 10

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

• Аналитик данных — 2 600 / 470 = 5,5

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

• Бизнес-аналитик — 3 900 / 2 000 = 2 (всего 24 000 резюме)

Бизнес-аналитик — также сравнительно простая профессия для входа, потому что подготовка занимает 50-100 часов.

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

• Специалист технической поддержки — 6 200 / 2 800 = 2,2

Достаточно приятный конкурс на специалиста технической поддержки. И на мой взгляд, техподдержка пока еще остается хорошей интересной «лазейкой» в ИТ (для тех, кто не успел заскочить на поезд через тестирование). Для того, чтобы претендовать на позицию такого специалиста, вам достаточно разобраться с тем, что такое операционная система, как работает браузер, файловая система, консольные команды и это можно освоить за 20-30 часов изучения. Оконченный вуз и хорошие soft skills повышают ваши шансы на фоне эникейщиков после школы.

• Разработчик — 50 000 / 19 500 = 2,6

Разработчиком начинать сложнее как минимум потому, что на разработчика невозможно учиться быстро. Как минимум, нужно 500 часов — поэтому это не очень простая профессия для входа.

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

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

• Когда мы говорим «системный аналитик», то подразумеваем — аналитик-проектировщик (корпоративных) информационных систем.

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

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

• По данным Headhunter, конкурс в профессии не очень большой (0,6 специалистов на место), но и вакансий для начинающих специалистов менее 3%. Это означает, что профессия системного аналитика не может быть стартовой для входа в ИТ.

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