Решил и для себя структурировать необходимые знания и для читателей. Что же вообще необходимо знать системному аналитику в 2024. И кто это вообще такой?

Если коротко, то Системный аналитик разрабатывает требования к программному обеспечению. 

Этапы карьеры системного аналитика

1. Стажер аналитик

2. Младший системный аналитик (junior)

3. Системный аналитик (middle)

4. Старший системный аналитик (senior)

5. Ведущий системный аналитик (lead)

6. Руководитель отдела системного анализа

7. Выход из аналитики: системный архитектор, технический руководитель проектов, фриланс или создание своей команды разработки.

Для начала я решил посмотреть сколько вообще вакансий на площадках размещено. Для удобства опишу, что я увидел по hh.ru. Вакансий системного аналитика немного более 5.000. Где-то пишут о гибриде системного и бизнес-аналитик, где-то данных или любой схожий франкенштейн из задач ПМ и СА/БА, но описание +- схожее. Если разделять эти 5к по годам опыта работы, то выглядит это следующим образом:

• От 3 до 6 лет 2 507

• От 1 года до 3 лет 2 162

• Нет опыта 235

• Более 6 лет 188

Посмотрели, подумали, давайте пойдем дальше, что предлагают аналитики в своих ключевых умениях. Гистограмма ключевых навыков по резюме системных аналитиков на hh.ru выглядит следующим образом. Т.е. видим что в основном из самых популярных hard skills это sql и powerpoint и большинство уверены, что они хорошие управленцы) Но составлять для себя какой-то план обучения или бежать тыкать менее популярные умения в свое резюме, чтоб вас заметили, нет смысла.

Поэтому, посмотрим все же на карту навыков:

Итак, мы с вами видим, что есть основные ветви которые желательно (иногда обязательно) знать аналитику, хотя бы в общих чертах, это:

• архитектуры ПО;

• программное обеспечение;

• инструменты;

• методологии ведения разработки и работы команды;

• работа веб-приложений и их интерфейсы;

• стандарты ведения документации;

• протоколы;

• языки моделирования и проектирования.

  Некоторые пункты я решил расписать поподробнее, это такие как: Архитектура ПО и её виды, виды интеграции, методологии управления проектами, а так же языки моделирования/проектирования. Если надо будет описать остальные, допишем!)

  1. Архитектура программного обеспечения (ПО) - это структура и организация системы, которая определяет ее компоненты, взаимодействия между ними и их отношения с внешней средой. Также можно сказать, что Архитектура представляет собой основу для дальнейшей разработки ПО, определяет его функциональность, надежность, масштабируемость, производительность и возможности расширения.

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

     _{? Разработка архитектуры для чайников. Часть 1 (https://habr.com/ru/post/658145/) / Часть 2 (https://habr.com/ru/post/658151/)}

     _{Архитектура ПО: разница между архитектурой и проктированием (https://medium.com/nuances-of-programming/архитектура-по-разница-между-архитектурой-и-проктированием-204f2e7aeff)}

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

     Монолитная архитектура – это крупнопланировочная структура с единым кодом, который включает в себя все компоненты приложения. Она обеспечивает простоту в разработке и тестировании, но часто имеет проблемы масштабирования и зависимости между компонентами.

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

     Клиент-серверная и микросервисная архитектуры часто являются лучшим выбором для крупных проектов, которые требуют масштабируемости и гибкости. Монолитная архитектура хорошо подходит для небольших проектов или простых систем.

     _{?Сравнение микросервисной и монолитной архитектур (https://www.atlassian.com/ru/microservices/microservices-architecture/microservices-vs-monolith)}

     _{Микросервисы или монолит. Какую архитектуру выбрать при разработке сложного приложения для крупного бизнеса (https://www.itweek.ru/management/article/detail.php?ID=223826)}

     _{Клиент-серверная архитектура в картинках (https://habr.com/ru/post/495698/)}

     
     Так же существует несколько видов интеграций систем, в том числе:

     1. Интеграция API (Application Programming Interface) – это способ связывания различных программных приложений через их программные интерфейсы.

     2. Интеграция через файловые форматы – это способ интеграции, основанный на конвертировании файлов в разные форматы для обмена информацией между ПО.

     3. Интеграция баз данных – это способ обмена информацией между различными базами данных на основе протоколов обмена.

     4. Интеграция с помощью платформы – это способ связывания различных приложений через одну платформу.

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

     _{?Видео - Способы интеграции систем (https://www.youtube.com/watch?v=Bw8f1Dd6Wr4&ab_channel=okiseleva)}

     2. Методология управления проектами – это стандарт ведения проектов от старта до завершения, который включает в себя принципы работы (способы оценки сроков, постановки задач и передача их между сотрудниками, сбор требований, способы согласований и тд)

     Наиболее распространенные методологии управления проектами:

     • Waterfall (Водопадная модель)

     • Agile (Гибкая модель)

       • SCRUM

       • Kanban

       • Lean и тд.

     • Гибридна модель (Waterfall+Agile)

     • PRiSM

     • PRINCE2

     Методы управления проектами:

     • Critical part method / Метод критического пути

     • Critical chain project management / Метод критической цепи

     • и др.

     Этапы управления проектом:

     • Инициация

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

     • Выполнение/Разработка

     • Мониторинг/Тестирование

     • Завершение

     _{?Методологии управления проектами: водопад, эджайл (https://vc.ru/flood/39800-metodologii-upravleniya-proektami-vodopad-edzhayl#:~:text=Методология,к завершению и готовому продукту.)}

     _{Методологии управления проектами: 12 популярных подходов (https://asana.com/ru/resources/project-management-methodologies)}

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

     _{?Как устроена каскадная модель управления проектами (https://kachestvo.pro/kachestvo-upravleniya/proektnoe-upravlenie/kak-ustroena-kaskadnaya-model-upravleniya-proektami/)}

     _{WATERFALL МЕТОДОЛОГИЯ РАЗРАБОТКИ (https://qaevolution.ru/metodologiya-menedzhment/waterfall/)}

     Методология Agile – это гибкий подход к разработке программного обеспечения, который помогает командам быстрее и с меньшими проблемами поставлять ценность клиентам. Вместо того чтобы выпускать весь продукт целиком, команда, следующая принципам Agile, выполняет работу в рамках небольших, но удобных инкрементов. Требования, планы и результаты оцениваются непрерывно, благодаря чему команды могут быстро реагировать на изменения.
     Процесс работы по Agile делится на итерации – короткие циклы по две-три недели. Каждый цикл решает серию задач.

     _{?Методология управления проектами - Agile (https://blog.skillfactory.ru/glossary/agile/)}

     _{Agile от А до Я (https://www.bigdataschool.ru/wiki/agile)}

     _{Понять в чем разница между Agile и Waterfall поможет статья - Agile vs. Waterfall: суть и отличия методологий разработки (https://web-academy.ua/blog/upravlenie/agile-vs-waterfall)}

     3. Языки моделирования и проектирования:

     UML (Unified Modeling Language – унифицированный язык моделирования). Это графический язык, который с помощью диаграмм и схем описывает разнообразные процессы и структуры. Данный язык в основном используется для разработки программного обеспечения. Однако он также используется для описания рабочих ролей, организационных функций и бизнес-процессов.

     Типы UML-диаграмм:

     Структурные диаграммы:

     • Диаграмма развертывания

     • Диаграмма пакетов

     • Диаграмма профилей

     • Диаграмма классов

     • Диаграмма объектов

     • Диаграмма компонентов

     • Диаграмма композитивной структуры

     Диаграммы поведения:

     • Диаграмма деятельности

     • Диаграмма вариантов использования

     • Диаграмма состояний

     • Диаграмма взаимодействий

     • Диаграмма последовательности

     • Диаграмма коммуникации

     • Диаграмма обзора взаимодействия

     • Диаграмма синхронизации

     _{?UML (https://blog.skillfactory.ru/glossary/uml/)}

     _{UML для бизнес-моделирования: зачем нужны диаграммы процессов (https://evergreens.com.ua/ru/articles/uml-diagrams.html)}

     BPMN (Business Process Modeling Notation - Нотация моделирования бизнес-процессов) – это метод, используемый для иллюстрации/описания бизнес-процессов, другими словами BPMN – это графическое представление бизнес-процессов. Данный метод наглядно отображает подробную последовательность бизнес-операций и информационных потоков, необходимых для завершения процесса.

     Можно сказать, что BPMN является частью двух важнейших составляющих:

     • Business Process Management (BPM) – управление бизнес-процессами, или процессное управление. Иными словами, BPM - это концепция управления организацией, представляющая деятельность предприятия как совокупность процессов.

     • Business Process Modeling System (BPMS) – это инструменты для исполнения созданных вами моделей. Это может быть Bizagi, Camunda, ELMA и пр.

     В нотации BPMN выделяют пять основных категорий элементов:

     • элементы потока (события, процессы и шлюзы);

     • данные/date (объекты данных и базы данных);

     • соединяющие элементы (потоки управления, потоки сообщений и ассоциации);

     • зоны ответственности (пулы и дорожки);

     • Artefact (артефакты/сноски).

     _{?Нотация BPMN (https://www.businessstudio.ru/wiki/docs/current/doku.php/ru/csdesign/bpmodeling/bpmn_notation)}

     _{Краткое описание BPMN с примером (https://trinion.org/blog/kratkoe-opisanie-bpmn-s-primerom)}

     В заключении, хочу сказать, у аналитиков странные задача, нестабильная нагрузка, рутинные будни и куча нужных навыков, но благодаря roadmap можно хотя бы понять что в работе может понадобится!)