воскресенье, 27 марта 2011 г.

Найм талантливого разработчика по-Спольски

Продолжаю тему найма, которая сейчас для нас актуальна.

Джоэла знают в общем-то все, представлять не буду. Это конспект его тоненькой книжки которая, конечно, не что иное как сумма записей в его блоге на тему найма программистов. Еще опишу те моменты, которые мне особенно понравились и как все эти практики и советы у нас в команде применяются.

Главная идея - действительно хороших программистов на рынке труда просто нет. У них всегда есть работа, причем интересная им самим прежде всего. Отличие хорошего программиста от простого описываются примером:

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

Общая цель при отборе - понять может ли кандидат (не удержусь от языка оригинала) get things done (доводить дело до конца) и способен ли.

Важно уметь отличать эти два качества. Примеры:

Люди которые способны, но не доводят дело до конца часто имеют ученую степень. Вместо того чтобы решить проблемы вовремя они они будут придумывать какой-то ее научный аспект. Например в день когда вам нужно выпускать бета-версию программы, они появляются в вашем офисе с кружкой кофе и пытаются начать долгий разговор о том, что же лучше - библиотеки СОМ-типов или самоанализ языка Java. Я про себя таких называют "философы". Работать с ними - сущий ад особенно когда вы работаете в одном проекте и ваша работа взаимосвязана.

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

Первое - где хороших разработчиков найти?

Следует быть осторожным с рекомендациями уже нанятых специалистов - особенно если за привлечение в компанию нового сотрудника поощряется премией. Главный совет - люди пришедшие из разных источников (рекрутеры, жертвы маркетинга и рекламы, случайные люди и рекомендованные кем-то изнутри) должныв проходить абсолютно одни и те же стадии интервью, тестов и т.п.

Конференции, мастер-классы и прочие профессиональные сообщества могут быть отличным источником. Здесь главное попасть в масштаб и специализацию (не искать PHP-разработчиков на конференции системных программистов).

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

Второе - идеальные условия работы для разработчика

Идея в том, что имея лучшие условия работы при прочих равных, люди будут выбирать вас. Собственно, условия

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

Думаю ситуации описанные выше так или иначе встречаются везде где сталкиваются время доставки и качество - т.е. где худшее техническое решение достигается за меньшее время. Мне кажется важным это учитывать.

Отличная цитата про разработчиков в инвест-банкинге (почти правда) "Чтобы удержать лучших программистов, в инвестиционных банках применяют две стратегии: платят море денег и разрешают программистам фактически свободно все переписывать на любом из новых языков программирования... А не переписать ли на Ruby то финансовое приложение? Да, что угодно, только принеси мне этот чертов чизбургер".

Программисты не должны беспокоится о деньгах. "Если вы начинаете слышать жалобы насчет зарплат там, где никогда их не слышали, то обычно это признак того, что на самом деле людям не нравится их работа". Кроме того, "предложение высоких зарплат будет на удивление неэффективным инструментом в решении таких проблем, как, например, то, что программистам выдают 15-дюймовые мониторы, что на них все время вопят продавцы и что работа ведет к созданию атомного ружья на детенышей тюленей". Важна мысль что, ЗП не должна быть ниже среднего по рынку - потому что как только она такой становится - тогда никого уже не удержать ничем. Но при равной ЗП в ход идет все "мелкое и приятное" что имеется у нас в арсенале и не обязательно при этом ее (ЗП) сильно задирать.

Дальше Джоэл нахваливал свой "бионический офис" - тут только "wow!" можно сказать.

Третье. Собеседование по-Спольски

Общая идеология - лучше не нанять хорошего чем нанять плохого (у нас эту проблему решает испытательный срок). Итак:

  • потратив на собеседования меньше часа вы не примете правильного решения;
  • не можете ничего сказать о кандидате после интерьвю - значит не нанимать;
  • что-то смущает - не нанимать;
  • хороший признак способного кандидата - вам не приходится что-то повторно объяснять;
  • важно не свести собеседование к опросу тривиальных фактов о программировании которые можно нагуглить за 15 секунд;
  • скорость с которой кандидат решает задачу так же важна как и решение;
  • не задавайте головоломных вопросов (как из 6-ти спичек построить четыре одинаковых правильных треугольника). Это вопросы из разряда "Ага!" т.е. ответ на них вам либо известен либо нет.


пятница, 25 марта 2011 г.

Новый проект - новая команда. Какая она?

При поиске нового места работы важна компания, предметная область, компенсация, перспективы и все такое. Мне же кажется что после компании как таковой на второе место по важности в выборе нового места работы выходит команда и продукт который она делает. Чем больше компания, тем больше внутри нее команд - как следствие корреляция между компанией и успехом/неудачей конкретных разработчиков в ней исчезает. Ну за редкими исключениями, когда компания сама по себе гарантирует интересный и реальный проект (ну-у-у кроме: раз два три). В остальных же случаях мне кажется очень важным распознать проект / продукт / команду в которой открыта вакансия.

Итак, когда в команде открываются вакансии?

1. Команда расширяется революционно

При численности N набирает A ~ N сотрудников. Выделится среди коллег легко, что больше больше подходит для самостоятельных и проактивных личностей.
Если используемые технологии вам знакомы - то все карты в вам руки, так как времени заниматься вами особо ни у кого не будет. А если последовательно начнете выполнять задачи (причем даже в том ключе который нравится вам, а не тот который принят в команде) - потом может оказаться что ваш подход имеет наибольшее покрытие в коде. Таким образом вы закроете своей экспертизой большой кусок функциональности - а это всегда очень ценится.
Если технологии незнакомы - то либо вы их срочно изучаете в процессе работы (и тогда см. выше), либо долго вы там не продержитесь потому что быстро окажетесь в аутсайдерах среди новичков.





2. Команда расширяется итерационно

При численности N набирает A < < N новых специалистов. Грубо говоря вы будете одним из немногих (если не единственным) новичком. Это значит что на первых порах команда сможет уделять вам достаточно много времени чтобы обучить и поделится опытом / технологиями / традициями / лучшими практиками. Так у вас всегда будет более опытный коллега который подстрахует в случае чего - то есть ваш уровень ответственности будет невысок. Идеальное место для изучения новых технологий и/или предметной области.
В то же время выделится будет очень непросто на фоне более опытных коллег и для этого нужно будет серьезно поработать - возможно лучшим вариантом было бы найти пробел в какой-нибудь области и начать его устранять собственными силами.


3. Команда стагнирует


Численность постоянна N = N. Вы претендуете как замена ушедшего [на повышение?] члена команды. Здесь важно знать контекст.
Если команда / продукт достаточно старые и уже прошли стадию "дойной коровы" - то скорее всего она сейчас находится в состоянии, когда хорошие спецы из нее уходят. При этом поддержка все равно нужна - как следствие набираются смена. В долгосрочной перспективе - уровень экспертизы в команде падает, звезды даже если в команду и попадают - достаточно быстро ее покидают ибо стагнирующий проект им не интересен. В общем, надо быть осторожным.
Возможен конечно вариант когда участник команду ушел на повышение/уволился - а проект вполне себе перспективный. Наверное, первое от второго можно отличить вопросом "сколько лет проекту?" Возможно, вполне честно ответят на вопрос "какие дальнейшие шаги по развитию проекта?". Идеальным вариантом было бы иметь инсайдера, который сможет рассказать историю проекта с самого начала.


4. Команда регрессирует

При начальной численности N, какое-то количество специалистов уходит, новый же размер команды M <>
Ну регресс понятен - это сжатие размеров проекта - как следствие увеличение доли поддержки в общем объеме работ. Если же ушедшим был тим лид - еще и деградация (по-крайней мере на первое время) руководящей / лидирующей функции. Сложно сказать что привлекательного в такой команде кроме разве что достаточно спокойной жизни - никаких серьезных встрясок во взрослом/старом проекте не будет.