Kitabı oku: «Как хорошему разработчику не стать плохим менеджером», sayfa 9

Первое задание менеджера

Хотя менеджер – это скорее состояние души, чем роль или, тем более, должность, но формальное присвоение должности “менеджер” всё-таки важно. Официально признанный менеджер имеет доступ к дополнительным ресурсам. Очень часто бывает так, что разработчик очень быстро вырастает до тимлида и проявляет задатки будущего менеджера проектов, и сам он не против стать менеджером, но всё как-то не срастается. Так вот первое задание такого начинающего менеджера – это добиться менеджерской позиции!

Для начала давайте рассмотрим, почему возникает такая “заминка” в карьере:

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

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

Шаг от тимлида к менеджеру значительный. Гораздо более значительный, чем рост от Middle до Senior разработчика, например. Если тимлидом разработчик может стать очень плавно и безболезненно, то шаг к менеджеру означает смену экспертизы и требует очень много усилий от самого тимлида да и от других людей тоже.

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

Да, часто тимлид может кое-чему научиться, наблюдая за менеджерской работой со стороны. Но есть очень много областей, куда тимлид доступа не имеет: решение некоторых конфликтных ситуаций с сотрудниками или переговоры с заказчиком.

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

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

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

Это, кстати, менеджерский взгляд на вещи, к которому тимлиду надо как-то прийти.

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

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

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

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

Что делать компании в такой ситуации? Если просто сказать человеку: “Ты вряд ли станешь у нас менеджером,” то тимлид начнёт подыскивать новое место работы. Поэтому формулируется гораздо более обтекаемо: “Пока возможности нет, но мы работаем над этим. Как только появится вариант, мы тебя сделаем менеджером”. Тимлиду может казаться, что вся компания в дружном порыве работает над его карьерой. Но вряд ли всё так радужно. Вполне возможен вариант, что об этом желании тимлида помнят и просто ждут (и то не особо), когда ситуация поменяется.

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

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

В общем, начинающему менеджеру пора как-то брать ситуацию в свои руки и действовать активно. Потому что это именно то, чего от него ждут на менеджерской позиции.

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

История про чужие решения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Алексей ушёл думать. Он решил докопаться до сути и погрузился в исследование решения Игоря. Почему оно проще и быстрее? Вскоре Алексей выяснил, что менеджер вместо работы с базой использовал заранее приготовленные файлики JSON с нужными данными и показывал только первые 1000 записей. Поэтому и производительность была нормальной. Когда эти хаки убрали, решение менеджера стало тормозить так же.

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

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

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

Анализ

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

Самое интересный вопрос тут, это зачем менеджер полез в код? Он хотел ускорить работу разработчика? Зачем тогда он делал это втайне, и почему не взял ответственность на себя? Менеджер (а скорее тимлид) может перевести на себя какую-то задачу, если видит, что разработчик не сделает её. Но тогда нужно делать это полноценно, по процессу, доведя задачу до конца.

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

То есть вместо ускорения работы Алексея получилось значительное замедление. Причём, например, заставлять Алексея тратить время на убеждение команды и менеджера в правильности принятого решения было совсем излишне. В этом и суть распределения ответственности. Если разработчик принимает решение, то заставлять его аргументировать излишне. Это если решение должен принять менеджер, то ему нужны доказательства, информация и прочее.

Собственно, из истории видно, почему менеджер не взял полностью решение задачи на себя. Он не мог довести его до конца. Из-за нехватки знаний, времени или и того, и того. Тем более странным является его поведение. Это больше похоже на какой-то прессинг разработчика.

Причём, здесь в высшей степени не важно, насколько хорошо Алексей сам подходил для решения задачи. Даже если действительно задача была простой “двухдневной”, а Алексей на неё тратил 2 недели из-за недостатка знаний. Ну и что? Менеджер может заменить разработчика или работать с тем, что есть. В конце концов, часто бывает, что тимлид работает с командой новичков. Там каждый(!) член его команды работает во много раз медленнее, чем он сам. Ну и что? Это нормально. Можно прокачивать свою команду, можно использовать их “как есть”. Но какой практический смысл в том, чтобы гнобить своих разработчиков? Это крайне непрофессионально.

Аналогичная картина видна и в продолжении истории. Какой смысл показывать недоверие всем оценкам? Зачем просить других членов команды подтверждать (или даже опровергать) оценки. Даже если есть какой-то Пётр, который может сделать какую-то задачу в два раза быстрее Алексея, то что из этого следует? “Я угадаю эту мелодию с трёх нот. – Угадывай!”

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

Что делать в такой ситуации менеджеру? Прекратить показывать свои комплексы и неуверенность и начать управлять. Либо заменить разработчика, либо начать ему доверять, а не устраивать детский сад.

Что делать в такой ситуации Алексею? Я бы занял жёсткую позицию. Менеджер даёт свою реализацию задачи. Что он хочет, чтобы я с ней сделал? Изучил код? Это reverse engineering и пусть менеджер даёт согласие на эту трату времени. Либо пусть сидит и объясняет, как его код работает. Нужно принять решение по выбору кода, который идёт в прод? Отлично, решение принято, в прод идёт мой код. А, так нельзя, нужно сравнить решения? Тогда это исследовательская задача и пусть менеджер явно назначает такое задание, и принимает решение сам по результатам сравнения. При этом где-нибудь я бы эскалировал проблему менеджеру менеджера, так как явно он мешает работать.

А вот финал истории вполне закономерен. Менеджер потерял разработчика, причём не по своей инициативе. То есть и здесь у него всё пошло наперекосяк.

История про деньги заказчика

Услышал интересные рассуждения от опытного фрилансера:

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

Спасибо, что дочитали эту книгу до конца. Я надеюсь, что эта книга принесла вам не только пользу, но и развлечение.

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

До новых встреч!