Как зайти в IT после 30+(40+)? (взгляд изнутри)
Intro
Периодически на ресурсе можно встретить авторские истории в стиле: “Как я стал разработчиком на Х в 30 лет” или “Как я перешел в IT на позицию Y в 40 лет” и т.д.
Все эти истории объединяет то, что это зачастую некая личная история успеха, а на нее всегда оказывают влияние какие-то личные предусловия и стечение обстоятельств. И напрямую такие истории не всегда легко можно перенести на свою ситуацию.
Работая в IT (software development) больше 25 лет в разных компаниях (западные, до 10к. человек) на менеджерских позициях, я наблюдал кого компании ищут, как происходит отбор, как кандидаты себя ведут на интервью и как они меняются попадая в команду, кто в итоге остается, а кто нет.
(!) В разных компаниях конечно все немного по-разному, со своей спецификой, но все же на больших числах общие паттерны похожи, т.к. основные принципы бизнеса и капитализма остаются одними и теми же.
В этой статье я бы хотел поделиться опытом наблюдений этого процесса, как все выглядит “с другой стороны стола для интервью”. И чуть более подробно рассказать о том, как выглядит IT индустрия изнутри, как новичку проще сориентироваться и примерно понять “мое / не мое”, и если “мое”, то как выбрать направление куда двигаться с чего начинать, и как не допустить типичных ошибок.
Scope Definition
Для кого это?
Зачем люди вообще идут в IT? Цели у каждого, конечно же, могут быть разные.
И логично, что от цели и причин будут зависеть и весь остальной выбор и следующие шаги.
Но я бы хотел сфокусироваться на 2-х самых популярных и прагматичных целях, которые можно встретить:
1. Возможность работать удаленно (актуально для тех, у кого в месте их проживании не очень хорошо с доступной работой offline. Актуальность особенно выросла в период локдауна во время ковида);
2. Возможность через “сравнительно небольшое” время обучения начать зарабатывать, с возможностью дальнейшего роста (актуально для тех, кто столкнулся с потолком зарплат на текущем месте или не устраивает текущая зарплата или профессия в принципе).
Т.е. В первую очередь этот рассказ именно для новичков в IT, для тех, кто думает о сравнительно быстрой смене профессии и рассматривает работу в найме IT как вероятную альтернативу.
С чего начать?
Общий большой план может выглядеть примерно так:
1. Выбираем позицию(роль) на которую хотим пойти;
2. Изучаем минимально необходимый объем материала (+получаем первый тестовый опыт);
3. Выбираем компанию;
4. Проходим собеседования;
5. Пытаемся удержаться;
6. …
7. Profit?
(Пункты 1-3 могут быть в разной последовательности, т.к. все действительно зависит от стартовых условий.)
Задайте себе простые вопросы:
1. Я уже знаю кем точно хочу быть и чем заниматься?
2. Или может я уже что-то умею и/или хочу на чем-то специализироваться?
3. Или может есть компания, в которую я хотел бы попасть и не важно кем?
(если уже что-то известно, то от этого и проще отталкиваться)
Важно:
Эмпирически, минимально-реальное время на первоначальное обучение - это месяцев 3-6.
И с вами уже могут начать разговаривать на собеседованиях.
Но это если ориентироваться на full-time (полный рабочий день) на обучение. Если планируете оставаться на текущей работе и учиться параллельно, то на обучение может потребоваться год или два.
Но как обычно, нюансы в деталях.
Поэтому чуть подробнее по пунктам.
Кем быть? (О ролях)
“-Кем ты хочешь быть в IT?
-Не знаю, а кем можно?”
(реальный диалог)
Сложно сделать выбор, когда непонятно из чего выбирать.
Когда говорят об IT, то самые популярные позиции которые на слуху - это “программисты” и “тестировщики” (которых еще ошибочно называют QA)
Но конечно же, мир IT гораздо шире.
В целом IT сейчас это больше про “информацию” и ее обработку, чем про технологии как таковые.
Процесс разработки. Как это происходит и кто участвует?
Софтверные компании крутятся вокруг информационных систем (неких программных продуктов, своих или заказных, не важно) и на всем жизненном пути системы, для ее поддержки требуются разные роли.
Процесс разработки (инициализация)
На начальных этапах инициализации работают в основном роли, связанные с управлением, финансами, юристами, ресурсами, менеджментом, HR и т.п.: т.е. все, что связано с управлением закупками, договорами, контрактами, маркетингом, рекламой, рекрутингом, выделением ресурсов, всевозможными планами и все такое.
(Если прежде вы занимались чем-то подобным, то перейти в IT может быть сравнительно просто, потребуется, в основном, обновить знания, связанные с IT спецификой).
Процесс разработки (реализация)
Дальше идет собственно сам этап разработки.
Именно здесь появляются все те роли, которые участвуют в непосредственном создании новой системы.
В целом, общий процесс разработки выглядит примерно так:
- бизнес аналитики работают с заказчиками/пользователями, собирают первоначальные требования и обосновывают экономические выгоды (часто это роль на стороне заказчика и вы можете ее занять в ИТ департаменте своей текущей организации, например, медицинского или государственного учереждения),
- системные аналитики превращают требования в описания проектировок,
- UI/UX дизайнеры рисуют пользовательские интерфейсы,
- архитекторы, на основе общих проектировок, создают технические описания реализации, (архитектуры) и реализуют базовые вещи: основные интерфейсы/компоненты/фреймворк/базу данных и т.д.,
- программисты, на основе базовых вещей, дальше реализуют весь основной функционал по описанию аналитиков,
- тестировщики проверяют соответствие реализации требованиям,
- документировщики оформляют пользовательскую документацию, системные сообщения и переводы,
- всевозможные администраторы/конфигураторы (их еще не совсем корректно называют devops) обеспечивают всю физическую инфраструктуру и развертывание системы в работу и делают систему доступной для пользователей (сервера, сети, доступ, и т.д.)
Процесс разработки (поддержка)
Когда система уже готова и запущена в продукции, дополнительно появляются роль
- Специалиста поддержки (1st line support, 2nd line support) - которые обрабатывают заявки от пользователей (проблемы, вопросы, улучшения) и помогают/направляют на разработку
Процесс разработки (дополнительные роли)
Еще добавьте
- всевозможных узких специалистов/консультантов которые нужны только в конкретном проекте (блокчейн, GDPR, искусственный интеллект, BigData, эксперты предметных областей и т.п.),
- возможных social специалистов, вроде Mental Health specialist (что-то среднее между психологом и коучем который следит чтобы в проекте никто не перегорел - обычно он один на организацию)
Оберните сверху всевозможными
- менеджерами процессов,
- дополнительными службами управления качества и
- безопасностью,
И вы получите представление как может выглядеть современная проектная команда в IT разработке.
Так что же выбрать?
Вот во всем этом вы где себя видите???
Это важный вопрос, т.к. если нет точного понимания то ответы могут быть:
- “Не знаю, но вот точно не <название_роли>, потому, что <причина>!”
- “Не знаю, но вот это, <название_роли>, кажется интересным и я бы попробовал”
- “Просто не знаю”. (А что проще? Или что я смогу научиться делать?)
Все вышеперечисленные - это все отдельные роли. И на каждую из них можно долго учиться, развиваться и специализироваться.
В идеальном варианте, нормальное распределение: 1 человек = 1 роль.
Но довольно часто бывает, что в конкретном случае (проекте/компании) выделенная роль не требуется вовсе или требуется в ограниченном виде (или компания просто пытается сэкономить).
Тогда роли начинают объединять.
И может получиться что человек например “программист”, но он в себе сочетает роли программиста, аналитика и UI дизайнера.
И это одна из причин почему можно услышать мнение что “в IT надо очень много знать и уметь делать кучу разнообразных вещей”
Если сразу нет каких-то предпочтений и хочется выбрать с позиции “минимального времени на обучение”, то по наблюдениям самый низкий порог эффективного вхождения (из популярных ролей), это роли:
1. Поддержка пользователей (1st/2nd line Support specialist)
2. Тестировщик
3. Программист
Что изучать? (О скилах)
Условно все навыки можно на hard skills (технические) и soft skill (не технические).
И вот здесь в большинстве историй начинают подробно рассказывают как развивали именно hard skills (какую взяли технологию, книгу, какой курс посмотрели и какой сделали свой проект).
Хотя это как раз и не важно. Вернее не настолько важно, как может думаться.
Конечно, что бы работать в IT, особенно на технических специальностях, hard skills нужны и без них никак. Но их все равно сильно не развить с нуля до хорошего уровня за те несколько месяцев, которые человек, думающий о переходе в IT, сможет выделить на свое обучение.
В компаниях это тоже понимают, поэтому если ищут джуниора, то уровень hard skills, как правило, должен быть “минимально достаточным", чтобы просто пригласили на собеседование, а там уже будут проверять немного другие вещи.
Что касается развития hard skills как таковых, то для всех кто не "программист / администратор” процесс первоначального обучения достаточно straightforward (прямолинейный):
для аналитиков есть их BABOK, для 1-st line суппорта - ITIL, для тестировщиков - ISTQB, для QA и прочего качества - CMMI, ISO, IEEE, для менеджеров PMI/Agile, и т.д.)
А вот для программистов и администраторов все гораздо сложнее и не тривиально.
Потому что это уже ТЕХНОЛОГИИ!
(Т.к. в комментариях встречал много сообщений про интерес именно к программированию, то расскажу о своих наблюдениях именно о технологиях в программировании).
Технологии (как выбрать?)
Технологии. Их много, они разные и везде требуются разные наборы (technology stack). Знать все не получится физически и для специализации приходится выбирать что-то одно (иначе в долгосрочной перспективе будет проседание по зарплате), а еще они имеют свойство быстро устаревать и каждый год, как грибы, вырастают новые.
Конечно, если хочется быть на переднем крае (on the bleeding edge), или в модерновом стартапе, то да, важно следить за трендами и вовремя переключаться.
В остальных случаях это не так критично, т.к. технологии меняются часто в целом, в индустрии.
А вот в конкретных компаниях/проектах все может быть совсем не так.
Т.к. при переходе в IT потом придется где-то работать, то эффективным может быть для начала посмотреть, какие сейчас есть актуальные вакансии и что там перечислено? (совпадающие названия и будут теми технологиями которые сейчас “популярны / востребованы”)
Или наоборот, можно смотреть от конкретной компании - узнать на каких там технологиях специализируются и пробовать уже их.
Технологии (как начать изучение)
Ок, допустим смогли определить с какой технологии попробовать,
что дальше, с какой книги/курса начинать изучение, так, чтобы это было эффективно?
И тут нет “серебряной пули” (идеального решения). Т.е. для начала можно пробовать любую доступную книгу/курс/ресурс для новичков (где есть слова for dummies, за 24 часа, 30 дней, или любую другую - для начала это не принципиально).
Важные критерии на этом этапе:
1. Понимать, что там написано (т.е. чтобы сам язык был доступным для понимания)
2. важно, чтобы в ближайших разделах уже можно было бы сделать что-то практически и увидеть готовый результат (приложение, сайт, сервис, что угодно). (Т.к. курсы, которые предлагают начать с фундаментальной теории, алгоритмов и структур данных - это все конечно интересно, но это очень не быстро)
На этом этапе первичная цель - просто начать что-то изучать, попробовать что-то сделать и оценить ощущения:
1. Было ли легко разобраться? Или наоборот приходилось продираться?
2. Было ли интересно разбираться? Или безразлично?
Потом, для сравнения, попробовать другую технологию и сравнить ощущения.
В идеале - найти то, что будет доставлять удовольствие от процесса (или, как минимум, легко изучаться).
Т.к. важно помнить, что в IT вашими потенциальные коллегами (конкурентами) вполне могут быть те парни с горящими глазами, которые после работы продолжают фанатично работать, но уже из дома, а в понедельник на собрании говорят, что на выходных попробовали новый вспомогательный фреймворк, который идеально подходит для нашего проекта, набросали пруф-оф-концепт и готовы показать демку после митинга.
И если работа вас “не прет”, то продолжать конечно же можно, просто может быть чуть сложнее.
Технологии (продолжение обучения)
После первой книги для новичков уже можно взять вторую, третью и т.д. (также, для начинающих) но в них уже выбирать то, что не было пройдено на предыдущей итерации.
И в один момент после выбора очередной книги/курса будет ощущение, что ничего нового в ней нет. И это косвенный признак, что начальный уровень пройден и можно переходить чуть выше.
Хотя конечно эта грань “я уже умею достаточно хорошо программировать, чтобы работать или еще нет?” во многом субъективна и условна.
Есть и вполне объективные критерии именно на знания (не навыки), которые одинаково могут признаваться и коллегами и компаниями.
Это официальные сертификации. А курсы для подготовки так же можно рассматривать как вариант обучения.
Т.е. как только нашли/выбрали подходящую технологию - проходим курс сертификации, сдаем экзамен и получаем сам сертификат.
Это как некое внешне авторитетное подтверждение, что знания в конкретной предметной области / технологии более-менее выровнены.
(продолжение следует)