Менеджер или Специалист
У начинающих менеджеров часто возникают проблемы, для решения которых им очень хочется вернуться в роль специалиста (разработчика, тестировщика). Например, у меня было такое, когда из одного из моих трёх проектов уволился программист. Я от безысходности (как мне казалось) стал его заменять, чтобы не останавливать проект. В результате я и программировал, и руководил проектами, и это было очень тяжело. Знаю много примеров, когда менеджеры поступали так же.
В конце концов ведь от менеджера требуют выполнения проектов. А что ему для этого надо делать, неважно. Если ему нужно самому писать код, то пусть пишет. Так ведь? Не совсем.
Для начала я хочу обратить внимание на то, что такие дилеммы возникают только у начинающих менеджеров. Почему? Потому что более опытный менеджер всё равно не сможет работать как специалист на своих проектах. Когда я развился как менеджер, то я никак не мог заменить ушедшего разработчика. Потому что у меня в подчинении была сотня человек и несколько проектов. Я не мог выделить даже полчаса, чтобы написать какой-то код. Плюс проекты были на технологиях, в которых я не специализировался. Тратить моё время на разработку было бы неразумно и неэффективно.
Такая картина у всех людей, которые развиваются в менеджменте. Работа специалиста и менеджера слишком отличаются, чтобы смешивать их. А если в будущем вы не сможете подменять специалиста, то почему бы не начать сразу работать на менеджерском уровне. В конце концов, вы же хотите быть менеджером? Ну и решайте проблемы как менеджер.
К слову, я, промучавшись с тем проектом без разработчика, в результате-таки пошёл договариваться с заказчиком о приостановке проекта. И направил усилия на поиск разработчика. В результате, привёл на проект разработчика, который классно решал все проблемы заказчика, и работу с которым до сих пор вспоминаю с большой теплотой.
Кейс "Менеджер-программист"
История от моего читателя Алексея, который любезно поделился своим опытом, за что ему большое спасибо. Пересказываю её тут своими словами:
Алексей был опытным разработчиком (Java/Scala developer/Data Engineer с опытом в C++), но его поставили на проект с абсолютно незнакомыми ему технологиями (web + Python + Front End). Причём времени на “раскачку” ему не дали, и ему сразу пришлось принимать важные технические решения, вроде выбора технологического стека для проекта и решения проблем с производительностью. Из-за этого Алексей иногда делал задачи дольше, чем мог бы, а его оценки были неточными.
Алексей старался закрыть пробелы в своих знаниях курсами, статьями и видео, но у него недавно родился ребёнок, и поэтому вне работы свободного времени было немного.
И вот в этом контексте и развернулась интересная история. Алексей работал над сложной задачей и потратил на неё 2 недели, но решение работало медленно. Главная сложность была в проблеме с производительностью использованного фреймворка в конкретном случае. Проблема была известной и общего решения не имела. Но хотя бы функционал работал.
И вот, когда Алексей бился над производительностью, его менеджер, Игорь, сообщил, что он сам делает эту задачу, и что он потратил всего 2 дня, и что у него проблем с производительностью нет. Игорю нужна была помощь Алексея, так как он всё-таки долго не программировал и не знал, как в новых фреймворках делаются некоторые вещи.
Алексей помог своему менеджеру доделать код. Код работал и работал быстро. Правда, он не соответствовал изначальным требованиям, но суть осталась верной. Можно было изменить требования под этот код и запустить в продакшн.
Алексей был поражён. Его менеджер, нетехнический специалист реализовал сложную задачу в пять раз быстрее, чем он сам. Как так-то?
Менеджер был доволен собой. Он сказал Алексею подумать и принять решение, чей код идёт в результате в продакшн. Есть код Алексея, который писался две недели и всё ещё тормозит, а есть код Игоря, который написан всего за два дня и просто летает. Может, не рисковать и использовать изящное и простое решение Игоря?
Алексей ушёл думать. Он решил докопаться до сути и погрузился в исследование решения Игоря. Почему оно проще и быстрее? Вскоре Алексей выяснил, что менеджер вместо работы с базой использовал заранее приготовленные файлики JSON с нужными данными и показывал только первые 1000 записей. Поэтому и производительность была нормальной. Когда эти хаки убрали, решение менеджера стало тормозить так же.
Алексей убедил команду, что надо в продакшене использовать его решение, так как оно соответствует изначальным требованиям. А чуть позже он смог и решить проблему с производительностью. Причём, решение было крайне нетривиальным и завязанным на конкретные структуры данных.