Как стать автором
Обновить
92.32
SSP SOFT
🔹 Более 15 лет занимаемся заказной разработкой ПО

Это реально? Что должен уметь джуниор системный аналитик по профессиональному стандарту Минтруда России

Уровень сложностиПростой
Время на прочтение7 мин
Количество просмотров21K

Нам оставили немало комментариев к статьям по подготовке к собеседованию системного аналитика (СА) о том, что примеры со сложными вопросами по SQL, REST и диаграммам — избыточны. И что СА не обязан знать, как написать код обработки запроса на Python, И даже СУБД — тоже не сфера знаний СА, как и много другое. А что же обязан знать и уметь СА? Давайте пройдемся по профессиональному стандарту «Системный аналитик» от Минтруда РФ и возьмем требования для грейда “джуниор СА”.
Нам откроется немало удивительного.


Начнем с того, что для оценки кандидатов на вакансии и для аттестации действующих СА в ИТ‑отделах бюджетных организаций действительно существует профессиональный стандарт «Системный аналитик». Ранее утвержденная версия датируется 2014 годом и заметно устарела. Поэтому в 2022 году в ФГБУ «ВНИИ труда» Минтруда России подготовили новую редакцию профстандарта СА, введенную в действие в 2023 году. Документ родился в сотрудничестве с Ассоциацией предприятий компьютерных и информационных технологий в составе ООО «ИБС Экспертиза», ООО «Информационные бизнес системы» и ООО «Лаборатория системного анализа» (все — из Москвы).

Проект Приказа Министерства труда и социальной защиты РФ "Об утверждении профессионального стандарта "Системный аналитик"  доступен всем желающим на портале «Гарант». Сам приказ Минтруда России № 367н от 27 апреля 2023 г. Об утверждении профессионального стандарта «Системный аналитик» — введен в действие на срок с 2023 по 2029 годы.

Посмотреть и составить мнение об этом документе вы можете и сами, но мы не удержались, чтобы его не прокомментировать. К слову, предыдущий профстандарт для СА от 2014 года на сегодня утратил силу.

Итак, в рамках новой версии профстандарта предусматриваются 4 грейда: младший СА, СА, а также старший и ведущий СА. Для этой статьи мы решили разобрать только знания и навыки младшего СА, которые в госконторах потребуют от этого специалиста (в более привычной для рынка формулировке, от джуниор СА). Особенность требуемого набора знаний и навыков в том, что они ожидаются от человека со средним профессиональным образованием, или «техника-программиста» в терминах Минтруда.

Небольшая реклама: SSP SOFT приглашает на позиции системного аналитика, разработчиков на Java, React и Python, 1С, инженеров DevOps и QA
— см. страницу компании на hh.ru.

Как составлен профессиональный стандарт «Системный аналитик»

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

  • Младший СА: «Техническое сопровождение проектирования системы»,;

  • Рядовой СА: «Техническое проектирование системы и сопровождение разработанных проектных решений»;

  • Старший СА: «Концептуально-логическое проектирование Системы и сопровождение разработанных проектных решений»;

  • Ведущий СА: «Управление работами системных аналитиков в проекте или процессе проектирования, создания, приобретения, развития, поддержки, замены или утилизации Системы».

Казалось бы, все логично, но давайте погрузимся в детали знаний и навыков, требуемых хотя бы от джуниор СА. В лучших традициях законотворчества, они поделены на несколько так называемых «трудовых функций», и начинаются с раздела сбора исходных данных. Здесь и далее для краткости исключим из рассмотрения простейшие навыки типа «Умение пользоваться электронной почтой» и сразу перейдем к «хардкору».

Необходимые навыки по сбору данных (оставлены сложные пункты):

Мы отобрали для обсуждения три пункта:

  • Сбор образцов данных из систем, продуктов и баз данных;

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

  • Сохранение собранных исходных данных и ведение реестра собранных материалов.

В целом, это достаточно непростые действия, требующие специальных навыков. Можно предположить, что джуниор СА потратит немало времени своего наставника или руководителя на объяснения «куда идти, кого трясти и что где получить».

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

Необходимые навыки по сбору данных (оставлены сложные пункты):

Здесь будет побольше пунктов для обсуждения и удивления:

  • Вести деловые переговоры;

  • Пользоваться инструментами для просмотра данных в текстовом и двоичном виде;

  • Пользоваться инструментами для доступа к данным и извлечения данных из реляционных баз данных;

  • Читать исходный программный код;

  • Знать языки манипулирования данными (SQL);

  • Пользоваться инструментами онлайн-опросов.

Первый же пункт вызывает оторопь: «Какие деловые переговоры и с кем может вести джуниор СА?». Это функция менеджмента. Можно, конечно, предположить, что речь идет о коммуникации между джуниор СА и системным администратором. Первый просит доступ к системам, второй его посылает. Тоже своего рода деловые переговоры.

Знание двоичных редакторов и редакторов кода (типа Hex Editor и Sublime) тоже не сказать, что простое дело. Тем более сложным навыком выглядит «Читать исходный программный код», что скорее подходит для СА уровня мидла и сеньора, причем с функцией разработчика.

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

Навыки по изучению задач автоматизации и работы аналогичных и интегрируемых систем (оставлены сложные пункты):

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

  • Подготавливать отчет по сценарию работы пользователя или исполнителя;

  • Уметь структурировать описание деятельности — разбивать поток операций на взаимосвязанные сценарии;

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

  • Знать метамодели деятельности;

  • Проводить тестовый прогон сценариев в роли пользователя изучаемой системы-аналога;

  • Составлять описание структуры системы-аналога и взаимосвязей ее компонентов;

  • Составлять описание алгоритмов работы системы-аналога;

  • Знать устройство и функционирование распространенных операционных систем;

  • Проводить сбор образцов данных из систем, продуктов и баз данных;

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

  • Проводить сбор снимков экрана у пользователей аналогичных, заменяемых, развиваемых или интегрируемых систем и продуктов;

  • Вести реестр собранных материалов;

  • Извлекать массив данных из системы-источника;

  • Исследовать фактический формат и ограничения на полученных данных;

  • Исследовать зависимости значений полученных данных;

  • Агрегировать значения на полученных данных;

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

Согласитесь, от младшего СА требуется довольно солидный набор знаний и навыков для анализа работы систем-аналогов и сбора данных. Вот представим, что разрабатываемая система будет построена на Microsoft SQL Server, а системой-аналогом является Oracle Database 10g, 11g, или 12c. У них, как минимум, поддерживаются разные версии языка,
T-SQL и PL/SQL, соответственно,  — т.е. имеются ряд расширений к стандартному языку SQL.

И что, младший СА способен исследовать обе системы, форматы данных, их ограничения, делать тестовые прогоны и составлять отчеты? Да тут работы на целую команду СА (если, конечно, делать все самостоятельно, а не копипастить из прежних отчетов).

Оформление проектной и эксплуатационной документации (оставлены сложные пункты):

Когда джуниор СА успешно все сравнил, оценил, разработал и протестировал, приходит время составить документацию. Опять простите за длинное цитирование и опять оно того стоит:

  • Строить эскизы и техническое описание пользовательских интерфейсов элемента поставки;

  • Описывать программные интерфейсы элемента поставки;

  • Описывать структуру данных элемента поставки; 

  • Формулировать и оформлять требования и постановку задачи на приобретение, разработку, доработку, интеграцию элемента поставки;

  • Уметь выделять режимы функционирования, элементы окружения (роли, смежные системы, компоненты), интерфейсы (программные и пользовательские);

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

  • Уметь описывать сценарии и алгоритмы поведения элемента поставки и его взаимодействия с окружением;

  • Уметь анализировать исключительные ситуации и формулировать альтернативные сценарии в поведения элемента поставки и его взаимодействии с окружением;

  • Уметь описывать вызовы, их сигнатуры и структуры передаваемых через отдельный интерфейс данных;

  • Разрабатывать эскизы интерфейса пользователя;

  • Формализовывать и описывать языки взаимодействия элемента поставки с окружением;

  • Разрабатывать детальное описание поведения интерфейса пользователя;

  • Описывать концептуальную, логическую и физическую структуру базы данных;

  • Описывать объектно-ориентированную структуру данных;

  • Описывать формат файла;

  • Описывать структуру сообщения;

  • Разрабатывать требования к изделиям машиностроения, приборостроения и их составным частям;

  • Готовить примеры данных на вход и выход работы элемента поставки для приемки;

  • Определять характеристики требований и наборов требований;

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

Тут что не пункт, то тянет на отдельную специальность и должность. Например, пункт «Разрабатывать требования к изделиям машиностроения, приборостроения» был бы уместен для должностных обязанностей конструктора‑технолога, а «Разрабатывать эскизы интерфейса пользователя» — для дизайнера интерфейсов.
Но все это никак не для младшего СА, согласитесь…

Заключение: впечатление от нового профстандарта СА, что "лохматость повысилась"

Общее впечатление от профессионального стандарта «Системный аналитик» 2022 года примерно такое, что процесс его подготовки был как в мультике про приключения в Простоквашино (это частное мнение автора):

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

Это было бы все смешно, но подобным профстандартом будут обязаны пользоваться и  руководствоваться в бюджетных организациях. Как вариант, можно предположить, что проблема не разнобое пунктов, подготовленных разными исполнителями. А дело в сознательном усложнении требований к СА, и использования профстандарта как инструмента для манипулирования на собеседованиях при приеме на работу и аттестациях действующих аналитиков (в том числе для увольнения неугодных).

А каково ваше мнение о профессиональном стандарте «Системный аналитик» от Минтруда РФ?

Будем признательны за ваши комментарии.

Автор текста: Сергей Березин

Теги:
Хабы:
Всего голосов 14: ↑11 и ↓3+10
Комментарии34

Публикации

Информация

Сайт
ssp-soft.com
Дата регистрации
Дата основания
Численность
201–500 человек
Местоположение
Россия
Представитель
Андрей