Можно ли после работы менеджером переквалифицироваться в программисты? И, вообще, кем лучше работать: менеджером или программистом? Как лучше строить карьеру в IT? Что при этом важнее: образование или опыт?

По мере продвижения по карьерной лестнице многие программисты проходят путь от джунов до сениоров, далее некоторые из них становятся тим-лидами и техническими руководителями. Среди моих знакомых менеджеров IT-проектов большинство – бывшие программисты. Путь от программиста до руководителя проектов не является из ряда вон выходящим явлением. Но среди моих знакомых программистов нет ни одного, кто, наоборот, стал писать код после того, как несколько лет проработал менеджером проектов. Поэтому свой случай я считаю достаточно неординарным и хочу поделиться опытом такого карьерного шага. Возможно, кого-нибудь это сподвигнет на подобные смелые изменения в собственной карьере.

С чего всё началось?

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

Я руководил различными проектами 12 лет, но в итоге всё-таки решил вернуться к работе программиста. Сразу скажу, что считаю правильными оба ключевых решения: стать менеджером тогда и снова переквалифицироваться в разработчики спустя столько лет. Почему я выбрал такой путь и как мне удалось достаточно безболезненно сменить профиль обратно, я расскажу чуть позже. Но сначала я хотел бы рассказать о нюансах работы на каждой из управленческих позиций, начиная с тим-лида и заканчивая менеджером портфеля проектов. Возможно, этот небольшой обзор позволит лучше понять суть работы на этих позициях для тех, кто только планирует свою карьеру. Затем я поделюсь опытом, как не растерять технически навыки, а наоборот, прокачать свой уровень, занимаясь управленческой работой.

Тим-лид

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

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

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

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

Руководитель отдела

Здесь под отделом подразумевается функциональное подразделение численностью порядка 20 человек и более, состоящее из команд с различной специализацией (например, аналитики, разработчики, тестировщики). На уровне руководителя отдела картина качественным образом меняется, поскольку теперь твои подчинённые — это уже не рядовые сотрудники, а руководители. А начальник - кто-то из топов или приближенных к ним (CTO, IT-директор).

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

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

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

Технический менеджер

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

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

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

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

Подводя промежуточный итог, важно отметить, что работа по рассмотренным выше позициям в основном состоит из общения (устного и письменного), работы с системами управления (Jira и подобные) и чтения/редактирования/написания различных документов (ТЗ, планов и так далее). Можно грубо оценить, что не менее 50% времени технического менеджера уходит коммуникации. От того, насколько компетентно и эффективно у него получается общаться, принципиально зависит возможность дальнейшего развития по карьере менеджера.

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

Менеджер проектов

Если обратиться к упомянутому выше PMBOK, то управление проектами включает в себя 10 областей знаний и 5 групп процессов, каждая из которых включает в себя множество отдельных процессов. И за всё это должен отвечать менеджер проектов. Даже краткое описание функций менеджера проектов не впишется в объемы статьи (можно взять любое руководство по проектному управлению, но PMBOK наиболее структурированный). Поэтому ограничусь своим видением ключевых особенностей работы на этой позиции.

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

Может возникнуть резонный вопрос: а что это за менеджер, у которого на проекте постоянно возникают проблемы? Со стороны часто кажется, что большинство проектов идёт, как полагается. Но за этой видимой лёгкостью стоит тяжелая непрерывная работа руководителя проекта. Если на проекте не возникает проблем, то и менеджер, честно говоря, не нужен. Такой проект команда сможет завершить самостоятельно. Конечно, ради справедливости стоит сказать, что существенная часть работы менеджера состоит в том, чтобы предвидеть и предотвратить возникновение проблем. Но это, опять же, достаточно тонкая и непростая работа, которая требует определенного опыта и умения работать на опережение. На фоне этого все технические навыки менеджера, такие как составление планов, отчётов, договоров, контроль бюджета, организация работы команды и так далее, я бы скорее рассматривал как hard skills (профессиональные знания), которые должны быть доведены до автоматизма. Такие вещи можно делегировать и администратору проекта.

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

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

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

Итак, что же даёт менеджерский опыт, если есть стремление продолжать карьеру как технический специалист?

Умение составлять реалистичные планы и фокус на результат. Основная проблема многих программистов – фокус на конкретной задаче и отсутствие навыка видеть картину в целом. Работа менеджером развивает способность видеть весь путь, который нужно пройти, чтобы завершить проект, и заранее подготавливать почву для следующих шагов, пока идёт работа над текущим. Этот навык также позволяет понять, что проект идёт не туда и своевременно скорректировать маршрут.

Общая техническая эрудиция, "насмотренность". Благодаря тому, что менеджер выполняет проекты с разнообразным техническим стеком, работает с разными командами, состоящими из разноплановых специалистов, понимает весь спектр проблем, к которым может привести использование тех или иных технических решений, он видит намного больше вариантов и способов решить одну и ту же задачу. Чем более комплексные проекты реализовывал менеджер, тем лучше он ориентируется в устройстве ИТ-систем, начиная с уровня «железа», заканчивая масштабными интеграционными взаимодействиями информационных систем.

Тайм-менеджмент, личная эффективность. Работа менеджером воспитывает привычку управлять своим временем и расставлять приоритеты, чтобы успевать выполнять поставленные задачи, но и не забывать про свои личные цели - карьера, саморазвитие, семья и так далее.

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

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

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

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

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

Как развить эти навыки и не растерять технические компетенции?

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

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

Нужно стараться работать на разноплановых проектах. Чем больше разных технических решений и разных специалистов пройдёт через руки менеджера, тем шире будет его кругозор. Наибольший выбор проектов доступен при работе в системных интеграторах, которые не только продают вендорские решения, то оказывают услуги по заказной разработке. Работа на проектах по внутренней разработке не даст таких возможностей, как участие в проектах для внешних заказчиков, причем желательно из разных отраслей (банки, ритейл, телеком и прочие).

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

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

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

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

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

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

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

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

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

Во-первых, резюме должно быть составлено под желаемую должность, то есть так, чтобы в нем было видно, какие технические задачи вы выполняли, несмотря на то что основной вашей функцией было руководство. Резюме должно максимально адресно подходить под описание вакансии. Например, если в вакансии указаны требования по языкам программирования, нужно указать, какие задачи вы выполняли с использованием этих языков. Подойдут и личные проекты, и задачи по автоматизации управленческих функций, которые вы выполняли по личной инициативе, работая руководителем (желательно со ссылками на github). Независимо от того, будете ли вы искать вакансии на стороне или воспользуетесь одним из описанных ниже вариантов, на составление резюме нужно обратить особое внимание.

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

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

Стоит ли решаться на кардинальные изменения?

Как я уже сказал ранее, я не жалею ни о выборе карьеры руководителя, ни о возвращении к технической работе.

Что мне дали 12 лет руководящей работы? Много интересных проектов из разных областей. Много интересных знакомств. Ценный опыт, который никак не получить другими путями. Развитие soft skills (гибких навыков), которые мне очень помогают в личной жизни. Ну, и в финансовом плане, работая как специалист, я бы, скорее всего, получил более скромный результат.

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

Оправдались ли мои ожидания от возвращения на роль программиста?

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

Однако есть и некоторые нюансы. Условно есть работа «в ширину», а есть «в глубину». Технические специалисты больше работают «в глубину», вникают в детали, совершенствуя себя в своей области знаний. Руководитель же должен видеть картину в целом, широким охватом, и в меньшей степени вникать в детали. Совместить и то и другое достаточно сложно. Спустя некоторое время мне стало не хватать именно работы «в ширину». Прогресс не стоит на месте, и хочется узнавать о возможностях новых технологий не из статей и конференций, а применяя их на практике.

Заключение

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

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

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

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

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