Getting Real

Персонал

Нанимайте меньше. Нанимайте позже

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

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

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

Каждый раз когда 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])

Не по словам, а по делам

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

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

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

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

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

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

воззрения

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