В ходе анализа может выявиться недостаточность ресурсов любого типа – властных, человеческих или инфраструктурных. Тем не менее искать дополнительно имеет смысл только человеческие ресурсы. Дополнительные властные ресурсы на этом этапе просто нечем привлекать: все обещания о чудесном продукте, который получится в результате, уже даны и привели именно к текущему раскладу стейкхолдеров. Чтобы этот расклад изменить, необходимо новое содержание, получить которое можно только в ходе реализации проекта. Дополнительные инфраструктурные ресурсы на данном этапе привлекать незачем: реально они понадобятся только на этапе разработки и только конкретной команде проекта, которая еще не создана.
Другое дело – человеческие ресурсы. Если в проекте до сих пор не закрыты ключевые вакансии (например, главного конструктора/архитектора/инженера), это означает, что команды проекта еще нет, а значит, двигаться дальше попросту невозможно. Человеческие ресурсы намного сложнее инфраструктурных, поэтому их привлечение занимает значительно больше времени (докупить недостающий стол и компьютер можно в течение дня, а на поиск нового разработчика могут потребоваться недели или даже месяцы). Вот почему искать дополнительные человеческие ресурсы необходимо уже на самой первой стадии проекта.
Стандартным и в целом работающим способом привлечения человеческих ресурсов является наём новых сотрудников. Первый метод, позволяющий успешно решить эту задачу, – назначение индикативных зарплат.
Как и на всех остальных рынках, цены на специалистов на рынке труда сравниваются по самым распространенным специальностям – менее распространенные есть не во всяком проекте. Самые распространенные специальности, как правило, не требуют высокой квалификации и низко оплачиваются.
При публикации вакансий для низкооплачиваемых (по сравнению с топ-специалистами, конечно) должностей указываются ставки выше рынка. По остальным вакансиям ставки не указываются.
Результат. Создается обоснованное впечатление, что все зарплаты в проекте выше рыночных.
Помимо сложности, человеческие ресурсы отличаются еще и субъектностью. Компьютеры, когда не глючат, всегда работают одинаково, а человек – в зависимости от настроения. Производительность мотивированного и прокрастинирующего разработчика (одного и того же!) различается на порядок (если не на два). Поэтому при найме новых сотрудников принципиально важно с первого же контакта сформировать у них позитивное отношение к проекту: «Меня здесь ценят, от меня ждут хорошей работы, и мне хочется ее сделать». Нанимать даже хорошего специалиста с позицией «перекантуюсь тут месяца три, а потом уйду на настоящую работу» – серьезная ошибка (чем лучше специалист, тем более важную роль он будет играть в проекте и тем дольше ему придется искать замену).
Таким образом, если в ходе собеседования кандидату стало понятно, что он не очень-то и подходит (например, в конце ему было сказано: «Мы подумаем, и если что – с вами свяжемся», – то есть «сейчас вы нам не подходите»), то нет смысла обращаться к нему еще раз. Повторное обращение к «отбракованному» на собеседовании кандидату – не только слабая переговорная позиция (не ему от вас что-то нужно, а вам от него), но и гарантированная демотивация будущего сотрудника («На самом деле я им не подхожу, уволят при первой возможности»). Конечно, в безвыходной ситуации можно делать и так, но лучше вообще не оказываться в безвыходной ситуации. Поэтому наем новых сотрудников в DaShe регламентируется специальным методом.
Задача подбора оптимального кандидата без возможности вернуться к уже отвергнутым кандидатам хорошо формализуется и математически представлена как задача о «разборчивой невесте». В оригинале невеста выбирает из N женихов, а если точнее, из N запечатанных конвертов, в которые вложены записки с суммой состояния каждого жениха. Вскрыв конверт, можно либо согласиться на брак, либо отказать навсегда. Оптимальное решение следующее: вскрыть и отказать независимо от сумм первым кандидатам (где 2,718… – это математическая константа, иррациональное и трансцендентное число е), после чего согласиться на первый же вариант, превосходящий уже отсмотренные.
Применительно к найму сотрудников это решение выглядит так:
1. Определяется предельное время, которое ПМ может потратить на подбор кандидатов (например, месяц). Делится на 2,718, и в итоге получается время на «вхождение в тему» ( = 11 дней).
2. Оценивается производительность ПМ (число собеседований в день, например шесть), рассчитывается общее число «калибровочных» собеседований и рабочих собеседований (66 и 114), делится на количество вакансий (например, три). Получается количество собеседований на вакансию (22 и 38).
3. Составляются (запросом к профильным сервисам или через объявления) списки кандидатов на каждую вакансию. Если по какой-то вакансии кандидатов меньше, чем планировалось, то плановые значения других вакансий пропорционально увеличиваются.
4. В один день проводятся собеседования только на какую-то одну вакансию. Независимо от оценки ПМ каждое собеседование завершается таким образом, чтобы у кандидата возникла положительная мотивация («меня ждут, хочу скорее приступить к работе»). Все кандидаты, кроме принятых, уведомляются об отказе на следующий день.
5. По результатам калибровочных собеседований отсеиваются все кандидаты. Исключения: 1) кандидат, которого нельзя упустить (квалифицированный, мотивированный и идеально вписывающийся в уже собранную команду); 2) в случае длительного проекта (больше шести месяцев) – кандидат с высоким IQ (> 135). Впрочем, такие исключения встречаются крайне редко, хорошо если в одном из десяти проектов.
6. По результатам основных собеседований отсеиваются все кандидаты, кроме того, кто оказался лучше всех из калибровочной выборки и из сегодняшней группы. Если такой кандидат обнаружился, ему звонят сразу после подведения итогов: «Когда вы сможете выйти на работу?»
7. В случае если ни один из кандидатов не оказался лучше калибровочной выборки, принимается лучший из последней группы. Разбивка кандидатов на группы производится именно для уменьшения риска неудачного распределения: если бы собеседования велись по одному, пришлось бы брать одного последнего, а так остается выбор хотя бы из шести человек.
Результат. Максимальная вероятность не упустить лучшего из кандидатов.
Метод «Разборчивая невеста» обеспечивает максимальную вероятность подбора наилучшего кандидата, но лишь при условии, что сам ПМ способен отличить хорошего кандидата от плохого. Поскольку общепринятые методики собеседований создаются в крупных компаниях, не испытывающих дефицита в квалифицированных работниках, а, напротив, сталкивающихся с огромным потоком кандидатов, бóльшая часть методик направлена не на выбор лучшего, а на отбраковку всех неподходящих. В случае проекта ситуация диаметрально противоположна: разработчиков у вас нет, а кандидатов – мало. Отсеяв всех кандидатов (кого за неопрятный внешний вид, а кого за неспособность справиться с красно-черным деревом), вы автоматически завершите проект: его некому будет делать. Поэтому в DaShe предусмотрен специальный метод для проведения собеседований.
Основная цель собеседования – привлечь квалифицированного и мотивированного разработчика, способного хорошо интегрироваться в команду. Квалификация и личные особенности в ходе собеседования не меняются, а вот мотивация может быть как создана, так и полностью убита. Собеседование в DaShe – начало совместной работы, а не отсев придурков, набежавших по объявлению. Поэтому независимо от текущих впечатлений от кандидата ПМ должен мотивировать его на будущую работу и на коммуникации с ним самим. ПМ очень важно с первых же минут собеседования показать, что у него всегда есть время на разработчиков, и к нему можно и нужно обращаться по любым, даже личным вопросам. Для этого при проведении собеседований ПМ руководствуется следующими правилами.
1. Вежливость и уважение. Будущему разработчику должно быть приятно общаться с ПМ – что впоследствии перерастет в «приятно общаться по поводу проекта» и в «приятно делать проект в такой компании».
2. Заинтересованность. Полезно узнать о кандидате какой-нибудь факт, не относящийся к его профессиональной деятельности, и упомянуть его в разговоре. Это покажет, что: 1) кандидат интересен ПМ как личность; 2) ПМ располагает временем и желанием обсуждать отвлеченные темы, а значит, к нему можно обращаться с личными вопросами.
3. Благожелательность. Каждый раз, когда в ходе собеседования возникает повод похвалить кандидата или выразить положительную эмоцию по поводу его слов или действий, это нужно делать.
4. Особое внимание общему интеллекту. Профессиональная квалификация – это владение неким набором компетенций. Высокий интеллект (IQ > 135) – это способность быстро освоить любую требуемую компетенцию. В ходе проекта требуемые от разработчиков компетенции меняются очень часто («а давайте попробуем ХХХ»), поэтому любой фиксированный набор компетенций окажется недостаточным, и разработчика с низким IQ придется менять. Для проектов продолжительностью от одного года и более интеллект становится единственным критерием, исходные компетенции попросту несущественны.
Общий принцип: собеседование – это первый рабочий день кандидата в проекте, а не соревнование «кто лучше споет песенку».
Результат. Кандидат, который будет нанят в проект, будет нанят уже мотивированным.
Решение о найме того или иного кандидата принимается только после завершения всех собеседований в текущий день и только после анализа, насколько кандидат может быть втянут в потенциальные конфликты (для чего следует обновить таблицу конфликтов, сопоставив профиль кандидата с профилями всех уже выявленных аффилянтов). Принимать решение в ходе самого собеседования нельзя, поскольку в это время внимание ПМ сфокусировано на задаче мотивации потенциального разработчика, а не на отбраковке.
Хотя наем разработчиков через собеседования может показаться довольно трудоемким, настоящие проблемы возникают у ПМ, когда в проект требуются разработчики с редкими или уникальными компетенциями (те, за которыми, собственно, и охотятся пресловутые хедхантеры). Единственный способ привлечь в проект настоящих профи – это личные контакты. Поэтому частью профессиональной квалификации ПМ является поддержание большого числа социальных контактов, распределенных по сферам проведения досуга, где чаще всего встречаются квалифицированные разработчики. Наиболее популярные сферы: искусство, эзотерика и магия, игры (компьютерные и интеллектуальные), вечеринки, здоровый образ жизни (массовый спорт).
Чем сложнее и уникальнее управляемые ПМ проекты, тем больше своего рабочего времени он должен тратить на участие в соответствующих сообществах. В случае если личные связи ПМ не позволяют подбирать соответствующих специалистов, эту задачу приходится перекладывать на стейкхолдеров или уже найденных разработчиков, что влечет за собой увеличение политических рисков.