- PVSM.RU - https://www.pvsm.ru -

Как увеличить эффективность разработки по методу Юрия Куклачева

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

Как увеличить эффективность разработки по методу Юрия Куклачева

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

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

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

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

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

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

До собеседования мы всегда даем кандидатам тестовое задание (об этом ниже). Выполненное тестовое задание намного лучше когда-то написанного куска кода, оно показывает, что кандидат — созидатель и достаточно сильно заинтересован. Код покажет компетентность, выполненное тестовое — уровень интереса (см матрицу интерес-компетентность [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 [2] улучшает жизнь, советую подробно прочитать про нее

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

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

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

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

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

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

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

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

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

Автор: kravets

Источник [3]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/53144

Ссылки в тексте:

[1] интерес-компетентность: http://habrahabr.ru/company/stratoplan/blog/201242/

[2] GitHub Flavored Markdown: https://help.github.com/articles/github-flavored-markdown

[3] Источник: http://habrahabr.ru/post/209664/