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

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

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

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

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

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

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

История про ненужные сложности

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

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

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

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

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

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

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

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

Исправление ошибок

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

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

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

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

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

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

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

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

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

Гораздо более правильным было бы признать свою ошибку и не говорить ни о каком “исправлении”, а говорить о будущем. Примерно так: “Вася, мне очень жаль, что ты решил нас покинуть. Очевидно, что это моя вина. Я недостаточно приложил усилий к твоему переводу. Мне жаль тебя терять и я хотел бы сделать всё, чтобы ты остался. Могу предложить тебе переход на любой другой проект вот из этого списка прямо с сегодняшнего дня. Текущему проекту будет тяжело, если ты уйдёшь, но ты с него уйдёшь в любом случае, а мне хотелось бы, чтобы ты остался в компании”. При таком подходе, когда менеджер признаёт свои ошибки и даёт человеку какой-то выбор, шанс на то, что человек останется в команде гораздо выше.