Опыт создания технических сообществ и организации их управления

Предисловие

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

Кратко о практики

Практика и комьюнити не имеют ярких и вызывающих названий, как, например, «Команда А» или «Операция Феникс». Наше комьюнити называется скромно — Стек, а практика управления, что логично, — Стек-Менеджерство.

Стек — это группа инженеров, объединённых одним технологическим направлением (например, PHP, .NET, Front-End, Python и другие). У нас таких групп 12. Каждая группа имеет набор лучших практик для ведения технологической деятельности, а также практик для найма новых инженеров в стек, подходы для проведения пресейлов, онбординга, набор инструментов для оценки инженеров по грейду и производительности. Группа периодически собирается для обмена знаниями и решения текущих вопросов.

Стек-Менеджерство осуществляет конкретный специалист — Стек-Менеджер (далее СМ), который возглавляет эту группу, а также Руководитель Стек-Менеджеров (далее РСМ). СМ проводит регулярные 1 на 1 встречи с инженерами стека и фиксирует результаты в системе контроля удовлетворенности.

Для чего это все?!

У многих может возникнуть вопрос: зачем это всё нужно?

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

Второе. У нас одновременно идет 20-25 проектов различной численности и сложности. Не все инженеры работают над проектами, которые прогрессивно развиваются и используют лучшие практики. Соответственно, чтобы эти инженеры поддерживали свой уровень и развивались вместе со стеком, мы вовлекаем их в интересующие их активности.

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

Четвертое. Информирование инженеров стека об изменениях в стеке или в компании (помимо ежемесячного дайджеста).

Какие плюшки для инженеров?

Главный момент: деятельность в рамках стека — это исключительно добровольная активность. Некоторые инженеры не проявляют желания участвовать в событиях стека, и, конечно, на них никто не оказывает давления, и это никак не влияет на их положение.

Естественно, деятельность СМ оплачивается, как и работа инженеров по задачам стека.

Как я уже писал ранее, многие инженеры хотят заниматься чем-то помимо написания кода, и стек предоставляет им такие возможности: участие в пресейлах, интервьюирование, роль наставника, формирование best practices, подготовка скринингов и лайфкодингов, а также многое другое.

Помимо оплаты, в нашей компании существует дополнительный критерий при грейдировании — level of influence (степень влияния на компанию). Инженер, активно участвующий в жизни стека, имеет высокий level of influence, что, естественно, учитывается в положительную сторону при грейдировании. Это может привести к регрейду и повышению заработной платы. В свою очередь, отсутствие активности в этих направлениях не ведет к понижению грейда. А при прочих хороших показателях это не мешает инженеру поднять грейд.

Давайте подробнее рассмотрим основные направления деятельности стека и СМ.

Участие в найме инженеров в стек

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

Что мы делаем в этом направлении в стеках:

1. Формируем базовые скрининги, которые передаем в рекрутинг для проведения первого HR-интервью. В последнее время мы начали внедрять новый формат при найме джуниоров и миддл- инженеров: мы готовим около 20 вопросов для скрининга — 10 простых с вариантами ответов, 6 средних без вариантов ответов и 4 сложных без вариантов. Этот подход уже позволил закрыть 2 позиции, и мы считаем его успешным для данных позиций.

2. Создаем и актуализируем лайфкодинг.

3. Подготавливаем и актуализируем вопросы для технического интервью (ТИ), на которые может опираться интервьюер.

4. Разрабатываем и актуализируем курс для подготовки интервьюеров.

5. Актуализируем формы обратной связи по результатам ТИ.

6. Контролируем качество обратной связи.

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

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

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

Регулярные встречи стека

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

Есть небольшая памятка для СМ о потенциальных темах встреч:

1. Встреча стека — обсуждение ситуации на проектах у инженеров.

2. Обзор новостей, связанных с технологиями стека за месяц.

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

4. Разработка и внедрение нового бизнес-процесса в отдел разработки.

5. Внедрение новой фичи в работу отдела или взаимодействие между отделами.

6. Обсуждение новых подходов к командообразованию и пипл-менеджменту.

7. Обсуждение проблем, возникающих в пипл-менеджменте и командообразовании.

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

9. Выпуск глобального обновления какой-либо технологии, инструмента и т. п.

10. Требуется обновление подхода к интервьюированию/найму сотрудников.

11. Разбор пройденных интервью у заказчика.

12. Разработка пэт-проекта — есть чем поделиться.

13. Завершение проекта — возможность поделиться результатами.

14. Обсуждение подходов к пресейл.

15. Обсуждение подходов к наставничеству.

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

17. Обсуждение прошедших конференций и других обучающих мероприятий: курсов, тренингов и т. п.

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

19. Обзор ноу-хау инженера/проекта.

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

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

Грейдирование

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

Стек отвечает за формирование матрицы компетенций (МК) по техническим навыкам. МК должна включать:

• Сами навыки с описанием.

• Разделение каждого навыка по грейдам. Например, инженер является мастером в JavaScript и экспертом в React.js.

Кроме того, СМ отвечает за то, чтобы в стеке, помимо него, были инженеры, которые могут объективно оценивать других специалистов по МК и присваивать им грейд на основе набора технических навыков. Небольшое отступление: финальный грейд присваивается не только на основании технической МК, но и по четырем другим критериям.

Операционная деятельность стека в рамках процесса грейдирования включает следующие шаги: получение уведомления о старте процесса для конкретного инженера, назначение ответственного за оценку МК, а также выдача заключения в установленный срок и внесение данных в систему учета грейдов.

Важно поддерживать МК в актуальном состоянии, так как IT-сфера постоянно развивается: каждый месяц появляются новые технологии, и некоторые из них могут стать важной составляющей того или иного стека.

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

1 на 1 встречи

В данном контексте речь идет о встрече в формате: СМ определённого стека с инженером этого же стека. Время встречи может варьироваться в зависимости от удобства инженера и СМ. Что касается частоты таких встреч, я рекомендую каждому СМ проводить их минимум раз в квартал.

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

После встречи СМ фиксирует её результаты в системе контроля удовлетворенности инженеров. Уведомление по каждому инженеру отправляется соответствующему руководителю проектов, РСМ и HR. Обновления по инженерам обсуждаются раз в неделю на встрече ДМ, СТО, РСМ и HRD. Если возникают задачи, назначаются ответственные и запускаются в работу.

Вы спросите, почему встречу не проводит РП инженера?

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

Во-вторых, технические проблемы не всегда можно обсудить с РП, и проще это делать с опытным специалистом, который может повлиять на ситуацию. Не всегда техлид проекта способен решить все вопросы на проекте, и в таких случаях требуется помощь архитектора или СМ.

Итак, что мы имеем в итоге?

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

Кто-то может сказать: «Зачем решать какие-то периферийные проблемы? Просто увеличьте зарплату!» Мы пробовали — отслеживали такие прецеденты на протяжении пяти лет. В большинстве случаев это давало лишь временный эффект, и если не решались периферийные проблемы инженера, он, как правило, уходил.

Другие практики внутри стеков

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

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

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

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

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

Заключение

В каждом пункте я подводил итоги, а здесь кратко еще раз их зафиксирую:

• Выстроен процесс найма, особенно технической части.

• Появилась площадка для обмена знаниями и совместного решения проблем.

• Альтернативное мнение от СМ о состоянии инженеров, что позволяет быстрее выявлять и решать проблемы.

• Система грейдирования стала прозрачной.

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

• Повышение экспертности в части найма. Это сократило затраты на найм.

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

На сегодня всё. Спасибо за прочтение, всем удачи в работе!

Если вам понравилась статья — заходите в мой TG-канал, там я делюсь мыслями и полезными материалами: https://t.me/Lazzy_IT