Как хорошему разработчику не стать плохим менеджером - читать онлайн книгу. Автор: Константин Борисов cтр.№ 20

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

Позиция работника: “Мне бы повысили зарплату на 50%, и я остался бы работать вечно”, очень наивна. Как показывает опыт, если ваш сотрудник заявил о желании уволиться, то даже, если вы его удержали, то он уволится в среднем через полгода. Поэтому часть менеджеров даже и не пытаются удержать людей.

Я лично считаю, что в IT нужно людей удерживать всеми силами, но в некоторых других областях людей заменить проще и руководители даже не пытаются научиться удерживать персонал. Но в любом случае, сотрудник который запросил повышение зарплаты на 50%, привносит очень высокие риски. Скорее всего, ему скоро станет скучно, или денег снова окажется мало, или что-то ещё случится, и он снова захочет такого повышения. В общем, повышение зарплаты – это, как минимум, временное решение, а то и не решение вовсе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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