Мой краткий чек-лист по скилам аналитика
Привет! Меня зовут Валид Панин, хочу поделиться кратким чек-листом скилов аналитика. Расскажу какие харды и соф-скилы использую в своей работе с примерами, пояснениями и списком литературы и ресурсов, которые помогут подтянуть знания. Мне бы пригодился такой чек-лист как карта развития, если бы я сейчас начинал свой путь аналитиком.
Об авторе:
Валид ПанинГлавный системный аналитик в Альфа-Банк
Чек-лист поделил на две части: харды и софт-скилы. В первой части поговорим про инструменты и чёткие знания, а во второй — про «неосязаемые», но без которых тоже будет трудновато.
Харды
Здесь я выделил знания SQL-запросов, архитектуры, интеграций и диаграмм и схем. Всё, что напишу дальше, я сам использую, например, чтобы писать ТЗ, документацию на API или в гайдах для пользователей.
SQL
Язык запросов для управления, чтения и изменения данных в БД.
Нужен как системному, так и бизнесовому аналитику. БД используются в любом проекте, и умение читать из неё информацию понадобится как и для анализа данных, так и для понимания как должна быть организована информация. А также для решения возникающих проблем и ошибок.
Уровни понимания:
Джун: простые SELECTы, джоины, агрегирующие функции, изменение данных.
Мидл: временные таблицы, процедуры, вьюхи, индексирование.
Сеньор: нормализация данных, ERD.
Мы используем SQL во всех проектах и он нужен аналитику любого уровня. Например, для джуна достаточно уметь работать с такими запросами.
SELECT to_char(dt, 'YYYY-MM-DD')
FROM
(SELECT
ROW_NUMBER() OVER (ORDER BY DT ASC) as rownumber,
dt
FROM CALENDAR
WHERE dt > sysdate and holiday != 1)
WHERE rownumber = 3)Это простой запрос с одного нашего проекта, но интересен тем, что в нём есть подзапрос. Для одной из задач было необходимо, чтобы запрос выбирал дату третьего рабочего дня, потому что многие банковские операции зависят от рабочих дней и выходных. Как раз здесь подзапрос выбирает третий по счету день из будних дней в таблице.
Как научиться?
Изучить Database and SQL Roadmap. Это один изу лучших ресурсов, по SQL с подробным и понятным объяснением.
Архитектура ПО
Существует несколько видов шаблонов архитектур. Аналитику любого уровня необходимо понимать, какие виды существуют, как они соотносятся между собой, знать о плюсах и минусах использования каждой. Например, чем отличается многослойная архитектура от многоуровневой, а когда вместо хайповой микро сервисной архитектуры подойдёт SOA.
Уровни понимания:
Джун: знает в теории о разных видах архитектур, умеет их отличать.
Мидл: знает плюсы и минусы разных типов, понимает сложность реализации.
Сеньор: задачи граничат с задачами системного архитектора.
Навык необходим в разной степени каждому системному аналитику. В работе часто придётся встречаться со схемами архитектуры, разбираться с интеграциями, что с чем взаимодействует, где «ручки-ножки» торчат. Разбираться нужно не только, чтобы думать как разрабатывать новые сервисы, но и, например, чтобы просто обновить документацию. Как раз знание архитектуры ПО поможет быстрее погружаться в проект и при разработки новых задач позволит избежать ошибок в технической реализации.
Например, мне приходится часто встречаться с таким схемами как на скрине, где показана часть нашей архитектуры. Опытный аналитик, наверное, сразу догадался, что у нас распределенный монолит (сильно не ругайте:)).
Как научиться? Для начала почитать обзорные статьи, например, про Многослойную архитектуру и другие виды, подробные разборы, например, Сервис-ориентированной архитектуры (SOA).
Потом почитать книги — рекомендую «Паттерны разработки и рефакторинга» Крисса Ричардсона, и перейти к отдельным ресурсам, посвященным разным паттернам проектирования, вроде https://microservices.io/. Микросервисная архитектура — сейчас очень популярна, поэтому часто встречаются рабочие задачи на движение от монолита к микросервисам.
Веб технологии: HTML, JS, CSS, AJAX
Аналитику нужно понимать как клиент отображает страницу/экран, что происходит под капотом на фронтенде и какую информацию клиент передает на сервер. Без этого никуда, потому что надо разбираться как будет работать система, которую нарисовал дизайнер, и перенести это вс1 в техническую документацию с описанием взаимодействия компонентов. Понимание как работает нужно всем, но особенно необходимо тем, кто будет работать с Front.
Например, я недавно участвовал в одном хакатоне и разрабатывал этот макет «аптечного приложения».
Здесь есть «нюанс» — в приложении предусмотрена авторизация на стороннем сайте, на Госуслугах. Чтобы мне, как аналитику прописать ТЗ надо бы знать, как она работает.
Уровни понимания:
Для джунов и миддлов даже не знаю, что написать, простите)
Сеньор: понимает как должно быть выстроено взаимодействие с бэкендом, например, что добавится в кэш. По ТЗ может сразу нарисовать диаграмму взаимодействий элементов и протоколов.
Как научиться: можно начать с основ HTML (здесь и здесь продвинутые курсы), CSS, продолжить JavaScript«ом. Ресуры на английском, но есть аналоги на русском — «Начало работы с вебом» и один из лучших ресурсов по JavaScript.
Интеграции
Интеграции перекликаются с архитектурой, потому что все системные задачи так или иначе связаны с взаимодействием систем.
В этот блок входят как и информация об основных протоколах передачи данных (HTTP, FTP, SMTP, DBC), так и информация про архитектурные стили связанные с системными интеграциями, о форматах обмена сообщений sync & async, а также про шины, очереди сообщений.
Протоколы: HTTP, FTP, SMTP, DBC.
HTTP (HTTPS) — HyperText Transport Protocol, знакомый протокол для передачи информации по интернету. Основа взаимодействия клиент — серверное взаимодействие: клиент посылает запрос — сервер отвечает. Самый часто встречаемый протокол на данный момент.
FTP — File Transfer Protocol, используется для передачи файлов, в отличие от HTTP. Также использует клиент — серверное взаимодействие, однако есть несколько ключевых отличий от HTTP.
SMTP & POP3 — протоколы используемые для взаимодействия с почтовыми серверами и почтовыми клиентами.
ODBC & JDBC — Стандарты взаимодействия с базами данных.
Примечание. протокол передачи ≠ формат взаимодействия систем.
Список протоколов не полный, но достаточный для начала.
Формат взаимодействия систем.
Выделю два основных, вариаций масса: REST и SOAP — не очень корректно сравнивать, про это уже написано десять раз. Основные отличия:
В интеграции «по REST»: JSON over HTTP.
В SOAP интеграции XML over HTTP.
REST сервисы проще в разработке, проще во взаимодействии.
SOAP сервисы как минимум из-за специфики сообщений считаются безопаснее, более стандартизированными, меньше подверженными ошибкам.
По скилам.
REST: необходимо понимание принципов архитектурного стиля, понимание работы основных методов (4 метода, покажу вам их на карте), структура и правила формирования JSON.
SOAP: XSD схема — правило составления XML файла, WSDL — схема описания веб сервиса, структура и правила формирования XML.
Как научиться: пара отличных статей про эти форматы взаимодействия.
Брокеры сообщений.
Не совсем корректно помещать в блок про протоколы, но подходит под форматы взаимодействий. Из названия можно догадаться, что брокеры сообщений — это такие компоненты системы, которые хранят в себе разные сообщения и распределяют их между получателями. Важно понимать, как это работает и зачем используется (в распределенных системах с асинхронным взаимодействием). Наиболее популярные (те с которыми я поработал): Kafka и RabbitMQ.
Уровни понимания:
Джун: понимает, какие интеграции существуют, через что реализованы, и что необходимо для корректной реализации.
Мидл: понимает разницу и ограничения каждого из типа интеграции.
Сеньор: может самостоятельно определять какой тип интеграции будет актуальнее в отдельных случаях.
Как научиться? Начать с документации Mozilla для разработчиков, не считая ссылок на статьи.
Диаграммы и похожие инструменты
Диаграммы — важный инструмент аналитика. Необходима как для отображения бизнес процесса, так и для детальной информации о вызовах и работе сервиса/ системы.
Обычно для диаграмм используют Draw.io и Visio, где можно руками двигать блоки и прочее, но я настоятельно рекомендую освоить PlantUML. В нём можно текстом передать алгоритм, где вот такое описание…
…превращается в ровную схему.
В PluntUML можно рисовать не только простые схемы бизнес-процессов, но и более детальные описания последовательности взаимодействия систем, что тоже нужно аналитику. Например, такие.
Как научиться?
Изучить туториал по UML: ER diagram, диаграммам последовательности, используются для описания системной части. Потом — по BPMN: необходима для описания бизнес процессов (часто используются упрощенные варианты)
Из инструментов Draw.io, Visio, и PlantUML.
Софты
Можно было бы написать здесь про «адаптивность, самостоятельность и стрессоустойчивость», но у меня немного другой список.
Желание упорядочить хаос
Я работаю в достаточно молодом проекте, поэтому у нас нет «легаси» в виде массива документации, в которой надо разбираться пару недель. Но нам активно накидывали задачи в почте, Jira, в Телеграмме, ещё в процессе появляются задачи «на потом», и идеи как можно лучше что-то реализовать.
Чтобы такие идеи не потерялись — решили командой организовать это в удобную таблицу в Конфлюенсе, которую я веду. Структурировали хаос, так сказать. Получилась таблица, где всё собрано в одном месте и достаточно удобно.
Планирование
Это предыдущий пункт, но применительно к своей работе. Например, я всегда планирую работу на неделю и день. Мой список задач, вам может быть непонятно, я для себя писал:)
Аналитическое мышление
Мы работаем с вендором, который нам отправляет техническую документацию, мы её ревьюим и фиксируем замечания. Однажды таких замечаний накопилось 400 штук. Сейчас мы меняем вендора и чтобы в будущем замечаний было меньше, мы решили замечания как-то проанализировать, обдумать. Собрал все от старого вендора, типизировал и построил разные графики и диаграммы.
Это одна из таких диаграмм. Мы потом с командой думали «над ними» как оптимизировать внутренние чек-листы, какие листы и гайды передать вендору, чтобы они сами разбирались., а какие нам.
Самостоятельность
Логично, что для таких «проектов» нужна какая-то проактивность, потому что обычно работа аналитика самостоятельная, одиночная. Хороший аналитик чётко должен понимать, как заниматься своими задачами, уметь самостоятельно следить за тем, что и когда должно быть выполнено.
Коммуникация
Без общения аналитику никуда. Иначе как собирать у бизнеса требования, или объяснять разработчикам суть задач? Аналитик должен уметь договариваться и отстаивать свою точку зрения.
Тяга организовывать людей
Спорный пункт, но аналитик это первый человек, к которому обратятся ребята из смежной (или собственной) команды, чтобы узнать о том, как что работает. Чтобы не потеряться самому и всегда знать куда отправить человека за ответами, на аналитика часто ложиться работа по организации информации о проекте.
На этом всё. Надеюсь, вам было интересно и полезно. Если у вас есть, что добавить — пишите комментарии, я обновлю статью и чек-лист дополню.
Подписывайтесь на Alfa Digital Jobs — там мы интересно и весело рассказываем про нашу работу, делимся новостями и полезными советами, иногда даже шутим. Проекты у нас тоже интересные, например, приложение или интернет-банк. Приходите к нам, сейчас есть несколько вакансий аналитиков, например, Системный аналитик и Ведущий системный аналитик.
Рекомендуем статьи:
