Команда разработчиков по принципам Agile: как найти, организовать и развивать эффективных сотрудников

12772

Построение эффективной команды разработчиков — непростая задача. Где найти и как выбрать хороших специалистов, как организовать их в команду, как измерять перфоманс каждого сотрудника и результат взаимодействия— вот лишь часть вопросов, которые могут встать перед руководителем. Их актуальность подтвердилась и на первом Kyiv CTO Meetup, который совместно провели Preply и Projector в марте— этому вопросу была посвящена отдельная панельная дискуссия. Не всегда получается сформулировать конкретную проблему, все сложности сплетаются в единый ком, и совершенно непонятно, с какой стороны к нему подступиться. Сооснователь и CTO Preply Дмитрий Волошин попытался распутать клубок проблем и найти готовые решения для построения dev-команд — на основе опыта зарубежных и украинских компаний.

Где искать: HR, агентство или рекомендации

Есть три основных подхода к поиску специалистов. Первый — нанять собственного HR-специалиста или даже команду. Второй — обратиться в профессиональное или рекрутинговое агентство. Третий — приглашать новых сотрудников по рекомендациям тех, кто уже работает в компании. На ранних этапах лучше объединить метод рекомендаций с методом кадрового агентства. Когда команда демонстрирует стабильный рост, пора нанять HR вместо сторонних специалистов: собственный профессионал в команде всегда лучше понимает ваши требования, а еще может распланировать поиск новых специалистов на несколько месяцев вперед.

Как показывает опыт, потребность в новом сотруднике обычно возникает задолго до того, как участники команды ее осознают. Принцип действует и в обратную сторону. CTO Genesis Кирилл Латыш на панельной дискуссии первого Kyiv CTO Meetup цитировал книгу «Who: The A Method for Hiring»: «Если вы задумались о том, чтобы уволить разработчика — скорее всего, уже поздно». Как бы то ни было, HR помогает отслеживать нагрузку и эффективность каждого специалиста, знает о планах компании и может своевременно начать поиск «на будущее». Но вот нанимать кого-либо раньше времени не советую: «лишние» сотрудники только затягивают сроки выполнения проекта.

Поиск «своих» и критерии отбора

Встречаясь с потенциальными участниками команды, стоит по отдельности оценивать реальные практические навыки и мотивацию. Идеальный кандидат — тот, кто полностью подходит вам по «техническим» требованиям и при этом мотивирован на результат. Но идеальные кандидаты, как и вообще идеальные люди, в реальной жизни встречаются редко, поэтому лучше искать в потенциальном сотруднике связку «мотивация плюс потенциал».

Как СТО стартапа, могу точно сказать, что из мотивированного сотрудника можно вырастить отличного специалиста в той области, которую на старте он знал только по касательной. А вот «зарядить» на хорошую работу скучающего и незаинтересованного профессионала — задача на порядок сложнее. Хайрить готового высококлассного специалиста стоит только тогда, когда без него и правда не обойтись. В остальных же случаях растить преданных профессионалов внутри компании — более выигрышная тактика.

Яркий пример тому есть и в Preply. Несколько лет назад мы взяли в команду молодого специалиста без опыта, выпускника вуза. Изначально он выполнял несложные технические задачи, изучал технологии и активно развивался как программист. После реализации нескольких успешных проектов в рамках компании, он начал предлагать и внедрять в нашу работу новые решения, например, с его легкой руки у нас появился Docker. Кроме того, в его обязанности входил онбординг новых специалистов, а также их курирование и коммуникация внутри компании. Со временем он вырос в тимлида, который может достойно заменить СТО во время его отсутствия на рабочем месте. Нам удалось рассмотреть его потенциал, потому что с первых дней своей работы он оценивал свою работу не количеством написанных строк в день, а возможностями и прибылью, которую его работа приносила команде в целом.

Kyiv CTO Meetup

Agile-методология и организация сотрудников

Теперь — о том, как нанятых сотрудников организовать в команду. Учитывая распространенность agile-подходов, имеет смысл говорить о построении команд, занятых гибкой разработкой. Agile-команды функционируют, например, в Apple, Netflix, Booking.com.

Ресурс Full-Stack Agile приводит в качестве примера описание организации работы в Spotify. Их команды известны как squads, но это лишь одна «боевая единица» в компании. На самом деле все чуть сложнее. Squad — это команда из разных специалистов, занятых в одном конкретном проекте. Это могут быть, условно говоря, проджект-менеджер, три разработчика с тимлидом, дизайнер, тестировщик и маркетолог. Несколько squads, занятых в смежных проектах, объединяются в tribe с единым лидером. В компании может быть несколько tribes, в каждом из них есть squads. Сотрудники одной специализации, работающие в рамках одного tribe, объединяются в chapter. К примеру, несколько тестировщиков, занятых в близких проектах, контактируют друг с другом и могут делиться опытом. И, наконец, есть guilds — объединения всех специалистов в компании, имеющих одинаковое направление деятельности. То есть, это все девелоперы, все дизайнеры, все аналитики или country-менеджеры.

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

Может показаться, что это решение для крупных компаний, где работают сотни или даже тысячи специалистов, но это не так. Мы внедрили подобную систему по совету инвестора из Booking.com Артура Костена, и подход отлично сработал, хотя в команде Preply всего 40 человек.

На работу с agile-командами переходят и другие украинские компании. Еще один спикер Kyiv CTO Meetup, CTO ЛУН.ua/Flatfy Станислав Скляровский говорил, что в «ЛУНе» сейчас работают кросс-функциональные команды, которые называются продуктовыми командами. Это позволило уменьшить задержки в разработке, улучшить коммуникацию между специалистами и понимание каждым своих задач.

Отслеживаем эффективность: как мерить перфоманс

Когда чистых dev-команд нет, измерять эффективность сотрудников можно по продуктовым KPI. Так оценивают работу в ЛУН.ua. Еще один вариант — составлять карту развития для каждого сотрудника, следить за тем, как человек осваивает новые навыки и улучшает свои показатели работы с уже знакомыми инструментами.

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

Как растить и удерживать специалистов

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

Тема роста junior’ов была одной из самых горячих на митапе. Оказалось, украинские компании совершенно по-разному подходят к решению этого вопроса. В одних количество молодых специалистов — на уровне 20%, в других — 50%, в третьих доходит до 80%. Кто-то тщательно отбирает кандидатов и затем развивает всех их до senior’ов, кто-то сознательно устраивает «текучку», чтобы на практике оценить прогресс и оставить в команде только лучших, никого при этом не упустив. Судя по выступлениям спикеров, обе стратегии имеют право на существование и показывают хорошие результаты.  

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

Автор: Дмитрий Волошин, сооснователь и CTO Preply

Оставить комментарий

Комментарии | 0

Поиск