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

Привет, Хабр! Меня зовут Любовь Кулева, я руководитель отдела разработки и методологии Учебного центра IBS. Каждый год в нашем центре сотни сотрудников проходят сертификацию навыков. Собрав статистику по итогам 2023 года, мы выяснили, что сертификацию успешно сдает лишь каждый третий системный аналитик. Да-да, вы не ослышались: это значит, что две трети специалистов в первый раз заваливают экзамен. Очевидно, что многие просто не замечают пробелов в собственных знаниях или не знают, какие именно компетенции следует подтянуть в первую очередь. Эта статья — дорожная карта для любого системного аналитика, желающего расти в профессии.

Must-have навыки для системного аналитика

Пункты 1–3 — это база, которая должна быть у всех системных аналитиков, включая Junior-специалистов.

1. Методы работы с требованиями и навыки документирования

Начнем с фундаментальных знаний. Любой системный аналитик — не только в ИТ-индустрии, но и в любой другой сфере — должен уметь собирать и выявлять требования, приводить их к единому виду, декомпозировать и классифицировать данные, детализировать требования, определять критерии качества, приоритизировать задачи и документировать все пожелания заказчика так, чтобы команда смогла их правильно понять и воплотить в жизнь. Собственно, именно в этом и заключается работа системного аналитика: обработать набор входных данных, провести глубокий анализ и «перевести» требования с языка бизнеса на язык исполнителей, в частности разработчиков. Когда продукта еще нет и в помине, системный аналитик должен детально представить, как этот продукт будет работать.

Здесь можно вспомнить американского консультанта по менеджменту Уильяма Деминга, который утверждал, что каждый специалист должен обладать системой глубинных знаний, понимать общую теорию систем и теорию вариабельности.

Эта база и хорошо развитое системное мышление должны быть у всех, кто хочет развиваться в профессии.

2. Моделирование и проектирование процессов и систем

Еще один блок базовых знаний для аналитика любого уровня касается методов и инструментов моделирования требований.

Что нужно знать всем:

• основы анализа и моделирования процессов и систем;

• иерархию моделей, методы выявления, анализа и документирования состояния системы As Is и To Be;

• моделирование процессов с помощью блок-схем;

• описание процессов и системы в нотации UML: диаграммы состояний, последовательностей, классов, активностей и вариантов использования;

• особенности реализации web-, desktop- и мобильных приложений, кроссплатформенной разработки.

Что хорошо бы знать:

• моделирование бизнес-процессов в нотации BPMN (Business Process Model and Notation);

• расширенные знания нотации BPMN и UML;

• другие нотации, стандарты и фреймворки: IDEF0, IDEF3, EPC, DMN, VAD, SIPOC, BABOK и т. п.;

• применение диаграмм компонентов (component) и развертывания (deployment).

3. Работа с базами данных

К этому блоку знаний относятся:

• основные типы баз данных — реляционные, объектно-реляционные, нереляционные, колоночные, текстовые, а также популярные системы управления базами данных (СУБД) для каждого типа;

• структурированные, неструктурированные и слабоструктурированные данные;

• языки запросов — SQL;

• теория проектирования реляционных баз данных;

• правила проектирования нереляционных баз данных;

• для уровня Senior и выше — объектно-реляционное отображение (Object-Relational Mapping, ORM);

• подходы к миграции данных — «извлечение, преобразование, загрузка» (Extract, Transform, Load, ETL);

• витрины данных, OLAP-системы, проектирование хранилищ данных, витрин данных и отчетных форм.

В первую очередь любой системный аналитик должен уметь писать простые SQL-запросы, чтобы понимать, какие таблицы используются и какие данные в них хранятся. Почему это важно? Входная документация зачастую бывает не совсем актуальной, а нам нужно понимать, как система работает в данный момент. Этот навык может понадобиться не на каждом проекте, но иметь его в своем арсенале нужно всем. Правда, в зависимости от используемой системы, аналитики могут использовать и другие инструменты для понимания актуального состояния системы, среди них логирование, API или специализированные аналитические системы.

На начальном уровне достаточно освоить реляционные базы данных, на уровне мидл — знать разновидности NoSQL, а сеньоры уже должны не просто понимать, чем отличаются разные виды баз данных и как именно в них обрабатываются и хранятся структуры данных, но и уметь выбирать подход и проектировать сложные решения.

Теперь переходим к более продвинутым компетенциям.

4. Архитектура

Что нужно знать:

• основные виды архитектур и их особенности: локальная, монолитная, клиент/сервер/база данных, сервис-ориентированная и микросервисная архитектура;

• архитектурные шаблоны: клиент-серверный, многоуровневый, шаблон посредника, шаблон Model–View–Controller;

• паттерны «хореография» и «оркестрация»;

• теорему CAP, она же теорема Брюера;

• для уровня Senior и выше — событийно-ориентированную (event-driven) архитектуру, включая event sourcing и Command Query Responsibility Segregation (CQRS);

• модель Component-Connector-Container и подход С4 Саймона Брауна;

• базовые фреймворки для описания архитектуры ПО: 4+1 и, опционально, TOGAF;

• основы построения корпоративной архитектуры в Archimate.

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

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

5. Интеграции

В этот блок знаний входят:

• виды интеграций информационных систем: API, шина данных — ESB/MOM/MQ, общая база данных, файловый обмен;

• pull- и push-модели;

• веб-сервисы и вебхуки;

• синхронные и асинхронные взаимодействия;

• протоколы и интерфейсы интеграции систем: SOAP, JSON:API, GraphQL, gRPC, а также API нативных библиотек, которые часто используются при интеграции с программными библиотеками или сервисами, которые работают локально, а не через сеть;

• общее представление о форматах данных и способах их описания: JSON, YAML, WSDL, XML, XSD и прочие;

• основы синтаксиса JSON и XML;

• протокол HTTP;

• средства документирования и тестирования API: Postman, Swagger, SoapUI, cURL, а также популярные облачные платформы для управления API, таких как Apigee;

• принципы REST-архитектуры и REST API;

• диаграммы потоков данных (Data Flow Diagram, DFD), которые могут быть дополнены диаграммами последовательности (Sequence Diagrams), для более детального представления потоков данных в синхронных и асинхронных взаимодействиях.

При проработке интеграции необходимо показать, как архитектурные компоненты взаимодействуют между собой, в том числе какие типы данных передаются и какие протоколы интеграции при этом используются. Вопросы интеграции также пора начинать изучать уже Junior-специалистам, накапливая практический опыт и навыки на Middle-уровне. А Senior-аналитики должны спокойно ориентироваться в теме и понимать, в каком случае какая интеграция нужна, а также учитывать при этом различные функциональные требования заказчика, которые могут оказывать существенное влияние на принимаемые решения.

6. Основы информационной безопасности

Сейчас уже достаточно очевидно, что базовые представления об информационной безопасности должны быть у каждого человека и уж тем более у всех, кто работает в ИТ-сфере. Даже Junior-аналитики обязаны иметь представление об основных схемах и протоколах аутентификации: базовой аутентификации, цифровом сертификате, аутентификации с помощью ключа, OpenID/OAuth, JSON Web Tokens и т. д. Если речь идет о джуне, который устраивается в компанию после университета с профильным образованием, скорее всего, он все это уже знает. Если же речь идет о человеке, залетевшем в ИТ из другой отрасли, то, возможно, ему придется отдельно изучить все эти вопросы. Главное, чтобы системный аналитик понимал азы: основные уязвимости и способы компрометации информации, способы аутентификации и авторизации.

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

7. Основы UX/UI

Дизайн — непрофильная область знаний для системного аналитика, однако базовые навыки в этой сфере не будут лишними для специалистов любого уровня. Джунам и мидлам начального уровня достаточно понимать, что для решения необходимо определить набор макетов, что он выстраивается в соответствии с клиентским путем (Customer Journey Map, CJM) и что в индустрии существуют общепринятые гайдлайны и правила построения интерфейсов. Умение читать клиентский путь помогает системным аналитикам лучше прописывать функциональные требования к системе и учитывать сценарии использования (use cases), определяя, как и на каком этапе пользователь взаимодействует с системой.

Часто требуются незначительные изменения в интерфейсах, и с этой задачей аналитик может справиться без UX/UI-специалиста, если освоит базовые инструменты и принципы.

8. Основы жизненного цикла разработки программного обеспечения

Чем «старше» специалист, тем больше его обязанностей можно отнести к менеджменту и контролю выполнения задач. Middle-аналитик должен понимать, в какой методологии — Waterfall, RUP, Scrum, Kanban, Lean, FDD, XP и. т. п. — работает его команда, и выстраивать коммуникацию, исходя из этого. Senior-специалист должен глубоко знать отраслевые стандарты в части жизненного цикла разработки программного обеспечения, видов проектной документации, особенностей применения различных методологий разработки и управления конфигурациями и изменениями (система контроля версий Git, конвейер CI/CD). А также понимать, какой подход будет наиболее эффективным для конкретного проекта, и участвовать в его выборе. Все это помогает наладить эффективную коммуникацию между разными членами ИТ-команды.

9. Основы тестирования программного обеспечения

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

Что важно знать:

• особенности тестирования на различных этапах жизненного цикла проекта;

• различные виды и инструменты тестирования;

• тестирование функциональных и нефункциональных требований;

• управление критериями качества программного обеспечения;

• управление дефектами и роль аналитика в этом процессе.

10. Объектно-ориентированный подход

К этому блоку знаний относятся:

• объектный подход — основные определения, объекты и их связи, классы, экземпляры, атрибуты, функции и события;

• принципы объектно-ориентированного программирования: абстрагирование, инкапсуляция, модульность, иерархичность, наследование и полиморфизм;

• объектно-ориентированный анализ и проектирование.

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

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

Карта компетенций эталонного системного аналитика

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

Вы можете скачать и сохранить для себя эту карту в ПДФ-формате по ссылке.

Как развиваться системному аналитику: сертификация и узкие места на Карте компетенций

Понимание того, какие компетенции проседают именно у вас, может дать сертификация. Это полезная штука: как я уже говорила, нередко специалисты сами не осознают, где «плавают». Сертификация — это эффективный инструмент для оценки и повышения профессиональных навыков. Она помогает адаптироваться к новым условиям и задачам, определяя необходимые для развития области экспертизы.

В 2023 году мы запустили отечественную сертификацию для системных аналитиков. Причин у старта программы было несколько. Во-первых, в Учебном центре IBS сформирована теоретическая база по повышению квалификации системных аналитиков и есть эксперты-практики, занимающиеся обучением специалистов. Во-вторых, мы долгое время проводили подготовку к сертификации у западных вендоров. И в-третьих, в течение последних двух лет из России ушло большинство иностранных компаний, и пройти независимую оценку компетенций стало сложно. Однако у работодателей и самих специалистов запрос на это сохранился.

В Центре сертификации IBS существует несколько уровней сертификации системных аналитиков: «Базовый», «Специалист» и «Профессионал» (в разработке). Перед тем как определиться с уровнем сертификации, можно пройти бесплатное тестирование и за 30 минут узнать, какой экзамен актуален на данный момент. Сертификация проходит каждые две недели в онлайн- и офлайн-формате. Результат сертификации становится известен сразу: специалисту выдается статистика по тому, насколько хорошо он знает темы, входящие в тест. У каждого уровня сертификации своя продолжительность теста, количество вопросов и проходной балл.

Я собрала статистику по сертификации сотрудников IBS на уровнях «Базовый» и «Специалист» за последний год и получила следующую картину.

Уровень «Базовый»

Ориентирован на начинающих специалистов. Проходной балл здесь — 70. При этом средний балл проходящих «Базовый» уровень — 68.5. Темы из Карты компетенций, по которым специалисты набирают меньше всего баллов: «Объектно-ориентированный подход» (средний балл — 57) и «Моделирование и проектирование процессов и систем» (средний балл — 62). Это может быть связано с тем, что системные аналитики часто фокусируются на анализе требований и связи между бизнес-процессами и ИТ-системами, а не на глубоком понимании технических деталей программирования или проектирования. В их образовании, возможно, был упор на другие аспекты информационных систем, и они не получили достаточно знаний по объектно-ориентированному подходу или моделированию. К тому же у начинающих специалистов может быть недостаточно практического опыта, который помог бы им лучше понять и применять эти концепции.

Уровень «Специалист»

Рассчитан на практикующих специалистов. Чтобы пройти сертификацию данного уровня, нужно набрать минимум 75 баллов, при этом средний балл проходящих — 72.92. По нашему опыту, специалистам сложнее сдавать сертификацию «Базового» уровня. Возможно, это связано с тем, что ее сдают начинающие специалисты, обладающие недостаточным уровнем насмотренности и практическим опытом работы.

Что касается слабых тем на уровне «Специалист», то это «Моделирование и проектирование процессов и систем» (средний балл — 64), «Основы UX/UI» (средний балл — 65) и «Основы информационной безопасности» (средний балл — 68).

Что делать после сертификации?

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

Какие граниты грызть, чтобы стать гуру системного анализа

Поделюсь списком ресурсов, который мы обычно выдаем нашим сотрудникам вместе с результатами сертификации:

• «Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0» под ред. А. А. Белайчука и В. Г. Елиферова;

• «BABOK. Руководство к своду знаний по бизнес-анализу»;

• Документация организации по разработке стандарта нотации BPMN от Object Management Group;

• Крэг Ларман «Применение UML 2.0 и шаблонов проектирования»;

• Джеймс Рамбо, М. Блаха «UML 2.0. Объектно-ориентированное моделирование и разработка»;

• Мартин Фаулер «Архитектура корпоративных программных приложений»;

• Бобби Вульф, Грегор Хоп «Шаблоны интеграции корпоративных приложений»;

• Сэм Канер, Джек Фолк, Енг Кек Нгуен «Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений»;

• Карл Вигерс «Разработка требований к программному обеспечению»;

• Алистер Коберн «Современные методы описания функциональных требований к системам»;

• Джефф Паттон «Пользовательские истории. Искусство гибкой разработки ПО»;

• Даниэль Розенберг «UX Magic»;

• Сергей Константинов «Проектирование API»;

• «OpenAPI 3.0. Спецификация»;

• Джим Р. Уилсон, Эрик Редмонд «Семь баз данных за семь недель»;

• Джим Арлоу, Айла Нейштадт «UML 2 и унифицированный процесс»;

• «ISO/IEC/IEEE 42010: Defining "architecture”»;

• Рон Паттон «Тестирование программного обеспечения»;

• https://www.istqb.org/

• Федеральный закон от 27 июля 2006 года No 149-ФЗ «Об информации, информационных технологиях и о защите информации»;

• «ISO/IEC IS 27001:2013 Information technology. Security techniques. Information security management systems. Requirements»;

• Илья Корнипаев «Требования для программного обеспечения: рекомендации по сбору и документированию»;

• Дин Лэффингуэлл, Дон Уидриг «Принципы работы с требованиями к программному обеспечению. Унифицированный подход»;

• Джон Яблонски «Законы UX-дизайна»;

• Брайан Кукси «Введение в API»;

• Лоре Арно «Проектирование веб-API»;

• Джим Калбаха «The Jobs To Be Done PlayBook»;

• Джошуа Понелат, Лукас Розенсток «Designing APIs with Swagger and OpenAPI»;

• Ильдар Хабибуллин «Самоучитель XML»;

• Валерий Бондарев «Введение в информационную безопасность

• автоматизированных систем»;

• Крис Ричардсон «Микросервисы. Паттерны разработки и рефакторинга»;

• Бэрон Шварц, Вадим Ткаченко, Петр Зайцев «MySQL по максимуму»;

• Томас Коннолли, Каролин Бегг «Базы данных».

Заключение

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

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