После этой истории меня спрашивают, не было бы разумней со стороны компании, не объявлять об окончании кризиса и о повышении зарплат, а продолжать работать дальше. Ведь сотрудники бы продолжали “поддерживать родную компанию” и не увольнялись бы ещё год-другой. Компания бы заработала больше денег. А так она потеряла деньги на повышении зарплат, а потом ещё и на увольнениях. Компания же работает для прибыли, так зачем её терять?
Так вот компания поступила абсолютно правильно. Заметьте, что как раз открытая и честная позиция компании помогла ей пережить трудные годы. Если бы компания начала бы развиваться и набирать людей, не “размораживая” зарплаты, то команда мгновенно бы поняла, что её обманывают. Тогда компания потеряла бы не только людей (причём гораздо большее количество), но и имидж. Потери даже в средней перспективе были бы гораздо больше, чем “сэкономленные” на зарплатах деньги.
Но в целом описанная ситуация довольно стандартна. Часто люди уходят сразу после повышения зарплаты, после ежегодной аттестации. До повышения они надеются на определённый уровень зарплаты, а после, если надежды не оправдываются, то они решают реализоваться в какой-нибудь другой компании.
Премия разработчика
Далеко не все менеджеры определяют премиальную систему компании, но всем им приходится работать с последствиями её применения. К тому же рассмотрение проблем с премиями показывает общие проблемы с денежной мотивацией. Я вижу некоторые плюсы от ежегодной премии (13 зарплата) или бонусов за завершение релиза. Но ежемесячная премия даёт больше проблем, чем преимуществ.
Почему? Источник этого в том, что в IT пока не придумали действительно эффективных метрик для измерения работы разработчика (как и тестировщика, аналитика и менеджера, но об этом пока не будем). Притчей во языцех является измерение работы количеством строчек кода и то, в какой ужас превращается код при этом.
На каждом проекте от разработчиков требуется разное: где-то тонкое знание редких технологий, где-то умение договориться о технических вопросах с заказчиком, где-то эффективная работа с тестировщиками и аналитиками. Менеджер видит достижения каждого, но его оценка субъективна и поэтому не всегда подходит для использования.
Поэтому в премии часто включают некие странноватые вещи, вроде количества отработанных часов, числа багов по реализованным тикетам или само число этих тикетов. И каждый месяц вы получаете разного рода конфликты с разработчиками, которые убедительно доказывают, что критерии премии не согласуются с качеством их работы.
К тому же в большинстве компаний премии строятся не по логике достижения, а по логике избегания. То есть декларируется принцип: “Не делай вот так, а то мы лишим тебя премии!” Нормой является наличие премии, а отсутствие её используют как наказание. Это сильно мешает созданию высокомотивированных команд, так как постоянно висящая над человеком угроза наказания давит инициативу.
Чтобы все эти проблемы были не такими значительными, премию делают низкой: 10%..15%. Разработчики обычно не сильно спорят из-за такой небольшой части своей зарплаты. Но это кроме снижения эффективности мотивации даёт еще один неожиданный эффект.
Разработчик может согласиться на лишение премии и отказаться от выполнения этих установленных норм. И менеджерам очень тяжело с этим работать. Это как со штрафом за превышение скорости. Водитель превысил – получил штраф. И всё, этим он искупил проступок. Да, он считается нарушителем и потом это может играть какую-то роль, но за конкретное превышение скорости он рассчитался.
У меня был такой случай в компании, где оплата разработчиков была почасовая, но чтобы стимулировать их работать 40 часов в неделю, им выдавалась премия 10%, если они работали полную рабочую неделю. И вот ко мне пришёл разработчик и сообщил, что у него очень много времени отнимает дополнительное образование и он решил отказаться от премии и работать полдня. А меня как менеджера такое не устраивает. Мне он нужен на проекте хотя бы 30 часов в неделю. А человек возмущён. Если он будет работать 30 часов, то ему будет очень тяжело, а его всё равно накажут лишением премии. Хотя он идёт мне навстречу. В IT проектах важна командная работа, а премия концентрирует внимание разработчика на его собственных показателях.
К тому же любая премиальная система снижает управляемость. Примерно на уровне, когда премия составляет 80% зарплаты работник становится полностью неуправляемым и делает не то, что ему говорит его менеджер, а то, что требует его премиальная система (см. книгу “Мотивация на 100%. А где же у него кнопка?” Ивановой С.В). Но даже при 10% иногда премия мешает.