Любой 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-продукта напоминает строительство. В качестве фундамента здесь выступают главные этапы проекта. Если пропустить хотя бы один кирпич, то работа над всем продуктом оказывается под угрозой. Ресурс не сможет полноценно работать и выполнять поставленные задачи. Поэтому так важно на старте понимать цели каждой стадии проекта и знать, чем занимаются ваши коллеги. Эти знания уберегут вас от факапов или, по крайней мере, минимизируют возникновение ошибок во время работы.
Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: