Меня зовут Настя Миронова, я менеджер разработки в Контуре и уже около двух лет руковожу командой рейнджеров – это разработчики без своего продукта, такие мобильные инженеры. Команда появилась в конце 2020 года, и за это время мы постоянно исследуем, чем можем помочь проектам компании, как делать это еще лучше, и как вырастить или найти ребят, постоянно готовых к вызовам.
Думаем мы не в одиночку – в компании развиты механизмы и практики горизонтальной мобильности, которые помогают в переходах между продуктами, командами и даже ролями.
Об этом и расскажу в статье с примерами коллег.
Зачем нужна горизонтальная мобильность
Для компании это способ найти лучшую команду для каждого. Такую, где он будет приносить максимальную пользу. Это помогает удерживать классных специалистов и развивать их. Наши разработчики могут сходить в другую команду, чтобы освоить новую технологию, а потом вернуться в прежний продукт и внедрить ее там. Это возможность видеть нужного человека в нужный момент и в нужном месте.
Для сотрудников мобильность — это возможность не быть привязанным к одному продукту. А в разных форматах быть полезным в других командах и продуктах компании, менять контекст и расширять компетенции, осваивая новые технологии. В Контуре процессы переходов выстроены так, что если сотрудник решит сменить команду внутри компании, на него не будут обижаться коллеги и руководитель. Сотрудник сможет спокойно передать все дела, закончить задачи и пойти искать новые вызовы в других продуктах.
Уровень погружения в новые продукты и длительность работы в новой команде зависит от формата переходов. В одном случае можно полностью перейти в другую команду, в другом — пойти на стажировки сразу в 3–4 разных продукта, а в третьем — вообще постоянно менять команды и подключаться к конкретным задачам. Все это – по желанию.
Смена команды как смена работы
Иногда сотрудник просто может захотеть сменить стек или роль. Для этого у нас есть внутренние обучения и система наставничества, так что смена контекста проходит не так сложно. Например, тестировщик может выучить React и перейти во фронтенд. А фронтендер может освоить высокие нагрузки и перейти в бэкенд.
Мой коллега из Бюро (о нем расскажу позже), Владимир Паршута – менял роль с тестировщика на менеджера разработки, но вернулся в прежнюю роль. Что он говорит о своем опыте:
|
«С момента прихода в Контур три года я работал тестировщиком в инфраструктурной команде Крипто. Еще я руководил кластером тестировщиков из 10 человек, участвовал в их оценке, развитии, занимался наймом и организовывал митапы. Участвовать в активностях и взаимодействовать с людьми мне всегда нравилось, и коллеги это тоже замечали. В какой-то момент руководители предложили попробовать себя в качестве менеджера разработки. Тогда я тоже думал об этом, и в смене роли видел для себя большой вызов. Прошел собеседование с руководителем функзоны менеджеров разработки и официально сменил роль. Состав новой команды был необычным: 4 бэкендера и менеджер разработки, то есть я. Поначалу было сложно понять свои задачи, но у меня был ментор, который помогал справляться с трудностями. А еще, до старта в новой роли я прошел внутренний курс от Контура — быстрый старт для менеджера разработки. Он помог получить базовое представление о зоне своей ответственности. В новой роли были и сложности — поначалу не понимал, как мотивировать коллег. А еще было очень много коммуникаций — постоянные встречи с интеграторами, синхроны — в итоге больше половины рабочего времени стало уходить на переговоры. Из-за этого я спустя год в новой роли решил вернуться в тестирование, потому что мне сильно не хватало работы "руками". Плюс я понял, что в роли тестировщика я тоже могу воздействовать на развитие продукта и закрывать свои потребности в увеличении зоны ответственности». |
Буткамп — экосистема для внутренних стажировок в других командах
Буткамп – это адаптация для бэкендеров, фронтендеров, тестировщиков и системных аналитиков. Обычно термин буткамп используют только для описания онбординга, но мы смотрим на него чуть шире: у нас он есть и для опытных сотрудников.
Для новеньких это классный способ погрузиться в контекст: устраиваясь в Контур, инженер попадает в буткамп. И несколько недель или месяцев (в зависимости от роли) обучается и стажируется в одной или 2-3 командах перед тем, как выберет одну для постоянной работы.
Но буткамп работает еще и для тех, кто в Контуре давно. Им он дает две возможности: найти новую команду внутри компании и сходить на стажировку в другом продукте на 1–2 месяца ради опыта и расширения инженерного контекста. Например, хочешь приобрести экспертизу в Apache Cassandra – иди в Диадок, сервис электронного документооборота с RPS. Там в работе он сможет узнать, как коллеги готовят ее, а потом принести экспертизу к себе в команду.
В чем польза буткампа для опытных сотрудников:
Проще найти новые задачи с вызовами, если заскучал в текущем проекте. Буткамп помогает сделать поиск таких задач гораздо более мягким и безопасным. Внутри буткампа есть менеджер, который поможет найти команду и заранее обсудит потенциальные задачи.
Есть возможность прокачивать софт скиллы. Во время стажировок в буткампе можно познакомиться с коллегами, у которых есть экспертиза в конкретных технологиях. А потом можно будет просто поболтать за кофе о решении рабочих задач с помощью этих технологий и открыть для себя что-то новое.
Можно выбрать самую подходящую команду. В Контуре 11 тыс. сотрудников, примерно 30% из них — разработка. Какие-то команды предпочитают работу из одного офиса, а другие команды распределенные. Если что-то идет не так — и у сотрудника и у команды есть право завершить стажировку раньше. Команда продолжит поиск подходящего человека, а у сотрудника будет возможность пойти на другую стажировку.
Команда рейнджеров — для тех, кто хочет постоянно переключаться между проектами
Есть в Контуре команда инженеров, которые готовы прийти и решить срочную задачу, на которую сейчас нет ресурсов в проекте. Это рейнджеры. Ребята не занимаются постоянно одним продуктом, а решают задачи по созданию MVP для стартапов, проводят аудиты, стартуют автоматизацию тестирования, решают инфраструктурные задачи. И не только.
В рейнджерах сконцентрированы контуровцы с самыми разными компетенциями. Из-за того, что ребята постоянно работают с разными проектами, у них большая насмотренность на паттерны проектирования и применение технологий в компании.
Я пришла к рейнджерам из продуктовой команды и мне интересно выстраивать процессы для ребят, у которых нет постоянного продукта. Например, я организовала прозрачное планирование ресурсов и бэклога, помогаю найти и адаптировать новеньких команде.
В рабочих процессах у рейнджеров есть несколько нюансов, с которыми не всегда просто работать. Во-первых, часто высокий уровень неопределенности. Во-вторых, приходится каждый раз адаптироваться к процессам в новой команде и налаживать общение с коллегами.
|
Дмитрий Зверев работает в Контуре уже 17 лет, за это время он успел сменить около 5 команд. А недавно понял, что устал от работы в постоянном продуктовом контексте и решил попробовать что-то новое — так и перешел в команду рейнджеров: «Переход в рейнджеры стал для меня вызовом. На момент перехода я понимал, что не хочу идти в продуктовую команду с фиксированной предметной областью. С другой стороны, идти в рейнджеры было страшно, так как я сомневался, что справлюсь с быстрой сменой контекстов задач. Но было и понимание, что рейнджеры — это путь к быстрой прокачке как в технологиях, так и в софт-скиллах В рейнджерах постепенно начал ходить в разные продукты и осваивать новые технологии. Например, в первом же проекте мы столкнулись с необходимостью быстро реализовать админку для менеджеров. Решили использовать Blazor, который на тот момент только вышел. Для меня это был абсолютно новый опыт, и это драйвило. Все получилось быстро, и нам не пришлось привлекать фронтендера на эту задачу. Сейчас я дорос до тимлида C#-рейнджеров. Здесь тимлидство отличается от того, что есть в продуктовых командах. В классической команде тимлид держит в голове только контекст по своему продукту, а в рейнджерах у тимлида есть своя задача, плюс контекст по задачам своей подкоманды. Тимлид “рейнджеров” онбордит новичков, растит инженеров: помогает с оценкой и развитием, с менеджером подбирает задачи, а еще участвует в выстраивании процессов в команде». |
Когда инженеры могут развивать насмотренность в технологиях и быть мобильными внутри компании — это классно. А Возможность постажироваться в других продуктах или вообще перейти в команду рейнджеров помогает сохранить сильных сотрудников, укрепить связи между командами и дает инженерам больше гибкости.
В конце прошлого года рейнджеры вместе с другими ролями объединились в Бюро разработки.
Бюро разработки – для усиления и буста команд
Бюро – это специалисты из управления разработки Контура, которые приходят в команду для решения задачи или проблемы на определенный срок. Это не обязательно разработчики. Сейчас в Бюро 6 команд:
Рейнджеры
Дизайн-бюро
UX-лаборатория
Технические писатели
Бюро тестирования
Группа аналитиков
Задачи выбираем по приоритету: за усилением может прийти большой продукт Контура или стартапы, которые мы запускаем и стараемся проводить сразу через Бюро. Но и туда, и туда может отправиться как один инженер из Бюро, так и команда.
В Бюро непросто, но интересно. Мы понимаем, что не каждый сможет работать в таком формате постоянных переключений между командами и проектами. Поэтому в первую очередь Бюро разработки – это команда. У нас свои мероприятия, активности, и внутренние технические процессы. И каждый сотрудник может пойти и посмотреть, как в разных командах строятся процессы и при этом привнести что-то свое.
Когда работаешь над одним продуктом, это может надоесть. В какой-то момент захочется попробовать новые технологии или заняться другими задачами в целом. Практика мобильности помогает человеку изменить работу и опыт в компании к лучшему. При этом не обязательно выходить на рынок, а менять свою деятельность уже в сработавшейся компании и контексте, который вы знаете. Вам пойдут навстречу и помогут даже сменить роль, что в целом сложновато и страшно – когда ты не очень компетентный в чем-то новичок.
Есть в этом подходе что-то от любви к людям и своему делу. Но в то же время мобильность – это не панацея в вопросах закрытия потребностей компании, профессионального роста сотрудников и их самочувствия. Тем более что, чтобы построить и поддерживать такую систему – требуется много ресурсов. Поэтому, прежде чем в неё вкладываться, стоит оценить масштаб работ и хорошо провалидировать цели.