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

У такой модели есть свои (очевидные) плюсы: проектный менеджер работает с человеком каждый день и хорошо понимает загрузку, мотивацию, настроение человека; человек ассоциирует себя с проектом заказчика и на 100% вовлечен.

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

Какой бы большой и продуктивной ни была рекрутинговая команда, клиенту обычно нужно 50 человек и «на вчера», потому что у него уже горят сроки, а отдел закупок не давал «добро» на тендер уже три месяца подряд, и теперь совсем пожар. А 50 человек с рынка на вчера – сложно.

Во-вторых, в проектной организации сложно найти людей для внутренних проектов и развития технологической экспертизы. Менеджеры экспертных направлений всегда знают, какой фреймворк нужно посмотреть, какой proof of concept написать, какую архитектуру попробовать, чтобы потом проще было получить новый проект, продемонстрировать наработки и, главное, писать более качественное ПО. Но где найти технических специалистов для реализации этих задач?

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

Приняв такое решение, нужно было ответить на несколько вопросов и развеять несколько мифов. Давайте рассмотрим их подробнее.

Миф 1. Неясно, кто и в каком количестве нам нужен

Разумеется, это в первую очередь определяется бюджетом. Также нужно построить процесс прогнозирования спроса на следующие 2–3 месяца, и это очень нетривиальная задача. Наш первый опыт был не очень удачным: у нас был большой спрос на Java, и мы решили, что нужно найти и привлечь для начала несколько Java-разработчиков на «пул». К тому моменту, как мы их отобрали и вывели в компанию, ситуация поменялась. Java уже был меньше нужен, зато критично не хватало .NET-разработчиков. 🙂

Мы выделили людей, ответственных за технологические направления (Java, .NET, embedded C, и так далее) – Technology Manager (TM) – и поставили каждому из них задачу разобраться с тем, на какие проекты нужны специалисты по их технологии, и также научиться собирать sale forecast по своим трекам. Тут нужно отметить, что роль TM-а мы дали senior project manager-ам и некоторым ENGINEering director-ам в дополнение к их основной загрузке. Мы не брали для этого новичков или junior manager-s, потому что нужно было строить процесс с нуля, и вначале было непонятно как.

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

Миф 2. Люди не захотят идти на «пул»

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

Здесь наша стратегия была простой. Мы предлагаем сотрудничество не в рамках конкретного проекта, а сотрудничество с компанией GlobalLogic. В качестве гарантии того, что мы можем предложить инженеру интересные задачи и достойную компенсацию, выступает бренд GlobalLogic – крупной и стабильной организации, а также те проекты, которые уже у нас есть. Мы работаем только со сложными R&D-задачами, и каждому из потенциальных кандидатов мы рассказывали про набор проектов на «его» технологии, который у нас уже имеется. Обычно описания двух-трех проектов было достаточно, чтобы человек составил впечатление о сложности задач и интересности проектов. Также мы обещаем, что человек будет иметь право отказа от предложенной позиции, если она не будет ему интересна.

Единственное условие – на «пуле» нельзя сидеть без дела, нужно либо учиться, либо помогать другим проектам, либо принимать участие во внутренних разработках (обычно это Proof of Concepts с использованием новых технологий, таких как data science, machine learning, automotive и т. д.).

И, «о, чудо»: оказалось, что люди готовы идти в компанию без привязки к конкретному проекту. Этот миф мы развеяли очень быстро.

Миф 3. Если вдруг новых проектов не будет, люди будут сидеть на «пуле» долго

Тут нам на помощь пришла статистика. Опытным путем мы определили, что среднее время ожидания на «пуле» – всего 26 дней. То есть нам достаточно всего одного месяца, чтобы найти подходящий проект каждому специалисту, которого мы изначально брали на «пул». Даже с учетом того, что люди могут отказываться от изначального предложения и пересмотреть несколько проектов до того, как окончательно определятся. Меньше чем один месяц, Карл! Зачастую поиски хороших инженеров и ожидание их выхода на проект занимает не меньше двух месяцев. В нашем случае выигрывает и инженер, и компания.

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

Итоги

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

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

Однако, мы не останавливаемся и хотим усовершенствовать еще несколько элементов:

  • Добавить программу обучения интернов (специалистов без опыта коммерческой разработки ПО) в программу предиктивного поиска технических специалистов. Поручить интернов technology manager’ам и развивать согласно потребностям компании и рынка, а не отдельных проектов.
  • Нанять выделенных technology managers на особо активные направления.
  • Унифицировать критерии для технических специалистов на каждый трек (составить чек-лист требований, в случае соответствия которому технического специалиста могут брать на любой проект без дополнительных интервью).

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

Делитесь своим успешным и провальным опытом поиска специалистов или нахождения на «пуле» в комментариях, мы используем ваш опыт для улучшения программы. Также буду рада, если наш опыт будет полезен вам.

А если вам интересно присоединиться к нашей команде в качестве Technology Manager, то описание открытых позиций вы найдете здесь и здесь.

Юлия Дубовая,
Vice President, Engineering,
GlobalLogic