Как выбрать, кем быть в IT: разбираем роль каждого специалиста в проекте

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

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

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

Обычно проект основывается на семи основных этапах:

• Выяснение требований
• Создание дизайна
• Разработка продукта
• Тестирование
• Запуск продукта
• Техническая поддержка
• Вывод продукта из эксплуатации.

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

1 Собираем требования к продукту — превращаем идею в перечень функционала

Представим, что к вашей команде обратился заказчик с просьбой разработать веб-приложение. Для начала нужно собрать требования к этому продукту. Sales Manager расспрашивает заказчика обо всех подробностях.

Учитывая пожелания клиента, специалист формирует команду из нужных в проекте специалистов:

• Для разработки визуальной составляющей продукта потребуется помощь дизайнера.
• Справиться с версткой макета сможет фронтенд-разработчик.
• За построение логики, создание алгоритмов и обработку данных будет отвечать бэкенд-разработчик.
• Тестировщик проверит продукт на наличие ошибок и укажет программистам найденные уязвимости.
• На этапе обсуждения требований к Sales Manager присоединяется бизнес-аналитик. Он задает дополнительные вопросы вроде: «Что собой представляет продукт?», «Для чего он нужен?», «Какие функции должен выполнять?»

Главная задача аналитика — детализировать каждое требование и оформить Software requirements specification (далее — SRS). Это документ, описывающий продукт в целом, его предназначение, целевую аудиторию, функции и ключевые параметры, интерфейсы. На основе спецификаций каждый в команде понимает, каков тип проекта перед ними.

В IT выделяют следующие разновидности проектов: 

• MVP (Minimum viable product) — минимально жизнеспособный продукт. Это пробная версия товара или услуги, выпускаемая компанией на рынок.
• POC (Proof of concept) — небольшой проект, предназначенный для проверки гипотез перед началом полноценной разработки.
• Product — рабочая модель продукта. Используется для представления какой-либо части разработки, обнаружения и устранения ошибок в ней, получения фидбека от пользователей.

В зависимости от типа проекта Sales Manager может представлять заказчику видение состава команды и назвать приблизительные сроки выполнения работы. Определить это все помогает Project Manager.

Специалист еще раз проверяет требования к продукту, просчитывает возможные риски и смету. В нашем случае продукт — это веб-приложение. Как только все детали утверждены, Sales Manager подписывает контракт и все специалисты берутся за дело. 

2 Создаем дизайн продукта

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

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

• Mockup — макет, позволяющий увидеть, как продукт будет выглядеть в реальности.
• Wireframes — черновик, показывающий, где и как необходимо разместить элементы на сайте. С этим дизайнеру помогает бизнес-аналитик. Он отлично разбирается в предметной области проекта. Следовательно, может предложить, например, как воплотить функционал оплаты за меньшее количество времени и с использованием минимального количества ресурсов.

Переходим к следующему этапу — разработке.

3 Превращаем визуальную идею в техническое решение

Фронтенд-разработчик начинает работу над видимым пользователям частью приложения — то, с чем он будет взаимодействовать. Специалист должен точно отразить в верстке то, что нарисовал дизайнер.

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

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

4 Тестируем продукт

Прежде чем презентовать разработку заказчику и конечным пользователям, команда должна убедиться в работоспособности продукта. Важно вовремя выявить критические баги и проверить соответствие разработки заявленным в начале требованиям. За эти шаги отвечает тестировщик. Для проверки продукта QA-инженеру могут потребоваться разные виды тестов. Например:

• Мануальные тесты. Классический метод оценки качества программы. Специалисты вручную проходят тестовые сценарии пользователя и составляют отчеты об ошибках.
• Автотесты. Выполняются с помощью специальных скриптов. При этом вмешательство человека сводится к минимуму, а точность и скорость проверок здесь намного выше мануального тестирования.

Выделяют и экспертов, специализирующихся на тех или иных разновидностях тестов — Manual или Automation QA. Это может быть и один специалист — General QA .

Главная задача тестировщика — найти ошибку и сообщить о ней разработчику или проектному менеджеру. Обнаруженные баги QA вносит в баг-репорт. Документ содержит подробное описание дефекта и причину его возникновения. Опираясь на полученный отчет, девелоперы исправляют ошибку. Затем тестировщики повторяют проверку и смотрят, решена ли проблема. 

5 Запускаем разработку в мир

Для этого приложение нужно загрузить на сервер и выполнить развертывание. Только так пользователи смогут увидеть ресурс в сети и воспользоваться им. Это уже компетенция DevOps-специалистов. Они сопровождают команду при разработке продукта и его запуске.

К основным обязанностям DevOps относятся:

• настройка облачных технологий (сетей, сервисов), установление связей между ними;
• внедрение обновлений и дополнений для продукта;
• помощь в масштабировании проекта;
• прием и обработка обратной связи пользователей ресурса/продукта.

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

6 Поддерживаем проект технически

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

Все это необходимо для планирования дальнейших изменений и доработок в продукте.

7 Выводим продукт из эксплуатации

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

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

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