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

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

У начинающих менеджеров часто возникают проблемы, для решения которых им очень хочется вернуться в роль специалиста (разработчика, тестировщика). Например, у меня было такое, когда из одного из моих трёх проектов уволился программист. Я от безысходности (как мне казалось) стал его заменять, чтобы не останавливать проект. В результате я и программировал, и руководил проектами, и это было очень тяжело. Знаю много примеров, когда менеджеры поступали так же.

В конце концов ведь от менеджера требуют выполнения проектов. А что ему для этого надо делать, неважно. Если ему нужно самому писать код, то пусть пишет. Так ведь? Не совсем.

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

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

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

История от моего читателя Алексея, который любезно поделился своим опытом, за что ему большое спасибо. Пересказываю её тут своими словами:

Алексей был опытным разработчиком (Java/Scala developer/Data Engineer с опытом в C++), но его поставили на проект с абсолютно незнакомыми ему технологиями (web + Python + Front End). Причём времени на “раскачку” ему не дали, и ему сразу пришлось принимать важные технические решения, вроде выбора технологического стека для проекта и решения проблем с производительностью. Из-за этого Алексей иногда делал задачи дольше, чем мог бы, а его оценки были неточными.

Алексей старался закрыть пробелы в своих знаниях курсами, статьями и видео, но у него недавно родился ребёнок, и поэтому вне работы свободного времени было немного.

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

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