С какой стороны проще войти в ИТ (не тестирование)

Нетерпеливым - прыгайте в середину статьи. ОЧЕНЬ много букв. Как и везде в ИТ.

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

Со всех сторон рекламируют курсы тестировщиков, где обещают трудоустройство и неприлично большие зарплаты. Хочу показать какие еще есть двери в ИТ и где очередь поменьше.

0. Введение в ИТ

Прежде чем начать, нужно понимать что происходит между словами "нужна программа" и "вхуж! оно работает!".

Так или иначе, все в ИТ движется по общему циклу:

Идея -> формализация идеи-> проектирование -> реализация -> тестирование ->внедрение и эксплуатация. Затем собирают обратную связь и заново идут генерировать идеи.

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

В больших проектах появляется специализация. Чем больше проект, чем больше людей - тем сильнее специализация. 10 "универсальных солдат" всегда менее эффективны чем 10 специалистов, знающих детально только 1 этап.

С какой стороны проще войти в ИТ (не тестирование) IT, Программирование, Длиннопост

И так далее - до 10 ролей и более доходит во многих крупных компаниях.

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

Отсюда следует два варианта:

  1. учить все и сразу, ориентируясь на средние компании.

  2. выбрать узкое направление и изучить его детально, чтобы попасть в большую компанию.

Далеко не везде нужно программировать. Через некоторые двери зайти проще.

Самое важно:

  • проще попасть в ИТ-проект на любую роль куда берут, а потом переместиться внутри на желаемую.

  • новичкам без опыта крайне сложно найти работу на конкурентные роли. Даже если вам обещали на курсах.

Итак, какие двери есть в ИТ:

1. Заказчик (Владелец продукта)

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

Пример: просите справку в бухгалтерии. Бухгалтерия - исполнитель, вы - заказчик, вы определяете какую справку нужно и в какой срок хотите.

Бухгалтерия дает прогноз, когда возможно (или невозможно) сделать. Не успели, сделали не то - вы высказываете свое недовольство.

Входные требования:

опыт работы руководителем проекта в любой области. Не обязательно разбираться в ИТ, достаточно понимать как программа вам поможет решить задачу бизнеса. Всю нагрузку по работе с ИТ может взять менеджер проекта (если, конечно же, он тоже не "искал вход в ИТ")

Что делает:

просчитывает имеющийся бюджет проекта, сроки, окупаемость.

За что отвечает:

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

Возможность переквалификации: во время работы можно выбрать направление, изучить, забрать на себя часть работы, затем перейти целиком. Например, изучить основы языка программирования, начать делать простые задачи по проекту, а потом постепенно "мигрировать" в разработчики.

2. Менеджер проекта

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

Входные требования:

  • проектное управление в ИТ (т.е. для “войти в ИТ” подойдет, только если есть опыт проектного управления). Agile, Scrum, Ci/Cd -нужно понимать что это и как работает. Объема знаний в виде курсов 20 часов по каждому направлению достаточно для входа.

  • управление коллективом

Что делает:

  • составляет план работ и контролирует соблюдение

  • управляет распределением ресурсов команды

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

За что отвечает:

  • срок выполнения. Уволился/заболел/ушел в отпуск разработчик или вся команда - это его ответственность. Нужно было учесть при планировании.

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

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

С одной стороны будет давить руководство: "нужно быстрее/дешевле/качественнее", с другой разработка: "так не делается! или быстро или качественно!". Для тех, кто был начальником производственного отдела ничего нового.

Возможности переквалификации: в менеджеры проекта. Реже - в любые другие роли.

3. Бизнес-аналитик (технический писатель)

Переводчик с языка заказчика "хочу" на язык разработчиков "что будем создавать". Есть разделение - бизнес-аналитик и системный аналитик.

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

Входные требования:

Предметная область в деталях. Например, знание всех деталей по оформлению кредита в банке достаточно для работы в этой роли. Естественно, со стороны банка.

Что делает:

переводит слова заказчика с "хочу чтобы клиент смог оформить заявку с телефона" на язык "открыть сайт, ввести определенные данные, затем данные передаются в отдел А, он делает с ними Б, передает в С" и т.д. Описывает все что видит и вводит каждый участник - какие окошки на мониторе, какие прикладываются документы и тд.

За что отвечает:

чтобы разработчик сделал то, что хотел заказчик.

Переквалификация:

  • В менеджеры проектов.

  • Реже в системные аналитики или тестировщики.

  • Вариант развития - бизнес-архитектор (редкая, но сытная должность).

4. Системный аналитик

Продолжает работу бизнес-аналитика, но действует “на этаж ниже”. Если бизнес-аналитик написал "пользователь нажимает кнопку А", то системный аналитик детально описывает как должна реагировать система, по каким протоколам идут данные, в каких форматах и что происходит внутри после нажатия кнопки.

Очень высокий порог входа для не "ИТшников", переподготовиться из бизнес-аналитика или тестировщика - дело 1 года.

Входные требования:

Особенности системы, протоколы взаимодействия внутри, форматы данных и тд. Чистое ИТ без программирования.

Что делает:

Переводит слова бизнес-аналитика "нужно чтобы отобразилась кнопка" в слова компьютеров "при запросе по протоколу Х в компоненте Y вызывается функция Z и возвращает результат XYZ..."

За что отвечает:

Система работает именно так, как описал бизнес-аналитик.

Переквалификация:

  • в менеджера проектов.

  • реже - в разработчика или тестировщика.

  • вариант развития в системного архитектора лет через 5-10.

5. Разработчик

Требуется отдельная статья, очень много нюансов и самая сложная для входа дверь в ИТ.

6. Тестировщик

Еще его называют QA (quality assurance) - ответственный за качество решения.  Направлений очень много, рассмотрим только ручное тестирование как простейшее для входа.

Входные требования:

  • особенности программ, которые планируется тестировать. Или, как минимум, чего-то похожего.

  • бизнес компании. Если устраиваетесь в финтех и слова "идентификация" вам неизвестно - шансы на успех сильно падают.

  • дотошность и готовность к рутине. Одни и те же кнопки придется нажимать каждый день много раз. Очень много раз. И описывать это.

Что делает:

  • принимает работу у разработчиков

  • сверяет требования заказчика с тем, что принесли разработчики

  • проверяет и. описывает все найденные расхождения

За что отвечает:

Число багов/ошибок, дошедших до клиента. За соответствие технического задания и разработанного результата.

Возможности переквалификации:

  • специализированное тестирование - автотесты, нагрузочное и тд (конкуренция ниже, зарплаты больше),

  • системные аналитики

  • разработчики.

7. Эксплуатация (секретная и свободная дверь!)

Или техническая поддержка. Не самый очевидный и прямой путь, но кому-то может подойти лучше. Пока самая "секретная" дорожка.

Входные требования:

Опыт работы с клиентами или опыт поддержки на второй линии.

Что делает:

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

За что отвечает:

  • пользователи довольны

  • система работает или руководитель знает, что и почему не работает

Возможности переквалификации:

  • в бизнес-аналитики

  • в тестировщики. Можно устроиться работать в поддержку, подключиться к тестированию и со временем попроситься в тестировщики.

Сократил и все равно много получилось. Готов развернуто отвечать на интересующие вопросы.

p.s. @Simulacris, блога все еще нет, но вопрос помню :)

p.s.2 За время работы в ИТ входил, выходил, входил снова с другой стороны и тд. Нанимал, обучал, переквалифицировал коллег.

1
Автор поста оценил этот комментарий
Классный пост, и удивительно отзывается моим актуальным мыслям:) Я тут время от времени подумываю про айти, но скорее со стороны контента и маркетинга:)
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Тоже вариант!
У меня есть наглядный пример, как человек начинал с яндекс-метрики и гугл-аналитики, а сейчас в аналитической базе данных отчеты строит и BI-витрины создает, работая внутри ИТ-команды.

2
Автор поста оценил этот комментарий

Первая вполне годная за долгое время статья по сабжу войти вайти с описанием дверей и способов перехода. Плюс вам в карму от того, кто в теме.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Рад, что оценили!

2
Автор поста оценил этот комментарий

Техпис и бизнес-аналитик не одно и то же

Техпис пишет руководства, справочную информацию, релизные документы продукта.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

По компетенциям тех.пис ближе к аналитикам. Но нет абсолютной истины - у всех по-разному организуется процесс.
И тот и тот отвечают за оформление процесса работы с системой. Часто требования переформатируются и ложатся в основу инструкций.

Автор поста оценил этот комментарий

Вариант чего? Ну вот для примера эксплуатация информационной инфраструктуры это:
- Участие в разработке и дальнейшей эксплуатации разрабатываемой системы
- Поддержа Dev, Test, UAT стендов
- Настройка мониторинга и продумывание точек мониторинга
- Учасите в Арх и Тех ревью влияние на будущее проекта
- Поддержка после выхода в прод, решение инцидентов и проблем
А клиентская поддержка это тупая девочка в кал-центре, которая умеет по скрипту ротик открывать. За ней стоит техническая поддержка, бизнес-поддержка и консультанты по выделенным юнитам. Я кстати последних консультировал, даже им до рядовых инженеров как до луны и они не могут внутри компании перейти. А вкатуны с улицы никогда всю цепочку не пройдут, потому что это не социальный лифт и тут так карьера не работает.

раскрыть ветку (1)
Автор поста оценил этот комментарий

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


Я же описывал с какой стороны можно в принципе войти в ИТ.  И это чаще не компании с четко разделенными матрицами компетенций и фиксированными RACI.


Очень много случаев на рынке из разряда " вот 3 рудокопа, сын маминой подруги вместо программиста, 10 менеджеров, завтра нам нужно организовать ИТ-компанию и сделать свой гугл".  (часто крупные проекты зарождаются именно в таком формате)


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

Особенно, если готов закрывать несколько дыр (нанаписать доки, протестировать, ответить пользователю, оформить заявки и тд).


Тогда следующий шаг будет на порядок проще и можно уйти в описанные вами компании.

показать ответы
Автор поста оценил этот комментарий

Хоспадя, какой же хлебушек в голове. Бизнес-аналитик это не технический писатель, а эксплуатация это не саппорт. Остальное вода и булшит.

раскрыть ветку (1)
Автор поста оценил этот комментарий

напишите свой вариант

показать ответы
1
Автор поста оценил этот комментарий

Про внедрение - внедрять сап в одного - это жесть и нафиг так жить (нужен реально мегаскилл), но почти любой из тимы внедренцев получает свой немалый инком. Но не сапом единым. Айтиха она большая и грамотный админ СХД+ВМ тоже стоит много (и, на самом деле, я видел в своей жизни только одного грамотного админа СХД+ВМ)


По ответственности - я в контексте айтихи говорил.
Ну и смотрите: есть тима, в ней есть мегаскилл, который получат x2 от начальника своего, от того, что незаменим. Незаменим - значит, что никто не понимает что он делает и на нём персональная ответственность за то, что он делает. А такие люди, как правило, делают что-то очень важное и критичное.

У меня есть знакомый офис-менеджер, который битрикс знает лучше чем дорогу домой).

раскрыть ветку (1)
Автор поста оценил этот комментарий

Речь изначально шла про "войти-в-айти".
Внедрение СХД, настройка рейдов и прочее - это уже другое кунг-фу. Разработка плат для того же СХД, проектирование сетей, подключение блоков вычисления в спецтехнику и тд и тп - тоже ИТ, но не для простого входа. 


сть тима, в ней есть мегаскилл, который получат x2 от начальника своего, от того, что незаменим. Незаменим - значит, что никто не понимает что он делает и на нём персональная ответственность за то, что он делает. А такие люди, как правило, делают что-то очень важное и критичное.

По этому есть что сказать :-)


Если никто не понимает, что делает сотрудник, и не может заменить - это минус в карму руководителю и плюс 1 пункт в матрицу операционных рисков. В хорошо организованных командах такое не должно встречаться.


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


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


Есть еще несколько ситуаций, но суть одна - нет привязки к важности и непонятности.

Автор поста оценил этот комментарий

Извиняюсь, видимо под конец дня уже совсем "не алё".

Ну и не стоит забывать о том, что it - это не только ПО в поивязке к разработке. Внедрение некоторых "коробок" тоже может быть весьма прибыльным заниятием. Раньше как было "Никого ещё не уволили за покупку продуктов IBM|cisco|oracle|SAP|microsoft", что, естественно, влечёт за собой необходимость внедрения и эксплуатации грамотными (а лучше - правильно сертифицированными) людьми, а жцпо остаётся за кадром совсем (хотя некоторые монстры практикуют багчек инжиниринг) или переходит в цикл вычеслительной системы/сервиса, который может перекликаться с циклом по, а может и существовать, развиваться, мутировать, менять элементы по совершенно независимо от изначальной поставки.

Да и посты новичков на форумах могут за 5 лет смениться с "не могу ввести пароль в линукс" до "зацените, я снизил задержки в rdma оптимизировав работу с памятью в сетевой подсистеме, как думаете, примут в ядро?".

Т.е. специализироваться в конкретной области это айти это всегда больше денег и больший гемор. Я люблю айти на столько, что работа стала отнимать слишком много не рабочего времени. Сейчас недалеко от савеловского вокзала собираю всякое железо покупанам, а в свободное из рабочего времени - патчу потихоньку всякую мелочь (до 128мб в собранном виде) и вспоминаю эти "виииил, у нас чет глюстра тормозит, помоги, вот наши патчи и конфиги" с некоторой теплотой и гораздо большим отвращением.


А ну и самое главное, с чего следует, на мой взгляд, начинать посты о вхождении в айти: деньги пропорциональны ответсвенности, пока есть человек который будет править твои косяки, много денег не заработать, а делать свою работу, брать ответсвенность за комманду, быть в своей специализации мегакрутым или быть сильно крутым во многих областях - это всегда большая нагрузка на организм. Стоит ли здоровье (которое будет потрачено и бессонными ночами падавана и бессонными ночами ловли отбившехся от стада котов на протяжении лет или десятилетий) инкома в 500-700 тыр - я себе ответил "нет".

раскрыть ветку (1)
Автор поста оценил этот комментарий

Про внедрение хорошее замечание! Но есть нюансы - это или SAP-подобные монстры, где с нуля буде долго и большо, или "прикруть форму Битрикса к сайту", что как бы ИТ, но не то, какое хотелось бы.


Про здоровье - верно! Почему-то мало кто из желающих войти осознает это - не всем дано работать в ИТ с комфортом и без ущерба для здоровье.


По деньгам тоже отдельный разговор, ноони не равны только ответственности.

Иначе таксист или врач получали бы еще больше - они за жизнь и здоровье отвечают.


БОльшую роль играет  как просто заменить человека. Чем сложнее найти нужно специалиста, тем большие деньги компании готовы предлагать за это.


Бывает, что подчиненный получает больше своего руководителя. Видел перекосы х2. Только потому, что сложно было найти нужного кандидата и пришлось задирать зарплату, пока не появятся варианты.

показать ответы
Автор поста оценил этот комментарий

где devops'ы и даже банальные сисадмины, которые несмотря ни на что - тоже вполне себе IT? и не только по функционалу, по и по всем остальным характеристикам, в том числе и по зарплате.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Сисадмины обычно работают в отрыве от команды разработки.

А вот девопс совсем не для входа. Здесь уже какой-то опыт требуется.

показать ответы
1
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
Автор поста оценил этот комментарий

Сертификаты - хорошо, но без опыта не помогут.

Чтобы практиковаться в проектах, нужно попасть в проект. А чтобы попасть в проект - нужна практиковаться. Речь о том, как попасть в этот замкнутый круг.

1
Автор поста оценил этот комментарий

Кажется, что про дизайнеров забыли?

раскрыть ветку (1)
Автор поста оценил этот комментарий

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

2
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
Автор поста оценил этот комментарий

Да, верно. Про это тоже упоминал:

"...внедрение и эксплуатация. Затем собирают обратную связь и заново идут генерировать идеи.


Именно поэтому говорим про  "жизненный цикл ПО"

показать ответы
Автор поста оценил этот комментарий
эксплуатация не все проблемы не решает, она их регистрирует, смотрит в инструкции есть ли описание кейса, если нет - передает на 3ю линию и контролирует исправление

Еще раз, медленно прочитай. Эксплуатация это девопсы и иногда безопасники, которые 24/7 поддерживают работу внешней и внутренней инфраструктуры. Вкатунов это не касается, им грозит только саппорт, который ты и описал. И это никакое не ойти, оттуда никуда не перейти.

мигрировать между ролями относительно легко

Хрен там плавал, потому что...

конкуренция за место ниже, и требования попроще

...это взаимоисключающие параграфы

Поэтому я и начал с того, что у тебя хлебушек в голове, обижайся, не обижайся, насрать.

раскрыть ветку (1)
Автор поста оценил этот комментарий

Эксплуатация это не всегде девопсы и девопсы не всегда связаны с эксплуатацией

Далее спорить смысла не вижу, слишком разный опыт


p.s. недавно коллега из саппорта перешел в тестирование и успешно там работает.