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

Я сам в своё время потратил очень много времени и сил на то, чтобы перевести свою карьеру на рельсы менеджмента. Пришлось иметь дело и с противодействием руководства, и с неприятными подковёрными играми, и с объективными обстоятельствами. Ну и кто мне виноват? Я же сам двигался к тому, о чём мечтал. Зато в процессе я получил бесценный опыт переговоров, который мне пригодился сразу же, как только я добился, чего хотел.

Как-то беседовал со знакомым, недавним студентом. Его зовут Андрей, он очень умный парень, делает карьеру в IT и ему нужны были мои советы по разным вопросам. В частности он рассказывал, что его девушка хочет переехать в Москву, и он, конечно, переедет с ней, хотя и сомневается в том, что оно того стоит, но девушка очень хочет переехать, и её не переубедить. Так что они переезжают, это 100%. Мы обсудили особенности IT в столице. И тут он попросил карьерного совета:

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

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

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

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

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

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

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

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

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

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

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

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