Agile пришел в HR – и быстро развивается

Джош Берсин

Я только что вернулся из Сингапура, где у меня была возможность встретиться со многими высокопоставленными HR-лидерами Азии. Это территория, где цифровой бизнес процветает, причем такие компании, как Grab (превосходящий Uber) и DBS (цифровой банк № 1 в мире) задают темп.

И когда я думаю о наших встречах, становится ясно, что одной из самых важных для эйчаров тем является принятие принципов Agile. Когда-то считавшиеся тайной методологией, используемой инженерами-программистами, концепты Agile широко распространяются в деловом мире. И они в корне меняют HR.

Agile — это философия, культура и набор методов управления. Позвольте немного раскрыть бэкграунд.

Agile Manifesto (Эджайл Манифест) впервые был написан в феврале 2001 года, когда группа разработчиков встретилась в Портленде, чтобы выяснить, как ускорить процесс программирования (они назвали это «экстремальное программирование».) Эти инженеры разработали набор принципов, которые позволили значительно ускорить и улучшить процесс разработки программного обеспечения.

Следует понимать, что в 1980-х и 1990-х годах требовались огромные команды для создания программного обеспечения, которые применяли для этого метод многолетнего «водопада». В увлекательной книге «Мифический человеко-месяц», написанной Фредом Бруксом из IBM (1975 г.), рассказывается о том, как большие проекты в IBM становились все медленнее и медленнее по мере добавления новых людей. Брукс экспериментировал с небольшими командами и открыл идеи Agile еще до того, как был написан манифест. (Скачайте книгу здесь, ее стоит прочитать.)

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

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

Его принципы были сосредоточены на трех фундаментальных вещах: во-первых, команды разработчиков должны были стать ближе к потребителям, чтобы обучаться и выполнять циклы в ускоренном режиме; во-вторых, им нужно было быстрее создавать программное обеспечение и передавать его клиентам; и в-третьих, они должны были координировать эти проекты без расходов на менеджеров среднего звена.

По мере развития принципов Agile, такие методы, как стендап-совещания (Stand-up meeting) (ежедневные встречи для обсуждения происходящего), SCRUM (метод простого управления проектами), MVP (минимально жизнеспособный продукт) и OKR (очень простой способ устанавливать цели и делиться ими) стали популярными артефактами. Я захожу во многие HR-департаменты и вижу, как небольшие коллективы в офисах со стикерами на стене пытаются «быть Agile».

Однако в действительности, как объясняет Маартен Ван Бик из банка ING, копирование этих инструментов не обязательно делает вас гибкими. Agile — это действительно философия: принятие решений на уровне знаний, предоставление людям возможности учиться и эксперименты с решениями, разработанными совместно с потребителями.

(Вот Маартен, объясняющий всё это.)

Если вы посетите ING, вы увидите множество небольших многофункциональных HR-команд, работающих вместе над различными программами. Люди регулярно выполняют определенные последовательности, и процесс вписывается в «цифровой темп» самого банка. Обучение и сотрудничество поощряются и подкрепляются, и люди переходят от проекта к проекту на протяжении всей своей HR-карьеры.

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

И так же, как Agile изменил разработку программного обеспечения, он изменит HR.

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

(ING практикует Agile в HR с огромным успехом, Sky в Великобритании делает это в L&D, и многие другие компании также.)

Agile-проектирование и Agile-обслуживание (DevOps для HR)

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

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

Одна из компаний, которые я недавно посетил, использует Agile в своем процессе управления эффективностью. Они не только используют OKR и другие гибкие подходы для сотрудников и менеджеров, но и разработали три «версии» процесса для тестирования в командах. Каждый из трех пилотных проектов содержит разные подходы к оценке и постановке целей, и они гибко используют «A-B-тестирование», чтобы решить, какие из них будут работать лучше всего.

Я верю, что гибкие принципы радикально изменят модели предоставления услуг. Зная, что многие из вас в течение последних нескольких лет проходили через HR-трансформации, которая зачастую были сосредоточены на создании центров передового опыта и поддержки, я бы предложил изменить это. В Agile нам нужны многофункциональные COE (центры управления, прим. переводчика) (ориентированные на решения, а не на HR-функции) и многофункциональные группы поддержки (типа DevOps).

С чего начать? Отличным примером является адаптация (в англ. версии onboarding, прим. переводчика) сотрудников и переход на другую работу. Это важные впечатления сотрудников, который всегда имеют кросс-функциональные границы.

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

Для оказания помощи по запросу нам понадобится сервисный центр, который понимает «процесс адаптации» и «процесс перехода на другую работу», а не просто нечто из разряда сервиса. Это означает, что нам нужен Agile-проект и Agile-модель для обслуживания и поддержки

(Дополнительные примеры читайте в статье Риины Хеллстрем о 8 способах применения Agile в HR.)

https://edwvb.blogspot.com