Как я подбирал людей к себе в команду

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




Решил немного структурировать свой опыт подбора персонала на свои проекты. Начну с того, что последние лет эдак шесть моя основная задача – работая в компании-подрядчике, выполнить договорные обязательства перед заказчиком. Обязательства заключаются в наличии договора на внедрение корпоративной информационной системы на платформе 1С, а для простоты – проекта. Отягчающие обстоятельства: у проекта есть сроки и бюджет. Проектов одновременно может быть несколько, с разными заказчиками и задачами – это можно назвать портфелем проектов. Получается, что для некоторых проектов я был в роли их руководителя, для некоторых, попроще – в роли куратора и руководителя отдела. В обоих случаях, инициация проекта, включая формирование команды ложилась на мои плечи. Для простоты буду называть себя во всех случаях РП.

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

  1. В корпоративных проектах 1С чаще всего задача подбора ресурсов ложится на плечи РП

  2. Правила игры на проекте зачастую определяются не столько компанией, сколько конкретным РП внутри компании. Два проекта в одной компании могут быть выполнены по совершенно разным методикам

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

  4. Команда среднестатистического корпоративного проекта в 1С – это от 5 до 10 человек. Так не всегда, но чаще всего

  5. В разных компаниях ролевая модель разная. Все сильно по разному и зависит от масштаба, сложности, роли заказчика в проекте и много чего еще. Но постепенно рынок приходит к тому, что основные роли на внутри команды проекта обязательно должны включать такие пункты:

  6. Функциональный архитектор

  7. Технический архитектор

  8. Аналитики (могут быть разного уровня)

  9. Разработчики (могут быть разного уровня)

  10. Почти в каждой компании есть HR. Почти везде функции HR сводятся к:

  11. Подбору и обзвону резюме на hh.ru

  12. Приглашению на интервью и проведении первой встречи, на которой отсеиваются точно не подходящие кандидаты

  13. В оформлении новых сотрудников

  14. Зачастую поиск людей на позиции архитекторов и аналитиков на внешнем рынке – задача с неизвестным сроком и результатом, который может превышать один и даже два месяца

  15. Поиск разработчиков сводится зачастую к обзвону подходящих кандидатов, приглашению на собеседование и решение ими тестовых задач. Тестовые задачи проверяются техлидом

  16. Как правило, у РП нет каких-то особых знаний про маркетинг или HR, потому процесс подбора кандидатов происходит исходя из общих представлений о прекрасном конкретного человека, который столкнулся с задачей


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



Стажеры


Текущий рынок таков, что обеспечить 3 интервью в день со стажерами – выполнимая задача для HR любого уровня.

Первое что нужно понимать – стажер тоже человек. Он скорее всего, мало что знает о профессии. Но от этого он не перестает быть личностью, у которой уже есть мировоззрение, сильные и слабые стороны. Моя задача – увидеть человека через 3 года. Сможет ли этот парень или девушка через год, три, пять превратиться в толкового аналитика, разработчика? Стажеры мало что знают о профессии и о себе. На вопрос «кем вы видите себя через 3 года в нашей компании» они либо соврут, либо честно нафантазируют.

Потому – спрашивать о навыках не имеет смысла. Имеет смысл давать задачи на общие компетенции. Потому, я действовал по следующему плану:

  1. Этап 1. Без моего участия.

  2. Для стажера-аналитика – приглашать на собеседование и отсеивать всех, кто не мог связать трех слов в предложение и тех, у кого нет высшего образования. Причина высшего образования проста: если даже человек дорастет до аналитика, его нельзя будет выводить на проекты без высшего образования в лидирующих ролях. Желательно, чтобы высшее образование хоть как-то затрагивало экономику или информатику.

  3. Для стажера-разработчика – приглашать на собеседование всех, кто в институте программировал. Отсеивать всех, кто на интервью сознавался в том, что пока не программировал но хочет

  4. Для всех стажеров давался КОТ-тест. Тест давался на бумаге, но есть онлайн-версия для удаленной проверки. Этот тест занимает ровно 15 минут времени и дает оценку общих способностей человека. Дальше проходили только те, у кого больше 20 баллов

  5. Этап 2. С моим участием

  6. Задача – найти время на отсев большого количества людей

  7. Собирался пул анкет – от 3 до 6. Назначалось одно время интервью.

  8. Тесты давались всем одинаковые

  9. Тест на логику. В нем задачи на общую логику. Например: как, из бочки на 5 литров налить во вторую бочку ровно 3 литра, имея ведро на 2 литра. Всего штук пять задач разной сложности

  10. Тест на алгоритмы. В нем задачи – написать алгоритм на любом языке программирования. Обычно 3 задачи разного уровня сложности

  11. Пока стажеры решали задачи, я общался с тем, кто уже закончил. На собеседование 5 человек уходило 2 часа за 1 подход

  12. Критерии оценки тестов:

  13. Аналитик

  14. Обязательно должен решить логические задачи

  15. Задачи на алгоритмы решить правильно было не обязательно, но мне обязательно увидеть, что человек хоть минимально обладает способностью к алгоритмизации

  16. При устном общении я также смотрел на внимательность в решении задач, подачу информации, гибкость мышления, спрашивал про умение работать с нотациями BPMN, IDEF0, UML.

  17. Разработчик

  18. Обязательно решить оба теста

  19. Обязательно в ходе общения – иметь опыт разработки. Я считаю так: если ты программист и тебе 20-22 года, у тебя обязательно уже пробовал делать какие-то хом-проджекты, на пятерки сдавать лабы по программированию и вот это вот все. Иначе ты на самом деле не хочешь программировать.

  20. Этап 3. Домашнее задание

  21. Для программистов решение принималось по факту собеседования. Все, кто понравился и решил тесты – можно было звать на стажировку

  22. Для аналитиков – домашнее задание заключалось в том, чтобы прислать презентацию. Давалась произвольная тема на предмет, близкий к нашей деятельности. Например, задача звучала так: подготовить презентацию в 3 слайда на тему «Основные функции систем класса CPM». Смысл был в том, что человек сможет нагуглить нужные термины и структурировать информацию в презентацию. Это покажет навыки подготовки презентации, умение работать с неопределенностью и желание продолжать. Положительное решение принималось в случае, если человек присылал презентацию и в ней я видел способность к изложению релевантной информации. Также сразу было видно, чему его учили в институте.

  23. Этап 4. Начало работы

  24. В течение 2 недель таким образом я выводил в команду от 1 до 4 новых стажеров

  25. Как правило, выводили по 2 стажера на аналитику и разработку, чтобы была возможность сравнивать успехи

  26. К каждому стажеру прикреплялся аналитик или разработчик для наставничества

  27. Максимум через месяц, мы старались давать безрисковые и не срочные задачи. Как правило, стажеру-аналитику и стажеру-разработчику давалась задача доделать что-то во внутренней системе.

  28. Через 3-4 месяца молодых отправляли на проекты в роли юных подаванов

  29. Основная установка – обеспечить за первые два года участие в не менее двух проектов от начала до завершения

  30. Результаты

  31. Сегодня эти ребята работают в роли ведущих разработчиков и аналитиков

  32. Всем меньше 26 лет

  33. У всех ребят резюме позволяет устроиться на работу в течение 3 рабочих дней

  34. Но их никто не отпускает, потому что они приносят пользу на любом проекте, даже самом кризисном

  35. Процент отсева – за первый год после приема мы прощались примерно с 2 из 6 человек



Разработчики

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

Что важно для меня:

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

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

  3. Все вопросы про стек технологий – вариативно, в зависимости от проекта. Где-то нужно было в автотесты, где-то хорошо уметь в веб-сервисы, где-то нужно было уметь быстро рисовать прототипы на основании мокапов.

  4. При всем при этом - не тратить на тестирование и интервью большое количество времени HR’a, меня, техлида.

В итоге, процесс строился так:

  1. Этап 1. Без моего участия.

  2. Давалась установка на ключевые слова для HR. Это были в зависимости от проекта, такие слова как УХ, веб-сервисы, работа с БСП

  3. По результату подбора резюме, задача HR состояла в том, чтобы кандидат до всяких предварительных встреч прошел онлайн-тест. Для этого я договорился (ну как договорился, купил) с работавшим на тот момент в бета-режиме сервисом по тестированию разработчиков. О нем ниже напишу поподробнее.

  4. В результате тестирования мы рассматривали разрабов, у которых был средний балл выше 5,5. Если балл был выше 7 – реагировали очень быстро и понимали, что это, вероятнее всего, очень интересный кандидат

  5. Этап 2. Интервью

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

  7. Долго общаться с разработчиком – лишено смысла. За первые 5 минут понятно, сработаетесь ли вы при прочих равных в виде компетенций

  8. Техлид общался с разрабом. Идеально – посмотреть на разработки, которые человек уже делал, обсудить.

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

  10. Наличие стандартов разработки внутри компании - хорошо, включается в собеседование с техлидом

  11. Результаты

  12. Поиск разработчиков - наиболее четкий процесс, за счет наличия онлайн-тестов и возможности посмотреть на код. Код либо хороший, либо нет.

  13. Поиск разработчиков обычно занимал не более 2 недель при адекватном уровне дохода со стороны компании

  14. Не было ни одного случая, когда мы ошиблись в уровне разработчика. И в его soft-skills

Про онлайн-тестирование.


Еще когда мы работали с ребятами из i-cron.ru на предмет привлечения удаленных разрабов, я узнал про сервис, который они делают. Что дает сервис – он дает средний балл на основании теоретического тестирования разработчиков. Первое что я сделал – прогнал всех своих разрабов через этот тест. Результат теста соответствовал их реальному уровню. Мидлы имели 5.5 и выше, ведущие разрабы и техлиды – от 6.5 до 7.8. Однажды я уговорил крутых ребят, которые от 1С обеспечивают на Ростехе релизы, пройти тест. В итоге мне через 10 минут позвонил Ранис, который эти тесты проверяет на своей стороне и сказал что у нас какой-то очень крутой спец прошел тест. Да, все тесты на той стороне проверяются вручную.

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

Каждому кандидату выдавался тест. Для того, чтобы застраховаться от рисков, я вводил их данные в тест в обезличенном виде. По каждому участнику получался вот такой (См. скрин) результат. Я мог при необходимости посмотреть ответы на каждый вопрос. Получилась сводная таблица с результатами.

Для меня этот тест давал экономию времени, возможность сопоставить результаты тестирования и определить сильные стороны.

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

Для меня этот тест – первый барьер, чтобы допустить человека до интервью с техлидом и потратить наше с ним время.

А для тех, у кого техлида нет (либо это HR, либо инсорс без сильного специалиста которому доверяют) – тест в принципе задает систему координат. Достаточно объективную. Так что могу сказать экспертно - штука стоящая, все рекомендую как первичный отбор разработчиков всех уровней начиная с Джуна.





Аналитики

Для моих проектов, которые были в сфере корпоративных финансов, аналитик – самая сложная позиция. Нет единых стандартов, стека технологий и вообще, единого понимания задач аналитика на рыке.

Потому задача HR сводилась к тому, чтобы по ключевым словам типа УХ, Казначейство, Бюджетирование, БИТ.Финанс – выделить вакансии и отправить мне.

Что я смотрел:

  1. Первым делом смотрел резюме. Очень часто оказывались знакомые, которые могли дать референс

  2. Проактивность человека. Тех кто хотел работать работу я определяю как правило за 5 минут встречи

  3. Навыки ИТ-аналитика. А именно:

  4. Пример ТЗ. Это могло быть что угодно – ФТ, ТЗ, КТ, ЧТЗ, аналитическая записка, отчет об обследовании. Главное, что нужно определить – способность формализовать, выявлять скрытые требования, отделать бизнес-требования от функциональных и от технических, способность донести каждый из этих видов требований

  5. Грамотность. Это отдельный важный пункт. Нельзя быть неграмотным

  6. Умение в базовую архитектуру 1С. Спустя годы работы в 1С, я утверждаю, что аналитик, который не понимает разницы между РС и РН, а также не может написать запрос в консоли и не знает что такое консоль – не имеет шансов на успех на моих проектах

  7. Умение в схемы. Нарисовать за полчаса схему в BPMN – базовый навык


Кого я точно не брал:

  1. Тех кто пришел из предметки. Профессия фин.контролера и профессия системного аналитика – разные. Вероятность успеха – 50%, время на обучение – не меньше года. Так как на проект нужно выводить готового аналитика, вывести на проект бывшего кей-юзера стремится к нулю

  2. Тех кто не соответствует уровню аналитика минимум Стандарт (см. это видео). Вообще, это видео крайне полезное для понимания функций аналитика. Рекомендую всем аналитикам для себя и HR'ам для подбора.Я теперь это видео даю посмотреть стажерам перед очным интервью.


Что могу сказать по результату


  1. Первые 5 минут - самые показательные. За 5 минут впечатление о возможности совместной работы сформировано. Оставшееся врем - продажа вакансии, определение текущего уровня компетенций и финансовых ожиданий.

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

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

  4. Самый работающий способ – растить своих аналитиков из стажеров. За 3 года вполне можно вырастить.

  5. Если нет времени ждать – нужно брать среднего аналитика за умеренные деньги, еще не словившего звездную болезнь и тренировать его на полном жизненном цикле проекта

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


Выводы

  1. Решение задачи подбора специалистов путем формализации заявки на специалиста и не-участия РП и/или тимлида, техлида - пустые надежды. Либо не найдется, либо найдется не тот человек.

  2. В отрасли 1С много компаний, которые ищут специалистов по 1С разного плана. Рынок не стандартизирован.

  3. Искать людей сложно, предложить специалистам что-то уникальное кроме уровня дохода – сложно. Нужно много думать о том, что ваша компания предлагает специалистам в части роста, комфорта, удобства, окружения.

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

  5. Многие из тех разрабов и аналитиков уходят спустя полгода-год не из-за денег, а из-за регулярной хаотичности процессов и недостатка коллег с равным или более высоким уровнем компетенций

  6. HR на рынке обычно ограничиваются поиском резюме на hh.ru. Редкие HR’ы публикуют вакансии в телеграме или ищут народ в линкдине. В линкдине в основном ищут корпорации и вот это вот все.

  7. Рекрутинговые агенства не всегда полезны, т.к. у них те же источники. Преимущества – компетенции по нетворкингу самих HR’ов, которые выуживают контакты у тех, с кем они уже общались ранее


Полезные ссылки


Просмотров: 2,248

©2020 by wangoff