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

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

И ещё иногда менеджеры смешивают доверие и технический уровень: “Задача сложная, Вася никогда не работал над такими, он может не справиться”. Это не имеет никакого отношения к доверию. Доверие – это про то, что Вася будет стараться изо всех сил (может и невеликих), а не про гарантию, что Вася справится с задачей. Работа с рисками, по-прежнему, на менеджере. Даже, если вы доверяете Васе, вы можете и должны помогать ему, контролировать его, организовывать ревью его работы более опытными разработчиками и т.д. Потому что никто (и вы в том числе) не застрахован от ошибок. И наличие ошибок не должно влиять на доверие.

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

Так как вопрос доверия является ключевым и часто сложным для усвоения я хотел бы конспективно перечислить ключевые моменты:

Менеджер должен доверять своей команде, так как нет никакого практического смысла ей не доверять;

Менеджер не должен работать с теми людьми, которых он считает недостойными доверия;

Менеджер не должен путать доверие и гарантию от ошибок. Каждый может ошибиться;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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