Привет, Хабр! Меня зовут Анна Пушкарева, я системный аналитик в компании «СИБИНТЕК‑СОФТ». Три года назад я перешла из разработки в аналитику и сейчас участвую в создании внутреннего сервиса для управления проектами — от первых требований до тестирования на реальных пользователях.
В этой статье я расскажу о профессии системного аналитика с практической точки зрения. Материал в первую очередь ориентирован на тех, кто работает или планирует работать в ИТ‑сфере, но будет полезен и аналитикам из других областей — многие подходы и принципы универсальны. Я поделюсь не только теорией, но и конкретными примерами из своего проекта, покажу, какие задачи реально приходится решать и с какими инструментами работать.
О чем поговорим:
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. Навыки: что реально нужно знать и уметь
Когда меня спрашивают, что нужно учить, чтобы стать системным аналитиком в ИТ, я всегда отвечаю, привязываясь к этапам разработки. Это помогает не хвататься за всё сразу, а видеть цельную картину.
Этап разработки | Soft skills | Hard skills |
Анализ | Коммуникация, умение слушать, критическое мышление, системное мышление | Интервьюирование, анализ бизнес‑процессов |
Проектирование | Внимание к деталям, аналитическое мышление | User Stories, Use Cases, BPMN, UML, проектирование архитектуры, моделирование данных (ER‑диаграммы), проектирование интеграций и API |
Дизайн | Коммуникация, умение объяснять простым языком | Основы UI/UX, умение прототипировать |
Разработка | Работа в команде, гибкость, многозадачность | Понимание Agile/Scrum/Kanban, декомпозиция задач, оценка трудозатрат |
Тестирование | Внимательность, критическое мышление | Тестирование API, валидация требований |
Внедрение | Навыки презентации, коммуникация, обучаемость | Подготовка инструкций, обучение пользователей |
Поддержка и развитие | Аналитическое мышление, работа с обратной связью | SQL, анализ логов и обращений пользователей |
Как видите, функционал у СА очень широкий. Но это и плюс: опытный аналитик может вырасти в архитектора, владельца продукта, руководителя проекта или даже вернуться в разработку, но уже с полным пониманием того, «зачем» это делать.
6. Итоги
Если вы, прочитав всё это, не испугались, а, наоборот, загорелись, у меня для вас два универсальных совета.
Совет № 1. Определитесь с направлением.
Еще раз перечитайте первую часть статьи. Точно ли вам нужен системный анализ, а не работа с данными или чисто с бизнес‑процессами? Ответ на этот вопрос сэкономит вам годы жизни.
Совет № 2. Начните учиться, но с умом.
Здесь есть два пути, и какой выбрать — решать вам:
Путь «слабое звено». Проанализируйте список навыков выше и честно скажите себе, чего вы НЕ знаете совсем. И начните учить это. Это самый прагматичный подход, который быстро закроет ваши пробелы.
Путь «интереса». Начните с того, что вам кажется самым интересным. Нравится рисовать — освойте Figma и попробуйте нарисовать прототип мобильного приложения. Нравится копаться в логике — напишите несколько пользовательских историй для своего любимого сервиса. Это сохранит мотивацию.
Надеюсь, мой опыт и эта дорожная карта будут вам полезны. Системный анализ в ИТ — живая и интересная профессия, в которой есть место и общению, и техническому творчеству, и постоянному развитию. Если остались вопросы — задавайте в комментариях, буду рада обсудить.
Спасибо за внимание!