Чем занимается системный аналитик: объясняем профессию человеческим языком

Чем занимается системный аналитик: объясняем профессию человеческим языком

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

Но почти сразу появляются вопросы:

• Какие заказы разрешено отменять?
• Что делать, если заказ уже передали курьеру?
• Нужно ли автоматически возвращать деньги?
• За какое время должен произойти возврат?
• Что увидит покупатель, если отменить заказ уже нельзя?
• Как склад узнает, что товар больше не нужно собирать?
• Что произойдёт, если один из сервисов временно недоступен?

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

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

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

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

Если говорить совсем просто, он находится между двумя сторонами:

• бизнесом, который понимает, что хочет получить;
• разработчиками, которым нужно знать, как именно это должно работать.

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

Системный аналитик:

1. Выясняет настоящую потребность.
2. Изучает существующую систему.
3. Находит ограничения и противоречия.
4. Продумывает логику будущего решения.
5. Описывает изменения для разработчиков и тестировщиков.
6. Помогает команде разобраться с вопросами во время реализации.

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

Простой пример работы системного аналитика

Допустим, владелец продукта приходит с задачей:

Нужно разрешить пользователям отменять заказы в мобильном приложении.

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

Шаг 1. Понять бизнес-правила

Аналитик задаёт вопросы:

• На каких этапах можно отменить заказ?
• Может ли пользователь отменить только часть заказа?
• Что делать с применённым промокодом?
• Возвращается ли стоимость доставки?
• Нужна ли причина отмены?
• Кто ещё может отменять заказ: оператор, администратор, сотрудник магазина?
• Нужно ли отправлять пользователю уведомление?

В результате может появиться правило:

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

Шаг 2. Посмотреть, какие системы участвуют в процессе

Один заказ может одновременно обрабатываться несколькими системами:

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

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

Шаг 3. Описать последовательность действий

Например:

1. Пользователь нажимает кнопку «Отменить заказ».
2. Приложение отправляет запрос в сервис заказов.
3. Сервис проверяет текущий статус.
4. Если отмена разрешена, заказ получает статус «Отменён».
5. Платёжной системе отправляется команда на возврат денег.
6. Склад получает информацию о прекращении сборки.
7. Пользователю отправляется уведомление.
8. В приложении отображается новый статус заказа.

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

Необходимо предусмотреть, что произойдёт, если:

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

Именно такие ситуации часто превращают «простую кнопку» в полноценную системную задачу.

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

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

Собирает и уточняет требования

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

Его задача — выяснить:

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

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

Изучает существующую систему

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

Аналитик может изучать:

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

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

Продумывает логику решения

Это одна из главных частей профессии.

Системный аналитик определяет:

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

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

Описывает данные

Аналитик определяет, какие данные нужны системе и в каком виде их передавать.

Например, запрос на отмену заказа может содержать:

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

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

Проектирует взаимодействие между системами

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

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

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

Готовит документацию для команды

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

Системный аналитик может подготовить:

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

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

Отвечает на вопросы во время разработки

Даже подробное описание не исключает новых вопросов.

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

Системный аналитик помогает:

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

Как выглядит задача до и после системного аналитика

Как проходит обычный рабочий день

У системного аналитика редко бывают два полностью одинаковых дня. Состав работы зависит от этапа проекта.

Пример рабочего дня может выглядеть так:

1. Короткая встреча с командой: разработчики, тестировщики и аналитики обсуждают текущие задачи и препятствия.
2. Разбор нового требования вместе с владельцем продукта.
3. Изучение документации и существующих API.
4. Подготовка схемы взаимодействия сервисов.
5. Обсуждение решения с разработчиком или архитектором.
6. Описание структуры запроса и ответа.
7. Ответы на вопросы тестировщика по задаче, которая уже находится в разработке.
8. Обновление требований после согласования изменений.

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

Системный аналитик сам придумывает техническое решение?

Частично.

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

Он может самостоятельно определить:

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

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

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

Чем системный аналитик отличается от бизнес-аналитика

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

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

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

Чем системный аналитик отличается от программиста

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

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

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

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

Какими инструментами пользуется системный аналитик

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

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

Аналитическое мышление

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

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

Умение задавать вопросы

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

Аналитик должен замечать пробелы:

• Что произойдёт, если данные не найдены?
• Кто имеет право выполнить действие?
• Можно ли повторить операцию?
• Как система должна вести себя при ошибке?

Техническая грамотность

Системному аналитику нужно понимать:

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

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

Умение объяснять

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

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

Внимание к деталям

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

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

Кому подойдёт эта профессия

Профессию стоит рассмотреть, если вам нравится:

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

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

Кому профессия может не подойти

Работа может оказаться некомфортной, если вы:

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

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

Что самое сложное в работе системного аналитика

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

Самое трудное — добиться однозначности там, где изначально её нет.

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

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

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

Как проверить, интересна ли вам эта работа

Попробуйте разобрать простую функцию любого знакомого приложения. Например, восстановление пароля.

Ответьте на вопросы:

1. Как система понимает, что пользователь существует?
2. Куда отправляется код подтверждения?
3. Сколько действует код?
4. Сколько раз можно ошибиться при вводе?
5. Можно ли запросить несколько кодов подряд?
6. Что произойдёт, если письмо не дошло?
7. Каким требованиям должен соответствовать новый пароль?
8. Нужно ли завершить активные сессии после смены пароля?
9. Что увидит пользователь при каждой возможной ошибке?

Затем попробуйте изобразить процесс в виде схемы.

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

Краткий вывод

Системный аналитик превращает общую идею в точное описание работы будущей или существующей системы.

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

Если сказать совсем коротко: системный аналитик делает так, чтобы бизнес, разработчики и сама система одинаково «понимали», что должно произойти.

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