Книга Как хорошему разработчику не стать плохим менеджером - Константин Борисов

Заморозка зарплаты во время общего роста цен фактически означала падение реальных доходов. Это коснулось абсолютно всех. Разработчики, тестировщики, аналитики и менеджеры стали жить всё хуже и хуже. Но открытая позиция компании всем понравилась. Большинство сотрудников проработали много лет в компании, очень её ценили и готовы были потерпеть временные трудности, чтобы помочь компании, которая была для них похоже на семью.

“Заморозка” зарплат длилась пару лет. И люди терпели. Абсолютное большинство не искало возможности сменить работу ради более высокой зарплаты, хотя предложений на рынке становилось всё больше и больше.

И вот настал день, когда компания официально объявила, что тяжёлые времена прошли, что компания теперь планирует расширяться и что зарплаты будут повышены. Директор поблагодарил всех за ту помощь, которую работники оказали компании во время кризиса. И все зарплаты были повышены процентов на 15.

А вот после этого повышения многие люди как раз и начали искать себе другое место работы. Почему? Потому что это повышение оказалось гораздо меньше, чем инфляция за эти пару лет. Кризис компанию не пощадил и она не смогла предоставлять такой же уровень зарплат, как до кризиса. Плюс сотрудники уже не считали необходимым терпеть какие-то невзгоды, ведь кризис официально закончился.  Так вот и получилось, что массовое повышение зарплат привело к увольнениям.

После этой истории меня спрашивают, не было бы разумней со стороны компании, не объявлять об окончании кризиса и о повышении зарплат, а продолжать работать дальше. Ведь сотрудники бы продолжали “поддерживать родную компанию” и не увольнялись бы ещё год-другой. Компания бы заработала больше денег. А так она потеряла деньги на повышении зарплат, а потом ещё и на увольнениях. Компания же работает для прибыли, так зачем её терять?

Так вот компания поступила абсолютно правильно. Заметьте, что как раз открытая и честная позиция компании помогла ей пережить трудные годы. Если бы компания начала бы развиваться и набирать людей, не “размораживая” зарплаты, то команда мгновенно бы поняла, что её обманывают. Тогда компания потеряла бы не только людей (причём гораздо большее количество), но и имидж. Потери даже в средней перспективе были бы гораздо больше, чем “сэкономленные” на зарплатах деньги.

Но в целом описанная ситуация довольно стандартна. Часто люди уходят сразу после повышения зарплаты, после ежегодной аттестации. До повышения они надеются на определённый уровень зарплаты, а после, если надежды не оправдываются, то они решают реализоваться в какой-нибудь другой компании.

Премия разработчика

Далеко не все менеджеры определяют премиальную систему компании, но всем им приходится работать с последствиями её применения. К тому же рассмотрение проблем с премиями показывает общие проблемы с денежной мотивацией. Я вижу некоторые плюсы от ежегодной премии (13 зарплата) или бонусов за завершение релиза. Но ежемесячная премия даёт больше проблем, чем преимуществ.

Почему? Источник этого в том, что в IT пока не придумали действительно эффективных метрик для измерения работы разработчика (как и тестировщика, аналитика и менеджера, но об этом пока не будем). Притчей во языцех является измерение работы количеством строчек кода и то, в какой ужас превращается код при этом.

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

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

К тому же в большинстве компаний премии строятся не по логике достижения, а по логике избегания. То есть декларируется принцип: “Не делай вот так, а то мы лишим тебя премии!” Нормой является наличие премии, а отсутствие её используют как наказание. Это сильно мешает созданию высокомотивированных команд, так как постоянно висящая над человеком угроза наказания давит инициативу.

Чтобы все эти проблемы были не такими значительными, премию делают низкой: 10%..15%. Разработчики обычно не сильно спорят из-за такой небольшой части своей зарплаты. Но это кроме снижения эффективности мотивации даёт еще один неожиданный эффект.

Разработчик может согласиться на лишение премии и отказаться от выполнения этих установленных норм. И менеджерам очень тяжело с этим работать. Это как со штрафом за превышение скорости. Водитель превысил – получил штраф. И всё, этим он искупил проступок. Да, он считается нарушителем и потом это может играть какую-то роль, но за конкретное превышение скорости он рассчитался.

У меня был такой случай в компании, где оплата разработчиков была почасовая, но чтобы стимулировать их работать 40 часов в неделю, им выдавалась премия 10%, если они работали полную рабочую неделю. И вот ко мне пришёл разработчик и сообщил, что у него очень много времени отнимает дополнительное образование и он решил отказаться от премии и работать полдня. А меня как менеджера такое не устраивает. Мне он нужен на проекте хотя бы 30 часов в неделю. А человек возмущён. Если он будет работать 30 часов, то ему будет очень тяжело, а его всё  равно накажут лишением премии. Хотя он идёт мне навстречу. В IT проектах важна командная работа, а премия концентрирует внимание разработчика на его собственных показателях.

К тому же любая премиальная система снижает управляемость. Примерно на уровне, когда премия составляет 80% зарплаты работник становится полностью неуправляемым и делает не то, что ему говорит его менеджер, а то, что требует его премиальная система (см. книгу “Мотивация на 100%. А где же у него кнопка?” Ивановой С.В). Но даже при 10% иногда премия мешает.

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

Забавная ситуация случилась как-то со мной. Я  работал в компании, где премия составляла значительную часть, примерно 30% моей зарплаты и была квартальной. Причём, сумма премии от меня зависела не сильно. Премия зависела от курса доллара, прибыли за квартал и тому подобных вещей. А от меня зависело, получаю я премию или нет. То есть я работал 3 месяца, получая откровенно маленькую зарплату, а потом получал некоторую сумму денег, величину которой мне никто не мог сказать заранее.