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

Бывают очень разные ситуации. Например, если мы говорим про разработчика, и он работает в проекте Time&Material, то замена его на двух других разработчиков – это повышение прибыли компании, а не траты. Потому что заказчик будет платить за двух разработчиков. А вот повышение зарплаты на 50% будет тратой, так как заказчик, скорее всего, откажется платить за того же разработчика в полтора раза больше.

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

И наконец, произошедшее реально могло быть ошибкой менеджера. И что? Ошибки делают многие и эта ошибка отнюдь не настолько дорогостоящая, чтобы делать вывод о профнепригодности менеджера. Как вы видите, у такого решения есть реальные плюсы, а вот бесспорный минус только один – некоторый проигрыш в заработной плате в ближней перспективе. Это не то, на чём стоит так уж заморачиваться.

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

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

И таким традиционным средством мотивации часто считают премию. Её получение не так жёстко регламентировано законами. Вполне можно награждать разработчиков, чтобы они были мотивированы и делали какие-то подвиги.

За подвиги в первую очередь и пытаются наградить. Если разработчик как-то спас проект, или его техническое предложение сильно понравилось заказчику, или благодаря ему был выигран пресейл, то вполне логично дать такому разработчику денежную премию.

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

К тому же работа в индустрии IT командная, поэтому часто заслуга не принадлежит какому-то одному разработчику. Каждый успешный проект – это подвиг, ради которого старается вся команда. Измерить этот уровень стараний каким-то объективным способом не представляется возможным, и понятные цели установить не получается.

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

Такие, казалось бы правильные рассуждения распространены. В очень многих компаниях именно так премирование и выглядит. Но можно заметить, что мы от мотивации достижения (сделай хорошее – и тебя наградят) перешли к мотивации избегания (не делай плохого – и тебя наградят). Вместо того чтобы давать премию хорошим работникам, мы лишаем премии нерадивых.

Так в чём проблема? Лишение премии – это освящённый многими десятилетиями принцип, который всегда работал. Чего это он вдруг стал плохим?

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