Быстро или правильно. Agility-подход к внедрению технологий в HR (и не только)
Что такое Agility-подход? Очередной тренд или четкая пошаговая методология, которая делает компанию живой системой, способной легко адаптироваться к любым внешним условиям? Как выстроить такую систему и применить гибкие технологии в HR-процессах, рассказывает Сергей Байтеряков, руководитель практики бизнес-консалтинга компании MOLGA Consulting.
«Вы никогда не заставите работать новые правила игры, пока ваши сотрудники не получат с их помощью результат.» (Александр Фридман)
Размышления на тему, обозначенную в заголовке, начались с разговора. Мы обсуждали вопросы проведения оценки персонала, и клиент пожаловался, как сложно внедрить такую программу:
— Наверное, мы потратим полгода, чтобы запустить отбор в кадровый резерв.
— Да нет, — ответил я, не понимая в чем проблема, — пару недель на разработку и столько же на согласование с топ-менеджментом. Через месяц можем стартовать.
— У нас так не выйдет…
Тут я грешным делом подумал, что есть какой-то особо зловредный менеджер. Или что генеральный директор постоянно в разъездах. Или…
Дело оказалось не в этом. HR-директор хотела внедрить правильную, совершенную систему. И не только для кадрового резерва. Она хотела сделать качественную программу для адаптации персонала, а значит — нужно было разработать раздаточные материалы и понятно описать весь процесс. А еще провести обучение для наставников. И подбор необходимо подтянуть, научить рекрутеров проводить правильные интервью, но времени и бюджета для тренингов в ближайший квартал не было.
С того разговора прошло больше года. Программа кадрового резерва так и не стартовала. Как и программа адаптации…
Знакомая ситуация? Не всегда «лучше» на самом деле означает лучше. Иногда это приводит к тому, что нужные изменения не происходят или происходят через несколько лет. Возможен и еще один вариант: программа долго разрабатывается, согласуется, происходит запуск… и получаем множество недовольных. Руководители бурчат, что наверху придумали очередную глупость, которая не учитывает особенности компании. А на вопрос: «Вы же все согласовали?» — отвечают: «А попробовали бы мы не согласовать!» Начинаешь разбираться и видишь: ситуация настолько изменилась, что правильные идеи через полгода уже устарели.
Какова же альтернатива? Брать людей «в штат»? Но это увеличение затрат, что плохо само по себе. Покупать услуги консультантов? Но может получиться даже не как в известной присказке: «Быстро, качественно, дешево, выберите два из трех…». Получается и дорого, и не быстро, причем большая часть времени тратится на внутренние согласования. Либо все-таки поменять подход к внедрению нового и отказаться от перфекционизма.
На помощь нам приходит Agility-подход. Напомню суть: мы не делаем идеальный продукт «за один раз», мы делим разработку и внедрение на маленькие отрезки и постоянно получаем обратную связь от конечных пользователей.
Как это работает при внедрении HR-технологий? Рассмотрим для примера внедрение системы адаптации новых сотрудников.
Классический подход выглядит следующим образом:
- Разрабатываем процесс, в который включены руководитель, ментор/наставник и сотрудник.
- Пишем положение, регламентирующие действия сторон. Создаем календарный график.
- Разрабатываем адаптационную программу — чему учим сотрудников. Придумываем КПЭ, оценивающие эффективность программы и отдельных участников.
- Отбираем будущих наставников.
- Разрабатываем программу и обучаем будущих наставников (а возможно и руководителей).
- Проводим PR-программу и стартуем программу адаптации.
Уточнение для больших компаний: делаем пилот, обкатываем программу на одном-двух подразделениях, вносим улучшения.
Я использую список из 37 вопросов, чтобы спроектировать систему менторинга/наставничества в компании и этот список уточняется и дополняется в каждом проекте.
Итак, по вашей оценке, сколько времени нужно на разработку такой программы? Да, на выходе будет комплексная, эффективная программа адаптации. Но — через три месяца или через пол-года. Если более важные и срочные дела не отвлекут сотрудника, занимающегося ее разработкой.
Предлагаемый Agility-подход:
Главное в Agility-подходе — польза для клиента.
Шаг первый
Кто наш клиент? Сотрудник, только что принятый на работу. В чем его ключевая выгода? Всегда понятно, кому задавать вопросы.
Кто еще наш клиент? Руководитель нового сотрудника. В чем его выгода? Снижение количества ошибок, совершенных новичком «по глупости». Увеличение скорости работы только что принятого на работу сотрудника.
Является ли клиентом будущий наставник и каковы возможные выгоды в этом случае — предоставляю решать вам. Ответ на этот вопрос для разных компаний — разный.
Определяем цель разрабатываемой системы: «Сделать так, чтобы новые сотрудники с первого дня работали на 100%», к примеру.
Шаг второй
Вы определили клиентов и их выгоды, настает время формировать команду проекта. По классике в ней от пяти до девяти человек. В описываемом случае я бы включил туда HR-специалиста для роли Мастера, управляющего разработкой и одного или двух руководителей, заинтересованных во внедрении данной процедуры, добавил людей, готовых быть наставниками, и пару новичков, только что принятых на работу в компанию. Выгода — возможность сначала не вовлекать в разработку никого, кроме членов команды и первые решения обкатать на себе.
Как вариант сформируем команду только из руководителей разного уровня. В этом случае на начальном этапе необходимый опыт она получит, тестируя разработки на других людях. Это потребует чаще общаться со смежниками и большей терпимости организации к ошибкам.
И еще нужен «Владелец продукта», менеджер, который выступит посредником между командой разработки и остальными пользователями разрабатываемой системы. Владелец продукта имеет право принимать решения относительно ведущейся разработки и постоянно быть на связи, как с командой, так и с клиентами. В описываемом случае на эту роль напрашивается HR-директор.
Шаг третий
Продумываем регулярность циклов разработки — спринтов, которая определяется тем, насколько быстро можно делать готовые элементы продукта. При разработке системы адаптации, как мне кажется, еженедельно будут появляться законченные элементы, которые можно внедрить в практику.
Если бы речь шла, например, о разработке новой системы мотивации, где было бы необходимо проводить исследования и строить математические модели — длительность спринта окажется выше. Но не стоит делать ее дольше месяца.
Стартуем!
На входе команда определяет цели на ближайший спринт: на неделю в нашем примере. Пример задач на первую неделю проекта:
- Найти желающих быть наставниками.
- Прикрепить к наставникам новичков.
- Описать требования к наставникам.
- Составить список обязательной информации, с которой должны быть ознакомлены новички:
1) …
2) …
3) …
- Обобщить успехи и неудачи на данном спринте.
И для каждой задачи отвечаем на вопросы:
Ценность решения для конечных пользователей / клиентов. Насколько решение продвигает нас к цели.
- Объем работы, необходимой, чтобы решить задачу(в человеко-днях).
- Из ответов на эти вопросы расставляем приоритеты.
В классической методологии предполагаются ежедневные 15-ти минутные совещания команды. Рекомендую придерживаться этого подхода.
А вот добиться того, чтобы команда делала только данный проект и не допускать многозадачности — увы, невозможно в большинстве случаев. Поэтому планируем с учетом ограничений по ресурсам. Оцените время, которые каждый человек выделяет под этот проект, и соотнесите с ним необходимые трудозатраты. Но оставляйте общекомандную ответственность за результат.
Конец первой недели
Система заработала и принесла первые результаты. У нас, скорее всего, уже есть наставники и их подопечные, произошли какие-то действия и можно сделать первые выводы. Поэтому проводим ретроспективное совещание, подводим итоги и отвечаем на два вопроса:
- Каким образом мы можем работать лучше в следующем спринте?
- Что нам мешало в этом спринте? Что снижало скорость?
На следующей неделе стартуем новый спринт, заново определяя его задачи с учетом полученного опыта.
Важные замечания и ответы на вопросы
Обратите внимание: прошла неделя, а мы уже запустили работающую систему. Пусть пока она распространяется только на трех человек, входящих в команду, но мы уже получили опыт из практики. А поскольку мы этот опыт осмысляем и дорабатываем, то можем поставить задачу в следующем спринте запустить систему на тестовом подразделении. Или понять, что мы к этому еще не готовы и нам надо сделать еще несколько шагов.
Главная выгода Agility-подхода — быстрое «столкновение с реальностью» и низкая цена ошибки. Мы можем и должны оперативно вносить изменения в планы. На втором шаге может выясниться, что несколько подопечных на одного наставника — плохая идея. Или что у новичков возникает так мало вопросов, что наставники недозагружены.
Мы понимаем, что есть знания, которые не могут быть эффективно переданы наставниками, а нужны специальные курсы на входе в компанию. Или — что лучшим наставником является непосредственный руководитель сотрудника.
Первое возражение, которое я слышу от клиентов: «Для процессов типа адаптации мы можем попробовать, а как быть с системой мотивации, например? Мы же не платить людям сегодня так, а завтра по-другому». Верно. Но тогда надо построить модель. Внедрить процесс виртуально. В одной компании людям, вовлеченным в программу, даже выдавали специально напечатанные «виртуальные» деньги, чтобы они почувствовали, как это все будет на самом деле. И есть много аспектов, которые проверить необходимо: создание отчетов, ведение баз данных, мотивационные встречи…
Второй выигрыш такого подхода — разработка может пойти не так, как мы планировали изначально, и компания получит иной продукт, совсем не тот, который запускала. Удивительно, что я называю это выигрышем? Ведь в классическом варианте управления проектами это как раз показатель провала?
Дело в том, что в начале каждого спринта, как вы помните, мы задаем вопрос: «А какие решения обладают максимальной ценностью для конечных пользователей?» И они бывают абсолютно неожиданными! Один из наших клиентов, разрабатывая систему адаптации, понял, что ему нужны не наставники, а обучающие курсы и мотивационные мероприятия для людей на входе. А вместо наставничества — полевой коучинг. Теперь сотрудники, поступающие на работу в эту компанию, обедают с генеральным директором (не обязательно в первый день, но в течение двух недель такой обед состоится). Для этой корпоративной культуры это оказалось идеальным решением. И конечно такой ход никакой консультант не придумал бы.
«Побочное» следствие такого подхода — меньше бюрократии и ненужных бумажек.
А когда мы прекращаем разработку?
В тот момент, когда Владелец продукта говорит: «Хватит! Цели разработки достигнуты, клиенты довольны в оптимальной степени. Мы все сделали и быстро, и правильно!»
Внедрение Agility-подхода требует готовности разговаривать и слышать, отказа от убежденности в своей правоте, как со стороны содержательных специалистов, так и со стороны заказчика. Будьте готовы быстро менять привычные методы работы!
Источник : hrdocs.ru
