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

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

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

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

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