Статья посвящается студентам 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 / product manager)

Часто появляются из бизнес-аналитика, продуктового-аналитика или менеджера извне IT.

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

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

Руководитель команды разработки (Team lead)

Обычно вырастает из разработчика, системного аналитика или тестировщика.

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

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

Системный архитектор (System Architect)

Обычно вырастает из разработчика или системного аналитика, иногда из тестировщика.

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

Инженер информационной безопасности

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

DevOps-инженер

Часто вырастает из разработчика, тестировщика или инженера внедрения.

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

P.S.

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

Комментарии (26)


  1. Samhuawei
    27.06.2024 05:45
    +3

    О времена о нравы. Инженеры без образования и опыта.


    1. Aleks_Otter Автор
      27.06.2024 05:45
      +5

      По-вашему, с опытом рождаются?


      1. kogemrka
        27.06.2024 05:45
        +4

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


    1. E1iasX
      27.06.2024 05:45
      +2

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

      Да и да:

      1) Как инженеру и любому другому спецу заработать опыт, если не берут без опыта? Все всегда с чего-то начинают. Это нормально.

      2) Зачем бумажка удостоверяющая об образовании, если есть интернет, огромнейшая библиотека, хранящая в себе все известные человечеству знания? Да, в любом случае это полезно ходить в какие-то учебные учреждения и получать там различные знания, возможно многим это покажется самым эффективным способом учиться чему-то новому, но это не должно являться чем-то обязательным ибо можно научиться самостоятельно будучи 1 на 1 с интернетом. Да и сегодня обяжут всех иметь эту бумажку, завтра ещё другую, послезавтра запретят удаленку и прикажут всем работать из офиса, послепослезавтра все будут спать на рабочем месте, а послепослепослезавтра это рабочее место и по совместительству ночлег превратится в барак казарменного типа, все будут просыпаться ранним утром под звон сирены, равняться, умываться и затем по очереди целовать портрет большого брата... Вам не кажется это абсурдным и чем-то, что нарушает человеческие права и свободы? Думаю достаточно средств и методов, которые способны отсеять некомпетентных людей, а бумажка об образовании не всегда о чем-то говорит и к тому же ее можно купить, как и опыт себе накручивают, а когда опыт не накручивают — это не всегда означает, что человек с бОльшим опытом умеет и знает больше, чем человек, который не может похвастаться столькими цифрами.


  1. R0bur
    27.06.2024 05:45
    +1

    Кем можно стать после обретения опыта в разработке

    Мне кажется, что вот этим категориям специалистов «отработка» совсем не обязательна:

    Менеджер проекта (Project manager) / Владелец продукта (Product owner)
    Инженер информационной безопасности
    DevOps-инженер

    И «Менеджер проекта» и «Владелец продукта» — это разные категории.


    1. Aleks_Otter Автор
      27.06.2024 05:45

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

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


      1. R0bur
        27.06.2024 05:45
        +1

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

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

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

        Менеджеры проектов обычно присутствуют в любых проектах — при решении уникальных задач в заданные сроки.


        1. Aleks_Otter Автор
          27.06.2024 05:45

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


          1. R0bur
            27.06.2024 05:45
            +1

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


            1. Aleks_Otter Автор
              27.06.2024 05:45

              Иногда PO есть, а скрама нет. Невероятно, но факт. Про должности и профессии, пожалуй, справедливо. Что ж, переименую в Продукт-менеджера, раз так коробит.


          1. R0bur
            27.06.2024 05:45

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

            Например, в методологии Microsoft Solutions Framework (MSF), о которой наверняка рассказывают студентам «программистских» направлений в курсах инженерии программного обеспечения. Там эти роли называются Program Management и Product Management, и, если посмотреть матрицу совмещения ролей, их пересечение в одном лице категорически не рекомендуется из-за конфликта интересов.


            1. Aleks_Otter Автор
              27.06.2024 05:45

              Я не писала о ролях, я писала о профессиях, вакансии на которые можно найти на HH. Вы правы, что здесь специализации смешаны с должностями, однако это отражение реального мира с реальными вакансиями.
              В моей схеме Program Manager соответствует Руководителю группы разработки. Так вот, по Москве сейчас ищут 588 Руководителей группы разработки / тимлидов и всего 14 Program Manager. Вы извините, что короблю ваше чувство прекрасного, но я считаю, что с людьми надо говорить на языке, который используется жизни, а не в туториалах.


  1. dabel1k0v
    27.06.2024 05:45
    +3

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

    Вы везде упоминаете разработчика, хотя имеете ввиду программиста (что как бы намекает).


    1. Aleks_Otter Автор
      27.06.2024 05:45

      Что как бы намекает на что? Сами-то как давно слышали слово "программист" применимо не к 1С? С#, Java, Go, даже Python преимущественно "разработчики", а не "программисты". Тут все специальности про разработку ПО, вообще-то.


      1. dabel1k0v
        27.06.2024 05:45

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


        1. kurozetsu
          27.06.2024 05:45

          А в чем собственно говоря разница?..

          Если поясните - буду очень благодарен).


          1. Aleks_Otter Автор
            27.06.2024 05:45

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


          1. dabel1k0v
            27.06.2024 05:45

            Например, Возняк и Аппл: один пишет код, а другой даёт продукт.


  1. dnegorov
    27.06.2024 05:45

    Я конечно понимаю, что Хабр больше про программистов...

    Но почему никто не рассматривает вход в ИТ со стороны сисадминской двери?

    Сисадминской в смысле "не разработка".

    Есть куча ИТ специалистов не в разработке. Например сети, почта, СХД, виртуализация и VDI и т.п.

    Зашёл в ЦОД младшим инженером сервак в стойку монтировать. Потихоньку научился ОС ставить, а там и сети, и виртуализация, и скрипты, и вот ты уже девопс.

    Так же можно свернуть в сетевые направления, ИБ, облака, да много чего ещё.

    Хороший инженер в своем направлении имеет деньги сравнимые с разработкой.

    Тут важно, наверное как и в разработке, не застревать надолго в одном болоте (технология, железка, направление, компания), а развиваться. Иметь желание развиваться.


    1. Aleks_Otter Автор
      27.06.2024 05:45

      Справедливости ради, системное администрирование я упомянула... Да, не отдельно. Ну как бы если хочешь разрабатывать ПО, то логично идти его разрабатывать или хотя бы внедрять.
      Думаю, о сисадминах и их путях развития лучше всех напишут сисадмины)


      1. dnegorov
        27.06.2024 05:45

        Это не претензия к Вам.

        Это рассуждение в слух на тему входа в ИТ и вообще о представлении об ИТ.


        1. Aleks_Otter Автор
          27.06.2024 05:45

          Я поняла) Мне ваше наблюдение показалось интересным.


  1. zergon321
    27.06.2024 05:45

    Вебкамщицей, вот кем


    1. MainEditor0
      27.06.2024 05:45

      Уборщиком в офисе


  1. Dolios
    27.06.2024 05:45
    +1

    Кем можно стать в IT без опыта работы

    Кем угодно. 100% нынешних "айтишников" когда-то были без опыта работы.


  1. psmolkin
    27.06.2024 05:45

    Бездомным