Как стать автором
Обновить

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

Уровень сложностиПростой
Время на прочтение7 мин
Количество просмотров21K
Всего голосов 14: ↑11 и ↓3+10
Комментарии34

Комментарии 34

Я вообще удивлен, что Минтруда делает профессиональные стандарты по такой специализации.

Некоторые уточнения. Минтруд "не делает" профессиональные стандарты, а лишь утверждает профстандарты, подготовленные профессионалами, действующими в сфере IT.

В конце профстандарта "системный аналитик" представлен список разработчиков профстандарта.

  1. Ассоциация предприятий компьютерных и информационных технологий, город Москва, на сайте которой вывешены все подготовленные профстандарты

  2. ООО "ИБС Экспертиза", город Москва

  3. ООО "Информационные бизнес-системы", город Москва

  4. ООО "Лаборатория системного анализа", город Москва

  5. Подготовка профстандарта - сложная, кропотливая, многоплановая работа. Проект каждого профстандарта вывешивается для публичного ознакомления. Любая конструктивная инициатива (критика, замечания, предложения) приветствуется. Профстандарты следует применять не только государственными структурами, но и бизнесом.

Судя по описания, сотавители перепутали должность джуна и сеньора.

Может они не с той стороны считают?

Хотя каждый отдельный пункт из ваши цитируемых в целом подходит под требования аналитиков.

По сути требований описанных выше системный аналитик это такой интеллектуал поверхностно разбирающейся в вопросе и следящий на узкими специалистами.

Такой арт-директор.

Для государственных учреждений - вполне себе нормальный перечень требований. Когда я начинал свою карьеру в 2009 году в качестве техника в одном ГосНИИ, это был минимальный набор, который надо было знать и уметь делать. И как студент-отличник третьего курса университета - я вполне себе это все умел делать.

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

Поэтому многие толковые, талантливые ребята уходят из НИИ так же, как в свое время ушел я - на зарплату x3 и требования / 4 (делить на четыре)

Но, к сожалению вот такая вот у нас практика.

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

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

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

Звучит, конечно, монструозно для джуна и хотелось бы посмотреть, чем отличаются навыки ведущего СА. Но в целом примерно именно всему перечисленному меня учили на направлении экономической информатики Латвийского университета ещё в махровом 2000-м году. Очень базово и поверхностно, но при желании уже было понятно, куда копать и чему учиться. И когда я пришла на 3-м курсе в госструктуру, то ориентировалась как рыба в воде в их форматах ТЗ, потому что именно так в ВУЗе всё и показывали. Возможно в РФ тоже сейчас есть такие специальные направления в ВУЗах, где как раз по этому стандарту и будут готовить. И да, нарисовать wireframe UI (разрабатывать эскизы интерфейса пользователя) даже начинающему СА должно быть вполне под силу, дизайнер на этом этапе вообще ни при чём.

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


так посмотрите, текст стандарта доступен как в справочно-правовых системах по ссылками в статье выше, так и на отдельном специальном сайте профстандартов минтруда

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

теперь должны ориентироваться программы обучения

а что изменилось ТЕПЕРЬ? профстандарт существует 10 лет, в прошлом году просто обновлён

Ну, судя по тому, что автор статьи уверяет, что требования ужесточились :) значит будут выпускать более приспособленных к работе кадры :)

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

Программа института не основана на деятельности министерства, тк минтруда запросило у минкомсвязи, какие профстандарты заказывать. Минкомсвязи назвало в том числе системного аналитика.

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

А в составе рабочей группы стандарта были сплошь действующие практики.

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

Не очень понятно, из чего вы исходите в оценке навыков младшего СА.

Профстандарт предполагает, что СА - это ИТ-инженер со специализацией в проектирование и разработку требований. И перед тем, как стать младшим СА надо стать вообще ИТ-инженером.

Теперь по пунктам:

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

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

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

Под контролем старших товарищей - идти, куда послали собирать то, что сказали, класть в реестр, разработанный старшими. Посмотрите комплиментарные функции более высоких грейдов.

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

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

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

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

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

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

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

Посмотрите ФГОС по информатике - это при нормальном преподавании дети умеют на выходе из школы.

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

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

Это делают бакалавры любой ИТ-специальности 2-3го курса в курсовом проекте.

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

Младший СА сегодня - это выпускник любой ИТ-специальности с высшим образованием.

Это становится разочарованием для тех, кто шел в специальность по принципу "я писать умею, пойду в аналитики требования писать" и для "беглых от технологий", кто имеет ИТ-специальность, но всерьез ненавидит технологии и не хочет к ним прикасаться.

Для таких товарищей можно рекомендовать профессию бизнес-аналитика. Правда, для нее есть свой профстандарт :)

Вы верно сказали, но немного упустили тот момент, что по профстандарту Минтруда, младший СА - это человек без высшего образования. Техник.
Отсюда и удивление по требуемым навыкам: приказ Минтруда России № 367н от 27 апреля 2023 г.

Я не преподавал в ит-колледже. Но думаю, что выпускник колледжа тоже вполне имеет эти навыки на выходе. По крайней мере ит-студент на 2-3м курсе может работать младшим и иметь эти навыки

Это вы не видели профессиональный стандарт "программист". Если следовать ему, то программист 6 уровня квалификации (высшей, техлид по-нашему) должен иметь высшее образование и 1 год опыта. Но, как мы понимаем, есть нюанс.

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

Добрался уточнить: в Москве на системного аналитика учат 20 колледжей. Обычно - это ~4 года, за которые сделать младшего СА из школьника, увлеченного информатикой, вполне можно. https://postupi.info/city/1/coll-prof/2384

Спасибо, интересная инфа про колледжи.

Тема богатая, спасибо что подняли.

Ничего сверхъестественного в требованиях действительно нет, в этом согласен c @darkboatman. Если рассматривать все уровни квалификации в совокупности, то логика понятна и джун становится джуном.

Но меня удивляет степень различия между новым и старым профстандартами. При этом сопоставимых изменений на рынке труда я не замечаю. Условно профстандарт "встал с ног на голову", а рынок "слегка наклонился".

Возможно, речь на самом деле идёт про разные профессии. В терминах SDLC упор сделан на разные этапы. Предыдущий стандарт можно назвать "аналитик требований" - и он не устарел, а по-прежнему весьма актуален. Из приходящих на собеседование 70-80% работают скорее в рамках терминов этого стандарта, и не воспринимают себе участниками процесса проектирования.

Системные аналитики в терминах нового профстандарта тоже встречаются, как правило из компаний где разделены роли БА и СА.

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

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

С другой стороны работа аналитика требований к системе глазами пользователей уходит к бизнес-аналитикам и продактам.

Так что по нашим наблюдениям, рынок, как вы говорите лег на бок.

Профстандарт расширен для учета обоих положений :)

Ну не знаю...

Мне кажется что "аналитик требований" это классическая профессия, которая будет актуальна всегда.

А "аналитик-проектировщик" - мода текущего сезона, которая со временем будет оценена по достоинству и уйдет в свою узкую нишу.

Лет через 10 посмотрим :)

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

А вот вопрос: кто напишет 200 тикетов в месяц стоит все острее

я основной автор первой версии стандарта и целиком за сдвиг в проектирование

вплоть до того, что я профессию предагал переименовать)

но министерство такого хода конём не поймёт

профстандарт должен фиксировать лучшие практики, а не популярные

иначе можно дойти до варианта, что СА — это такая птица-ит-секретарь

профстандарт должен фиксировать лучшие практики, а не популярные

Это спорная позиция.

"Популярность" практики это объективный критерий, его можно замерить (с той или иной точностью).

"Лучшесть" практики - это оценочное суждение, с которым можно соглашаться, а можно не соглашаться.
Можно сказать что "лучшее" - это то, что станет "популярным" через 5-10 лет. Но с машинами времени пока напряженка.

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

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

а мы как эксперты знаем, что нужны и концептуальное проектирование и рациональный выбор вариантов решений

лучшее не становится автоматически популярным, тк для него нужны отдельные когнитивные и организационные ресурсы

для здоровья общества лучше, чтобы люди с утра занимались зарядкой. но большинство это не делает. поэтому это лучшая практика, а не популярная.

Прочитал бегло но отторжения требования не вызвали. Все это изучается в ВУЗе на профильной специальности, джун аналитик это прежде всего аналитик а во вторую очередь джун. Так что все что описано он делает, на своем уровне естественно. Я не теоретически говорю а вполне практически, да у меня есть в управлении джуны вчерашние студенты которые вполне тянут все вышеперечисленное после трехмесячного натаскивания на исп. сроке. Если это после нормального ВУЗа а не переученые за полгода [все равно кто] схема рабочая

Системный аналитик - не профессия. Года 4 назад их не было столько на рынке. Этой задачей занимался разработчик, и вполне успешно. Наплодили с курсов разрабов-импотентов, которым нужен человек, говорящий как переменные назвать. Такой разработчик никогда не станет полноценным, а системный аналитик никогда не станет разработчиком, потому что сам с курсов вылез. Не представляю вообще что с этим делать. Приходишь в такую команду, и на каждой задаче, у которой есть аналитика, на этой самой аналитике танцуешь до посинения. Только ждать пока рынок выплюнет неликвид. Но может быть неликвидом будут разработчики "старого" формата.

Это профессия, причём:

а) древняя, для примера посмотрите тезисы конференции 1976-года (48 лет назад): https://dl.acm.org/doi/proceedings/10.1145/800282

б) популярная, 500 тыс занятых в США по данным их Бюро трудовой статистики: https://www.bls.gov/ooh/computer-and-information-technology/computer-systems-analysts.htm

в) растущая: прогноз роста спроса по ссылке выше 10% на 10 лет.

Как человек, практикующий СА после разработки с 2004-го года и наблюдавший развитие культуры и сообщества СА в России тоже не могу сказать, что этим занимался всегда разработчик.

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

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

Потом выяснилось, что для успешной системы одних требований мало и более того, в ряде случаев детальные системные требования просто вредны.

Но нужно принимать много разных проектных решений по внешнему и внутреннему поведению системы:

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

б) проектировать взаимодействие машина-машина: тут у разработчиков сильно лучше, но оказалось экономически выгоднее заказывать эту работу по технической контрактации выделенному специалисту

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

Далее выяснилось, что архитекторы настаивают, что командам нужны не только структуры данных, но и доменные модели. Бизнес-аналитики доменные модели делают не очень, СА в этом сильнее натренированы.

Сейчас ещё пытаются отдать СА не только проектирование взаимодействия, функционального состава, интеграций, но ещё и структур БД и архитектуры. Последнее имхо спорно без кругозора, но этот кругозор скоро научатся давать благодаря движению system design и прочим, а у программиста всё равно этот кругозор не сильно шире, тк он обычно проектирует в 2-х режимах-крайностях: 1) сделаем вот так, потому что так работало всегда в предыдущих проектах (это если времени мало); 2) сделаем на новой технологии, потому что она новая и интересная (если времени много). Ни то ни другое, очевидно, не является рациональным архитектурным подходом.

Добавлю к этому: "проектировать взаимодействие машина-машина: тут у разработчиков сильно лучше "
Тут оба разработчика взаимодействующих машин каждый тянет в свою сторону и получаются часто очень причудливые архитектуры :)
А потом нужна связь взаимодействия пяти машин с пользовательским сценарием и у разрабов сразу лапки: "у меня все работает, а пользовательский сценарий - не моя профессия!"

На ум приходит классическое "Вам шашечки или ехать"?
Ты можешь сколько угодно не соответствовать стандарту, не дотягивать даже до джуна, но какой в этом толк, если тебя и схожих с тобой по навыкам людей нанимают на 300 на сеньорские позиции?
От того, что есть какая-то бумага, которая говорит, что так не должно быть, ничего на рынке не поменяется

Зарегистрируйтесь на Хабре, чтобы оставить комментарий