Кто такой Head of Profession и зачем он нужен компании

Мария Долгушина

Старший эксперт по системному анализу, Head of Profession System Analysis

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

В Газпромбанке подход немного другой. У нас есть деврел (от англ. - Development Relationship), которые запускают и развивают сообщества, есть актив этого сообщества, состоящий из наиболее вовлеченных участников, и есть Head of profession — лидер, который отвечает за развитие профессиональных компетенций внутри структуры (например, среди представителей определенной профессии ИТ блока розничного бизнеса). 

Далее подробно разберем процессы на примере нашей команды — Head of profession системных аналитиков.

Кто такой Head of profession?

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

И что важно — готов и умеет делиться опытом и знаниями с другими. Например, может рассказать, разъяснить, если нужно — зажечь команду, если нужно — успокоить.

Основных задач у лидера компетенций несколько:

• сформировать концепцию и разработать стандарты профессии;
• выстроить процесс найма и оценки персонала;
• мониторить и внедрять новые практики и технологии.

Разумеется, он будет делать это не один, а вместе с командой — но спросят с него.

Кроме того, Head of profession работает по специальности, в нашем случае — системным аналитиком. Нормальное разделение нагрузки — 50/50. Потому что если лидер компетенций будет уделять почти всё своё время системному анализу, то просто не успеет закрыть свои задачи. А если полностью уйдёт в менторство — то через год, максимум два, отстанет от профессии и перестанет быть экспертом.

Как стать Head of profession?

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

Сложно ли быть Head of profession?

Да. Когда в твоей группе 300–350 системных аналитиков, со своими вопросами, болями, проблемами, голова разрывается. Приходится очень быстро прокачивать собственные софт и хард скилы (я, кажется, никогда не росла так быстро, как в роли хэда), чуть ли не каждую неделю осваивать что-то новое.

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

А что тогда хорошего?

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

Как работает Head of profession — на примере системного анализа

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

Ушли от «Водопада»

Первое, что мы рассказываем нашим аналитикам: необходимо минимизировать документацию. А ещё уйти от waterfall, где анализ, разработка, тестирование происходят последовательно, и параллелить работу разных специалистов для сокращения time-to-market. 

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

Объяснили всем, что аналитик — это не переводчик

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

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

Превратили аналитика в инженера

В нашем понимании, аналитик — такой же инженер, как разработчик или тестировщик. Он должен так же переходить в Git, работать в IDE и прочих «разработческих» инструментах, а не «гуманитарных», таких как Jira, Confluence.

Что мы уже начали использовать как инженеры:

• API First. Это подход, когда аналитик пишет спецификацию в YAML и передаёт её в разработку. И программисты на её основе генерируют код, минуя «табличное описание».
• Doc-as-Code. Мы сделали свою версию — Doc-from-Code, когда аналитику не приходится делать текстовые описания вручную, а итоговая документация генерируется сразу по скриптам, комментариям в коде, процессам BPMN. Пока этот подход используется лишь в некоторых командах и есть трудности во внедрении — но это нормально.

Для аналитиков это сложно, многие воспринимают новые процессы в штыки, потому что приходится превращаться из senior-аналитиков в junior-разработчиков. Но мы стараемся до них донести, что эти трудности поднимают их ценность на рынке. И помогаем: организуем митапы, показываем инструменты, отвечаем на любые вопросы в чате, заполняем свою Wiki и так далее.

Мы даже сделали мем с котиками про стадии принятия — и все системные аналитики, которые становятся инженерами, их проходят. От «нашего продукта это не коснётся» до огромных эмоциональных сообщений в чатах сообщества и, наконец, конструктива.

Какие результаты мы получили

Сообщество системных аналитиков сформировалось больше года назад, и за это время мы создали артефакты (какие-то с нуля, какие-то — на базе уже имевшихся документов).

Карта компетенций

Она состоит из трёх блоков: 

• аналитические компетенции: перечень знаний и умений, которые должны быть у системного аналитика Газпромбанка;
• технические компетенции: по сути, инструменты, которыми должен владеть специалист;
• вспомогательные компетенции: преимущественно софт скилы.

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

Ассесменты

Они же — оценка персонала. Сейчас она специфичная для аналитиков. Эксперты:

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

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

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

Наём персонала

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

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

Онбординг

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

Техрадар

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

В идеале техрадар должен постоянно меняться, чтобы соответствовать рынку. Например, в сентябре мы поместили doc-as-code и doc-from-code в «песочницу», но сейчас они используются в проде на некоторых стримах, поэтому мы обновим схему.

Cook Book

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

Что ещё сказать

Мы разобрали, кто такой Head of Profession, поговорили про его роль и навыки. И обсудили на примере системных аналитиков, как он меняет процессы в компании. Надеюсь, это станет для вас полезным и, возможно, вдохновит при выборе трека развития.