“Привет, июль! Салют, пляжи и горные кемпинги!” – это я так настраиваю себя на будущий отпуск, друзья) А заодно хочу рассказать вам о новых и интересных людях, которые появятся в вашей жизни, если решите учиться на программиста.
Как вы помните, моя стажировка в компании Akhter Studios плавно переросла в настоящую полноценную работу в на должности Junior backend developer – бэкендера, проще говоря. Под чутким руководством своего тимлида я училась работать с одним из внутренних проектов студии, параллельно готовясь к техническому собеседованию.
Ну, а с получением настоящей штатной позиции, мне доверили уже полноценный клиентский продукт. Что автоматически привело к тому, что количество моих деловых связей с командой резко возросло. И самым первым среди них стал… владелец продукта.
Продакт-оунер – душа продукта
На первый взгляд может показаться, что название позиции Product Owner прямо указывает на то, что этот менеджер – реальный владелец продукта, то есть клиент собственной персоной. Но в реальности он не обязательно может быть связан с компанией заказчика. Просто его главная роль – распоряжаться продуктом от имени заказчика.
И я не ради красного словца наградила его эпитетом “душа продукта”. Продакт-оунер всегда ассоциируется с очень сильными эмоциональными ролями, типа: родитель, защитник, адвокат... Возможно, поэтому оунеры стремятся лично познакомиться с каждым разработчиком, от джуниора до системного архитектора. Ведь всем этим людям предстоит работать над его ДЕТИЩЕМ!
Фронтендер – властитель интерфейсов
Несмотря на то, что мы с фронтендером работаем на разных полюсах – он отвечает за работу интерфейса будущего продукта, а я создаю код на серверах и базах данных, с которыми наш проект будет обмениваться данными – мы очень много коммуницируем.
Помните, я рассказывала, что часто занимаюсь созданием интерфейсов (API), которые позволяют правильно “состыковать” клиентскую и серверную части программы? Вот на этом участке мне и приходится часто взаимодействовать с этим специалистом, согласовывая с ним массу важных деталей и параметров.
Это как если бы мы вместе с фронтенд-разработчиком собирали ракету на Марс: пока я вожусь с двигателями, он настраивает все рычаги и кнопки, а потом мы вместе проверяем – правильно ли идут сигналы от пульта до двигателя?
Тестировщик – соколиный глаз
Ребята, а вы не замечали, что в нашем восприятии образ программиста всегда связан с кодингом, то есть написанием программ? Между тем в разработке есть много важных профессий, которые остаются в тени этой славы. Особенно это касается QA-инженера, то есть тестировщика (от англ. Quality Assurance), без которого производство любого коммерческого сервиса или сайта превратилось бы в сплошную нервотрепку.
На первый взгляд, в его работе нет ничего сложного – надо просто имитировать действия пользователя, чтобы находить баги в программе. Но в жизни, как правило, все намного сложней. Есть множество методов и автоматических тестов, которые, тестировщик привлекает к работе на каждом цикле кодинга. И чтобы справиться со всем этим зоопарком инструментов, нужно быть тем еще аккуратистом! Так что, смело записываю эту профессию в список самых важных моих знакомств.
Тимлид – гуру и наставник
И снова вернусь к тому человеку, с упоминания которого начала писать свои блоги – тимлиду. Тимлид, он же руководитель подразделения, был и остается главным проводником джуна через все перипетии проекта. Возможно, с каждым новым опытом его роль будет менее заметной в моей карьере, но она всегда будет значимой, потому что именно тимлид отвечает за общее самочувствие своей команды. А значит, к нему можно обратиться за той помощью, которую вряд ли смогут оказать другие коллеги.
Тимлид следит за моим развитием, находит слабые стороны и рекомендует подходящие курсы или уроки, которые закроют конкретный пробел. Он же может помочь выпутаться из какой-то сложной рабочей паутины, потому что умеет взглянуть на ситуацию с высоты своего опыта. А потому, да здравствует тимлид!
Вот, всех перечислила. Но если кого-то забыла, то это отличный повод вернуться к вам с новыми темами!