Статьи по рубрикам
Показать все
Отдаем журнал бесплатно!

«Бриллианты» опыта

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

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

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

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

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

Компания, в которую меня пригласили, была и остается лидером в сегменте программно-аппаратных комплексов. Штат разработчиков медленно, но постоянно растет и на данный момент составляет 300 человек. Основная часть — это программисты, сотрудники инсталляции и технической поддержки.

Для начала я собрала доступную информацию в целом по IT-компаниям — поговорила о системах мотивации с пятью разработчиками из США, Израиля, России и Украины. Замечу, что рынок труда настолько дефицитный, что за 3 часа после размещения резюме ведущего разработчика количество приглашений на собеседование составляло от 30 до 50. HR-ы из IT-компаний, конечно, люди общительные, но все равно получить достоверную информацию о системах премирования компаний сложно.

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

Далее я подробно изучила бизнес-процессы компании — это было достаточно легко, так как в организации уже пять лет функционировала система менеджмента качества ISO. Ландшафт процессов был понятен, производство и другие функции ориентировались на выполнение набора метрик, связанных с удовлетворенностью потребителя. Вся деятельность фиксировалась в EMS-системе и дополнительных программах, например Jira[1].

Система мотивации была достаточно простой и понятной. Премии выплачивались регулярно, размер определял руководитель подразделения в рамках имеющегося у него бюджета. Анализ выплат показывал, что премии получали 85 % сотрудников. И в целом складывалось ощущение справедливости и адекватности распределения премий.

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

Я начала серию встреч с руководителями подразделений для того, чтобы выявить и описать зависимости выплат и структурировать все это в систему целей и KPI. И уже на этом этапе встретила уверенное сопротивление. Менеджеры скептически относились к введению каких-либо показателей эффективности. Основной аргумент — работа разработчика ПО сродни работе творческих специалистов и не поддается оцифровке. Я прочитала десятки статей о мотивации разработчиков. Есть ресурсы, где сами разработчики пишут на организационные темы. Типичное отношение к KPI: «В нашей сфере люди работают в основном потому, что им это интересно. Не надо им мешать тупыми корпоративными правилами»[2].

Я решила пойти длинным путем — провести ряд управленческих тренингов для руководителей и таким образом повлиять на культуру менеджмента в компании. Сама разработала содержание программы, провела тренинги. Безусловно, это помогло найти контакт с тимлидами и менеджерами. Мы выслушали друг друга и обсудили факторы мотивации. Далее я подтянула серьезную артиллерию — пригласила провести тренинг признанного профессионала в IT Сергея Архипенкова. В его книге «Руководство командой разработчиков программного обеспечения. Прикладные мысли» представлены четкая структура и особенности работы с персоналом в IT. Он пишет: «Разработчик состоит из четырех компонентов: тело, сердце, разум и душа. 1. Телу необходимы деньги и безопасность. 2. Сердцу — любовь и признание. 3. Разуму — развитие и самосовершенствование. 4. Душе — самореализация». Программа его тренинга не была посвящена разработке KPI, но касалась этой темы. Сергей приводил примеры IT-компаний, где были внедрены показатели эффективности.

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

Метриками разработки ПО являются:

1) сравнение плановых и фактических трудозатрат на производство ПО;

2) эффективность устранения дефектов (Defect Removal Efficiency DRE) — величина, которая показывает процентное отношение найденных и устраненных ошибок во время разработки и тестирования внутри производителя по сравнению с количеством ошибок, о которых сообщают пользователи на протяжении первых 90 дней использования программы. Если разработчики нашли 90 ошибок, а пользователи сообщили о 10 ошибках за три месяца, то DRE равняется 90 %.

Таким образом, качество и интенсивность производства контролировались системой СМК. Руководители не нуждались в дополнительном инструменте мотивации достижения показателей.

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

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

Это не была в чистом виде оценка деятельности или оценка компетенций. Раз в полгода руководитель в одностороннем порядке проводил оценку эффективности конкретного сотрудника за определенный период, а также оценивал вероятность последствия его ухода из компании, указывал, кто сможет заменить его в случае необходимости. Я предвижу удивление адептов оценочных диалогов, взаимодействия менеджера и сотрудника, культуры обратной связи. Но это суровое IT. Конечно, диалоги присутствуют, есть развивающая обратная связь, планирование развития. Но в вопросах премирования компания доверяет менеджеру. Справедливости ради скажу, что корпоративная культура компании открыта, и в случае менеджерской несправедливости замалчиваться сотрудником это не будет, потому что на рынке для любого сотрудника найдется сразу же 3–4 предложения на тех же финансовых условиях.

В качестве ключевых точек оценки персонала я предложила следующие:

1) оценка совокупного дохода сотрудника в текущем периоде (0 — ниже рынка, 1 — соответствует рынку, 2 — выше рынка), учитывая оклад и все остальные выплаты;

2) оценка личностных компетенций;

3) оценка профессиональных компетенций;

4) влияние ухода сотрудника на рабочий процесс;

5) субъективная оценка вероятности ухода сотрудника из компании;

6) наличие кадрового резерва на данную позицию (если нет резерва среди специалистов, указать — «внешний»);

7) стаж на данной позиции.

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

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

 

[1]  Jira — коммерческая система отслеживания ошибок. Предназначена для организации взаимодействия с пользователями, хотя в некоторых случаях используется и для управления проектами. Разработана компанией Atlassian.

[2] Владимир Завертайлов. KPI, или Пособие по командному самоубийству. https://habrahabr.ru/post/152445/.

Юлия КУРИЛОВА, директор по персоналу компании «МФИ СОФТ»

Статья опубликована в журнале «Современные технологии управления персоналом» № 2, 2018.

Отдаем журнал бесплатно!

«Бриллианты» опыта

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

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

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

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

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

Компания, в которую меня пригласили, была и остается лидером в сегменте программно-аппаратных комплексов. Штат разработчиков медленно, но постоянно растет и на данный момент составляет 300 человек. Основная часть — это программисты, сотрудники инсталляции и технической поддержки.

Для начала я собрала доступную информацию в целом по IT-компаниям — поговорила о системах мотивации с пятью разработчиками из США, Израиля, России и Украины. Замечу, что рынок труда настолько дефицитный, что за 3 часа после размещения резюме ведущего разработчика количество приглашений на собеседование составляло от 30 до 50. HR-ы из IT-компаний, конечно, люди общительные, но все равно получить достоверную информацию о системах премирования компаний сложно.

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

Далее я подробно изучила бизнес-процессы компании — это было достаточно легко, так как в организации уже пять лет функционировала система менеджмента качества ISO. Ландшафт процессов был понятен, производство и другие функции ориентировались на выполнение набора метрик, связанных с удовлетворенностью потребителя. Вся деятельность фиксировалась в EMS-системе и дополнительных программах, например Jira[1].

Система мотивации была достаточно простой и понятной. Премии выплачивались регулярно, размер определял руководитель подразделения в рамках имеющегося у него бюджета. Анализ выплат показывал, что премии получали 85 % сотрудников. И в целом складывалось ощущение справедливости и адекватности распределения премий.

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

Я начала серию встреч с руководителями подразделений для того, чтобы выявить и описать зависимости выплат и структурировать все это в систему целей и KPI. И уже на этом этапе встретила уверенное сопротивление. Менеджеры скептически относились к введению каких-либо показателей эффективности. Основной аргумент — работа разработчика ПО сродни работе творческих специалистов и не поддается оцифровке. Я прочитала десятки статей о мотивации разработчиков. Есть ресурсы, где сами разработчики пишут на организационные темы. Типичное отношение к KPI: «В нашей сфере люди работают в основном потому, что им это интересно. Не надо им мешать тупыми корпоративными правилами»[2].

Я решила пойти длинным путем — провести ряд управленческих тренингов для руководителей и таким образом повлиять на культуру менеджмента в компании. Сама разработала содержание программы, провела тренинги. Безусловно, это помогло найти контакт с тимлидами и менеджерами. Мы выслушали друг друга и обсудили факторы мотивации. Далее я подтянула серьезную артиллерию — пригласила провести тренинг признанного профессионала в IT Сергея Архипенкова. В его книге «Руководство командой разработчиков программного обеспечения. Прикладные мысли» представлены четкая структура и особенности работы с персоналом в IT. Он пишет: «Разработчик состоит из четырех компонентов: тело, сердце, разум и душа. 1. Телу необходимы деньги и безопасность. 2. Сердцу — любовь и признание. 3. Разуму — развитие и самосовершенствование. 4. Душе — самореализация». Программа его тренинга не была посвящена разработке KPI, но касалась этой темы. Сергей приводил примеры IT-компаний, где были внедрены показатели эффективности.

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

Метриками разработки ПО являются:

1) сравнение плановых и фактических трудозатрат на производство ПО;

2) эффективность устранения дефектов (Defect Removal Efficiency DRE) — величина, которая показывает процентное отношение найденных и устраненных ошибок во время разработки и тестирования внутри производителя по сравнению с количеством ошибок, о которых сообщают пользователи на протяжении первых 90 дней использования программы. Если разработчики нашли 90 ошибок, а пользователи сообщили о 10 ошибках за три месяца, то DRE равняется 90 %.

Таким образом, качество и интенсивность производства контролировались системой СМК. Руководители не нуждались в дополнительном инструменте мотивации достижения показателей.

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

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

Это не была в чистом виде оценка деятельности или оценка компетенций. Раз в полгода руководитель в одностороннем порядке проводил оценку эффективности конкретного сотрудника за определенный период, а также оценивал вероятность последствия его ухода из компании, указывал, кто сможет заменить его в случае необходимости. Я предвижу удивление адептов оценочных диалогов, взаимодействия менеджера и сотрудника, культуры обратной связи. Но это суровое IT. Конечно, диалоги присутствуют, есть развивающая обратная связь, планирование развития. Но в вопросах премирования компания доверяет менеджеру. Справедливости ради скажу, что корпоративная культура компании открыта, и в случае менеджерской несправедливости замалчиваться сотрудником это не будет, потому что на рынке для любого сотрудника найдется сразу же 3–4 предложения на тех же финансовых условиях.

В качестве ключевых точек оценки персонала я предложила следующие:

1) оценка совокупного дохода сотрудника в текущем периоде (0 — ниже рынка, 1 — соответствует рынку, 2 — выше рынка), учитывая оклад и все остальные выплаты;

2) оценка личностных компетенций;

3) оценка профессиональных компетенций;

4) влияние ухода сотрудника на рабочий процесс;

5) субъективная оценка вероятности ухода сотрудника из компании;

6) наличие кадрового резерва на данную позицию (если нет резерва среди специалистов, указать — «внешний»);

7) стаж на данной позиции.

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

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

 

[1]  Jira — коммерческая система отслеживания ошибок. Предназначена для организации взаимодействия с пользователями, хотя в некоторых случаях используется и для управления проектами. Разработана компанией Atlassian.

[2] Владимир Завертайлов. KPI, или Пособие по командному самоубийству. https://habrahabr.ru/post/152445/.

Юлия КУРИЛОВА, директор по персоналу компании «МФИ СОФТ»

Статья опубликована в журнале «Современные технологии управления персоналом» № 2, 2018.

Подписка для физических лицДля физических лиц Подписка для юридических лицДля юридических лиц Подписка по каталогамПодписка по каталогам