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



Под катом — о том, так ли все страшно, глазами специалистов из “Максилекта”, уже проходивших через аналогичный выбор.

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

Закрывать эту потребность можно по-разному. Можно периодически кардинально менять предметную область, например, из разработки каких-то интеграционных вещей перейти в big data или вообще покинуть ИТ, выбрав другую отрасль. Но обычно начинать все сначала желающих мало, поэтому прыжков “с места в карьер” (в незнакомую область) избегают, предпочитая искать пути развития поблизости. Об этом и поговорим.

Направо пойдешь, развивая навыки руководителя, — станешь тимлидом или ПМ

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

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

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

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

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

Надо помнить, что путь менеджера — это и не универсальный ответ на все вопросы. Он не для всех. С первой же руководящей ступени придется учиться нести ответственность за все, что происходит вокруг — в первую очередь за команду, сроки и бюджет проекта. Придется выйти из своего уютного ИТ-мира и одновременно говорить со сторонниками разных взглядов на ситуацию — с разработкой и бизнесом — выступая своего рода переводчиком. Грубо говоря, уже не получится объяснять необходимость оптимизации кода лишь тем, что тот “некрасив”. Придется вникнуть в детали и представить бизнес-последствия каждого из вариантов решений.

Налево пойдешь, углубишься в технологию — станешь principal

Не всем в этом мире стоит идти в менеджеры, ведь не каждый видит в этом венец своей карьеры (о том, лучше ли это, чем писать код, можно спорить бесконечно).

Решая задачи в своей сфере, опыт получают все — т.е. все в каком-то смысле растут технически, кто-то быстрее, кто-то медленнее. Техническая специализация не имеет своего “потолка”. По мере развития в этом направлении ты фокусируешься на более сложных технологических вещах, глубже в них разбираешься. Когда ты вырастаешь далеко за пределы сениора, становишься своего рода “гуру”, для которых в западных компаниях даже есть свое наименование — principal.
Грамотных нишевых специалистов, способных крутить и обрабатывать огромные объемы данных, строить low-latency архитектуру или разбирающихся в перформансе Java, на рынке не так много, поэтому востребованность и ценность человека как специалиста растет. Хотя при этом диапазон вакансий сужается, а спектр ожидаемых навыков увеличивается. Помимо решения технических задач, на специалиста уровня principal, например, могут возложить задачу код-ревью, за счет которого его собственный опыт станет достоянием команды (ключевой момент в том, что он должен объяснять, почему надо делать так, а не иначе). Что касается денег, то здесь как повезет. У разработчиков зарплата, возможно, и не больше, чем у менеджеров, но стабильность и предсказуемость обычно выше.

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

Прямо пойдешь, разовьешь ответственность — станешь архитектором

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

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

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

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

Прежде чем сворачивать куда-то еще, оцени риски

Иногда хочется не менять круг обязанностей, а сохранить все как есть, но добавить немного драйва в саму работу. И первый порыв — сменить компанию, чтобы поискать более “веселенькую” команду. Но тут важно понимать, что драйв зачастую приходит вместе с рисками. Стабильные проекты обычно самые скучные. Драйв же ассоциируется с созданием своего собственного продукта или с участием в стартапе, которые могут не взлететь из-за промаха маркетинга, ошибки с целевой аудиторией или миллиона других причин, иногда даже не связанных с конечной разработкой (особенности процесса запуска продукта — это тема для отдельного разговора).
Вопрос, который надо задать себе, звучит просто: позволяют ли жизненные обстоятельства в экстренном случае некоторое время посидеть без денег и выйти на поиск работы? Если другие пути не нравятся, трезво оценивая риски, можно хотя бы подготовить подушку безопасности перед тем, как искать драйва.

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

А как складывается ваш карьерный путь? Осознанно ли вы выбирали это направление развития? Кем вы видите себя в будущем?

Эта статья — четвертая часть нашего цикла публикаций о карьере ИТ-шника.
Первая часть здесь.
Вторая часть здесь.
Третья часть здесь.

Коллектив компании Maxilect.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

P.P.S. С наступающим 2020 Новым годом! Желаем в Новом году двигаться в правильном направлении!