Руководство системного аналитика

Как аналитику работать с задачами на интеграции — пошаговая инструкция

Привет! Я хочу рассказать о важной части задач, с которыми работают системные аналитики. Это задачи на проектирование интеграций.

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

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

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

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

Пошаговая инструкция по проектированию интеграций

1. Подготовка

• Знакомство с проектом.

  • Предметная область.

  • Как сейчас работают бизнес-процессы — AS IS.

  • Что по системам, приложениям и сервисам уже есть в проекте.
    Есть ли программные интерфейсы (API), которые надо будет учитывать или дорабатывать при работе с текущей задачей на интеграцию.

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

  • API-документация (REST API, GraphQL, SOAP API и другие).

  • Комплекты SDK.

  • Другие документы и файлы, необходимые разработчикам для создания кода.

• Запрос доступов к внешним системам, тестовых площадок:

  • Тестовые и боевые URL.

  • Логины, пароли и токены.

  • Тестовые электронные ключи на носителях.
    Был опыт, когда надо было подписывать запросы к API с использованием ЭЦП (электронно-цифровой подписи на флешке).

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

  • Другие неоходимые данные для аутентификации и авторизации запросов.

2. Сбор и анализ требований

Как только поняли, что из себя представляют бизнес-процессы AS IS, то необходимо получить понимание что требуется от разработки — TO BE.

• Бизнес-цель разработки интеграции.
  Пример:
  Увеличить продажи товаров.

• Бизнес-задачи интеграции.
  Пример:
  Подключить сервис SMS-рассылок чтобы делать рассылки специальных предложений клиентам через дополнительный канал коммуникаций.

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

• Функциональные требования.
  Примеры:
  — Добавить поле ввода номера телефона, обязательное при регистрации клиентов в мобильных приложениях и на сайте.
  — Сделать возможность создания SMS-рассылки в панели админисратора.

• Нефункциональные требования.
  Пример:
  Рассылка 10тыс сообщений должна выполняться не более чем за 5 минут.

• Разработка схемы архитектуры — первое приближение. Инструкция опубликована здесь. Может быть использована нотация C4.

3. Анализ API документации

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

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

2. Авторизация и аутентификация.

3. Тестовые доступы, если еще не получили.

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

5. Общие требования к обработке ошибок. Коды ответов.

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

API-документация может быть передана вам в виде ссылке на Postman-коллекцию, Swagger-коллекцию, сайт разработчика, PDF-документ, Word-документ.

Кстати, API-документация не всегда есть. И иногда надо «пытать» разработчиков в переписке, чтобы получить описание методов API. Всякое бывает.

4. Тестирование API

Этот этап нужен при анализе и проектировании по следующим причинам:

1. Убедиться, что все работает как в API-документации.

2. Понять как реально работает API и весь бизнес-процесс. Посмотреть на данные.

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

4. Лучшее понимание технической части задачи.

Для тестирования Web API (REST API, GraphQL, SOAP API и другие) работаем с Postman или SOAP UI.

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

5. Разработка логики и алгоритмов

Необходимо описать логику работы — Use Case — сценарии интеграции. Это самое главное, что прорабатывает аналитик при работе с интеграционной задачей.

Критерии хорошего интеграционного Use Case:

• Описана полная последовательность шагов и альтернативные сценарии по каждому шагу.

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

• Для шагов, где есть интеграционное взаимодействие, указаны интеграционные методы.

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

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

6. Анализ данных = маппинг данных

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

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

Пример таблицы с маппингом:

7. Разработка схемы архитектуры

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

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

8. Постановка задач

Создаем задачи в Jira и собираем описание по каждой задаче в Confluence или в аналогичных системах. Как правило создаются задачи на:

• Создание файлов конфигураций или доработка существующих.

• Изменение БД — создание таблиц, добавление новых полей.

• Реализация интеграционных методов для Backend-разработчиков.

• Поддержка изменений, связанных с изменениями для приложений пользователей.

9. Релиз, сопровождение и документация

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

Одна из рекомендаций по структурированию знаний:

После релиза важно следить за обновлениями API внешней системы и, в случае необходимости, своевременно делать переезды на новые версии.

Заключение

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

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

Сохраняйте инструкцию и применяйте в своих проектах

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

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

Функциональное проектирование отличается от технического проектирования, которое выполняет архитектор или разработчик, когда он определяет внутреннее наполнение информационной системы — языки программирования, СУБД, архитектурный шаблон, модульное разбиение, готовые компоненты, инструменты интеграции.

Также не всегда, но часто, системный аналитик занимается:

• анализом и моделированием бизнес-процессов (как и бизнес-аналитик — например, при помощи BPMN)
• анализом данных с помощью SQL
• созданием графических моделей работы системы (обычно с использованием UML)
• проектированием интеграций (API, JSON, REST, XML)
• постановкой задач разработчикам
• макетированием интерфейсов систем внутреннего использования
• приёмочным тестированием
• разработкой пользовательской документации

Конкретный набор обязанностей системного аналитика зависит от компании.

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

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

Системный аналитик в IT-компании — специалист на стыке аналитики, разработки, менеджмента. Он анализирует потребности заказчика, формулирует требования к IT-проекту и курирует процесс разработки. Системный аналитик создает основу продукта и делает так, чтобы результат соответствовал желаемому. Чтобы погрузиться в работу системного аналитика, поговорили с Ангелиной Шконда, Middle System Analyst IT-компании Smartex.

Обязанности системного аналитика

Обычно процесс работы системного аналитика выглядит так:

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

Отличия системного аналитика от других профессий

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

А теперь к заповедям

При обсуждении проекта аналитику нужно не только фиксировать требования заказчика, но и ясно понимать возможности своей команды, учитывать ресурсы проекта и доступные технологии. В идеале это выглядит так: получение требований => быстрый анализ текущих возможностей => выдача рекомендаций. Конечно, знать все сложно (цитата автора: «абсолютно анпосибл»), но быть в курсе технического рынка жизненно необходимо.

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

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

Считывать эмоции, подстраиваться под настроение и чувствовать контекст — важнейшие soft skills системного аналитика. Формальная отработка — не лучший подход. Боль и потребность заказчика необходимо прочувствовать. Нужно поставить себя на место конечного пользователя, увидеть продукт его глазами. Если подходить к заказчику с заботой, шанс создать классное решение намного выше!

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

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

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

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

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

Чтобы ускорить запуск процесса разработки, команда аналитики должна отработать быстро. А скорость лежит в дисциплине и декомпозиционном подходе. Всегда стоит быть реалистом и честно оценивать свои возможности — не стоит планировать на день 15 спецификаций, если в силах сделать только 5.

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

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

Чем занимается системный аналитик?

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

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

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

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

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

Обязанности системного аналитика

В процессе реализации проекта системный аналитик первым шагом собирает требования с заказчика. Нужно выяснить, что заказчику нужно от программного обеспечения. Он анализирует эти требования на полноту, непротиворечивость, уточняет проблемные места и проводит дополнительные интервью. На интервью системный аналитик спрашивает заказчика обо всём, в чём сомневается: «А для чего? Какую проблему это решит? А точно ли это надо?»

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

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

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

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

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

Отличия системного аналитика от бизнес-аналитика

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

1

Навыки специалиста

Софтскилы

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

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

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

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

Хорошая память. Системный аналитик должен быть «живым справочником» по проекту, который отвечает на любой вопрос.

Хардскилы

SQL на базовом уровне. SQL (structured query language) — язык структурированных запросов. Его применяют для создания, модификации и управления данными.

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

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

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

Необходимые навыки системного аналитика, по данным «Хабр Карьеры»:

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

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

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

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

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

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

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

Где работают и сколько зарабатывают системные аналитики?

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

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

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

На hh.ru работодатели ищут начинающих системных аналитиков и предлагают им зарплату от 40 000 рублей. Стажёрам и младшим специалистам работодатели предлагают 60 000—130 000 рублей. Средняя зарплата системного аналитика: 150 000—250 000 рублей. Зарплата старшего системного аналитика — от 270 000 рублей.

По данным «Хабр Карьеры», за второе полугодие 2021 года средняя зарплата системного аналитика составляет 147 000 рублей. Конечно же, эти цифры условны. Чем больше у специалиста опыта, навыков и знаний, тем выше он ценится на рынке труда.

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

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

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

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

Если на стажировку попасть не получится, можно пройти обучающие курсы. В Яндекс Практикуме есть курс «Системный аналитик», на котором вы получите необходимые навыки для быстрого старта в карьере: сделаете практические работы, которые сможете добавить в портфолио.

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

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

Благодарим за помощь в подготовке материала Ксению Шипину, системного аналитика Skyeng и преподавателя курса «Системный аналитик» в Нетологии.

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

Его можно назвать посредником между заказчиком — руководством компании — и исполнителем — разработчиком.

Итог такого сотрудничества — программный продукт.

Такое определение близко к истине, но не универсально. У проблемы трактовки есть несколько причин.

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

Другая причина — разница в развитии IT-рынков в России и в мире. Впервые термин «системный анализ» ввела в 1948 году некоммерческая организация RAND, которая в 1956 году выпустила книгу на эту тему. В 1959 году американские предприниматели Рой Натт и Флетчер Джонс основали первую компанию по разработке ПО — Computer Sciences Corporation. И многие практики задумались о том, что основы системного анализа можно использовать в разработке.

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

В России и странах ближнего зарубежья развитие IT-рынка началось позднее. Разработка первых программ для коммерческого использования ЭВМ стартовала только в 1980 году. А индустрия информационных технологий начала развиваться только в 1990-х — после распространения первых ПК.

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

Профессия системного аналитика окончательно оформилась как самостоятельная и стала востребованной по нескольким причинам:

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

• Рост конкуренции на рынке ПО тоже оказал влияние. По разным причинам многие проекты завершались неудачно: компании вкладывались в невостребованные решения из-за недопонимания между заказчиком разработки и исполнителем. Так возникла потребность в специалистах с хорошим техническим бэкграундом и развитыми soft skills, которые могут правильно понять боли бизнеса и оптимизировать процесс разработки.

• Усложнение программ сыграло свою роль — для грамотной интеграции ПО нужны узкоспециализированные специалисты.

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

Что делает системный аналитик:

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

Для выполнения рабочих задач специалист должен владеть определёнными компетенциями:

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

Процесс разработки — это постоянный обмен информацией. Чтобы правильно запрашивать и ясно доносить её, системному аналитику важно развивать и soft skills.

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

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

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

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

Осваивать всё сразу необязательно: профессия быстро развивается — стремительно меняются и тенденции.

Аналитика — широкая сфера деятельности. Расскажем об отличиях системного аналитика от схожих и смежных профессий.

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

Аналитик занимается Big Data: умеет обрабатывать сырые данные и строить гипотезы на этой основе. Аналитик данных работает с метриками, системный аналитик — с процессами. Для первого знание Python необходимо, для второго — будет плюсом.

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

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

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

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

По данным Glassdoor, средняя зарплата системного аналитика в Москве — 150 000 рублей:

Согласно данным Хабр Карьеры, в 2020 году медианная зарплата специалистов по России составила 100 000 рублей:

На HeadHunter на момент написания статьи за месяц по России размещено более 3 000 вакансий по запросу «Системный аналитик» с зарплатой от 75 000 рублей:

Американский новостной журнал US News and World Report поставил эту специальность на 5-е место в списке лучших технических профессий. По данным издания, в 2019 году медианная зарплата системного аналитика в Америке составила $91 000.

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

Вертикальный рост не отличается от традиционного для интернет-профессий: стандартные Junior, Middle и Senior — это младший, старший и ведущий аналитики, далее — руководитель отдела аналитики.

А вот возможности для горизонтального развития шире:

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

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

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

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

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

Лучшие выпускники курса пройдут собеседование в компании «Спортмастер».

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

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

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

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

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

---

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

Иллюстрация: Garetsvisual / Freepik / Annie для Skillbox Media

Редактор Skillbox Media. Пишет о бизнесе и маркетинге вместе с экспертами.

Автор статьи

Руководитель Центра компетенций аналитики в ITQ Group.

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

• Кто такой системный аналитик и чем он отличается от бизнес-аналитика
• Чем занимается системный аналитик? Разбираем на примере
• Что должен уметь системный аналитик? Soft skills
• Hard skills и карьерный путь системного аналитика

---

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

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

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

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

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

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

Мы в ITQ Group делаем новый платёжный движок для крупного российского банка. Платёжный движок — одна из центральных для банка подсистем. Без него не пройдёт ни одна транзакция. Система важна и для внутренних, и внешних платежей. Разберём работу системного аналитика на примере этого проекта.

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

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

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

Обучение для менеджеров в Skillbox

• Профессия «Бизнес-аналитик». Специальность, которая особенно востребована во время нестабильности.
• Профессия «Операционный менеджер». Для тех, кто хочет настроить эффективную работу отделов компании, повысить KPI и зарабатывать больше.
• Профессия «Менеджер проектов». Для тех, кто хочет научиться управлять проектами с помощью разных методик, пополнить портфолио сильным кейсом и найти оплачиваемую работу проджектом.

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

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

У системных аналитиков существует профессиональный стандарт.  Он будет полезен, если вы начинаете карьеру в системной аналитике или хотите сверить свои компетенции с требованиями, которые предъявляет рынок к кандидатам уровня junior, middle или senior.

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

Младший системный аналитик (junior). Способен самостоятельно выполнять долгосрочные аналитические задачи под контролем старших коллег. Опыт — от четырёх месяцев на позиции стажёра. Зарплата — 120–150 тысяч рублей.

• Участвовал при формировании первичных требований к IT-системе, при формировании технического задания и при техническом проектировании — как минимум на одном проекте.
• Проводил интервью по сценарию, составленному старшим коллегой. Есть опыт подготовки протоколов рабочих встреч
• Анализировал нормативно-правовые акты, которые регулируют процессы в системе. Знаком с регламентами организаций, которые касаются системной аналитики. Анализировал документацию для систем и системы конкурентов, выбранные старшим коллегой.
• Наблюдал за работой пользователей, может создать спецификацию для разработки в уже готовом шаблоне. Есть опыт написания спецификаций в формате use case с описанием целей, участников, стейкхолдеров, событий-триггеров для системы, основных сценариев её работы, ограничений и дополнений.
• Знает общие принципы проектирования и описания UI. Владеет хотя бы одним средством прототипирования уровня Balsamiq. Имеет опыт подготовки требований по семи критериям качества: единичность, атомарность, недвусмысленность, полнота, выполнимость, проверяемость и непротиворечивость.
• Знает способы выявления и анализа рисков. Имеет опыт авторского контроля атомарных требований, которые сам сформулировал.
• Способен участвовать в коммуникации и постановке задач разработчикам, вносить правки в базу знаний и документацию. Имеет опыт авторской приёмки атомарных требований, которые сам сформулировал. Может подготовить презентацию по атомарной функции — как минимум по шаблону в PowerPoint.
• Участвовал в обучении пользователей системы под контролем старшего аналитика. Имеет опыт участия в проектах по модели Waterfall. Имеет опыт участия в проектах по другим гибким методологиям — например, Kanban, Lean, Agile или Scrum.
• Знает основы жизненного цикла системы при работе по гибким методологиям. В него входит планирование, разработка, демонстрация и внедрение системы. Знает основные функции BI — это хранение, интеграция, анализ и представление.
• Знает состав описания API. Может описать API с минимальной помощью разработчика; понимает разницу между синхронным и асинхронным взаимодействиями между компонентами системы.
• Опционально: документировал требования по методологии Agile.

Аналитик (middle). Способен к самостоятельному выполнению всех аналитических задач в отдельно взятом проекте. Опыт — 1,5–2 года. Зарплата — 150–180 тысяч рублей.

• Умеет собирать требования к системе. Знает, какие инструменты для этого нужны. Инструментами могут быть, например, программы Confluence и Jira.
• Имеет опыт подготовки и проведения интервью. Готов проводить ревью списка вопросов и протоколов интервью, составленных младшим коллегой. Знает, как составлять анкеты для интервью и обрабатывать их результаты.
• Знает, какие нормативно-правовые акты нужны для анализа проекта, какие понадобятся регламенты, корпоративные инструкции и документация для системы.
• Наблюдал за работой пользователей проектированной системы. Умеет выявлять узкие места, способен вносить предложения по их устранению.
• Умеет декомпозировать задачи, готовить шаблоны для написания спецификаций, проводить их ревью, выявлять ошибки и неточности. Коммуницирует по этим вопросам с IT-архитекторами, разработчиками и бизнес-заказчиком.
• Умеет декомпозировать требования к готовой системе до уровня отдельных подпроцессов. Имеет опыт проработки ограничений к набору требований. Речь, например, об ограничениях по стеку технологий — когда у компании уже есть IT-система и нужно продумать, как интегрировать в неё новые функции.
• Умеет проводить ревью и оценку качества требований по семи критериям: единичность, атомарность, недвусмысленность, полнота, выполнимость, проверяемость и непротиворечивость. И тремя дополнительными: прослеживаемость, актуальность и обязательность.
• Умеет писать и документировать требования для user story. Знает алгоритм работы с рисками: выявление, анализ, оценка и выбор стратегии.
• Проводил авторский контроль раздела с требованиями в зоне своей ответственности. Например, делал авторский контроль конкретной подсистемы.
• Знает инструменты описания API — например, Swagger, Postman. Знает спецификацию OpenAPI. Может описать API без помощи разработчика. Знает основы работы протоколов HTTP, REST, SOAP, а также форматов обмена данным XML и JSON.
• Умеет оценивать и декомпозировать задачи по системной аналитике с общей трудоёмкостью до трёх месяцев.
• Опционально: умеет применять в работе методики PERT, UCP и Agile.

Старший аналитик (senior). Способен выполнять задачи самостоятельно и распределять их внутри команды, контролировать качество и сроки их выполнения — на одном или нескольких проектах. Опыт — от трёх лет. Зарплата — 200–250 тысяч рублей.

• Умеет составлять план и выбирать стратегию сбора требований для проекта. Способен понять, как собрать требования наиболее эффективно: какие методы выбрать, у кого собирать требования и с кем их согласовывать.
• Умеет проводить интервью и анкетирование. Отвечает за все процессы, связанные с их организацией, — включая анализ результатов.
• Подбирал системы конкурентов заказчика для анализа в условиях высокой неопределённости — когда прямые аналоги отсутствуют.
• Способен выполнить декомпозицию задач в рамках проекта, определить и назначить исполнителей. Имеет опыт разработки шаблонов для написания спецификаций под конкретные задачи.
• Проводил ревью спецификаций от младших коллег. Умеет проводить ревью описания процессов, выявлять ошибки и неточности.
• Может самостоятельно спроектировать API — при условии, что есть возможность уточнить технические параметры у разработчика или архитектора системы.
• Умеет разрабатывать шаблоны описания интерфейсов, чтобы ставить задачи для разработчиков. Может спроектировать общую концепцию интерфейса системы с помощью вайрфрейма. Может разработать кликабельный прототип.
• Проводил ревью и оценку качества требований по всем 10 признакам. Разрабатывал и внедрял методологии проверки качества требований на проекте. Контролировал её применение — например, с помощью чек-листов.
• Делал ревью требований в формате user story по методике INVEST. Прорабатывал полный набор ограничений для технического задания на систему.
• Прорабатывал риски проекта, которые связаны с аналитическими работами. Подбирал стратегию управления каждым риском: продумывал способы, которые помогут их избежать. Составлял программу действий, чтобы их минимизировать.
• Декомпозировал и оценивал задачи для команды аналитиков проекта — общей трудоёмкостью от трёх месяцев.
• Делал авторскую приёмку требований к системе в целом. Успешно проходил внешнюю экспертизу отчётных документов со стороны заказчика. Проводил тесты готовой системы на стенде заказчика.
• Самостоятельно разрабатывал обучающий курс по функциональности системы. Разрабатывал методические материалы: теоретическую часть, набор практических кейсов, составлял список контрольных вопросов. Проводил внутреннее и внешнее обучение пользователей для подразделения или департамента.
• Проектировал функциональность хотя бы одной BI-системы в целом.
• Опционально: применял PERT, UCP и Agile для оценки аналитических задач проекта в целом. Работал в крупных agile-проектах, где требовалось масштабирование agile-методик. Под крупными проектами имеются в виду государственные проекты федерального уровня или, например, проекты по созданию автоматизированных банковских систем. Применял Scalable Agile Framework.
• В идеале работал на десяти и более проектах по модели Waterfall. Имеет экспертный опыт в управлении жизненным циклом ПО по модели Waterfall — в части анализа и проектирования IT-системы.

• Системный аналитик — специалист, который работает с IT-системами. Он переводит требования к IT-продукту с языка бизнеса на язык разработки и контролирует процесс его создания — вплоть до запуска в работу.
• Системным аналитикам хорошо платят. Уже на старте специалист может получать от 120 тысяч рублей, а опытные аналитики зарабатывают 250 тысяч и более.
• Стартовать в профессии придётся с позиции стажёра. Для этого нужно быть студентом старших курсов или выпускником вуза технической специальности, знать основы работы с базами данных и основы моделирования бизнес-процессов.
• Качества, которые нужны системному аналитику: коммуникабельность для общения с командой и заказчиками, готовность обучать и обучаться. Системный аналитик должен быть готов стать лидером — начиная с позиции middle, он может занимать в проекте руководящую должность.

Научитесь: Профессия Бизнес-аналитик
Узнать больше

Меня зовут Соня, и в 20 лет я стала самым молодым системным аналитиком в отделении крупного российского банка.

Я живу в Саратове, войти в ИТ хотела еще со школы. В 2018 году поступила в СГУ имени Чернышевского на факультет системного анализа и управления. Но не могу сказать, что вуз как-то помог в карьере. Совершенно бесполезные академические знания, никак не связанные с рыночным представлением о профессии системного аналитика, и шуточки преподавателей, что на работу возьмут только официанткой, оставили не самое приятное впечатление.

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

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

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

Образование и первые шаги в ИТ

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

Для меня это стало любовью с первого взгляда: я нашла что-то на стыке технаря и гуманитария! Еще и с приятной средней зарплатой 180 тысяч рублей. При взгляде на цифры оставшиеся сомнения исчезли.

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

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

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

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

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

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

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

Стажировка и работа

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

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

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

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

Собеседование немного напомнило игру: предлагали представить, что ты сделаешь в той или иной ситуации. Еще давали задачи на логику из серии: «Все арбузы — это коровы, а все коровы красные. Значит ли это, что все арбузы красные?»

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

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

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

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

Так пролетели три месяца, и я, уже совсем «взрослая», оказалась в штате. Мне предложили должность младшего системного аналитика, 40-часовую рабочую неделю и оклад больше, чем на стажировке. По NDA я не могу назвать размер зарплаты.

Задачи системного аналитика

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

Работа системного аналитика напоминает роль следователя в остросюжетном детективе.

Любой продукт проходит через шесть фаз:

1. Сбор и анализ требований.
2. Документирование требований.
3. Дизайн.
4. Разработку.
5. Тестирование.
6. Внедрение и поддержку.

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

Наш герой-следователь заводит дело и выезжает на место преступления. А я завожу задачи в трекере YouTrack для описания техзадания.

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

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

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

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

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

Мой рабочий день

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

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

В 10:15 у нас обязательное ежедневное совещание с коллегами-аналитиками. Обсуждаем, кто что делал вчера и какие у кого планы на сегодня. Иногда на них весело.

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

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

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

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

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

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

Советы для старта в профессии

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

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

Методология разработки определяет порядок выполнения задач, методы оценки и контроля. Бывают разные виды: waterfall, спиральная, итеративная, инкрементная, V-образная, RAD и, конечно же, одна из самых популярных, актуальных и удобных — Agile. Между собой они различаются подходом к постановке задач, контролю результата и тем, насколько четко сформулированы требования к продукту.

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

Советую:

• книгу «Руководство по Scrum» Кена Швабера и Джеффа Сазерленда;
• книгу «Канбан. Альтернативный путь в Agile» Дэвида Андерсона;
• книгу «Impact Mapping. Как повысить эффективность программных продуктов и проектов по их разработке» Гойко Аджича;
• курс «Постановка задачи на разработку ПО»;
• мультик, который за пять минут расскажет о самом популярном фреймворке разработки ПО, — для самых ленивых.

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

Рекомендую книги:

• «Разработка требований к программному обеспечению» Карла Вигерса и Джоя Битти;
• «Пользовательские истории. Искусство гибкой разработки ПО» Джеффа Паттона;
• «Современные методы описания функциональных требований к системам» Алистера Коберна.

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

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

Рекомендую:

• книгу «Введение в UML. Краткое и информативное пособие по основам UML-моделирования» Мартина Фаулера — это наиболее популярный труд по моделированию бизнес-процессов, читается максимально легко и просто;
• курс лекций «Введение в программную инженерию» Дмитрия Кознова;
• графический редактор draw.io для отработки навыков на практике. Он создавался для построения диаграмм бизнес-процессов, и в него изначально загружены самые популярные фреймворки, чтобы моделирование процессов занимало минимум времени.

Базы данных и умение составлять SQL-запросы. Это нужно для систематизации информации и мгновенного поиска. К примеру, относительно недавно мне нужно было найти все актуальные документы, хранящиеся в базе, — один запрос, и готово!

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

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

• «От монолита к микросервисам» Сэма Ньюмена;
• «Шаблоны интеграции корпоративных приложений» Грегора Хопа и Бобби Вульфа;
• «BABOK. Руководство к своду знаний по бизнес-анализу. Версия 3.0» — это гайд, который разработал Международный институт бизнес-анализа.

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

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

Планы

Разумеется, я не могу не думать о дальнейшем развитии, поэтому регулярно читаю книги и статьи по своему профилю. Например, есть интересные телеграм-каналы «Бизнес-анализ & ИТ», «Physics. Math. Code» и «Business Analysis Magazine chat». Иногда хожу на вебинары, чтобы послушать коллег из других компаний. Советую новичкам в профессии доклады с конференции по системному и бизнес-анализу Analyst Days.

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