Напишіть нам
Є думка, що рекрутери — істоти гуманітарні, з утворенням філолога/психолога та не дуже логічним складом розуму. Проте робота рекрутера, крім щирого інтересу до людей, має чіткий алгоритм дій. Іноді у нас теж горять дедлайни, клієнти приходять з проєктами “на вчора” та “раптово”, а робота – ітераційна. Десь про це вже чули? Так “ми ж у ІТ” (с)
Ми в Індіго зіткнулися з такими проблемами:
- як міряти свою ефективність та робити наочним процес роботи?
- як ділитися з командою прогресом, не витрачаючи часу на щоденні звіти?
- як налагодити взаємодію сейлз-рекрутер?
І щоб не винаходити велосипед, ми звернулися до ІТшників. Хочемо поділитися, як ми розв`язуємо наболілі питання за допомогою інструментів, які знає кожен програміст.
Естімейт проєкту
Минулого року наша команда зросла: з'явилися бізнес Ксю і тим-лід, тобто я. Ролі були незвичні, іноді інформація від клієнта губилася між мною, Ксю і рекрутером, зона відповідальності кожного була розмитою. Крім того, що ми прописали чіткі ролі для кожного учасника цієї взаємодії, ми вивели формулу естімейту нових проєктів. По ній ми приймаємо рішення, брати проєкт у роботу, чи ні, і який рекрутер над ним працюватиме.
Відповідальний рекрутер
- Скільки у роботі проєктів
- Кількість проєктів на рисерчі
- Готовність та бажання рекрутера
Умови співпраці
Емоційна складова (чи подобається клієнт, чи хочемо спробувати свої сили)
Аналіз ринку
- Зарплатні очікування
- Ємність ринку
- Експертиза Індіго з таких вакансій
- Ресурси та методи пошуку
Естімейт за часом на закриття вакансії
- optimistic
- pessimistic
- average
Показники аналізу ринку та естімейту за часом на закриття вакансії відкриті для клієнтів.
Канбан
Канбаном для візуалізації користуємося вже давно, і підхід до нього змінювався.
Спочатку була фізична дошка в офісі, потім KanbanFlow, де вели кандидатів на стадії. Якось вирішили поекспериментувати, і перейшли на Trello, де позначали лише завдання.
Фаворитом рекрутерів все ж таки залишився KanbanFlow: у ньому на одній дошці зручно вести кілька проєктів. Але зараз ми переходимо на нову ATS, яка замінить дошки та заощадить час.
Про те, як вибирали ATS, напишемо трохи пізніше.
Є думка, що рекрутери — істоти гуманітарні, з утворенням філолога/психолога та не дуже логічним складом розуму. Проте робота рекрутера, крім щирого інтересу до людей, має чіткий алгоритм дій. Іноді у нас теж горять дедлайни, клієнти приходять з проєктами “на вчора” та “раптово”, а робота – ітераційна. Десь про це вже чули? Так “ми ж у ІТ” (с)
Ми в Індіго зіткнулися з такими проблемами:
- як міряти свою ефективність та робити наочним процес роботи?
- як ділитися з командою прогресом, не витрачаючи часу на щоденні звіти?
- як налагодити взаємодію сейлз-рекрутер?
І щоб не винаходити велосипед, ми звернулися до ІТшників. Хочемо поділитися, як ми розв`язуємо наболілі питання за допомогою інструментів, які знає кожен програміст.
Естімейт проєкту
Минулого року наша команда зросла: з'явилися бізнес Ксю і тим-лід, тобто я. Ролі були незвичні, іноді інформація від клієнта губилася між мною, Ксю і рекрутером, зона відповідальності кожного була розмитою. Крім того, що ми прописали чіткі ролі для кожного учасника цієї взаємодії, ми вивели формулу естімейту нових проєктів. По ній ми приймаємо рішення, брати проєкт у роботу, чи ні, і який рекрутер над ним працюватиме.
Відповідальний рекрутер
- Скільки у роботі проєктів
- Кількість проєктів на рисерчі
- Готовність та бажання рекрутера
Умови співпраці
Емоційна складова (чи подобається клієнт, чи хочемо спробувати свої сили)
Аналіз ринку
- Зарплатні очікування
- Ємність ринку
- Експертиза Індіго з таких вакансій
- Ресурси та методи пошуку
Естімейт за часом на закриття вакансії
- optimistic
- pessimistic
- average
Показники аналізу ринку та естімейту за часом на закриття вакансії відкриті для клієнтів.
Канбан
Канбаном для візуалізації користуємося вже давно, і підхід до нього змінювався.
Спочатку була фізична дошка в офісі, потім KanbanFlow, де вели кандидатів на стадії. Якось вирішили поекспериментувати, і перейшли на Trello, де позначали лише завдання.
Фаворитом рекрутерів все ж таки залишився KanbanFlow: у ньому на одній дошці зручно вести кілька проєктів. Але зараз ми переходимо на нову ATS, яка замінить дошки та заощадить час.
Про те, як вибирали ATS, напишемо трохи пізніше.
Стендап
Коли я тільки прийшла до Індіго, звітність вели просто і сердито: щодня рекрутери надсилали листа про те, що зробили. Це займало багато часу, і не вистачало зворотного зв'язку та спілкування з командою.
Якось ми з цікавості спробували зробити стендап. Було складно: хтось відволікався, хтось надто довго розповідав, хтось не розумів, навіщо це потрібне.
Згодом ми відмовилися від письмових звітів та перейшли на живе спілкування. Стендапи проводимо 2 рази на тиждень, і ми маємо правила:
- Вирішення проблем не виносимо на стендап, обговорюємо після
- 1й стендап на тижні - розповідаємо про плани
- 2й стендап на тижні — озвучуємо вимірні результати (кількість поданих резюме, співбесід, зустрічей)
Перехід на стендап дозволив заощадити час, а головне — команда дізналася про проблеми та успіхи один одного.
1-to-1
Але стендапів не вистачало, щоб обговорити нагальні проблеми. Крім того, коли я почала менеджувати команду, важливо було "втертися в довіру" своїм колегам? І для того, і для іншого, ми стали зустрічатися раз на 2 тижні на 1-to-1: зустрічі формату тимлід + рекрутер.
І тут були труднощі. Якщо на перших зустрічах ми говорили безперервно, то тривалість наступних зустрічей поступово скорочувалася, а ефективність закриття вакансій не підвищувалася.
Щоб зустрічі були корисними, ми стали готуватися до них. Рекрутер має чек-лист, за яким він готує інформацію, а я виділяла час перед зустріччю та аналізувала прогрес по вакансіях.
Так 1-to-1 стали не просто душевною бесідою, а глибшим зануренням у процес.
Упевнена, це ще далеко не всі ідеї з управління проєктами та командою в ІТ, які можна з успіхом запровадити у рекрутингу. Може, у нас ще з'являться деплої, релізи та багфікси... Хто знає??
Підписатися
Успіх! 