Есть ли жизнь после Синьора?

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


Источник

В сфере информационных технологий много стереотипов, как и везде. Один из них касается карьеры разработчика. Иногда кажется, что, если ты пишешь код в сорок лет, с тобой что-то не то, и единственный путь – расти и становиться руководителем. Из-за этого я периодически наблюдаю картину, когда опытные разработчики не двигаются с места годами, ожидая “того самого места выше”. Но те пути развития специалиста, о которых я расскажу ниже, полезно знать на всем, от джуниора до синьора — сменить направление работы никогда не поздно. Оговорюсь сразу. Я не буду говорить о деньгах и зарплатах (оставим все это за рамками, наконец, есть hh.ru), а буду рассуждать именно о возможном творческом и карьерном развитии.
Я могу выделить несколько основных путей развития в IT для тех, кто имеет опыт разработчика. Каждый из них очевиднее предыдущего, кто-то может вообще ничего нового не услышать. Но часто то, что мы ищем, как раз и лежит на поверхности, нужно только обратить на это внимание.

Итак, поехали:


Источник

1. Переходить в руководство

Тот самый “стандартный” путь, живущий в умах большинства разработчиков. Куда он приводит знакомо всем: руководство группой (TeamLead), проектами, отделом, технологической практикой, техдиректор… В каждой компании свой набор должностей. Этот вариант предполагает наличие навыков управления. Нужно начинать изучать премудрости менеджмента, находить подход к людям, понимать, как работает компания. Опыт разработчика тут уже уходит на второй план и выступает в качестве бэкграунда. Код писать становится уже либо совсем не нужно, либо нужно в гораздо меньшем объеме.

Это для тебя, потому что:

• Нет необходимости писать код, актуально для тех, кто хочет что-то поменять.
• Реальное управление и влияние.

На что стоит обратить внимание:

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

Источник

2. Продолжить писать код

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

Это для тебя, потому что:

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

На что стоит обратить внимание:

• Приходится успевать за развитием технологий, чтобы оставаться на плаву и в своем статусе.
• Подходит только для тех, кому нравится сам процесс разработки.
• Риск «мнимого» роста. Он особенно подстерегает людей, давно работающих на одном проекте. Тезис следующий: если вам кажется, что вы знаете все, потому что видели каждый потаенный участок кода своего проекта, это абсолютно не значит, что, если вас пересадить на другой проект, все получится. Как проверить себя? Попробуйте сделать что-то на технологиях незнакомых вам.

Источник

3. Податься в архитекторы

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

Это для тебя, потому что:

• Частая смена проектов. Сделали, следующий проект. Это драйв.
• Создание фундамента приложений. Кайф от глобальности своей задачи.
• Весь накопленный опыт используется на 100%, а то и 150%. Постоянный поиск нового и оптимального решения.

На что стоит обратить внимание:

• Высокая ответственность за каждый проект. Цена ошибки высока – это жизненный цикл вашей системы. А ее еще нет… Здание пока только в вашей голове.
• Много бумажной работы. Написание технических документов. Одно дело придумать, другое дело все это описать, включая большой объем правок от коллег и заказчика.
• Работа с типовыми архитектурами. А куда без них? И здесь иногда будет «день сурка».
• Умение отстаивать свою позицию и решение.
• Требуется постоянное изучение новых технологий и решений.

Источник

4. Опробовать маркетинг

Это более редкий и менее популярный вариант. IT — такой же бизнес, и всю работу разработчиков нужно продвигать. Это направление находится где-то между продажами, рекрутингом и маркетингом. Сюда попадают такие должности как Developer Advocate и Евангелист. Человеку с большим техническим опытом проще объяснить другим разработчикам, в чем преимущества того или иного продукта, найти подход и “правильно” рассказать про свою компанию. Ни один классический маркетолог не сделает это так, как человек, который сам был когда-то разработчиком. А уж тем более, если ваша задача – это развитие HR-бренда, то есть привлечение и удержание разработчиков в своей компании. Такие люди, как правило, много общаются в соцсетях, пишут статьи и выступают на конференциях. Этот путь не для интровертов.

Это для тебя, потому что:

• Общение с разными людьми.
• Выступления на конференциях и митапах.
• Жажда популярности и узнаваемости.

На что стоит обратить внимание:

• Требуется грамотная речь и умение быстро реагировать на неожиданные и порой очень нестандартные вопросы,
• Нужно уметь легко и быстро писать, знать иностранные языки
• Очень мало вакансий. Скорее это путь внутри своей компании.
• Одиночная работа, при калейдоскопе общения и людей вокруг. Можете забыть о понятии команда, к которому вы привыкли в разработке.
• Постоянные командировки и поездки. И это не романтика (О! Я объезжу весь мир!), это тяжелый труд, вереница отелей и постоянное отсутствие дома.

Источник

5. Стать звездой продаж

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

Это для тебя, потому что:

• Работа в самом сердце бизнеса, вы будете зарабатывать деньги.
• Общение напрямую с заказчиком. Много встреч и переговоров.
• Никакого кода.
• Вам сюда, если вы хотите заработать все золото мира.

На что стоит обратить внимание:

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

Источник

6. Переквалифицироваться в аналитики

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

Это для тебя, потому что:

• Более творческая работа, чем разработка.
• Никакого кода.
• Наконец-то вы спроектируете “реально правильный интерфейс”. И теперь другие разработчики будут делать ваш “правильный и юзерфрендли интерфейс”.
• Широкая сфера деятельности. Сегодня у вас проект из банковской сферы, а через два месяца приложение авиакомпании или сети АЗС.

На что стоит обратить внимание:

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

Источник

7. Уйти в науку

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

Это для тебя, потому что:

• Создание чего-то нового.
• Открытия.
• Ваш личный вклад в развитие IT в целом как отрасли.
• Возможность войти в историю.

На что стоит обратить внимание:

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

Источник

8. Преподавать

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

Это для тебя, потому что:

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

На что стоит обратить внимание:

• Умение объяснять – это непросто. Объяснить порой сложнее, чем сделать. Этому нужно учиться.
• Иметь крепкую психику. Вам придется раз за разом объяснять одно и тоже и миллион раз отвечать на одни и те же вопросы.
• Нужен навык публичных выступлений перед большой аудиторией.
• Много времени на проверку домашней работы и вопросов от студентов. И это вне рабочего времени.
• Уверенное знание предмета, который преподаете.
• Обычно невысокие зарплаты.

Я намеренно не стал ничего писать про конкретные навыки специалистов. Эти пути доступны как суровым бэкэндщикам, так и кропотливым тестировщикам, как творческим фронт-разработчикам, так и отъявленным мобильщикам. Никто и никогда не помешает остановиться на достигнутом уровне и начать развиваться в ширину, постигать те знания, которыми жонглируют ребята за соседними столами. Так рождаются full stack разработчики. Зная, как располагаются цвета на других сторонах кубика Рубика, намного легче собрать свою.

Важно помнить, что не обязательно концентрироваться на чем-то одном. Например, преподавать можно параллельно с любым из остальных пунктов, выступать на конференциях, рассказывая о продукте, над которым работаешь в основное время, заниматься наукой и проектировать приложения, развивать Open Source. Эти восемь пунктов лишь капля в море возможностей. Например, еще есть продукт оунеры, коучи, можно создать собственный бизнес. Я за свою бытность в «Рексофте» видел коллег, которые выбрали и успешно реализовали каждый из описанных выше путей. Ограничений нет, сфера информационных технологий шире, чем кажется, а объем еще не проделанной работы колоссален. Главное – найти свое место в этом океане и делать свою работу качественно и ответственно, и получать кайф от того, что делаешь! И помните, все стереотипы у вас в голове, не бойтесь пробовать себя и развиваться!

Это материал руководителя группы практики Java компании «Рексофт» Зураба Белого, написанный по итогам его выступления на SECR-2019. Доклад получил первое место по результатам голосования участников мероприятия.