Мой краткий чек-лист по скилам аналитика

Привет! Меня зовут Валид Панин, хочу поделиться кратким чек-листом скилов аналитика. Расскажу какие харды и соф-скилы использую в своей работе с примерами, пояснениями и списком литературы и ресурсов, которые помогут подтянуть знания. Мне бы пригодился такой чек-лист как карта развития, если бы я сейчас начинал свой путь аналитиком.

4e20355808bdb7cf2bd046e9b43278f4.png

Об авторе:

e05bd11729fecc7601553328d203ea7b.pngВалид Панин

Главный системный аналитик в Альфа-Банк

Чек-лист поделил на две части: харды и софт-скилы. В первой части поговорим про инструменты и чёткие знания, а во второй — про «неосязаемые», но без которых тоже будет трудновато.

Харды

Здесь я выделил знания 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. 

Уровни понимания:

  • Джун: знает в теории о разных видах архитектур, умеет их отличать.

  • Мидл: знает плюсы и минусы разных типов, понимает сложность реализации. 

  • Сеньор: задачи граничат с задачами системного архитектора.

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

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

0f6061823e0aa107f562df4d997ad82f.png

Как научиться? Для начала почитать обзорные статьи, например, про Многослойную архитектуру и другие виды, подробные разборы, например, Сервис-ориентированной архитектуры (SOA). 

Потом почитать книги — рекомендую «Паттерны разработки и рефакторинга» Крисса Ричардсона, и перейти к отдельным ресурсам, посвященным разным паттернам проектирования, вроде https://microservices.io/. Микросервисная архитектура — сейчас очень популярна, поэтому часто встречаются рабочие задачи на движение от монолита к микросервисам. 

Веб технологии: HTML, JS, CSS, AJAX

Аналитику нужно понимать как клиент отображает страницу/экран, что происходит под капотом на фронтенде и какую информацию клиент передает на сервер. Без этого никуда, потому что надо разбираться как будет работать система, которую нарисовал дизайнер, и перенести это вс1 в техническую документацию с описанием взаимодействия компонентов. Понимание как работает нужно всем, но особенно необходимо тем, кто будет работать с Front.

Например, я недавно участвовал в одном хакатоне и разрабатывал этот макет «аптечного приложения».

cadcfd7056bf57a60f82fb33224c0c41.png

Здесь есть «нюанс» — в приложении предусмотрена авторизация на стороннем сайте, на Госуслугах. Чтобы мне, как аналитику прописать ТЗ надо бы знать, как она работает.

Уровни понимания:

  • Для джунов и миддлов даже не знаю, что написать, простите)

  • Сеньор: понимает как должно быть выстроено взаимодействие с бэкендом, например, что добавится в кэш. По ТЗ может сразу нарисовать диаграмму взаимодействий элементов и протоколов. 

Как научиться: можно начать с основ 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. В нём можно текстом передать алгоритм, где вот такое описание…

ccf46e9d50f01e6626da50cc6bc912ec.png

…превращается в ровную схему.

0fbe40c09afaa3e320ef1946b2502bbb.png

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

b991c43895432ade9a52b3aeb1f2c8e4.png

Как научиться?  

  • Изучить туториал по UML: ER diagram, диаграммам последовательности,   используются для описания системной части. Потом — по BPMN: необходима для описания бизнес процессов (часто используются упрощенные варианты)

  • Из инструментов Draw.io, Visio, и PlantUML.

Софты

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

Желание упорядочить хаос

Я работаю в достаточно молодом проекте, поэтому у нас нет «легаси» в виде массива документации, в которой надо разбираться пару недель. Но нам активно накидывали задачи в почте, Jira, в Телеграмме, ещё в процессе появляются задачи «на потом», и идеи как можно лучше что-то реализовать.

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

1091896e9572e87bfc77b15fe1a1d339.png

Планирование

Это предыдущий пункт, но применительно к своей работе. Например, я всегда планирую работу на неделю и день. Мой список задач, вам может быть непонятно, я для себя писал:)

176f655ad3758893065507d42a4a6d4b.png

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

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

1af1bfe696322d2040412f1050624d78.png

Это одна из таких диаграмм. Мы потом с командой думали «над ними» как оптимизировать внутренние чек-листы, какие листы и гайды передать вендору, чтобы они сами разбирались., а какие нам.

Самостоятельность

Логично, что для таких «проектов» нужна какая-то проактивность, потому что обычно работа аналитика самостоятельная, одиночная. Хороший аналитик чётко должен понимать, как заниматься своими задачами, уметь самостоятельно следить за тем, что и когда должно быть выполнено.

Коммуникация

Без общения аналитику никуда. Иначе как собирать у бизнеса требования, или объяснять разработчикам суть задач? Аналитик должен уметь договариваться и отстаивать свою точку зрения.

Тяга организовывать людей

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

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

Подписывайтесь на Alfa Digital Jobs — там мы интересно и весело рассказываем про нашу работу, делимся новостями и полезными советами, иногда даже шутим. Проекты у нас тоже интересные, например, приложение или интернет-банк. Приходите к нам, сейчас есть несколько вакансий аналитиков, например, Системный аналитик и Ведущий системный аналитик.

Рекомендуем статьи:

© Habrahabr.ru