Ошибки сложных систем В одной из компаний, где я работал у нас была… — HR Сугробов — TG.ME

Ошибки сложных систем В одной из компаний, где я работал у нас была довольно хорошо выстроена система целеполагания – оценки – вознаграждения. Сотрудникам ставились цели (бизнесовые и на развитие), раз в полгода проводилась оценка, и по итогам премиальный фонд распределялся в зависимости от оценки по коллективу. Правила были довольно чёткие, процессы хорошо регламентированы: как цели ставятся, как считаются и оцениваются результаты, как распределяются премии. И вот однажды приходит ко мне сотрудник поддержки и говорит: «Хочу заявить, что на ревью меня несправедливо оценили». А история там такая: парня взяли в большой спешке, почти без опыта, умом и рвением он не отличался, но ребятам из IT его было жалко, и они пытались его вытянуть, давали ему задания на развитие. Такой сын полка, в общем. Открываю его бланк целей, а там все 100% целей – на развитие: - Пройти такой-то тест с результатом не ниже определённого. - Выучить 10 основных команд Bash. - Что-то ещё про «стать полноценным инженером». Зову его руководителя и руководителя руководителя, берём бланк целей, и я прошу сотрудника повторить результат каждой из целей: пройти тест, написать в консоли 10 команд и выполнить третье задание. Оказывается, что тест он полгода проходил каждый день и научился отвечать правильно наугад, а команды для Bash просто гуглил. С третьей целью было то же самое. Де-юре он цели выполнил, но по духу, конечно, это была чистая профанация. В итоге я объявил, что его действительно оценили предвзято, но его реальная оценка ниже той, которую поставил руководитель. То есть мы тратим кучу времени на постановку целей, каскадируем их по компании, в середине срока открываем окно для изменения целей, потом запускаем цикл оценки, проводим калибровку результатов, смотрим на распределение оценок по кривой Гаусса, считаем премии, тратим сотни часов HR и руководителей на весь этот процесс, чтобы какой-то хитрожопый сотрудник эту систему хакнул и заставил нас нарушать свои же правила в попытке восстановить баланс. Так же и руководители в итоге подгоняют оценку под своё мнение о сотрудниках. Это суперчастый пример ошибки при внедрении новых процессов: когда менеджмент внедряет новые практики – почти всегда в порыве энтузиазма и от желания всё контролировать – системы получаются избыточно сложными. Подход «а давайте каждому разработаем модель компетенций из 100500 штук, плюс с помощью алгоритма будем оценивать вклад каждого в успех» приводит к тому, что появляются лазейки, чтобы систему хакнуть, а исполнение нового процесса настолько трудозатратно, что просто укладывает менеджмент на лопатки, и все бегают в пожаре. Отсюда очень простой вывод: внедрять сложные вещи лучше с простых версий, не пытаясь сразу создать космолёт. Простая система, как правило, надёжнее, менее трудозатратна, и хакнуть её сложнее. А каждое усложнение нужно пропускать через призму: сколько дополнительной работы нужно будет проделать vs. выгода, которую мы получим. P.S. Ну а целеполагание-оценку я сейчас внедряю так: - Цели ставятся верхнеуровневые на подразделение и всё. Бонусы платятся только за результат подразделения, пропорционально ЗП и грейду. - Компетенции оцениваются отдельным процессом и оценка влияет именно на повышение. По результатам даётся обратная связь и могут формироваться индивидуальные планы развития.