How to Find Right People for Agile
| February 9, 2007 | Posted by Denis under Практики, Статьи |
Правильные люди. Перед тем, как начать подыскивать человека в Agile команду, следует четко представлять себе, что мы ожидаем от этого человека. На самом деле, важно понимать, что подбор персонала — это шахматная партия, в которой текущий ход зависит от предыдущих, равно как и определяет в огромной мере последующие. Естественно, команда юниоров не превратится в гибкую команду — не стоит пробовать, Agile —это прежде всего реализм. Но это не означает, что гибкая команда состоит из 100% старших разработчиков, тестеров и т.д. Итак, перечислим основные необходимые качества для человека в гибкой команде:
- Ответственность
Человек, не способный свято следовать командному commitment’у будет серьезной проблемой для команды.
- Коммуникабельность
Общение — центральная ценность в agile. Человек должен иметь желание делиться знаниями и ни в коем случае не испытывать проблем узнать что-то у кого-то. Это повседневная реальность гибкой команды. Также не должно быть проблем с языком заказчика, так как коммитмент каждый член команды несет напрямую перед заказчиком.
- Решительность
Принимать решения в гибкой команде приходится каждому ее члену. Члены команды должны иметь достаточно полномочий, чтобы реализовать свой коммитмент. Но, очевидно, они должны быть к этому готовы. Также, член команды должен обладать достаточным мужеством, чтобы в случае объективной необходимости удалить свой код, написанный за целый день, отказаться от разработанной архитектуры и т д. Рефакторинг, иначе говоря, требует не только мастерства, но и психологической готовности.
- Гибкость
Умение переключаться с одной задачи на ту же, но с качественно иной формулировкой, требованиями и ожиданиями очень важна.
- Мотивированность
Успешный продукт удастся разработать быстро и эффективно только команде мотивированных людей. Подспорье для мотивации у разных людей разное, но мотивация должна присутствовать. Не стоит брать в гибкую команду низко мотивированного человека в надежде в последствии развить в нем мотивацию практически с нуля.
- Практичность
Человек даже глубоко понимающий технологии, способный уверенно двигаться вперед, наращивая невероятно сложную функциональность, но не способный посмотреть на систему с точки зрения пользователя, мыслить в терминах выгоды и удобства для конечного пользователя, а также безразличный к качеству будет в большой степени бесполезен в команде.
- Логика
Нужно уметь не просто принимать решения. Они в большинстве своем должны быть разумными.
- Технологии
Знание большинства (но не обязательно всех) технологий, необходимых на проекте, является необходимым).
Как эффективно проводить интервью.
Простой телефонный разговор продолжительностью 15-25 минут. Цель телескрина весьма тривиальна: получить первое представление о человеке по всем основным областям — как следствие либо назначить очное интервью или отказаться от проведения очного, если сразу видно, что кандидат не подходит под вакансию. На типичный вопрос: «не является ли телескрин пустой тратой времени?», я привожу нередкостный в практике пример:
Телескрин. Мы ищем старшего C++ разработчика на проект. На вопрос, «кем вы видите себя на проекте ?» следует уверенный ответ: «менеджером проекта, конечно!».
Итак, мы потратили 5 минут, пожелали кандидату удачи в трудоустройстве и вернулись к текущей работе. Но ни кандидат, ни мы не потратили 1-2 часа своего времени на очное интервью, транспорт и т д. Приведем пример вопросов на телескрине. В первую очередь обязательно расскажите кандидату о вашем проекте и скажите, что это Agile проект. Это важно. Практика показывает, что не все чувствуют себя комфортно (или вообще видят себя) на проекте, где полноценная версия демонстрируется заказчику каждую неделю или, скажем, каждые две.
- Роль на нашем проекте? Почему считаете, что сможете успешно подойти и реализовать себя в этой роли? (О желаемой роли мы именно спрашиваем, а не утверждаем ее. Очень желательно, хотя и не всегда возможно, чтоб человек попал именно на ту роль, на которую претендует. Если он, конечно, вас заинтересовал. Если чувствуете незаинтересованность в вашем проекте — задайте вопрос напрямую. Если проект, либо стиль разработки не интересен — не тратьте свое время и время кандидата даром, пожелайте друг другу успеха и попрощайтесь).
- Почему ищете новую работу?
- Наиболее интересный проект, в котором вы участвовали? Почему интересен? Ваша роль?
- Масштабы предыдущих проектов, методологии и подходы, проблемы и решения? (Ни в коем случае не делайте плохих выводов из того, что кандидат не практиковал или не знает, что такое Agile. Если у человека гибкий ум, полнценное «вертикальное» мышление, сфокусированность на существенном — этот человек вам подходит. Больше требовать не нужно).
- Юнит тестирование, рефакторинг? Опыт?
- Технические вопросы. Имеет смысл привлекать 1-2-ух людей из команды для успешного и быстрого кросс-интервью по технологиям.
- English. В какой-то момент интервью, после ответа кандидата попросите его сказать то же самое (1-2 предложения) на английском. Очень помогает.
- Ожидания от новой работы?
Несколько советов
- Во время интервью не задаем наводящих вопросов. Это просто трата времени. Плюс, во время телескрина, не следует таким способом излишне располагать к себе кандидата. Обе стороны должны быть хорошо сфокусированы на главном — получении наиболее адкеватного первого представления друг о друге.
- Проводите телескрин в первой половине дня. По крайней мере старайтесь. Причина проста: уставший кандидат + уставшие интервьюверы — низкая адекватность телескрина как результат.
- Держим хороший темп. Если нет ответа на текущий вопрос некоторое время — пропускаем и движемся дальше.
- «Каждый вопрос интервью – первый». Под этим мы понимаем, что перед каждым вопросом мы стараемся забыть о текущем впечатлении о кандидате. К сожалению, впечатление имеет свойство накапливаться. На самом же деле плохой или хороший ответ на вопрос «каков порядок сложности алгоритма поиска по хэш-таблице?» не должен влиять на впечатление от ответа на следующий по счету вопрос: «какова цель юнит-тестирования?».
- Во время проведения скрина, интервьюверы не обмениваются мнениями, удивленными взглядами и т д.
- Не все интервьюеры должны читать резюме. Если резюме содержит фото — тот, кто его первый увидел, предупреждает и никто больше (!) фото не смотрит. В большинстве случаев резюме портит представление о человеке, часто — неадекватно. В 99% случаев фото работает также против кандидата. Но ни то ни другое не имеет ничего общего с тем, насколько успешным будет человек на проекте.
После окончания собеседования интервьюверы просто говорят друг другу — приглашать на очное собеседовние или нет. Очень желательно обмениваться аргументами после того, как каждый сказал свое мнение. Если мнения в пользу кандидата или даже неоднозначно разделились — следует приглашать.
Принимать на работу человека без проведения очного интервью очень рисковано. Очное интервью должно показать, на что человек способен. Если вы принимаете на работу разработчика — вы обязаны (!) попробовать его в деле — дать ему возможность покодировать. Как это можно делать:
- Начните с довольно простой задачи. Важно: реалистичной задачи! Не ограничивайте слишком возможные решения, формулируйте только основную суть задачи — дайте кандидату возможность проявить изобретательность.
- После реализации текущей задачи добавьте новые требования и/или измените старые. Итак — все время по ходу сессии кодирования.
- Просите написать юнит тесты. Если даже нет под рукой подходящего UT-фреймворка, с которым ваш кандидат знаком, – попросите просто их написать и ограничьтесь ривью. Главное – как человек покрывает код тестами. Важно его отношение к качеству кода.
- После сессии кодирования, попросите человека открыть notepad и написать текст письма виртуальному заказчику, где нужно описать, что написанный им сниппет делает и для чего. Так вы проверите не только письменный английский.
После этого поговорите с человеком о том, что вы ожидали бы от него на новой должности. Попросите рассказать, чего ожидает он и как представляет себе свою роль и обязанности в новой среде. Также пообшайтесь немного о чем-то, не имеющем отношения к работе. Вам нужен не робот, а нормальный человек. Никогда не принимайте решения в присутствии кандидата. Принимайте его, когда и вы и остальные интервьюверы вышли из контекста собеседования, тогда впечатления уступают место здравому смыслу.
Дополнительно
Bill Wood (VP Software Engineering, Ping Identity), более чем успешно практикующий Agile, советует перед тем, как приглашать человека на интервью, дать ему домашнее задание – выше среднего уровня. Это покажет, хочет ли действительно человек работать на вашем проекте.
Никогда полностью не делегируйте интервью кому-то извне команды. Если даже вы не знаете технологий, у вас в команде также нет специалистов в этой области – старайтесь присутствовать на техническом интервью, если оно даже проводится внешним тех-интервьювером. Обязательно плотно сами пообщайтесь с кандидатом.
И, наконец, подчеркнем, что вам нужен не кодер, а именно полноценный участник процесса гибкой разработки, ответственный не за написание кода, а за успех проекта.
(c) Alex Yakima
