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

Говоря по-простому, продукт — это то, что удовлетворяет потребности потребителей на рынке. Продуктовый менеджер сегодня — это частично айтишник, понимающий в разработке IT-продукта, частично специалист по UX, управляющий впечатлением пользователя продукта, и частично предприниматель. HR также может быть продуктовым менеджером, потому что делает продукт на внутреннем рынке компании. Пользователем HR-продукта является организация в широком смысле и ее конкретные сотрудники в узком смысле. Предлагаю попробовать научиться нанимать работников, применяя Product Mindset — продуктовое мышление.

Главный продукт HR-а или рекрутера — это решенческая экспертиза. Именно из-за нее он нужен компании.

HR создает продукт для двух типов целевой аудитории (ЦА): кандидаты или работник и руководство. В трудовом законодательстве — это две стороны трудового договора. Тип ЦА со стороны работодателя — это лица, принимающие решения (ЛПР). Если решения касаются работников — а, как правило, почти все решения в организации касаются работников — то это касается и HR. Другой тип ЦА — это работники. Каждый из них ЛПР, представляющий себя самого. Для обоих типов ЦА уточненным продуктом является проект решения, который устроит обе ЦА. Это очень трудная проблема.

Для того, чтобы понять, что сильнее всего беспокоит ваши ЦА, нужно с ними разговаривать. Для этого в продуктовом менеджменте применяются глубинные интервью. Это отдельная очень интересная история, но для нее нужна отдельная статья.

Знать свою ЦА — это не значит правильно выполнять работу HR-а. Гораздо важнее ситуации, которые порождают потребность в HR. Поэтому хороший HR акцентирует своё внимание на проблемных ситуациях. Чтобы закрывать боли и проблемы в сложных ситуациях, в теории продукта используется подход Jobs-To-Be-Done (JTBD).

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

Основная проблема найма заключается в том, что в организации возникает необходимость сделать то, что в настоящий момент никто делать не умеет (из-за отсутствия специальных навыков) или не может (из-за отсутствия времени). Что это значит? Это открывается вакансия. Вакансия — это действия, которые может выполнить только человек с определенными навыками, причем как можно более качественно и за определенную стоимость. Помимо этих критериев еще важно время: когда нужен такой человек? Ответ “вчера” очень плохой. На самом деле, срочность может быть оправдана только внезапной потерей бойца (смерть или увольнение одним днем). Все остальное может быть предсказуемо и планируемо.

Полный контекст найма как хорошей работы — это время, качество, и стоимость. Отсюда по формуле Job-As-Activity (Глагол + Объект + Контекст) работу по найму можно описать так: Находить + Способы выполнения задач компании + Быстро, качественно и недорого.

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

Для того чтобы выполнить  задачу (функцию) быстро:

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

Риски этого решения: некачественно выполненная задача, плохой результат. В первом случае также повышается стоимость.

Если заботиться только о качестве, то в процессе найма вы найдете отличного кандидата, но скорее всего это будет нескоро и недешево. Риски этого решения: несвоевременно выполненная задача, плохой результат.

Если заботиться только о стоимости, то решение может быть таким:

1. Сверхурочная работа и прочее без оплаты (плохо, потому что будет недовольна ЦА — работники).
2. Находим кандидата по стоимости и обнаруживаем, что он не умеет решать нужную задачу. Берем – учим – не выполняем задачу вовремя. Не берем – не выполняем задачу. Имеем плохой результат.

JTBD должен помочь нам выполнить нашу работу целиком. Здесь отлично работает следующая метафора.

Нам всем нужна вода. Если мы находимся в месте, где её легко достать, то мы об этом не задумываемся. Но представим, что нам надо попасть из точки А в точку В через пустыню (рынок труда), чтобы найти того, кто нам выполнит задачу (кандидата). Хорошо точно знать ближайший источник воды (для этого надо иметь карту пустыни). У нас есть несколько вариантов решения:

1. Можно иметь с собой запас воды, но она кончится, если мы не знаем, велика ли пустыня;
2. Можно использовать ресурсы организма, но это совсем ненадолго;
3. Можно не идти пешком, а взять в пустыню верблюда, проводника, джип;
4. А можно не ездить через пустыню, а полететь на самолете.

Последние два решения — это уже Job-As-Activity.

Мы нанимаем агентство, рекрутера-фрилансера, CRM, аутсорсинговую фирму. Однако и это еще не всё.

А что, если мы вообще не едем в точку В, потому что она сама к нам приехала? Или нам поможет сила мысли, потому что мы сделали научное открытие? Это решение Job-As-Progress — инновация. Какое?

Нам нужно выполнить рабочую задачу (на самом деле, дело в этом, а не в вакансии). У нас есть следующие сценарии решения:

1. Ее может не выполнять человек (роботизация). Риски: это отложенная проблема, затем нам понадобится нанять того, кто будет создавать или обслуживать робота.
2. Ее может выполнять удаленная команда. Риски: ее тоже надо искать. Кроме того, нужна особая инфраструктура и управление для удаленной команды.
3. Для закрытия сложных задач набираем внутренний кадровый резерв, а извне набираем только на простые (экономия на качестве, стоимости, времени). Риски: кадровый резерв может уволиться, и его нужно уметь создавать (нужны другие скиллы, не только наём).
4. Обучаем своих работников постоянно новым задачам. Они их либо выполняют вместе со старыми, либо переходят на новые (далее сценарий №3). Риски такие же как и у решения 3.
5. Перестраиваем работу в компании так, чтобы выполнение этой задачи было уже не нужно. Риски: есть риск не найти таких талантливых управленцев внутри компании.

Итераций может быть множество — это называется Re-Invention в теории JTBD. Но посмотрите: каждое новое решение влечет другие работы. Здесь мы выходим за рамки JTBD и сталкиваемся с тем, что называется системностью, а об этом лучше поговорить в следующий раз.

Автор: Ольга Арлашкина
HR, преподаватель и методолог корпоративного обучения, член АККС