Системный аналитик: чем занимается и как войти

Чем отличается от других аналитиков

Названия путают всех, поэтому по-простому:

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

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

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

Границы размыты, и в разных компаниях одну и ту же работу называют по-разному. Смотрите на обязанности в вакансии, а не на название.

Что делает на самом деле

Выясняет, что нужно. Заказчик говорит «нужен отчёт». Аналитик выясняет: кому, зачем, какие данные, как часто, что делать при отсутствии данных, кто имеет право смотреть. Половина работы — задавать вопросы, о которых заказчик не подумал.

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

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

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

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

Что нужно знать на входе

Как описывать требования. Пользовательские истории, сценарии использования, критерии приёмки. Главный навык.

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

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

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

Форматы обмена данными. Уметь прочитать описание интерфейса и понять структуру.

Кому подходит

Тем, кто умеет слушать и переспрашивать. Кто способен превратить «сделайте нам удобно» в двадцать конкретных пунктов.

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

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

Как войти

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

С нуля. Дольше, но реально. Порядок: методики описания требований → схемы → техническая база → запросы к базам.

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

Как собрать портфолио

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

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

Ещё лучше — поучаствовать в чужом проекте: помочь описать требования тем, кто делает что-то своё. Там будут настоящие противоречия и настоящие изменения требований на полпути, а это именно то, что отличает практику от упражнения.