Как Юрию Куклачеву удалось создать команду, которая стабильно, на протяжении многих лет показывает немыслимые для других аналогичных команд результаты?
Секрет Юрия Куклачева прост:
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
