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

– Константин, мне хотелось бы из разработчиков стать менеджером в ближайшее время. Что вы мне посоветуете?

– Андрей, главный совет для тебя, это научись принимать решения. Для менеджера это очень важно. Например, ты мне рассказывал про ваш переезд в Москву, но так, будто это за тебя решили, а не ты согласился.

– Но ведь это  не моё решение! Это моя девушка хочет, а я не уверен.

– Но ведь ты точно переезжаешь?

– Да, уже билеты куплены.

– Значит, ты принял решение.

– Ну… я бы так не сказал…

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

Возможно, вы слышали оправдания разработчика, когда ему указывали на его кривые коммиты на его старом проекте: “Да это не я такой! Там все так писали, хотя я был против! Тимлид коммиты откатывал, если в них хотя бы пары багов сразу не было! Заказчик требовал, чтобы билд всегда сломан был! Я хотел нормально писать, но мне не давали! Да я даже лучше код делал, чем он был, только это незаметно на общем уровне”. Все эти оправдания разной степени правдоподобности не имеют никакого значения. Разработчик отвечает за код, с которым он работает.

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

Менеджер или Специалист

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

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

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

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

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

Кейс "Менеджер-программист"

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

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

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

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

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

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

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

Менеджер был доволен собой. Он сказал Алексею подумать и принять решение, чей код идёт в результате в продакшн.  Есть код Алексея, который писался две недели и всё ещё тормозит, а есть код Игоря, который написан всего за два дня и просто летает. Может, не рисковать и использовать изящное и простое решение Игоря?