{"id":13577,"url":"\/distributions\/13577\/click?bit=1&hash=e52de3cb96bc976bea78d5b7766560bb7dab3556d094a176b9efc522dc9ec6a3","title":"\u041a\u0443\u0434\u0430 \u0443\u0442\u0435\u043a\u0430\u0435\u0442 \u043c\u043e\u0439 \u0431\u044e\u0434\u0436\u0435\u0442 \u043d\u0430 \u0440\u0435\u043a\u043b\u0430\u043c\u0443?","buttonText":"\u041a \u043c\u043e\u0448\u0435\u043d\u043d\u0438\u043a\u0430\u043c","imageUuid":"f14d918a-59c9-5701-b718-30025e0ce469","isPaidAndBannersEnabled":false}
Teachbase

Продуктовый подход: подробный гид для HR

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

Что такое продуктовый подход

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

Проектный подход:

- А давайте запустим такую-то штуку, должно быть классно. Да и конкуренты уже сделали.

- Да, я сам пользуюсь, крутая штука. Мы можем еще добавить туда вот эту фишку.

- Отлично. Давай тогда писать ТЗ, планировать срок и бюджеты.

Продуктовый подход:

- Нам нужно вырастить вот этот показатель. Читал, что конкуренты сделали вот такую штуку и решили похожую задачу.

- Давай исследуем: нужна ли нашим клиентам такая штука и что мы получим от запуска, как сможем измерить пользу?

- Вернусь с ответами и решим, что будем запускать и вообще надо ли.

Продуктовый подход пришел из IT–компаний. Со временем стало понятно, что его принципы — здоровые и универсально полезные, и их можно использовать не только при разработке IT-продуктов. В принципе, любая работа — это создание продукта.

Продуктовый подход в HR

Где продукты?

1. Продукты в HR — инструменты автоматизации. Например, платформа, которая помогает сделать обучение сотрудников системным и удобным. Или форма для сбора фидбеков, которая упрощает Performance Review.

2. Почти все HR-инструменты завязаны на каких-то процессах: онбординг, отбор стажеров, опять же ревью. К процессам тоже можно подходить как к продуктам.

А пользователи кто?

Те, кто вовлечен в HR-процессы: руководители, сотрудники, кандидаты на работу в компании. А кто именно — зависит от конкретной ситуации.

Как строить работу?

1. Ставим цель: какую проблему хотим решить.

2. Определяемся с метриками: что поможет оценить результат работы?

3. Выдвигаем гипотезы: в чем причина проблем?

Опрашиваем причастных и отсеиваем верные.

4. Делаем необходимый минимум, «чтобы все заработало».

5. Анализируем метрики. Если что-то не так — п. 3.

6. Если решили проблему — не делаем улучшения ради улучшений.

В чем польза для компании?

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

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

Меньше рисков. Оптимизация — наведение порядка в процессах, «выпиливаем» лишние, объединяем похожие. А чем меньше этапов, тем меньше рисков, которыми нужно управлять.

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

Выше качество работы. Оптимизация вычищает часть рутины. У HR-ов появляется время не только разгребать горящее, но и заниматься более сложными и стратегическими вещами.

За счет продуктового подхода компания может получить дополнительное конкурентное преимущество и найти новые, ранее недоступные инсайты.

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

Михаил Карпов, CEO ProductStar

Разберем на практике: кейс Авито

В Авито продуктовый подход применяют сотрудники разных специализаций и уровней, от стажеров до опытных руководителей. Здесь поделимся кейсом, как этот подход использовали для решения HR-задачи — оптимизации Performance Review.

Ревью — регулярная практика в Авито. Сотрудники пишут обзор сделанного по кварталам, потом собирают фидбек коллег и руководителя. По итогам ревью строятся планы развития. Процесс важный, но раньше отнимал много времени и ресурсов.

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

  • Описание сделанного за каждый квартал виделось процессом долгим и сомнительно полезным, а оказалось важным. Проходящим ревью это помогает отрефлексировать опыт, а пишущим фидбеки вспомнить контекст. Тут ничего менять не стали.
  • Возможность собрать неограниченное количество фидбеков усложняет жизнь сотрудникам (некоторым приходили запросы на 40 откликов). А критична ли эта возможность? Оказалось 90% сотрудников, хватает и 10-20 фидбеков. Ограничили количество.
  • Фидбеки пишутся долго. Может, поменять формат, чтобы сотрудники просто выставляли уровень развития компетенций? Оказалось, нельзя все переформатировать без смысловых потерь. Но для ускорения стоит дать сотрудникам опору. В форме сбора фидбеков сделали структуру, которая задает направление мысли: даешь обратную связь коллеге только по тем целям, над которыми работали вместе.

По итогам первой итерации расход времени сократился на 34%, но цель была 50%. Снова работали по схеме: гипотезы, UX-тесты и опросы сотрудников, правки. В итоге небольшими продуманными шагами пришли к запланированному результату: сократили ревью в 2 раза и сэкономили ресурсы компании.

Еще разбор: пример оптимизации найма

Шаг 1. Выявили проблемные места процесса. Собрали метрики по каждому этапу найма. Посмотрели, где воронка проваливается: кандидаты сильно отсеиваются на этапе тестового и на интервью.

Шаг 2. Исследовали процесс, уточнили проблемы. Выяснили, что тестовое завязано на хард скилах, поэтому его проверяют сотрудники, а у них редко есть свободное время — отвечают долго. А на интервью кандидатов чаще всего отсеивают из-за нехватки хард скилов — уделяют время тем, кто не совсем подходит.

Шаг 3. Предположили, как можно решить проблемы. Скорее всего, кандидаты «растворяются» после тестового, потому что успевают найти другую работу в долгом ожидании отклика. Тут нужно ускоряться. Тестовое делают удаленно, возможно, не сами — вот и нерелевантные кандидаты на интервью. А тут нужен дополнительный фильтр.

Шаг 4. Внедрили изменения, отследили результат. Для ускорения проверки тестового упростили задание, чтобы HR мог справляться сам. Для дополнительной фильтрации добавили короткие онлайн-встречи перед интервью, тоже c HR-ом, чтобы не отвлекать команду. На этих встречах HR быстро пробегается с кандидатами по хардам (его для этого подготовили) и отсеивает нерелевантных.

Новые решения некоторое время потестировали, потом снова посмотрели метрики — процесс найма выправился.

3 ошибки при внедрении продуктового подхода

1. Автоматизация без оптимизации. HR-процесс неэффективный (например, сотрудники долго адаптируются)? Давайте автоматизируем, запилим такую-то фичу и решим проблемы. Но если в процессе бардак или много лишних элементов, технические примочки не решат проблемы. Автоматизация — не есть оптимизация, это дополнение, которое помогает сделать процесс удобнее.

Оптимизация — это пройтись по процессу, проверить логику и пользу его составляющих и навести порядок:

2. Фокус на IT-продуктах. Продуктовый подход пришел из IT. Продукты этой сферы — программы и инструменты, цель — улучшать их работу. Практикуя продуктовый подход в других сферах, иногда допускают ошибку: фокусируются на улучшении IT-продуктов без оглядки на свою цель.

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

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

3. Забыли про итерации. Важно не только правильно стартовать: вот цель, вот такие метрики будем отслеживать, а вот проверенные потребности пользователей. Не менее важно правильно продолжать — работать итерациями. Всем хочется сразу «диснеевский замок принцессы, а не избушку на курьих ножках». Но рациональнее сначала сделать «избушку», то есть запустить пилот (MVP):

  • У вас быстрее появится продукт — быстрее начнут решаться проблемы.

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

MVP — это:

1. Только самое необходимое:

этапы, роли, инструменты и их функционал.

2. Простая логика:

процесса, работы инструментов.

3. Конкретная ценность для бизнеса.

Об экспертах

Это статья по мотивам совместного вебинара. Организация вебинара и подготовка материала — от Teachbase, экспертиза — от ProductStar. Ценным опытом с нами поделилась:

Анастасия Кондрашова
Senior Product Manager Авито, 5 лет в разработке HR-продуктов, ведет канал Продуктовая бомбежка

И пару слов о ProductStar. Это ведущий российский онлайн-университет с экспертизой в продуктовом менеджменте, аналитике и программировании. Помогает получить диджитал-профессию, пройдя курсы от главных практиков индустрии. Среди спикеров и трекеров — эксперты из Amazon, Booking, PayPal, Google, Яндекс. А обучение построено на прикладных кейсах российских и международных компаний.

А еще ProductStar — соорганизатор сообщества ProductCamp, которое с 2011 года объединяет лучших специалистов в сфере продакт-менеджмента России и Восточной Европы.

0
18 комментариев
Написать комментарий...
Vik Enot

Порадовала инфографика. На vc редко кто делает инфорграфику. А зря мне кажется это привлекает внимание и вовлекает в статью!

Ответить
Развернуть ветку
Николай Виноградов

Действительно подробно, благодарю.

Ответить
Развернуть ветку
Valeratal Val
Продукты в HR — инструменты автоматизации.

не согласен. Инструменты автоматизации это продукты у прогеров. А у HR - продукт это собственно для чего эти инструменты используются. Вы ж не скажете, что у садовника - продукт садовые ножницы? У садовника - продукт ровно постриженные кусты

Противопоставление продуктового и проектного подхода довольно странно. Как-то получается из текста, проекты делаются "потому что захотелось", а вот продукты делаются для блага людей. интересно, а кто деньги выделяет на проекты, не интересуется результатами?

И продукты и проекты это термины из разных сфер/стадий, а не антонимы/антогонисты.

Ответить
Развернуть ветку
Илья Ланкевич

Там следом второй пункт:
«Почти все HR-инструменты завязаны на каких-то процессах: онбординг, отбор стажеров, опять же ревью. К процессам тоже можно подходить как к продуктам».
И это верно. Устойчивый результат процесса (outcome) — это продукт.
А продукты и процессы — это не противоположности, а разные основания для разных управленческих подходов к организации в первую очередь.

Ответить
Развернуть ветку
Valeratal Val

Ага, почти все инструменты садовника завязаны на каких-то процессах. К процессу тоже можно подходить как к продукту
А далее Вы от "процесса" переходите резко к "устойчивому результату процесса"
Батенька, Вы демагогией занимаетесь. Вот устойчивый результат процесса - будет продуктом, а вот инструменты и процесс - нет.
Это как с детьми. Есть инструменты (не буду описывать) , есть процесс (секс или иные методы), а есть устойчивый результат - дети. Вот дети - это продукт (японцам нравились), а все остальное - нет

Ответить
Развернуть ветку
Илья Ланкевич

Сынуля, ты какую тему хочешь обсудить?
Спи, всё у тебя есть.

Ответить
Развернуть ветку
Илья Ланкевич

У тебя конвейер, техпроцесс, на выходе молоток.
Молоток — инструмент и продукт.

Ответить
Развернуть ветку
Valeratal Val

Не, у HR нет конвееров и техпроцессов. Конвееры и техпроцессы у разработчиков средств автоматизации

1. Продукты в HR — инструменты автоматизации. Например, платформа, которая помогает сделать обучение сотрудников системным и удобным. Или форма для сбора фидбеков, которая упрощает Performance Review.

Платформу разрабатывают разработчики. Для них она "продукт", а для HR это инструмент. Продуктом работы HR будут адаптированные сотрудники (это если речь про адаптацию), Выводы по результатам перфоменс ревью (а софт для проведения перфоманс ревью - это инструмент), эффективный найм (если это ATS, при этом ATS это инструмент)
а вот для разработчиков ATS, ATS - это продукт, они его продают

Проще говоря, продукт это то, что продают клиенту. HR не продает софт. Это ему софт продают (на самом деле продают ЛПР, но это уже тонкости)

Ответить
Развернуть ветку
Илья Ланкевич

черт, катастрофически сложно ответить кратко…

Ответить
Развернуть ветку
Илья Ланкевич

«Не, у HR нет конвееров и техпроцессов».

Есть, т. н. массрекрутинг. В общем случае — могут быть.

«Конвееры и техпроцессы у разработчиков средств автоматизации».

И у этих есть. Но здесь это необязательно, в общем случае — могут быть, но могут и не быть. От конвейера легко можно отказаться, а техпроцесс потребует уточнения, что под подразумевается. Просто связь выполняемой работы с технологией, например, сублимирование (не путать с сублимацией, хотя это ближе HR), не делает процесс технологическим.

«Платформу разрабатывают разработчики».

Э-э-э, если под платформой понимать «ИТ платформу» то, её разрабатывают (кодируют) разработчики. Если под платформой понимать набор правил взаимодействия, например, рыночных структур (работника, организации, регулятора, ИТ системы) и процедур принятия решений то, нет. Про кодеров могут и не вспомнить.
Когда речь идет про платформу, «которая помогает сделать обучение сотрудников системным и удобным», меня меньше всего интересует создание корпоративной «Телеги», т. к. я могу воспользоваться Телеграм.

«Продуктом работы HR будут адаптированные сотрудники… Выводы по результатам перфоменс ревью… эффективный найм…»

Бесспорно. И всё это результаты HR-процессов: адаптация → адаптированные, результаты оценки → оценка (assessment), наймиты → найм. Именно поэтому я указал, что сразу седом за словами, на которые ты обратил внимание следует: «Почти все HR-инструменты завязаны на… процессах… К процессам тоже можно подходить как к продуктам». И это верно! (повторю я). Т. К. продукт в современном понимании — это набор услуг (если очень нравится — сервисов), которые может иметь вещественные элементы (а может и не иметь:).

«… продукт это то, что продают клиенту»

Да.

«HR не продает софт».

Продает, см. здесь: https://peoplemanagingpeople.com/topics/hr-software-companies/
Большинство зарабатывают на выручке от услуг и SaaS.

Вот не будет у нас предмета спора, если мы уточним некоторые вещи:
1) Продуктовый подход появился (принято считать) в 1931 г. ширпотребе (Procter & Gamble), примечательно, что тогда речь шла про «brands» (= продукт:)
2) Дальнейшее развитие получил в Hewlett-Packard в 1940–50, но «продукт» = «товар»
3) Потом его задвинули, т. к. речь шла про «концепцию маркетинга», «продукт» = «воспринимаемый потребителем набор характеристик товаров/услуг, специфическая форма удовлетворения потребности»
4) В 1983 начало новой эры продуктового подхода — проект Excel for Mac, но «продукт» = «program», прям так и было — program management
5) И вот где-то в 0-е, сформировалось представление о «продуктовом подходе», о котором пишет @Teachbase : у нас есть тотем = «продукт» и мы с ним носимся как с писанной торбой, скрами, канбаним и спринтим в эпиказ, чтобы делать инкрементальные изменения

Ответить
Развернуть ветку
Valeratal Val
Продает, см. здесь:

Это софтверные компании. Причем тут HR.

История "продукта" примечательна, но что все это время делали с проектами? почему все зОщитники продуктового подхода все время пытаются унизить проектный подход? в чем тут у них (защитников) проблема то?
Уйма людей работали и работают проджект-менеджами, есть немалое кол-во софта под это дело (майкрософтский, например. навскидку или даже шаблоны для диаграммы Ганта). Все эти проекты делали получается неправильно, а тут вылезли новые консультанты и говорят "Вы делали абы как, а вот мы мерим. Как будто в проектном подходе кто-то запрещал мерить"

Ответить
Развернуть ветку
Илья Ланкевич

Угу.
Если эти компании «софтверные», то и Wildberries и Сбер (мечта Грефа сбылась) тоже «софтверные», а IBM — консалтинговая? По какому критерию ты определил, что компании из списка «софтверные»?
Это вопрос д. б. риторически.

Что происходило с проектным управлением с 30-х и до нынешнего?
Также несколько этапов: с 10-х до Манхэттенского проекта; с окончания 2МВ и до конца 50-х (DoD, Rand, Xerox, Bell); потом (условно) до конца 80-х; и потом…
В отличие от продуктового подхода, проектное управление развивалось от очень больших (мега) проектов к маленьким, а многое было заимствовано из производственного и операционного управления, например, WBS и КСГ.

Имхо, большой битвы подходов нет.
Просто изучив и научившись применять один, люди очень неохотно воспринимают другой. Плюс, совершенно точно:), сейчас есть хайп «нового» продуктового подхода (management fashion).
Но это всё неважно.
Противопоказаний у этих подходов нет, много побочки и у одного, и у другого, их даже можно поженить.:)
А я, к примеру, апологет процессного подхода.:)

Ответить
Развернуть ветку
Valeratal Val

Компании, которые пишут софт (как основной вид деятельности) - софтверные (все из того списка)
Вайлдбериз - маркетплейс (основной вид деятельности). Про остальных вообще не понял.

Ответить
Развернуть ветку
Илья Ланкевич

Как определить основной вид деятельности? Например, IBM или Gusto?

Ответить
Развернуть ветку
Valeratal Val

Вам интересно? Вы изучите их профиль деятельности. Обсуждали компании, которые пишут софт для HR. Вы их называли HR-компаниями, я их называют софтверными. Потому что они софт пишут. По этому пункту есть возражения?
Или Вы считаете, что если компания пишет софт для логистики, то она логистическая (ну типа деловые линии и у них парк грузовиков). а если пишет HRIS, то hr-овская

Ответить
Развернуть ветку
Илья Ланкевич

Ну да, спорить не о чем.
«Вы их называли… я их называют».
Я именно об этом и говорю. По мне, наличие in-house разработки (Wildberries), 30% выручки от продажи ПО (IBM) и даже ярлык навешанный журналистами (Alphabet) не повод называть компании «софтверными». Но это совсем неважно. Т. к. не софт продают эти компании (не сверла в четверть дюйма), а решение некоторых задач (отверстия в четверть дюйма).
Также и с подходами, оргструктура и распределение полномочий м. б. по проектам, процессам, продуктам. Вот и всё.

Ответить
Развернуть ветку
Valeratal Val

Вы демагогией занимаетесь, вместо того, чтобы признать, что сели в лужу

Инхаус разработка есть почти везде. Кто-то пишет софт, кто-то делает себе сайт, кто-то макросы пишет в эксель. Только это не делает компанию софтверной
Софтверные компании разрабатывают и продают софт. Вы когда-нить софт покупали? У Вас там было что в счете "решение ваших задач" ? или типа 1с, или Майкрософт офис?
А вот решения задач продают другие ребята, называются интеграторы. (у них в счете тоже будет не "решение задач, но где-то уже ближе к проблемам клиента)
Бывает конечно что они же и разрабатывают, они же и продают, 3 в одном (мем с Сашей)

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

Ответить
Развернуть ветку
F2F Studio

спасибо большое, мощная статья

Ответить
Развернуть ветку
Читать все 18 комментариев
null