Мифы и легенды системного анализа или чем занимается аналитик в банке

Привет! Меня зовут Настя, я аналитик мобильного приложения Альфа-Бизнес. Иногда меня спрашивают о том, чем я занимаюсь на работе. Друзья, родные и, как это ни странно, разработчики. Каждый раз я отвечают по-разному, пытаясь привести наиболее близкие собеседнику примеры.

«Системный аналитик переводит требования пользователей с человеческого языка на разработческий…» — звучит довольно понятно для человека, не связанного с ИТ. Но если ты непосредственно участвуешь в разработке, вряд ли такого определения будет достаточно. Ради небольшого эксперимента я задала своей команде вопрос: «Чем занимается системный аналитик?». Читаем под катом, что из этого получилось.

Для меня системный аналитик — это человек, который может дать ответ на любой вопрос: от «Как должна работать фича», до «Почему Земля круглая» (с) тестировщик


Насчёт Земли, может, и перебор, но в остальном довольно точно. Где хранить данные, как их передавать, как работает фича, почему фича не работает… Каждый раз, когда в бэклоге продукта обнаруживается что-то непонятное, следует фраза «нужна аналитика».

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

Уверенное использование систем логирования может сократить чтиво с 30-страничного ТЗ до нескольких запросов. Главное — знать, что искать. В логах содержится информация о вызываемых методах, входных и выходных параметрах, причинах ошибок. Если сервис композитный — о пошаговом выполнении операции. Аналитику нужно разбираться в структуре логов и уметь их фильтровать: логируется обычно огромный объем данных.

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

Если появляется задача, которую никто не решал, в ход идут внешние источники. Окей, Гугл, космологические модели Вселенной? Тут хороши любые средства: статьи, форумы, обучающие курсы, документация на сторонние системы. Иногда на помощь приходят индусы с ютуба, но это крайний случай. Кстати, уметь искать надо на двух языках, ну или сразу на индусском английском.

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

Аналитик как навигатор, прокладывает путь до цели, огибая препятствия, и постоянно ищет более короткие пути (с) фронтенд-разработчик

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

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

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

Ну не знаю, ты для меня просто тестировщик. Ну, или смесь продакта с тестировщиком, как-то так (с) бэкенд-разработчик

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

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

Собирает информацию о продуктах, проектах и системах банка, занимается ее актуализацией и распространением, находится на острие информационного ножа (с) скрам-мастер

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

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

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

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

Насколько карта универсальна, мне судить сложно. Поэтому жду комментариев от разработчиков и аналитиков из других организаций :)