Как Юрию Куклачеву удалось создать команду, которая стабильно, на протяжении многих лет показывает немыслимые для других аналогичных команд результаты?

UPD: Пост не про лишение еды.

Секрет Юрия Куклачева прост:

1. Правильный подбор специалистов (супер-важно)
2. Правильное выстраивание процессов

Эти два принципа можно использовать и для построения эффективных команд при разработке программных продуктов.

Подбор команды

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

1. Созидатель

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

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

2. Мотивирован не деньгами

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

Узнать об этом можно задавая открытые вопросы о том, к чему кандидат стремится в жизни, что ему нравилось/не нравилось на предыдущих местах работы. Многим разработчикам такие вопросы могут показаться странными и глупыми, поэтому, надо постараться хотя бы не задавать шаблонные вопросы “кем вы видите себя через 5 лет”, а придумать что-то оригинальное, то, на что человек ответит искренне.

3. Любит изучать новые технологии и подходы

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

Идеально, если ваше тестовое задание само по себе будет для кандидата чем-то новым. Например, если он никогда не использовал GitHub, а тестовое задание предполагает его использование, это отлично покажет, может ли человек быстро сориентироваться.

На собеседовании снова помогут открытые вопросы. Избегайте вопросов, которые подразумевают очевидный социально-желательный ответ, например, “готовы ли вы изучать новые технологии?”. Намного продуктивнее будет спросить что нового в своей или смежных областях он узнал за последние пару месяцев.

4. Адекватно общается

Если кто-то устраивает холивары по любому поводу или у него слабая толерантность к ошибкам других, это погубит атмосферу в команде.

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

Советы по подбору команды мечты

1. Вакансия

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

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

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

Например, мы разрабатываем на yii, но подчеркиваем, что опыт работы с этим фреймворком не так уж критичен

2. Тестовое задание

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

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

Не могу не похвастаться тем, как кандидаты реагируют на наше тестовое:

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

3. Собеседование и выбор

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

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

Выстраивание процессов разработки

Для хранения кода мы используем приватный репозиторий на GitHub, его же мы используем для треккинга задач и ведения документации.

Несколько советов, которые могут вам пригодится:

1. Приоритизация. Используйте ярлыки в тасктреккере GitHub

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

2. Eat the elephant bite by bite
Лучше стремиться избегать эпичных тасков, а бить их на маленькие. Но однотипные маленькие — группировать в один issue списком с чекбоксами. Используйте для этого разметку:
— [ ] Таск еще не готов
— [x] Таск готов

3. Оформление задач. Применение GitHub Flavored Markdown улучшает жизнь, советую подробно прочитать про нее

4. Прозрачность целей и задач. В понедельник мы составляем список задач на неделю и объединяем их в milestone. На ретроспективах анализируем результаты майлстоуна, что можно улучшить в процессе разработки. Хвалим друг друга за успехи, хорошие идеи, это положительно влияет на атмосферу в команде.

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

5. Персональная ответственность. За каждый таск должен быть только один ответственный, никакой коллективной ответственности за таски.

6. Стендап митинг. По утрам проводим быстрый стендап митинг, с традиционными вопросами кто что сделал, какие есть проблемы и кто что собирается сделать сегодня.

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

7. Максимальная доступность информации. Документация ведется в wiki репозитория. Широко применяем групповые чаты в Skype, в том числе при общении со специалистами, которые не в команде, чтобы все в команде были в курсе ситуации, могли прочитать.

8. Cross code review. В конце каждой недели мы делаем cross code review для взаимного обучения и повышения качества кода.

9. Поддержка пользователей. Все так или иначе взаимодействуют с пользователями, соприкасаются с их поддержкой. Это позволяет всем лучше понимать продукт и потребности пользователей.

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

Автор: kravets

Источник