Кем можно стать в IT без опыта работы
Статья посвящается студентам IT-специальностей. Когда 10 лет назад я была студенткой провинциального ВУЗа, то думала, что меня учат на программиста. Преподаватели — теоретики, доценты, профессора — были настолько же далеки от реальной разработки ПО, как программа ВУЗа от программирования и современных технологий (в ней были полугодовые курсы Delphi, Pascal, 1C и Java). В дипломе значится безликое «инженер», просить помощи было не у кого.
Глядя на знакомых студентов и кандидатов, которые приходят на собеседования, могу сказать, что проблема актуальна до сих пор. Зачастую даже люди с опытом работы в несколько лет не понимаю, чем ещё они могли бы заниматься, кроме почти случайно выбранного направления. Сама я кодила пять лет, прежде чем осознала, что моё призвание в системном и бизнес-анализе.
Картинки говорят лучше слов, так что вот схемка. На ней представлены основные специальности в IT и стрелочками — наиболее вероятные пути развития. Как видите, специальностей очень много, и лишь некоторые требуют навыков программирования. Скорее всего, я вспомнила не все. Системный аналитик и Инженер тестирования расположены на границе потому, что понимание принципов программирования существенно облегчит им жизнь.
Переквалификация на смежную специальность возможна почти всегда. Компании обычно идут навстречу сотрудникам, ведь вырастить мотивированного специалиста самостоятельно проще, чем найти необходимого на рынке.
Кем можно стать без опыта
Я старалась расположить специальности по порядку участия в работе над проектом от старта проекта до внедрения, однако некоторые специальности особенно важны в итерационной разработке и работают с результатами предыдущей итерации.
Бизнес-аналитик (Business analyst)
Этот человек должен ответить на вопросы:
Что мы делаем?
Для кого?
Какие есть ограничения извне?
Какими должны быть рабочие процессы в компании?
Что должно происходить с информацией в системе?
Бизнес-аналитик исследует деятельность компании, её предметную область, процессы работы, производства, а ещё нормативные акты и законы, которым компания должна подчиняться. Бизнес-аналитик должен найти проблемные места в рабочих процессах и предложить, как их можно улучшить. Может случиться так, что информационная система для этого и не нужна. Но мы говорим о разработке, поэтому бизнес-аналитик — это тот человек, который приносит бизнес-требования команде, то есть говорит, как система должна менять жизнь компании и взаимодействовать с пользователями.
Будет намного проще пройти собеседование, если почитать перед ним книжку «Разработка требований к ПО» (К. Вигерс, Дж. Битни).
Продуктовый аналитик (Product Analyst)
По сути подвид бизнес-аналитика на проекте системы, которая разрабатывается без конкретных требований от пользователей, итерационно. Задача продуктового аналитика — выдвигать гипотезы о том, какие доработки принесут максимум пользы, проверять их, отказываться от провальных гипотез, и так, путём проб и ошибок, вести продукт к славе и величию к обретению конкурентного преимущества.
Аналитик данных (Data Analyst)
Этот человек собирает данные и выжимает из них полезную информацию. Его стезя — статистика, графики, скрытые зависимости и коэффициенты доверия.
Это специфическая область, в которой пригодятся математика, статистика и программирование.
Перед собеседованием желательно пройти курс по анализу данных. Скорее всего он будет включать в себя основы программирования на Python.
К этой профессии близки инженеры машинного обучения (Machine Learning Engineer), которые занимаются настройкой всевозможных нейросетей. Не стала выделять их отдельно, потому что требования вакансий к ним очень схожие.
BI-аналитик (Business Intelligence Analyst)
Подвид аналитика данных, который специализируется на формировании отчётов, дашбордов и презентаций для руководителей и специалистов, которые по этим документам будут принимать решения о стратегии развития своего отдела или компании.
До собеседования желательно пройти курс по теме и потренироваться работать в BI-системе.
Дизайнер интерфейсов (UI/UX designer)
Определяет внешний вид и поведение пользовательского интерфейса, но что ещё важнее — путь пользователя в нём. Сколько кликов сделает пользователь для достижения своей цели, сколько времени проведёт на странице сайта, какого цвета будет заветная кнопочка — зависит от дизайнера. Дизайнер должен быть художником и психологом, а ещё хорошо знать паттерны и возможности платформы, на которой реализуется интерфейс приложения.
Перед тем, как отправиться на собеседования, стоит пройти курс по Figma и добавить в портфолио учебный проект.
Системный аналитик (System Analyst)
Этот человек должен ответить на вопросы:
Как мы будем реализовывать требования, которые принёс бизнес-аналитик?
Какие технологии мы будем использовать для этого, как именно?
Какими данными и в каких форматах наша система должна обмениваться с пользователем, с другими системами, между своими частями?
Как происходит обработка данных внутри системы и её частей?
Какие ошибки при этом могут возникнуть?
Системный аналитик служит связующим звеном между бизнес-аналитиком и разработчиками. Он раскладывает потребности бизнеса (заказчиков, пользователей) на техническую реализацию. Системный аналитик знает, как именно работает система изнутри. И ещё он много пишет. Системный аналитик создаёт и поддерживает документацию, которая содержит все технические требования к системе. Именно по ней разработчик будет писать код, а тестировщик проверять реализованную функциональность.
Зачастую между бизнес и системным аналитиками нет чёткой границы. Также могут плавать верхняя (сбор требований) и нижняя (описание требований для разработчиков) границы обязанностей — уровень проработки требований может быть совершенно разный.
Перед собеседованием советую почитать ту же книжку «Разработка требований к ПО» (К. Вигерс, Дж. Битни) и телеграм-канал «Системный аналитик».
Разработчик (Developer)
Это человек, который реализует требования, которые передал системный аналитик.
Разработчик непосредственно программирует алгоритмы обработки данных, программные интерфейсы, управляет хранилищами данных.
Выбирая эту стезю, нужно определиться, что вам ближе: пользовательские интерфейсы (frontend, все эти экранные формы, окошечки, кнопочки) или сложные алгоритмы обработки данных (backend, логика «под капотом» системы); разработка мобильных приложений, веб или десктопных?
Исходя из этих предпочтений, стоит выбрать язык программирования и пройти по нему курс, чтобы как минимум не теряться в синтаксисе на собеседовании.
Инженер тестирования (Quality assurance engineer)
Человек, который следит за тем, чтобы все требования к системе были выполнены. Тестировщик проверяет не только реализованную функциональность, но и сами требования — на предмет неполноты и противоречивости. Он же устраивает системе краш-тесты нагрузкой и т.п.
Как и разработчики, тестировщики могут делиться на frontend и backend, но часто работают с системой целиком.
Тестировщики ведут особый вид документации — тест-кейсы.
Технический писатель (Technical writer)
Этот человек готовит официальную документацию по системе: технические задания для заказчиков, руководства пользователей, маркетинговые документы и документы для регистрации в различных организациях (например, в патентном бюро или Минцифры).
Технический писатель не должен глубоко разбираться в технологиях, он описывает систему со слов других членов команды. Однако он лучше всех знает правила оформления документов, ГОСТы, стандарты и правила русского языка.
Инженер технической поддержки и/или внедрения
Объединять эти категории не совсем корректно, но их обязанности схожи и зачастую совмещены.
Инженер внедрения настраивает систему на стендах заказчика. В зависимости от проекта и сложности системы он может разворачивать систему самостоятельно или ожидать окончания работы DevOps-инженеров.
Инженер внедрения взаимодействует с прямыми пользователями системы, проводит их обучение, помогает адаптироваться к системе, собирает боли и пожелания, фиксирует ошибки опытной эксплуатации.
Инженер технической поддержки первой линии также взаимодействует с пользователями, фиксирует запросы, ошибки, оказывает консультации. Вторая и третья линии технической поддержи обрабатывают более сложные запросы.
Оба вида инженеров хорошо знают систему и могут выполнять первичный анализ проблем: воспроизводить ошибки, анализировать логи системы и данные в базе.
Опыт инженера внедрения или технической поддержки третьей линии — хорошая база для развития в системный анализ или тестирование.
Кем можно стать после обретения опыта в разработке
Менеджер проекта (Project manager) / Владелец продукта (Product owner)
Часто появляются из бизнес-аналитика, продуктового-аналитика или менеджера извне IT.
Выполняют схожие функции — определяют границы проекта и направление развития исходя из финансовых показателей, рисков и сроков. Эти люди составляют план проекта и следят за его выполнением. Они же оценивают риски и принимают решения о том, какие действия предпринять в случае, если негативная ситуация всё-таки наступила. Они же набирают команду и распределяют финансирование.
Менеджеры проектов обычно присутствуют в проектах заказной разработки или продуктах с чётко определёнными целевой аудиторией и направлением развития. Владельцы продукта отвечают продуктовые проекты, у которых есть клиенты, но нет заказчиков извне компании.
Руководитель команды разработки (Team lead)
Обычно вырастает из разработчика, системного аналитика или тестировщика.
Этот человек организует работу команды разработки. Он служит связующим звеном между менеджером проекта, вышестоящим руководством компании и командой. Он синхронизирует цели компании и команды разработки, выстраивает внутренние процессы, подбирает персонал и следит за развитием подчинённых.
Тимлиду необходимо обладать как навыками менеджера, так и техническими знаниями, ведь без последних невозможно эффективно решать внутренние проблемы команды разработки.
Системный архитектор (System Architect)
Обычно вырастает из разработчика или системного аналитика, иногда из тестировщика.
Этот человек проектирует систему на уровне компонентов, обмена данными между ними и с внешними системами. В отличии от аналитика, архитектор решает не сиюминутные, а стратегические задачи. Он должен понимать, в какую сторону будет развиваться система в ближайшие полгода, год, три года, чтобы укладывать текущую разработку в целевое решение и тем самым снизить необходимость глобальной переделки системы в будущем.
Инженер информационной безопасности
В его обязанности входит анализ уязвимостей системы и обеспечение защиты данных. Обязанности могут включать анализ архитектуры и кода системы, анализ логов, системное администрирование, мониторинг и анализ действий сотрудников компании вне системы, обучение сотрудников правилам информационной безопасности.
DevOps-инженер
Часто вырастает из разработчика, тестировщика или инженера внедрения.
Специалист широкого профиля, который отвечает за развёртывание системы, выделение для неё ресурсов, доставку обновлений на стенды, системное администрирование, устойчивость к сбоям и безопасность.
P.S.
Я хотела рассказать ещё и о том, почему не стоит бояться собеседований, как составить резюме при отсутствии опыта и как выбрать компанию по душе, но статья и без того вышла очень длинной. Эти темы подниму в следующий раз.
Есть идея собрать контакты опытных специалистов разных направлений, которым студенты могут написать в личку/мессенджер и задать вопросы о самой работе, о том, что нужно подучить к собеседованию. Конечно, есть множество статей «что нужно знать начинающему», но, к сожалению, они не могут заменить персональные вопросы.
Если вы являетесь специалистом уровня middle+ и выше и согласны принять участие в этой инициативе, пожалуйста, напишите в комментарии свою специализацию и канал связи. Я соберу эти контакты в единый список и добавлю в эту статью или следующую.
