{"id":14289,"url":"\/distributions\/14289\/click?bit=1&hash=892464fe46102746d8d05914a41d0a54b0756f476a912469a2c12e8168d8a933","title":"\u041e\u0434\u0438\u043d \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u043b \u043f\u0440\u043e\u0434\u0430\u0436\u0438 \u043d\u0430 5%, \u0430 \u0441\u0440\u0435\u0434\u043d\u0438\u0439 \u0447\u0435\u043a \u2014 \u043d\u0430 20%","buttonText":"","imageUuid":""}

«Нам нужен сотрудник!» Как компании выстроить найм. Осторожно - лонгрид

Как выстроить найм в компании?

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

Для начала проясним базовые вещи. В зависимости от размера и целей компании, её потребности в HR процессах будут отличаться. В этом случае важно сохранять адекватность и объективность: если вы молодой стартап, которому для работы объективно необходимо до 10 человек, то раздутие штата в погоне за «скоростью» может обернуться для вас тем, что большая часть людей будет сидеть без работы, но получать зарплату и тем самым вредить производству. Перед каждым наймом задайте себе и нанимающему менеджеру вопрос: «А для чего нам этот сотрудник и что будет, если мы сейчас никого не наймем». В идеале, для каждого нанимаемого сотрудника у вас должен быть готов список задач еще на этапе сбора заявки. И задач не на 1-2 недели, а структурированный и понятный план того, чем человек будет заниматься на продолжительной основе. Если вам нужно закрыть одну две задачки - наймите фрилансера и не раздувайте ФОТ(фонд оплаты труда).

Так вот, пойдем разбирать на примерах:

«Компания А»

Мы начинали работать с этой компанией на этапе, когда команда состояла из 4 человек. Ребята занимались тем, что начали продвигать купленное «коробочное» решение из мира азартных игр. По сути, команда выглядела следующим образом: Owner (он же главный инвестор), Media Buyer, Менеджер службы поддержки и «человек оркестр» - занимается всем, чем может быть полезен.

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

Большим плюсом проекта было то, что ребята не первый день знакомы со сферой и знают, как должны работать подобные площадки.

Несмотря на то, что, повторюсь, вопрос о разработке не стоял, первично команду необходимо было пополнить:

  • Product Manager. Необходимо было проработать специфику продвижения и развития продукта. Переработать некоторые визуальные моменты площадок и грамотно выстроить систему опорных метрик, по которым можно было бы следить за динамикой продукта и вовремя отслеживать слабые места
  • Google Media Buyer. Основная ставка была сделана на привлечение трафика по средствам его закупки. Кто знает, тот знает, и сейчас я не буду вдаваться в подробности этой специальности.
  • Специалисты службы поддержки. Очень важно, чтобы все спорные ситуации решались сразу же внутри площадки и не выходили за ее пределы. Поэтому саппорту было уделено большое внимание, чтобы пользователь мог сразу сообщить об ошибке или обсудить спорную ситуацию

Перед тем, как вы собираетесь нанять человека, вам нужно определиться, кто за него будет отвечать. Не просто руководить и говорить что ему делать, а именно отвечать за его работу.

С этого мы и начали. Масштабирование команды стартовало с разделения её на отделы и распределения зон ответственности.

Каждому отделу был назначен «руководитель» - ответственное лицо, которое отвечает за все результаты отдела. В этом случае они и стали нанимающими менеджерами.

Далее мы составили «Планы найма» для каждого отдела, исходя из которых уже приступали к поиску сотрудников.

План найма - прогнозируемый и обоснованный план, включающий в себя перечень позиций, которые компания планирует ввести/обновить и бюджет, который компания готова на это выделить. Согласовывается на основе ФОТ и актуальных кадровых проблем. Составляется совместно с лидами направлений, HR и Бизнесом

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

Кто нам нужен мы поняли, время нанимать

На следующем этапе мы начали выстраивать процессы рекрутинга. Так как всем наймом на проекте изначально занимаемся мы, то в данном случае мы просто выстроили конкретную процедуру:

  • Подача и сбор заявки
  • Предоставление кандидатов
  • Первичное интервьюирование
  • Согласование технических собеседований
  • Интервью с нанимающим менеджером
  • Опциональное тестовое задание
  • Оффер лучшему кандидату

2 пункт, в зависимости от пожеланий нанимающего руководителя, может отсутствовать, но в данном случае руководители пожелали видеть весь поток кандидатов и самостоятельно отсматривать резюме.

Для отслеживания процессов найма мы рекомендуем создать собственную базу резюме либо интегрировать готовые системы автоматизации рекрутинга, которые позволят прозрачно и понятно вести найм. Дабы не делать бесплатную рекламу (ведь компаниям так важно засветиться в статье на 300 просмотров) название подобных указывать не буду. Но мы чаще всего используем Хантфлоу :)

Нанять то наняли, а дальше что?

Что делать после найма сотрудника?

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

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

Вся эта информация позволит новому сотруднику самостоятельно познакомиться с компанией и сэкономит вам время, если найм будет большим. Если в месяц у вас закрывается 1-2 вакансии или того меньше, то это дополнительно решение, но никак не лишнее. В конце концов, каждый раз актуализируя её, вы сами сможете дополнительно отслеживать результаты компании :)

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

Резюмируя конкретно этот кэйс:

  • План найма - важный инструмент при масштабировании компании
  • Четкое распределение зон ответственности. Без этого невозможно выстраивать работу отделов
  • Процедура найма. Понятная и прозрачная с интеграцией базы данных кандидатов
  • Онбординг новых сотрудников

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

Конкретным итогом работы на этом проекте стало: найм Product Manger(срок найма - 2 недели), найм 2 Google Media Buyer (общий срок найма - 1 месяц), 3 специалиста службы поддержки (общий срок найма - 3 недели), найм внутреннего HR специалиста(срок найма - 2 недели), создание корпоративного портала для онбодинга, прописанный регламент найма.

«Компания Б»

Вот это по истине сложный и интересный кейс из категории «я люблю и ненавижу»

Заказчиком в нем выступил инвестор, с которым мы ранее работали на другом проекте. И задача звучала следующим образом:

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

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

Отсюда следует, что первостепенно нам нужно найти человека, который будет все это строить. Здесь нет готового продукта, так что разработка будет вестись с нуля, значит нужен человек с опытом управления командами разработки. Но и про продуктовую концепцию забывать не стоит. Отсюда просится вывод, что нам нужны Product Owner и Project Manager. Но косты на старте проекта переваливающие за 500к деревянных в месяц только на управление мало возбуждали как нас, так и заказчика. Благо Российский IT рынок разделяет наше стремление экономить и специалистов, которые умеют и в Product и в Project вполне себе хватает (я уже прям предвижу комментарии в духе «вам бы лишь бы сэкономить»)

Соответсвенно первоначально мы начали поиск на позицию Product/Project Owner (дальше буду называть его «Руководитель»)

Поиски заняли 1,5 недели и после «технического» этапа с заказчиком человеку был сделан оффер, а уже через 2 дня мы приступили к работе по планированию команды.

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

Далее вернемся к HR процессам.

Посовещавшись с Руководителем и заказчиком было принято решение изначально разделить команды разработки, а не надеяться на Fullstack разработчиков. Поэтому мы нанимали отдельно Frontend и Backend девелоперов.

Дальше уже по знакомой нам процедуре:

  • Подача и сбор заявки на подбор
  • Первичное интервьюирование
  • Представление кандидатов
  • Согласование технических этапов
  • Оффер кандидатам

Повторюсь, одним из требований к поиску сотрудников был найм людей с опытом на аналогичных проектах, поэтому «тестовое задание» или «лайфкодинг» как этап отсутствовали (ну и комментарий «давайте тестить в бою» давал понимание, что заморачиваться с ТЗ никто не будет)

Собрав команду из: 1 UI/UX Дизайнера, 1 Frontend Dev, 1 Backend Dev и Product/Project Manager наша работа до поры до времени свелась к минимальному участию на проекте и контролю выплат зарплат (по желанию заказчика, не то что мы навязались с чужими деньгами дело иметь). По прошествию времени было принято решение по увеличению команды, так как MVP продукта было запущено и настало время команду масштабировать.

Резюмируя конкретно этот кейс: острой необходимости в построении сложных HR процессов до недавнего времени у проекта не было, поэтому усложнять все ненужными процедурами не было необходимости. Мы применили сюда стандартные процедуры найма и даже до определенного момента не создавали Wiki.

Так все таки, как компании подойти к вопросу найма сотрудников. Отвечаю - ответственно.

Шутка конечно же, вот вам чекист поподробнее:

  • Первое с чего нужно начать, это определиться, под какие задачи вам нужны сотрудники. И формулировка «Ну, нам надо увеличить прибыль» здесь не подходит от слова совсем. Под такой запрос вы сможете найти человека, но это либо будет просто стоить очень дорого (если вам повезет), либо очень дорого и бесполезно.
  • Второе. Попытайтесь спрогнозировать найм на будущее. Не забывайте про окупаемость сотрудников и не раскидывайте задачи на миллион новых сотрудников. Каждый нанимаемы сотрудник должен быть на пользу компании, а не чтобы заткнуть маленькую дырочку
  • Третье. Структурируйте и пропишите систему найму. Как базовый шаблон можно использовать ту процедуру, о которой я писал в статье. Вы можете сделать это либо самостоятельно, либо наняв себе человека. А о том, кто вам может в этом помочь я писал в этой статье (приложить ссылку на статью)
  • Четвертое. Уделите время онбордингу. Чем быстрее человек погрузится в проект, тем быстрее он станет для него полезным

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

О чем рассказать в следующий раз?
Я устал, я мухожук: как говорить с руководителем об увольнении?
Синдром самозванца в работе и как с ним бороться
Делегирование: не хочу или не успеваю делать сам
Показать результаты
Переголосовать
Проголосовать

YPA TECH | NEWS - Новости из IT. Каждый день мы подбираем для вас интересные новости из мира IT и все это разбавляем смешными (или не очень) мемами

Рекрутер КОТорый | YPA BLOG - Мой личный блог, в котором я делюсь личными соображениями о работе и полезными материалами на тему

0
4 комментария
Alexxx1ndr

Ждем статью про делегирование

Ответить
Развернуть ветку
Татьяна Столярова

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

Ответить
Развернуть ветку
Владислав Санников x YPA
Автор

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

Ответить
Развернуть ветку
Антон

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

Ответить
Развернуть ветку
1 комментарий
Раскрывать всегда