Из разработчика в системные аналитики: практический путь в профессию

Привет, Хабр! Меня зовут Анна Пушкарева, я системный аналитик в компании «СИБИНТЕК‑СОФТ». Три года назад я перешла из разработки в аналитику и сейчас участвую в создании внутреннего сервиса для управления проектами — от первых требований до тестирования на реальных пользователях.

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

О чем поговорим:

1. Такие разные «аналитики»: как не запутаться в терминах и выбрать своё

2. Системный аналитик на всех этапах разработки ПО

3. Артефакты: что остается после работы

4. Инструменты: чем пользуюсь я

5. Навыки: что реально нужно знать и уметь

6. Итоги

1. Такие разные «аналитики»: как не запутаться в терминах и выбрать своё

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

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

Аналитики требований (проектируют, как будет работать система):

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

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

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

Аналитики данных (исследуют цифры и метрики):

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

• Продуктовый аналитик. Смотрит на метрики продукта, строит гипотезы и проверяет их через A/B‑тесты. Его задача — сделать продукт удобнее и прибыльнее.

• Аналитик данных (Data Analyst). Ищет в данных закономерности, причины тех или иных событий, строит прогнозы. Похож на BI‑аналитика, но больше анализирует, чем визуализирует.

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

2. Системный аналитик на всех этапах разработки ПО

Часто кажется, что аналитик нужен только в начале проекта — написал требования и ушел. На практике всё иначе.

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

Анализ

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

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

Проектирование

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

На этом этапе я составляла User Story и Use Case, проектироватала архитектуру по модели С4, описывала, как пользователи будут взаимодействовать с системой. Вместе с дизайнером и владельцем продукта мы прорисовывали интерфейс, обсуждали логику экранов и сценарии поведения.

Дизайн

Главный на этом этапе — UI/UX‑дизайнер. Я выступаю в роли консультанта, объясняю пользовательские сценарии и слежу, чтобы визуальное решение не ломало логику продукта. И, конечно, участвую в финальном согласовании макетов.

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

Разработка

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

Я отдавала команде User Stories, Use Cases, макеты, схему базы данных. Программисты по ним разрабатывали нужный функционал. В процессе работы постоянно консультировала, что‑то уточняла, вносила правки.

Тестирование

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

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

Внедрение

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

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

Поддержка и развитие

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

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

3. Артефакты: что остается после работы

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

Внешние артефакты

То, что мы показываем заказчику и пользователям. Отвечают на вопрос «ЧТО система будет делать?», например:

• Пользовательские инструкции.

• Функциональные требования.

• Техническое задание.

Внутренние артефакты

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

• Архитектурные схемы.

• Модели данных (ER‑диаграммы).

• Спецификации API.

• Схемы интеграций.

4. Инструменты: чем пользуюсь я

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

Для документации

• GitLab, Confluence, Word, Excel. По большей части использую GitLab и Confluence — там удобно вести версионирование, и у всех всегда под рукой актуальная версия.

• Jira. Для ведения и постановки задач, планирования спринтов.

• Различные конвертеры. Требуются для перевода из markdown в html или Excel, в зависимости от того, какой формат удобнее команде.

Для схем и моделей:

• Draw.io и Miro. В Draw.io рисую диаграммы, в Miro удобно проводить воркшопы и мозговые штурмы.

• Pixso и Figma. Использую для работы с дизайн‑макетами.

Для API:

• Swagger. Это стандарт описания REST API. Почти все современные бэкенды отдают документацию в Swagger. Умение читать Swagger‑спецификацию — базовый навык.

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

Для анализа данных:

• SQL (любой клиент: DBeaver, pgAdmin). Знание базового SQL обязательно, с ним можно самостоятельно исследовать данные и проверять гипотезы.

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

5. Навыки: что реально нужно знать и уметь

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

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

6. Итоги

Если вы, прочитав всё это, не испугались, а, наоборот, загорелись, у меня для вас два универсальных совета.

Совет № 1. Определитесь с направлением.

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

Совет № 2. Начните учиться, но с умом.

Здесь есть два пути, и какой выбрать — решать вам:

• Путь «слабое звено». Проанализируйте список навыков выше и честно скажите себе, чего вы НЕ знаете совсем. И начните учить это. Это самый прагматичный подход, который быстро закроет ваши пробелы.

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

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

Спасибо за внимание!