Новичкам в ИТ не место?

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

Меня зовут Дарья Евстратова, ведущий системный аналитик и техлид команды аналитиков в «БАРС Груп». Три года назад, когда я только окончила университет, было страшно делать первые шаги в профессии. И сегодня я расскажу, что мне действительно помогло и поделюсь своими лайфхаками.

На третьем курсе университета, меня накрыл классический студенческий ужас: «Для того, чтобы устроиться в ИТ, нужен опыт работы более 2 лет». У меня его не было и я боялась, что опоздала.

Знакомо? Если да — выдохните. Главное — начать.

На тот момент за плечами у меня были:

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

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

А что с учебными проектами?

Я долго сомневалась: стоит ли вообще писать в резюме про университетские проекты? «Это просто учеба, не реальная работа». Но потом поняла: даже в маленьком формате — это презентация моих профессиональных навыков:

Вокруг темы: «Нужен ли диплом о высшем образовании для работы в ИТ» идёт много споров. Кто-то говорит: «Главное — курсы и портфолио». Кто-то: «Без вуза никуда». Я всегда придерживалась мнения, что диплом в первую очередь говорит о том, что человек доводит дело до конца.

Я закончила ИТИС КФУ с красным дипломом по специальности «Программная инженерия» и горжусь этим . Для меня университет стал важным этапом для построения карьеры.

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

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

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

Еще одно препятствие, с которым многие сталкиваются в первые годы работы — это синдром самозванца. Чем сложнее мне давали задания, тем сильнее он проявлялся. Когда новичку дают первое серьёзное задание — это своего рода проверка: готов ли он познавать новое и пробовать делать что-то масштабное. Не нужно оглядываться на специалистов с большим опытом: действуйте в своем темпе и не бойтесь спрашивать совета у руководителя и команды.

И да, рисковать можно и нужно, но необходимо также реально оценивать свои силы!

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

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

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

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

Таблица требований — это содержание. Теперь нужна «обложка» — визуальное представление. Можно собрать визуальную доску (для этого можно использовать различные сервисы), где каждая задача будет привязана к требованию из таблицы. Также добавляем быстрые фильтры: по источнику, по функциональному блоку, по исполнителю. Благодаря таким инструментам можно в быстро и удобно отслеживать количество задач на каждом этапе.

Если проект сложный, с большим количеством зависимостей (напомню, интеграции — это всегда зависимости), — используем диаграмму Ганта. Её плюсы: планирование сроков по задачам, группировка задач в логические блоки и выстраивание последовательностей

Заводить глоссарий и согласовывать его с заказчиком — важно, это не формальность, а необходимый инструмент. В глоссарий я включаю бизнес-термины ( «заявка», «клиент», «аккаунт» — в контексте проекта), технические термины («REST API», «очередь») и сокращения — расшифровываю всё, что может вызвать разночтения.

Например: заказчик обозначил, что хотел бы видеть справочник в «отдельной таблице». Два аналитика восприняли это предложение по-разному: первый аналитик был уверен, что заказчик имел ввиду отдельную таблицу на UI, второй — таблицу в БД. Глоссарий помогает избежать таких ситуаций.

Проектировать функционал легче, когда применяется подход сверху вниз: от верхнеуровневых бизнес-объектов, которые как раз и участвуют в бизнес-процессах, до конкретной ERD. Это мостик между бизнес-логикой и структурой данных. Такую схему легко согласовать с заказчиком, когда он видит знакомые объекты, а вы не застреваете в деталях типов данных и индексов, пока не утверждена общая картина.

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

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

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

Необязательно знать всё. Необязательно быть лучшим. Главное — начать, сделать первый шаг и не останавливаться: ошибаться, учиться, снова пробовать. Ищите поддержку у команды, родных и близких, не бойтесь просить помощи, не замыкайтесь в себе. ИТ — это не про идеальных людей с красными дипломами и большим опытом. Это про тех, кто готов учиться, расти, брать на себя ответственность и не сдаваться. Я начала свой карьерный путь с отправки резюме. И у вас тоже получится. Удачи!