Использование Scram на примере кейса по подбору персонала, когда клиент отказывается платить

Многие специалисты и HR агентства, занимающиеся подбором персонала, сталкивались с ситуацией, когда по запросу клиента подбираешь кандидатов, предлагаешь их клиенту, а клиент отказывается оплачивать оказанные услуги под разными предлогами. Или пост-фактум меняет условия. В результате HR тратит свои деньги и время на поиск кандидатов, передает их клиенту, а клиент отказывается платить. Почему так происходит?
Всем кадровым агентствам и специалистам HR, занимающимся наймом персонала, посвящается.

Найдите консультанта
для ваших целей

Расскажите, с чем вам нужна помощь (консалтинг по продажам, сервису или управлению, создание документов), и мы бесплатно подберем для вас консультанта из нашей базы экспертов

Подобрать

Процесс подбора персонала прост. От клиента поступает заказ на поиск кандидатов. Это может быть внутренний клиент, если HR работает в компании, и заказ поступил от руководителей подразделений внутри компании. Или внешний клиент, когда HR получил заказ от сторонней компании. Рассмотрим в упрощенном виде второй вариант, как более полный и содержащий в себя первый вариант.

И так, ситуация для HR развивается по следующему сценарию:

1. Получил заказ на подбор кандидатов.
2. Запросил у клиента необходимую дополнительную информацию.
3. Оценил предложение клиента и свои возможности.
4. Заключил с клиентом договор, с закреплением количества кандидатов и стоимости работ.
5. Нашел кандидатов, проинтервьюировал и оценил их.
6. Подготовил кандидата к встрече с клиентом (при необходимости).
7. Клиент проинтервьюировал кандидата и принял решение принять его на работу.
8. Клиент принял кандидата на работу.
9. Выставил счет на оплату, в соответствии с условиями договора.
10. Клиент оплатил оказанные услуги.

В теории все красиво, знай себе работай и зарабатывай деньги. Но жизнь вносит свои коррективы. И часто приходится слышать, что кто-то из коллег HR выполнил свою часть договора, а клиент отказывается платить под различными предлогами. Почему так происходит? Причины могут быть совершенно разные:

1. Прошло больше времени, чем ожидал клиент.
2. Изменились требования к кандидату или к HR.
3. Изменились внутренние или внешние условия.
4. Некомпетентность одной из сторон.

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

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

Подобные задачи лучше всего решать методами проектного управления. Описанный выше сценарий в проектном бизнесе называется «классическая модель» и полностью соответствует требованиям.

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

В нашей стране наибольшее распространение получил «A Guide to the Project Management Body of Knowledge (PMBOK® Guide)» от PMI (Project Management Institute), который сегодня считается признанной классикой проектного управления.

К сожалению, при использовании данного подхода многие (не только HR специалисты) не раз сталкивались с тем, что большинство таких проектов заканчиваются неудачей. Да, мировая статистика приводит неутешительные цифры. При использовании классической модели положительно завершается менее 30 % проектов из 100. А более 70 % проектов так и остаются не завершенными. Эти неудачи многие специалисты связывают с недостатками самой методологии.

Что бы устранить недостатки классической модели, передовые умы активно работают над созданием иных подходов к выполнению проектов.

Одним из таких подходов можно смело считать Scram, который, в отличии от PMBOK® Guide, не является методологией. Авторы определяют Scram как framework (от англ. рамки, структура, каркас, среда) или набор принципов для управления работами. Скажем несколько слов об истории появления Scram.

Название Scrum первые прозвучало в докладе «SCRAM Development Process» на конференции OOPSLA 95 в 1995 году. Затем в 2001 году Ken Schwaber выпустил в свет книгу Agile Software Development with Scrum. А в 2014 году Jeff Sutherland опубликовал книгу Scrum: The Art of Doing Twice the Work in Half the Time, которая стала бестселлером, и с ее выходом широкие массы по всему миру узнали про Scrum.

Так в чем же разница между двумя этими подходами и в чем преимущества? Чтобы это понять, необходимо рассмотреть, предпосылки для их появления на свет.

Предпосылки для классической модели управления проектами сформировались в начале 20-го века. В то время считалось, что для правильной работы компании необходимо все подробно и качественно описать, чтобы потом пользоваться разработанными материалами. И весь прошлый век большинство шло именно по этому пути. Описывались процессы, разрабатывались методологии, инструкции, регламенты. Проекты разбивались фазы, которые выполнялись последовательно. Но все чаще и чаще такой подход подвергался критике со стороны бизнеса.

Научная мысль того времени не стояла на месте, разрабатывались различные новые подходы, методы и инструменты для развития компаний. Так в 1946 году американский ученый и консультант по менеджменту (управлению) Уильям Деминг был приглашен в Японию для восстановления разрушенной войной промышленности. Он не был приверженцем классической школы и пропагандировал свои научные разработки: цикл улучшения PDCA, известный сегодня как цикл Шухарта-Деминга; теорию глубинных знаний и построенную не ее основе теорию менеджмента; методы статистического контроля качества. Его влияние на японское производство было огромно. И именно он считается основоположником японского экономического чуда. С его подачи на японских заводах были построены и внедрены системы улучшения качества и бережливого производства. Кроме того, его подходы легли в основу создания Scrum, гибкой технологии для разработки программного обеспечения.

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

Несколько слов о том, как организовать работу при подборе персонала по Scrum:

• Заключить договор типа Time & Material (оплата фактически выполненных работ).
• Организовать работу малой команды от 3 до 9 человек (возможно 1 человек).
• Проводить ежедневные короткие совещания команды (для фиксации результатов, рисков и поиска улучшений).
• Работы вести итерационно. Каждая итерация длится несколько дней.
• Каждую итерацию завершать встречей с клиентом, для передачи результатов и корректировки задач.
• Выстроить с клиентом деловые конструктивные отношения.

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

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