Путь IT-менеджера к командной работе

Мир IT сегодня не похож ни на одну из других отраслей — над кодом приложений, игр, корпоративных решений, сервисов работают увлечённые, грамотные ребята. Программисты и инженеры, дизайнеры и тестировщики, системные администраторы и новомодные DevOps превращают идеи в программное обеспечение, которым пользуются миллионы людей. Они вдохновенно пишут код, разрабатывают алгоритмы, готовят макеты и соединяют это в работоспособные полезные механизмы. Пользователи Хабра, часто говорят о разработке, администрировании, новых технологиях и языках программирования, зарубаются в жарких спорах о преимуществах одного стека над другим. Но все мы забываем о важном звене в любой IT-компании — менеджерах проектов и продуктов. А между тем не факт, что завтра именно вам не предложат отойти от дел программерских и стать менеджером. Мотивация? Стоит ли? Потолок? Карьерный тупик? Новый горизонт? Давайте разбираться.

Менеджер и бэклог

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

Работа без цели, плана и этапов проекта. Такая ситуация может возникнуть, если менеджер плохо представляет себе этапы разработки и вообще процесс создания программного обеспечения, то есть фактически ему просто трудно адекватно планировать. Сумбурная работа, метание от задачи к задаче, постоянно изменяющиеся требования выматывают всех членов команды, приводят к увольнениями и профессиональному выгоранию.
Изменение проекта на лету — ещё одна ненавистная черта менеджера. Вы легко узнаете этот тип работника: услышав на конференции или очередном митапе о новой технологии или модных моделях управления, он возвращается в компанию с горящими глазами и начинает активно продавливать новинку на старом проекте. Причём это не эксперимент с лучшими практиками, а именно тотальное и безоглядное погружение во что-то новое. По ощущениям — больше макание. Приводит к срывам срока проекта и резкому падению качества и скорости разработки. Если горе-новатор умудряется заручиться поддержкой топ-менеджмента — пиши пропало.
Стратегия любой ценой — девиз менеджеров ИТ-проектов, работающих на свой собственный бонус, но не на благо команды. Такие ребята готовы на всё ради KPI и ROI и исключают любые риски, лишь бы не потерять заветные значения коэффициентов. Самый опасный вариант, когда менеджер лоббирует внедрение в матрицы показателей коэффициенты, связанные с «нетрудовыми» достижениями — такие как коэффициент лояльности, показатель внутренней мотивированности и оценочный уровень взаимодействия с коллегами. Как правило, профессионалы-интроверты сквозь это решето не проходят и остаются без премий. А там и без мотивации, и… без работы.
Непонимание принципов разработки — бич менеджеров-нетехнарей. Не зная особенности создания кода, скорость работы программистов, принципы тестирования, сроки выведения продукта в продакшен, крайне трудно прийти к общему знаменателю с R&D и стать настоящим связующим звеном внутри проекта. Именно такие менеджеры любят заучить несколько словечек ИТ-тематики и говорить: «Успеешь фичу до пятницы?», «Отрефакторь код, чтобы быстрее работало», «Да там всего две строчки поменять. Зачем весь билд тестировать?».

Некоторые менеджеры так и думают, что на входе какая-то идея, на выходе величайшее в мире ПО, а посередине — магия. Не-а, обычно великая идея, долгая-нудная-сложная разработка и продукт, который ещё и конкуренты опередили. И вот как раз классный менеджер и толковые разработчики этот продукт ведут к GREAT 🙂

Совещания без конца — отличный способ имитировать деятельность, не достигая при этом результата. Главное, чтобы был календарь резервирования переговорок (желательно, публичный), а сам менеджер с важным видом заслушивал состояние дел на проекте и давал комментарии. Если постараться, то можно назвать эту имитацию Scrum или Agile. Но тогда обязательно должна быть доска с цветными бумажками. Это менеджер-совещанец усвоил.
Клиент всегда прав, даже когда точно не прав. Почему-то волшебная формула «клиент всегда прав» из ритейла и сервиса перекочевала в том числе в разработку. Менеджер, призванный работать в том числе на стороне клиента, превращается не в адвоката клиентских интересов, а в кивающего божка, таскающего самые бредовые задачи от клиента с пометкой срочно-важно. И, конечно же, без составленного и подписанного ТЗ.
Игнорирование личностных аспектов — ошибка, которую может допустить любой менеджер, в том числе технарь. Ни в коем случае не стоит игнорировать тот факт, что вы работаете в окружении людей — а значит, в окружении личности, характера, настроения, мотивации. И если не учитывать эти особенности внутри команды, можно получить эффект ядерной мини-бомбы внутри коллектива. Заденет всех.
Неумение расставлять приоритеты приводит к однозначным срывам сроков проекта, сумбурности в разработке, брошенным делам, неразобранному бэклогу и переполненному багтрекеру. Разработка как любое инженерное дело не терпит хаоса.
Тотальный контроль и микроменеджмент — болезни управления, которые могут напасть на каждого. Нет ничего хуже, чем менеджер. стремящийся заменить каждого на рабочем месте и готовый влезть в каждый этап разработки.
Отсутствие ретроспектив — отличный способ снизить мотивацию команды и качество разработки. Если менеджер по какой-то причине избегает анализа ошибок, проделанной работы, боится похвалить или призвать к качественным изменениям, он неизбежно получит команду, не знающую, каким курсом она движется.
Игнорирование лучших практик. Чужие успехи, находки и преимущества порой трудно признать. Однако в работе подобное поведение фатально — если не принимать во внимание лучшие практики, можно отстать от конкурентов и по сути потерять все преимущества. Если менеджер боится признать лучшее и активно внедрять это, проект обречён.
Есть ещё один аспект работы менеджера, приводящий к негативным последствиям, — стремление создать дружную команду даже в ущерб эффективности и продуктивности. В погоне за комфортным психологическим климатом в коллективе и полной неконфликтности менеджер загоняет проект в ранг «дружеской посиделки», на которой всем хорошо, но работа не делается. Рано или поздно это обязательно приводит к конфликтам и глубокому управленческому кризису.

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

Пусть самурая или из программиста в менеджеры

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

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

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

Программисты и менеджеры — это совершенно разные сущности, которые практически противоположны друг другу. Я не знаю ни одного программера, который стал бы хорошим менеджером. Руководителем отдела разработки, тимлидом — да, а чтобы работать в том числе на продвижение и работу с клиентами — не знаю таких. Программисты действительно достаточно пассивны в плане общения — нередко молчаливые, упёртые, суровые интроверты, немногословные, не любят, когда их дергают и сами дергаться тоже не любят. Менеджер должен быть экстравертом, любить общаться, решать задачи, планировать и проявлять инициативу — конечно, рядом с психотипом большинства программистов, это категорически разные типы.

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

Менеджер экспертного уровня — это всегда звезда в любой команде, потому что он и умеет работать «продвиженцем» и знает предмет вопроса изнутри. Это как Королев, когда он возглавил КБ для разработки ракеты. Если бы он сам эти детские ракетки и самолёты не запускал и не конструировал, он бы никогда не смог управлять целым КБ и не создал бы ракету, способную покорить космос.

От менеджера нужны лидерские качества, чтобы сплотить вокруг себя команду и суметь ей управлять, ставить задачи, планировать достижение промежуточных результатов и т.д. И, безусловно, в разработке ПО, в технической сфере это особенно важно.

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

Переход из разработчиков в менеджеры разработки — это карьерный рост с точки зрения и общества, и руководителя, и коллектива. Это повышение заработной платы, новые задачи и новая ответственность. Но разработчик не всегда готов забросить код и приступить к новым обязанностям — хотя бы просто потому что программировать ему нравится гораздо больше. Эта позиция заслуживает огромного уважения (и повышения зарплаты — да-да, господа руководители, это свидетельство почти что патологической лояльности продукту и оно дорого стоит!), но мы всё же остановимся на более распространённой ситуации: зарплата манит, новые задачи будоражат и вы почти согласны стать менеджером, но с чего начать? Как встать на этот путь и стать на нём эффективным, а не попасть в ловушку принципа Питера?

Что нужно осознать?

Любая смена деятельности как внутри компании, так и вне её — это определённый стресс, сопряженный с множеством вопросов и сомнений. Даже если вы знаете проект много лет, всё равно вам предстоит посмотреть и на него, и на команду с другой стороны, обратиться к новым сторонам взаимодействия, стать руководителем своих коллег, стать лидером. Важно сразу осознать несколько моментов, которые помогут собраться и приступить к работе «с той ноги».

Должность менеджера — это рост для программиста, новый виток развития в сфере управления. Когда разработчик достиг практически всего в коде, ему стоит шагнуть дальше и управлять именно так, как того проект требует. Когда знаешь процессы разработки и особенности продукта изнутри, ты способен изменить многое в управлении, сделать команду по-настоящему сильной. Бонус за все риски — новые задачи и материальная сторона.
Переход в менеджеры — способ преодолеть достигнутый карьерный потолок. Особенно это важно для тех специалистов, которые хотят развиваться внутри своей компании, а не менять работу. Это способ применить накопленные знания в новом качестве.
Менеджеру проще перейти на высокооплачиваемую работу в другую компанию, поскольку программист должен вникать в код, стиль разработки, разбираться с не всегда лучшим «наследством» от предшественника, а менеджер приходит со способностью грамотно управлять проектом, понимая разработку, но тратя время на разгребание кучи кода. Он изначально эффективен (хотя не факт, что разборки с кучей отменяются!).
Став менеджером, следует избежать микроменеджмента и перестать вникать в мельчайшие особенности разработки, в каждую строчку кода, — нужно дать возможность команде решать задачи разработки. Однако часто менеджер, выросший из программиста, продолжает просматривать билды и отдельные коммиты, нередко даже сам продолжает писать код. однако рано или поздно объём серьёзных менеджерских задач вытеснит такую возможность, поэтому важно правильно выстроить делегирование в команде.
Менеджер — это не айтишный бюрократ и не боец на тёмной стороне. Это человек, который способен применить свой опыт для того, чтобы сделать живой идею продукта, создать ПО, которым можно пользоваться и которое способно приносить пользу.

Как по мне, нет причин для беспокойства

Менеджер — это человек, работающий с людьми, и это не стоит сбрасывать со счетов. Ваша новая работа — это непрерывный процесс взаимодействия с руководством, клиентами и, конечно, командой. Важно обеспечить благоприятную рабочую обстановку, научиться управлять совершенно разными людьми и при этом не скатиться в развесёлую компашку или, наоборот, в запруженное болотце только «нужных и спокойных» людей. Помните Высоцкого «настоящих буйных мало, вот и нету вожаков»? Нужно оставаться по-хорошему буйным.
Менеджер должен быть в движении, но ни в коем случае не двигаться от стека к стеку, от технологии к технологии. Должны создаваться технические условия для успешной работы — в частности, внедряться автоматизация там, где она нужна.

С автоматизацией можно перестараться. В теории. На практике ощущается вечная недоавтоматизация.
И да, вам придётся столкнуться с этой картинкой в жизни 🙂

Главное — очень-очень любить свой продукт. Иногда, конечно, вопреки 🙂

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

Что придётся принять?

Есть несколько вещей, которые нужно принять в роли менеджера: риски, умение прислушиваться к критике и реагировать на неё, новая мера ответственности, умение принимать жёсткие и иногда непопулярные решения. Придётся стать лидером своей же команды. Впрочем, если вы доросли до менеджера разработки, скорее всего, вы уже были неформальным лидером.

Самый большой страх

Главный страх менеджера, бывшего в недавнем прошлом разработчиком, — это потерять квалификацию, технические навыки, отстать от нововведений в стеке. Этот страх оправдан, но зависит всецело от вас. Менеджер должен быть на острие технологий и максимально разбираться во всех инструментах. Благо сейчас информации очень много и она легко доступна.

Как быстро научиться

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

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

Самая дешёвая и вполне адекватная возможность — найти наставника в компании, который позволит вам войти в новую колею. Это может быть глава департамента, опытный менеджер или даже генеральный директор, особенно в небольшой компании. Сотрудник, зная свою сторону работы, быстро освоится и изначально будет знать о проблемных точках проекта.
Углубиться в книги, блоги, материалы, заняться самообразованием. Отличное решение, но оно займёт много времени и будет иметь теоретическую основу. Скорее, это обязательное дополнение к любому из перечисленных способов.
Пойти на второе высшее, в магистратуру, на сложные курсы. Ну, если у вас есть время и деньги… На самом деле, это довольно затратно и не всегда эффективно — фишечка вузов, понимаете ли: есть учебный план и неприкаянные преподаватели, поэтому кроме нужных вещей вы будете изучать разную -логию. Впрочем, если вы студент последних курсов или хотите войти в ИТ уже не просто джуниором, но и подающим надежды молодцом, можете попробовать свои силы.
Получить степень МВА. Дорого, сложно, жрёт много времени, региональных работодателей не впечатляет. К тому же, хороших программ в России мало. Обычно на MBA решаются топы или почти готовые топы крупных корпораций, в которых это добавляет веса. Но, по нашему опыту, в ИТ-сфере ценятся несколько иные навыки: мозги, опыт, умение работат.

Но в целом все способы хороши, особенно если их смешивать с толковыми книгами и блогами реальных практиков ИТ-менеджмента. Главное, помнить, что вы должны стать лидером, а не «айти-бюрократом».