Кто такой Head of Profession и зачем он нужен компании
Лидер компетенций (или Head of profession) — это человек, который занимается развитием компетенций сотрудников определенной профессии. В статье разобрали на примере системного анализа, в чём именно его роль и почему такой специалист нужен большой компании.
![Аватар эксперта Мария Долгушина](https://media.tproger.ru/user-uploads/100503/2024-05-21/b05447ca-bf85-4d69-ad1d-afeb1b486f6e.png)
Мария Долгушина
Старший эксперт по системному анализу, 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, поговорили про его роль и навыки. И обсудили на примере системных аналитиков, как он меняет процессы в компании. Надеюсь, это станет для вас полезным и, возможно, вдохновит при выборе трека развития.
639 открытий7К показов