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

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

Одно время я вёл примерный учёт заведённых на меня багов. Для разработчика каждый баг можно считать официальной регистрацией сделанной им ошибки. Вести счёт я прекратил, когда багов стало больше 3000. Менеджер делает свою работу в тех же условиях неопределённости, что и разработчик, поэтому в IT проекте будут менеджерские ошибки. И их будет много.

Иногда бывает, что разработчик, которому сказали, что по его функционалу нашли 20 багов, удивляется и начинает их разбирать: “Ну, этот баг – это не я виноват, это там у нас дизайн кода такой кривоватый. А эти два бага надо в один объединить, и вообще это, скорее, в требованиях ошибка. А эти баги я уже исправил, это у вас просто код старый в тестирование ушёл. А эти баги очень мелкие, они не считаются. В общем, я реализовал всё без ошибок!”

Очень странно слушать такие речи от разработчика, но совсем недопустимо, когда подобное говорит менеджер. Вместо оправданий менеджеру нужно брать на себя ответственность. Любая ошибка, сделанная командой – это ошибка менеджера. Менеджеру полезно это не только знать, но и признавать публично.

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

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

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

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

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

Нужно быть очень аккуратным в выборе слов, чтобы подать пример. Менеджер должен сказать то, что он хотел бы услышать от каждого из своей команды. Например: “Как вы уже знаете, продуктовый сервер заказчика на новой версии не работает, старая версия не восстанавливается, и заказчик несёт большие убытки. Причина может быть в том, что я запланировал недостаточно тестирования на этот релиз. Или в целом процесс релиза я не сделал надёжным. Или, может, мне надо было сильнее вовлечь заказчика в процесс проверки релиза. Точная причина неизвестна и не важна. Над предотвращением таких проблем в будущем мы подумаем позднее, когда пожар потушим. А пока, кто что может предложить для того, чтобы починить сервер сегодня, чтобы, когда клиенты заказчика проснулись, они могли бы работать?”

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

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

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

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

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

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