1
5.0

Оцінити

Статті читати 3 хв. 5.0 1 голос 99

Виправляємо помилки при пошуку джуна

Очікування техліда

Давайте розберемося, хто створює описи вакансій. Їх створюють техліди. Основна проблема в тому, що кожен техлід хоче бачити в претендентові самого себе. Тобто бере свій досвід, віднімає від нього 5-6 років, бере свій багаж технологій, віднімає від нього те, що за ці 5-6 років абсолютно застаріло, і вуаля — готові вимоги до кандидата.

Виходить нереалістичний портрет: перспективний джун з досвідом роботи не менше 10-12 років, зі знанням PHP, JavaScript, .NET, Python і з бажанням вивчити GoLang. Після цього додається англійська, знання процесів і методологій гнучкої розробки. І як вишенька на торті — «великим плюсом буде» — досвід роботи з BigData, досвід у створенні нейронних мереж тощо. Так вимальовується пунктиром портрет вашого техліда, помолоділого на 5 років і не обтяженого знаннями COM, VisualBasic і WinForms.

Коли рекрутер отримує таку заявку, можна припустити, що волосся у нього на голові стає дибки. Тому що, якщо і є така людина, то це — Толік з R & D, який склав опис вимог і який вже працює у нас.

Потім рекрутер біжить до проектного менеджера, до якого майбутній джун піде працювати. І менеджер впевнено заявляє рекрутерам: «Такі люди є, і їх багато, ви просто погано шукаєте».

Зростає напруга в команді

Тепер ми перескочемо на два-три місяці вперед. Пошук кандидатів не приніс бажаних результатів. Проектний менеджер тисне на рекрутерів, бо вони погано шукають. Всім рекрутинговим агентствам були обіцяні великі бонуси. Техлід, який склав вакансію, розповідає, що в його час і народ був тямущим, і дерева вищими. А проектна команда або овертайміть, або ставить багато проектних активностей на паузу.

У будь-якому випадку замовник втрачає гроші, якість продукту страждає, а також зростає напруга в команді. У проектного менеджера з рекрутерами, у команди — з овертаймами, у рекрутерів — від техліда до кандидатів, які кожен раз не підходять за критеріями.

Що потрібно зробити?

Треба розбиратися, що ми робимо не так. Як можна вийти з глухого кута, не вигідного нікому. У цій ситуації всі знаходяться у програші: перспективний кандидат не може знайти роботу, розробники не можуть задовольнити всіх потреб замовника, команда не може нормально функціонувати, тому що у її членів абсолютно немає часу. Звичайно, можна піти шляхом «сильних» людей і звинувачувати в своїх нещастях когось третього або списати все на кон'юнктуру ринку, але ми не будемо так робити і розберемося, що команда робить не так.

У мене є одне правило:

Якщо кожен наступний етап роботи вимагає на порядок більше зусиль, потрібно зупинитися і спробувати зрозуміти, що все-таки йде не так.

Може справа не в обставинах, а в мені? Може спочатку, щось було зроблено невірно?

Виправляємо помилки

  1. Потрібно описувати не того, кого хочеться найняти, а обов'язки, які виконуватиме той чи інший працівник. Якщо нам потрібен формоштампувач, то не варто писати у вимогах «великим плюсом буде знання теорії нейронних мереж». Ні, я не пропоную знизити планку. Але планка проходу повинна бути знижена до прийнятної величини, і задирати її не має сенсу — можна втратити дуже хороших перспективних кандидатів.
  2. Необхідно організувати розмову між проектним менеджером і техлідом. Техлід повинен усвідомити, що якщо не буде нового джуна, то йому доведеться робити все самому. І сам він не встигне зробити всього наміченого, тому що у нього є сім'я або особисте життя, хобі та плани на відпустку. Так, він може описати свого ідеального кандидата. І рекрутери можуть паралельно з низьким пріоритетом шукати цього супермена. Але покладатися на таку позицію не можна ні в якому разі, так як її закриття — справа випадку. А все, що пов'язано з випадковостями, а не чітким процесом, нам у бізнесі не підходить.
  3. Необхідно поговорити з рекрутерами. Може, шукають не за тими критеріями? Може, варто показати пару-трійку сторінок LinkedIn, які за всіма параметрами підходять під вимоги? Може, варто розповісти, кого ще ми можемо розглянути, щоб розширити поле пошуку. Розробникам потрібно усвідомити, що IT-рекрутери, які б розумні вони не були, не володіють тим бекграундом, який дозволив би їм розставити допуски в пошуку кандидата.
  4. Необхідно мислити стратегічно. Може, варто взяти кандидата на виріст? Може, комусь варто дати шанс? У деяких випадках можна піти на мінімальний ризик. Якщо ви бачите, що людина адекватна, їй цікавий ваш проект і вона сповнена бажання працювати, то чому б і ні. Спробуйте, принаймні, у вас завжди є в запасі випробувальний термін. Так цим не варто зловживати, але і нехтувати цією можливістю теж не варто.

Висновки:

  • Завжди треба виходити з посадових обов'язків людини, а не з завищених очікувань, інакше справа затягнеться на невизначений термін.
  • Не можна виставляти завищені вимоги. Вони повинні бути складені на основі тих посадових вимог, які ви пред'являєте до кандидата.
  • Не бійтеся давати адекватним людям шанс. Спробуйте брати людей на виріст.
  • Намагайтеся дивитися на світ реально і не намагайтеся воювати з навколишньою реальністю, тому що саме вона визначає ваше буття.

Схожі матеріали

Подпишитесь на рассылку
Компьютерной школы Hillel

Ви отримаєте:

  • Інформацію про корисні галузеві заходи
  • Цікаві статті IT-сфери
  • Новини Комп'ютерної школи Hillel