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

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

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

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

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

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

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

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

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

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

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