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

Сергей был отличным парнем и очень опытным разработчиком, но скоро я согласился, что работать с ним невозможно. В компании менеджмент был слаб и Сергей этим нещадно пользовался. Он демонстративно игнорировал прямые указания и нужды других членов команды. Он затягивал разработку и внезапно пропадал без объяснения причин. Он делал некачественную работу и давно потерял доверие к компании, поэтому договориться с ним было невозможно. Единственный выход был – увольнение.

Я сообщил об этом владельцу компании и отделу HR, получив в ответ ожидаемое: “Мы же говорили!” Владелец сказал, чтоб я увольнял Сергея, как можно быстро, так как тот и так много вреда компании принёс.

С увольнением проблем не ожидалось. Сергей прекрасно понимал, что его поведение непрофессионально, и увольняться “по статье” не хотел. Так что он согласился расстаться миром и написать заявление по собственному желанию. Заявление на увольнение нужно было подписать у владельца компании, к нему я Сергея и отправил.

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

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

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

Исправление ошибок – это больная тема. Часто от разработчиков можно слышать про менеджеров: “Ну он же не с компьютерами работает, а с людьми! Тут ошибки исправить нельзя! Поэтому и допускать их нельзя!”

Конечно, на предложение менеджеру не допускать ошибок можно только предложить разработчикам писать без багов. Индустрия должна полностью преобразиться, чтобы такое было возможно.

А вот насчёт исправления ошибок ситуация интересней. Что подразумевает разработчик, когда говорит, что он исправил ошибку? Он подразумевает, что в код внесены изменения и баг, который там был, теперь отсутствует. Но разве такое “исправление” достаточно, чтобы действительно исправить весь нанесённый ущерб? Конечно, нет. Тестировщики потратили время, работая с неисправным билдом. А теперь еще новый заново тестировать. Другие разработчики мучались при реализации своих кусков, так как код работал некорректно. Заказчик, видел баг в трекере и терял доверие ко всей команде.

Если разработчик исправит злой баг, из-за которого долго лежал сервер, то ему не стоит говорить заказчику: “Я всё исправил, теперь всё хорошо!” Так как с точки зрения заказчика всё совсем не хорошо, и ему нужно что-то делать с толпой недовольных пользователей.

У менеджеров всё так же. Сделанные ошибки исправить совершенно нельзя, но можно как-то попробовать компенсировать нанесённый ущерб, и улучшить ситуацию в целом.

Так же, как разработчики считают, что они исправили баг и стало всё хорошо, некоторые менеджеры тоже считают, что они исправили проблему, и стало всё хорошо. Не стоит думать таким образом и, тем более, не стоит так говорить пострадавшим от этих менеджерских ошибок.

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