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

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

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

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

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

Закон Брукса

Привлечение людей к просроченному проекту задержит его ещё больше.

(— Fred Brooks)

Программирование и «Реквием» Моцарта

Хороший одиночный программист, работающий над отдельной задачей, не имеет над собой проблем координации работы и общения. Пять программистов, работающих над той же задачей, обязаны общаться и координировать свои действия между собой. Это занимает много времени... Основная проблема с использованием группы посредственных программистов вместо парочки хороших состоит в том, что не имеет значение как долго они работают, они никогда не создадут что-то так же хорошо, как это делают великие программисты. Пять Антонио Сальери не смогут создать «Реквием» Моцарта. Никогда. Даже, если они будут работать над этим 100 лет.

(— Joel Spolsky, software developer, Fog Creek Software (from Hitting the High Notes))

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

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

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

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

Начните с малого

Попробуйте для начала дать небольшое тестовое задание. Не надо набрасываться сразу со всей вашей работой. Дайте вашему новому виртуальному помощнику (virtual assistant, VA) один или два проекта для проверки и посмотрите, как налаживается с ним взаимопонимание. В самом начале может показаться легким закрыть глаза на потенциальные проблемы, но помните - это проверочный забег.

(— Suzanne Falter-Barns, author/creativity expert (from How To Find And Keep The Perfect VA[11]) )

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

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

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

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

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

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

воззрения

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

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

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

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

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

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

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

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

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

Увлеченные программированием

Что вы больше всего хотите от недавно нанятого человека? Конечно увлеченности своим делом. И нет лучшего способа увидеть это, чем посмотреть на участие человека в открытых проектах.

(— Jarkko Laine, разработчик ПО (из «Уменьшите риски, нанимайте опенсорсеров»[12]))

Быстро обучающиеся универсалы лучше закостенелых авторитетов

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

В маленьких командах нужны мастера «на все руки». Дизайнеры, умеющие вести техническую документацию. Программисты, сведущие в вопросах дизайна. Каждый должен себе представлять какой должна быть структура системы (какой бы смысл вы бы не вкладывали в это понятие). Каждому нужно мыслить системно. Каждый должен уметь общаться с клиентами. И, в случае необходимости, каждый должен уметь, резко «дав по тормозам», развернуться контролируемым заносом. Запомните, маленьким командам иногда надо изменить направление и сделать это быстро. Вам нужен тот, кто сможет учиться, привыкать, приспосабливаться, а не закостенелый брюзга, специализирующийся на чём-то одном.

Берите счастливых середнячков, а не разочаровывающих гуру

Энтузиазм. Свойство, не передающееся даже самым умелым притворством. Пришло время нанять кого-то в команду? Не думайте, что нам нужен гуру или хорошо известный (в тесных кругах) специалист. Такие всё равно чаще всего выступают в роли «свадебных генералов». Счастливый специалист средней руки лучше раздражённого эксперта.

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

Дополнительные баллы тем, кто спрашивает

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

(— Eric Stephens, BuildV1.com[13])

Нанимайте хороших писателей

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

Хороший писатель не просто тот, кто грамотен. Хорошие писатели знают как донести суть. Они делают сложное — понятным. Они умеют посмотреть на вещи «непонимающим» взглядом. Они знают что лишнее. Их мысли ясны. И они те, кто вам нужен.

Светлый Разум

Умение хорошо писать — показатель того, насколько организован человек; способен ли он упорядочивать, систематизировать и подавать информацию так, чтобы другим было легче её понять. Это сказывается на коде, общении, чатах (для коллективов которые работают удаленно) и даже на таких сокровенных понятиях как профессионализм и надежность.

(— Dustin J. Mitchell, разработчик (из Signal vs. Noise[14]))

Письмо упорядочивает мысли

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

(— Michael A. Covington, профессор теории вычислительных систем Университета Джорджии (из Как правильнее писать, четче мыслить и изучать сложное просто[15]))

Примечания:

1

http://www.bartleby.com/141/strunk5.html

11

http://www.promotionworld.com/promotion/articles/findperfectva.html

12

http://www.loudthinking.com/arc/000505.html

13

http://blog.buildv1.com/

14

http://www.37signals.com/svn/archives2/hiring_tip.php

15

http://www.ai.uga.edu/mc/WriteThinkLearn_files/frame.htm