- PVSM.RU - https://www.pvsm.ru -
Привет! Меня зовут Валид Панин, хочу поделиться кратким чек-листом скилов аналитика. Расскажу какие харды и соф-скилы использую в своей работе с примерами, пояснениями и списком литературы и ресурсов, которые помогут подтянуть знания. Мне бы пригодился такой чек-лист как карта развития, если бы я сейчас начинал свой путь аналитиком.
Об авторе:
Главный системный аналитик в Альфа-Банк
Чек-лист поделил на две части: харды и софт-скилы. В первой части поговорим про инструменты и чёткие знания, а во второй — про «неосязаемые», но без которых тоже будет трудновато.
Здесь я выделил знания SQL-запросов, архитектуры, интеграций и диаграмм и схем. Всё, что напишу дальше, я сам использую, например, чтобы писать ТЗ, документацию на API или в гайдах для пользователей.
Язык запросов для управления, чтения и изменения данных в БД.
Нужен как системному, так и бизнесовому аналитику. БД используются в любом проекте, и умение читать из неё информацию понадобится как и для анализа данных, так и для понимания как должна быть организована информация. А также для решения возникающих проблем и ошибок.
Уровни понимания:
Джун: простые 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 [1]. Это один изу лучших ресурсов, по SQL с подробным и понятным объяснением.
Потренироваться на старом, но проверенном сайте SQL-ex [2].
Существует несколько видов шаблонов архитектур. Аналитику любого уровня необходимо понимать, какие виды существуют, как они соотносятся между собой, знать о плюсах и минусах использования каждой. Например, чем отличается многослойная архитектура от многоуровневой, а когда вместо хайповой микро сервисной архитектуры подойдёт SOA.
Уровни понимания:
Джун: знает в теории о разных видах архитектур, умеет их отличать.
Мидл: знает плюсы и минусы разных типов, понимает сложность реализации.
Сеньор: задачи граничат с задачами системного архитектора.
Навык необходим в разной степени каждому системному аналитику. В работе часто придётся встречаться со схемами архитектуры, разбираться с интеграциями, что с чем взаимодействует, где «ручки-ножки» торчат. Разбираться нужно не только, чтобы думать как разрабатывать новые сервисы, но и, например, чтобы просто обновить документацию. Как раз знание архитектуры ПО поможет быстрее погружаться в проект и при разработки новых задач позволит избежать ошибок в технической реализации.
Например, мне приходится часто встречаться с таким схемами как на скрине, где показана часть нашей архитектуры. Опытный аналитик, наверное, сразу догадался, что у нас распределенный монолит (сильно не ругайте:)).
Как научиться? Для начала почитать обзорные статьи, например, про Многослойную архитектуру [3] и другие виды, подробные разборы, например, Сервис-ориентированной архитектуры (SOA) [4].
Потом почитать книги — рекомендую «Паттерны разработки и рефакторинга» Крисса Ричардсона, и перейти к отдельным ресурсам, посвященным разным паттернам проектирования, вроде https://microservices.io/ [5]. Микросервисная архитектура — сейчас очень популярна, поэтому часто встречаются рабочие задачи на движение от монолита к микросервисам.
Аналитику нужно понимать как клиент отображает страницу/экран, что происходит под капотом на фронтенде и какую информацию клиент передает на сервер. Без этого никуда, потому что надо разбираться как будет работать система, которую нарисовал дизайнер, и перенести это вс1 в техническую документацию с описанием взаимодействия компонентов. Понимание как работает нужно всем, но особенно необходимо тем, кто будет работать с Front.
Например, я недавно участвовал в одном хакатоне и разрабатывал этот макет «аптечного приложения».
Здесь есть «нюанс» — в приложении предусмотрена авторизация на стороннем сайте, на Госуслугах. Чтобы мне, как аналитику прописать ТЗ надо бы знать, как она работает.
Уровни понимания:
Для джунов и миддлов даже не знаю, что написать, простите)
Сеньор: понимает как должно быть выстроено взаимодействие с бэкендом, например, что добавится в кэш. По ТЗ может сразу нарисовать диаграмму взаимодействий элементов и протоколов.
Как научиться: можно начать с основ HTML [6] (здесь [7] и здесь [8] продвинутые курсы), CSS [9], продолжить JavaScript’ом [10]. Ресуры на английском, но есть аналоги на русском — «Начало работы с вебом [11]» и один из лучших ресурсов по JavaScript [12].
Интеграции перекликаются с архитектурой, потому что все системные задачи так или иначе связаны с взаимодействием систем.
В этот блок входят как и информация об основных протоколах передачи данных (HTTP, FTP, SMTP, DBC), так и информация про архитектурные стили связанные с системными интеграциями, о форматах обмена сообщений sync & async, а также про шины, очереди сообщений.
HTTP (HTTPS) — HyperText Transport Protocol, знакомый протокол для передачи информации по интернету. Основа взаимодействия клиент — серверное взаимодействие: клиент посылает запрос — сервер отвечает. Самый часто встречаемый протокол на данный момент.
FTP — File Transfer Protocol, используется для передачи файлов, в отличие от HTTP. Также использует клиент — серверное взаимодействие, однако есть несколько ключевых отличий от HTTP [13].
SMTP & POP3 — протоколы используемые для взаимодействия с почтовыми серверами и почтовыми клиентами.
ODBC [14] & JDBC [15] - Стандарты взаимодействия с базами данных.
Примечание. протокол передачи ≠ формат взаимодействия систем.
Список протоколов не полный, но достаточный для начала.
Выделю два основных, вариаций масса: REST и SOAP — не очень корректно сравнивать, про это уже написано десять раз. Основные отличия:
В интеграции «по REST»: JSON over HTTP.
В SOAP интеграции XML over HTTP.
REST сервисы проще в разработке, проще во взаимодействии.
SOAP сервисы как минимум из-за специфики сообщений считаются безопаснее, более стандартизированными, меньше подверженными ошибкам.
REST: необходимо понимание принципов архитектурного стиля [16], понимание работы основных методов ( 4 метода, покажу вам их на карте), структура и правила [17] формирования JSON.
SOAP: XSD схема — правило составления [18] XML файла, WSDL — схема описания веб сервиса [19], структура и правила формирования XML.
Как научиться: пара отличных статей [20] про эти форматы взаимодействия.
Не совсем корректно помещать в блок про протоколы, но подходит под форматы взаимодействий. Из названия можно догадаться, что брокеры сообщений — это такие компоненты системы, которые хранят в себе разные сообщения и распределяют их между получателями. Важно понимать, как это работает [21] и зачем используется (в распределенных системах с асинхронным взаимодействием). Наиболее популярные ( те с которыми я поработал): Kafka [22] и RabbitMQ [23].
Уровни понимания:
Джун: понимает, какие интеграции существуют, через что реализованы, и что необходимо для корректной реализации.
Мидл: понимает разницу и ограничения каждого из типа интеграции.
Сеньор: может самостоятельно определять какой тип интеграции будет актуальнее в отдельных случаях.
Как научиться? Начать с документации [24] Mozilla для разработчиков, не считая ссылок на статьи.
Диаграммы — важный инструмент аналитика. Необходима как для отображения бизнес процесса, так и для детальной информации о вызовах и работе сервиса/ системы.
Обычно для диаграмм используют Draw.io [25] и Visio, где можно руками двигать блоки и прочее, но я настоятельно рекомендую освоить PlantUML. В нём можно текстом передать алгоритм, где вот такое описание…
…превращается в ровную схему.
В PluntUML можно рисовать не только простые схемы бизнес-процессов, но и более детальные описания последовательности взаимодействия систем, что тоже нужно аналитику. Например, такие.
Как научиться?
Изучить туториал по UML: ER diagram [26], диаграммам последовательности, используются для описания системной части. Потом — по BPMN [27]: необходима для описания бизнес процессов ( часто используются упрощенные варианты)
Из инструментов Draw.io [25], Visio, и PlantUML.
Можно было бы написать здесь про «адаптивность, самостоятельность и стрессоустойчивость», но у меня немного другой список.
Я работаю в достаточно молодом проекте, поэтому у нас нет «легаси» в виде массива документации, в которой надо разбираться пару недель. Но нам активно накидывали задачи в почте, Jira, в Телеграмме, ещё в процессе появляются задачи «на потом», и идеи как можно лучше что-то реализовать.
Чтобы такие идеи не потерялись — решили командой организовать это в удобную таблицу в Конфлюенсе, которую я веду. Структурировали хаос, так сказать. Получилась таблица, где всё собрано в одном месте и достаточно удобно.
Это предыдущий пункт, но применительно к своей работе. Например, я всегда планирую работу на неделю и день. Мой список задач, вам может быть непонятно, я для себя писал:)
Мы работаем с вендором, который нам отправляет техническую документацию, мы её ревьюим и фиксируем замечания. Однажды таких замечаний накопилось 400 штук. Сейчас мы меняем вендора и чтобы в будущем замечаний было меньше, мы решили замечания как-то проанализировать, обдумать. Собрал все от старого вендора, типизировал и построил разные графики и диаграммы.
Это одна из таких диаграмм. Мы потом с командой думали «над ними» как оптимизировать внутренние чек-листы, какие листы и гайды передать вендору, чтобы они сами разбирались. а какие нам.
Логично, что для таких «проектов» нужна какая-то проактивность, потому что обычно работа аналитика самостоятельная, одиночная. Хороший аналитик чётко должен понимать, как заниматься своими задачами, уметь самостоятельно следить за тем, что и когда должно быть выполнено.
Без общения аналитику никуда. Иначе как собирать у бизнеса требования, или объяснять разработчикам суть задач? Аналитик должен уметь договариваться и отстаивать свою точку зрения.
Спорный пункт, но аналитик это первый человек, к которому обратятся ребята из смежной (или собственной) команды, чтобы узнать о том, как что работает. Чтобы не потеряться самому и всегда знать куда отправить человека за ответами, на аналитика часто ложиться работа по организации информации о проекте.
На этом всё. Надеюсь, вам было интересно и полезно. Если у вас есть, что добавить — пишите комментарии, я обновлю статью и чек-лист дополню.
Подписывайтесь на Alfa Digital Jobs [28] — там мы интересно и весело рассказываем про нашу работу, делимся новостями и полезными советами, иногда даже шутим. Проекты у нас тоже интересные, например, приложение или интернет-банк. Приходите к нам, сейчас есть несколько вакансий аналитиков, например, Системный аналитик [29] и Ведущий системный аналитик [30].
Рекомендуем статьи:
Как мы участвовали в чемпионате по DS длиной 3,5 месяца [31]
Эволюция Server-Driven UI: динамические поля, хэндлеры и многошаг [32]
Webpack Module Federation: «официальное» решение в микрофронтендах [33]
Зачем в Альфа-Банке создали команды Growth Hacking, или «Кнопки мы и сами поменяем» [34]
Как изменилась работа UX/СХ-исследователей весной 2022 года: опрос Альфа-Банка [35]
Автор:
AlfaTeam
Источник [36]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/javascript/375867
Ссылки в тексте:
[1] Database and SQL Roadmap: https://www.databasestar.com/sql-roadmap/
[2] SQL-ex: https://www.sql-ex.ru/?Lang=0
[3] Многослойную архитектуру: https://medium.com/nuances-of-programming/4-%D1%82%D0%B8%D0%BF%D0%B0-%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D1%8B-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE-%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F-917133174724
[4] Сервис-ориентированной архитектуры (SOA): https://herbertograca.com/2017/11/09/service-oriented-architecture-soa/
[5] https://microservices.io/: https://microservices.io/
[6] HTML: https://htmldog.com/guides/html/
[7] здесь: https://htmldog.com/guides/html/intermediate/
[8] здесь: https://htmldog.com/guides/html/advanced/
[9] CSS: https://htmldog.com/guides/css/
[10] JavaScript’ом: https://htmldog.com/guides/javascript/
[11] Начало работы с вебом: https://developer.mozilla.org/ru/docs/Learn/Getting_started_with_the_web
[12] по JavaScript: https://learn.javascript.ru/
[13] несколько ключевых отличий от HTTP: https://ru.wikipedia.org/wiki/FTP
[14] ODBC: https://ru.wikipedia.org/wiki/ODBC
[15] JDBC: https://ru.wikipedia.org/wiki/Java_Database_Connectivity
[16] принципов архитектурного стиля: http://www.infoq.com/articles/rest-introduction
[17] структура и правила: https://www.w3schools.com/js/js_json_syntax.asp
[18] правило составления: https://habr.com/ru/post/90696/
[19] схема описания веб сервиса: https://ru.wikipedia.org/wiki/WSDL
[20] отличных статей: https://habr.com/ru/post/131343/
[21] как это работает: https://ru.wikipedia.org/wiki/%D0%91%D1%80%D0%BE%D0%BA%D0%B5%D1%80_%D1%81%D0%BE%D0%BE%D0%B1%D1%89%D0%B5%D0%BD%D0%B8%D0%B9
[22] Kafka: https://kafka.apache.org/documentation/
[23] RabbitMQ: https://www.rabbitmq.com/documentation.html
[24] документации: https://developer.mozilla.org/ru/docs/Web
[25] Draw.io: http://Draw.io
[26] UML: ER diagram: https://plantuml.com/ru/sequence-diagram
[27] BPMN: https://www.lucidchart.com/blog/diagrams-for-dummies-a-BPMN-tutorial
[28] на Alfa Digital Jobs: https://t.me/alfadigital_jobs
[29] Системный аналитик: https://digital.alfabank.ru/vacancies/analytic
[30] Ведущий системный аналитик: https://digital.alfabank.ru/vacancies/sys-anlyst
[31] Как мы участвовали в чемпионате по DS длиной 3,5 месяца: https://habr.com/ru/company/alfa/blog/669522/
[32] Эволюция Server-Driven UI: динамические поля, хэндлеры и многошаг: https://habr.com/ru/company/alfa/blog/668754/
[33] Webpack Module Federation: «официальное» решение в микрофронтендах: https://habr.com/ru/company/alfa/blog/668118/
[34] Зачем в Альфа-Банке создали команды Growth Hacking, или «Кнопки мы и сами поменяем»: https://habr.com/ru/company/alfa/blog/665594/
[35] Как изменилась работа UX/СХ-исследователей весной 2022 года: опрос Альфа-Банка: https://habr.com/ru/company/alfa/blog/660545/
[36] Источник: https://habr.com/ru/post/669842/?utm_source=habrahabr&utm_medium=rss&utm_campaign=669842
Нажмите здесь для печати.