Добавляйте медленнее, чтобы двигаться быстрее

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

Так что не нанимайте. Серьезно, не нанимайте никого. Взгляните на это с другой стороны — действительно ли работа, которая вас отягощает, так необходима? Что случиться, если вы просто её не сделаете? Можете ли вы решить проблему с данной частью системы другим способом?

Каждый раз когда Jack Welch (former CEO of GE) увольнял кого-либо, он не нанимал человека взамен сразу. Он хотел посмотреть как долго GE может обходиться без данной персоны и его роли. Конечно, мы не призываем увольнять людей, чтобы проверить эту теорию, но мы думаем, что Jack настаивал на чём-то вроде: «Вам не нужно столько людей, сколько вам кажется необходимым».

Если нет никакого другого варианта — рассмотрите возможность найма нового человека. Но вы должны точно знать кто вам нужен, как вы введёте его в работу и как много головной боли обретёте.

Назначайте потенциальным работникам испытательный срок

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

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

Сроки для подобных вещей могут быть сжатыми, но даже если это задание на 20 или 40 часов — это лучше, чем ничего. Соответствует ли вам человек или нет — это будет очевидно. И если нет — то обе стороны оберегут друг друга от множества проблем и рисков, проиграв возможную ситуацию наперёд.

Ищите потенциальных работников среди разработчиков проектов с открытым кодом

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

Проекты с открытым кодом — находка для того, кто ищет техперсонал. Они дают вам возможность следить длительное время за работой того или иного специалиста.

Это значит, вы можете оценивать людей по-сделанному, а не по-сказанному. Вы сможете принимать решение основываясь на действительно важных факторах:

качество работы

Некоторые программисты могут красочно «заливать» о своих способностях, но при этом «съезжать с темы» когда доходит до дела. Участие человека в открытых проектах покажет суть его умений и опыта.

воззрения

Программирование это постоянное принятие решений. Огромного их количества. Решения зависят от воззрений, ценностей и идеалов. Присмотритесь к тем решениям, которые принял потенциальный кандидат при разработке кода, тестировании, в спорах, чтобы понять, в какой мере его представления соответствуют вашим. Если эта мера мала, вам будет трудно принимать решения вместе.

уровень увлеченности

Определенно, участие в открытых проектах требует хоть малость увлеченности. Иначе, зачем человек тратит время сидя за монитором? Степень занятости в открытых проектах часто показывает насколько человек действительно любит программировать.

умение довести дело до конца

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

умение работать в коллективе

Работая с кем либо долгое время, проходя через взлёты и падения, стрессы и «расслабоны» вы увидите реальный характер человека. Даже не обращайте внимания на тех, кто не обладает достаточной сдержанностью, или щедро наделён несносными манерами.

Когда речь идет о программистах, мы нанимаем только тех, кого мы знаем по проектам с открытыми исходниками. Считаем остальные подходы несостоятельными. Мы пригласили Джеймиса заметив его участие в разработках сообщества Ruby. Он выделялся среди остальных. Не было необходимости рассматривать второстепенные факторы, поскольку мы могли оценить его работу по главному критерию — качеству.

Не переживайте если какие-либо внештатные увлечения отвлекают ваших сотрудников от их основной работы. Перефразируя избитое выражение: если хочешь, чтобы дело было сделано хорошо, доверь его самому занятому человеку. Дэвид и Джеймис самые активные разработчики Rails и все еще успешно справляются с техническими вопросами в 37signals. Вашей команде нужны те, кто обожает программирование и умеет довести начатое до конца.