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

NOTES 07.06.22 07.06.22 294
Бесплатные курсына главную сниппетов

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

Харды

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

SQL

Язык запросов для управления, чтения и изменения данных в БД. 

Нужен как системному, так и бизнесовому аналитику. БД используются в любом проекте, и умение читать из неё информацию понадобится как и для анализа данных, так и для понимания как должна быть организована информация. А также для решения возникающих проблем и ошибок. 

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

Мы используем 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 != 1WHERE rownumber = 3)

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

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

Архитектура ПО

Существует несколько видов шаблонов архитектур. Аналитику любого уровня необходимо понимать, какие виды существуют, как они соотносятся между собой, знать о плюсах и минусах использования каждой. Например, чем отличается многослойная архитектура от многоуровневой, а когда вместо хайповой микросервисной подойдёт SOA. 

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

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

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

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

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

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

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

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

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

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

Как научиться: можно начать с основ HTML (здесь и здесь продвинутые курсы), CSS, продолжить JavaScript’ом. Ресурсы на английском, но есть аналоги на русском — «Начало работы с вебом» и один из лучших ресурсов по JavaScript.

Интеграции

Интеграции перекликаются с архитектурой, потому что все системные задачи так или иначе связаны с взаимодействием систем.

В этот блок входят как и информация об основных протоколах передачи данных (HTTP, FTP, SMTP, DBC), так и информация про архитектурные стили, связанные с системными интеграциями, о форматах обмена сообщений sync & async, а также про шины, очереди сообщений.

Протоколы: HTTP, FTP, SMTP, DBC.

Примечание. протокол передачи ≠ формат взаимодействия систем.

Список протоколов не полный, но достаточный для начала.

Формат взаимодействия систем.

Вариаций масса, но выделю два основных: REST и SOAP — не очень корректно сравнивать, про это уже написано десять раз. Основные отличия:

По скилам.

REST: необходимо понимание принципов архитектурного стиля, понимание работы основных методов ( 4 метода, покажу вам их на карте), структура и правила формирования JSON.

SOAP: XSD схема — правило составления XML файла, WSDL — схема описания веб сервиса, структура и правила формирования XML.

Как научиться: пара отличных статей про эти форматы взаимодействия.

Брокеры сообщений.

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

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

Как научиться? Начать с документации Mozilla для разработчиков, не считая ссылок на статьи.

Диаграммы и похожие инструменты

Диаграммы — важный инструмент аналитика. Необходима как для отображения бизнес процесса, так и для детальной информации о вызовах и работе сервиса/ системы. 

Обычно для диаграмм используют Draw.io и Visio, где можно руками двигать блоки и прочее, но я настоятельно рекомендую освоить PlantUML. В нём можно текстом передать алгоритм, где вот такое описание…

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

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

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

Софты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

на главную сниппетов
Курсы