Профессиональные стандарты в ИТ

О профессиональных стандартах в IT-отрасли рассуждает Борис Назаров, руководитель проектов Luxoft Training. 

Когда в очередной раз поднимается тема стандартизации профессиональных знаний в ИТ, обычной реакцией является встречный вопрос: как (и зачем) можно стандартизировать такую быстро меняющуюся область? Нужно ли вообще навязывать регулирование? Как это может работать, особенно, если до сих пор наблюдается нехватка ИТ-специалистов? Что, кстати, странно, т.к. сейчас многие пытаются "программировать веб-сайт" или "написать игрушку". Может быть, это связано с тем, что ИТ-отрасль ожидает специалистов с несколько более широкими знаниями, чем создание динамических веб-форм или анимация на мобильных платформах? И налицо несоответствие требований отрасли и представлений людей, рассматривающих начало карьеры в ИТ?



Давайте для начала разберёмся, что такое профессиональные стандарты и где они применяются.

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

Но хорошо, это регулируемая государством область для "серьёзных" профессий.

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

Известно, что непонимание, ведущее к большому количеству конфликтов, возникает из-за терминологии, когда разные люди, используя один и тот же термин, имеют в виду совершенно разное. Именно таким образом появился (и успел уже надоесть) мем "тыжпрограммист". Причина путаницы проста: люди, не пересекающиеся напрямую с ИТ, имеют смутное представление, какие бывают специализации и как все устроено внутри. Конечно, это может быть забавно в формате шутки, но определенно принесет серьезные проблемы, когда ожидания и планы разойдутся с реальностью в бизнесе.

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

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

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

Бизнес точно знает, что для учета финансов нужен бухгалтер и, возможно, специалист по управленческой отчетности. Для работы с контрагентами – юрист. Для работы с персоналом - специалист отдела кадров и специалист по развитию персонала (кстати, это разные профессии, несмотря на их частое совмещение). Но, если необходим ИТ-специалист, кого необходимо искать? Системного администратора? Руководителя проекта? Аналитика? Программиста? А если программиста, то какого?

Как происходит сейчас подбор сотрудников на ИТ специальность: руководитель подразделения или эксперт составляет длинное описание позиции с требуемыми навыками, как техническими (языки программирования, библиотеки, знания определённых процессов, умение работать в команде, знание бизнес-областей и т.п.), так и общими. После этого уже специалист отдела кадров (или HR) пытается сопоставить резюме кандидата с описанием позиции, далеко не всегда понимая детали требований. Из-за этого часто подбор растягивается.

Детальное описание вакансии в ИТ – это ведь, по сути, каждый раз разрабатываемый профессиональный стандарт для одной отдельно взятой должности.

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

Для эффективной работы персонал (и особенно ИТ-персонал в этой постоянно изменяющейся отрасли) необходимо постоянно обучать. Да, профессиональные стандарты чаще всего связывают с обучением и, особенно с первоначальным обучением в училищах и ВУЗах. Но неверно рассматривать их только в таком ключе.

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

Разрабатывать матрицу компетенций под себя достаточно долго и дорого (да и часто непонятно как, если нет соответствующего универсального специалиста). Было бы гораздо проще, если можно было взять готовый пример матрицы и немного доработать под себя, а в качестве дополнительного преимущества получить один язык при общении с другими компаниями-партнёрами или аутсорсерами.

Пока речь шла только про компанию, которая решала свои организационные проблемы.

А нужны ли стандарты самим техническим специалистам?

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

Также стандарты могли бы помочь ответить на вопрос: моё руководство считает, что я ещё не достоин должности "ведущий программист"? Но это уже совершенно отдельная тема аттестации и оценки, которая связана со стандартами, но не сводится только к ним.

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

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

В нашей практике мы создаем набор тестов по ИТ-направлениям, которые позволяют получить независимую картину знаний по конкретному специалисту и по подразделению или компании. Конечно, результаты данного теста нельзя использовать "сами по себе", это один из компонентов при оценке сотрудника или планировании обучения, но компонент существенный. Он позволяет получить независимость от субъективного мнения, общий охват и базу для сравнения как горизонтально, между специалистами (подразделениями), так и вертикально, по времени.

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

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

Стандарты в ИТ должны создаваться и поддерживаться.

Главное, чтобы не в формате обязательного (и застывшего во времени) закона и не в формате средневекового цеха с ореолом таинственности и закрытости для постороннего.