Всем привет! На связи команда из самого большого IT хаба на Черноморском побережье. Мы реализуем проект «TechQuest» для новичков в ИТ и решили поделиться с вами серией статей экспертов, в которых расскажем о личных кейсах, лайфхаках и приемах, которые немного приоткроют дверь работы в большой компании. 

Первая тема – запуск ИТ-продукта. Наш эксперт Сергей расскажет, как выстраивается работа над продуктом в крупной компании. Как строятся процессы, погрузимся во все этапы разработки цифрового продукта, и я расскажу почему важно не только «написать код», но и правильно всё спланировать, протестировать и учесть потребности бизнеса.

IT-индустрия — это не только разработчики

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

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

Этапы создания IT‑продукта

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

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

И сейчас мы с вами на примере условной социальной сети с рекомендательной системой пройдемся по каждому из этих этапов.

Этап 1: Бизнес‑анализ и дизайн

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

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

Бизнес-требования состоят из нескольких элементов:

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

• Схемы процессов: важно представить все ключевые процессы на схеме, чтобы каждый в команде имел общее понимание.

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

На этом же этапе важно начать разработку дизайна, чтобы требования уже были визуализированы и понятны для дальнейших этапов разработки.

Этап 2: Сессии «3 Amigos»

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

Мы используем подход BDD (Behavior-Driven Development) и записываем пользовательские сценарии на языке Gherkin. Этот подход позволяет не только членам команды, но и бизнесу заглянуть в сценарии и проверить, что будет реализовано.

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

Этап 3: Системный анализ, тест‑кейсы и доработка дизайна

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

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

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

Этап 4: Разработка и авто‑тесты

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

Для создания авто-тестов мы используем инструменты Cucumber и Playwright JS, которые позволяют автоматизировать процесс. Тестировщики и разработчики совместно работают над авто-тестами, проверяя основные сценарии. Это сокращает количество ошибок на следующем этапе и помогает команде уверенно двигаться к финальной проверке.

Этап 5: Тестирование

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

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

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

Этап 6: Демо и релиз

Завершив тестирование, мы представляем продукт на демо для бизнеса. На этом этапе бизнес-заказчики видят, как всё реализовано, проверяют соответствие своим ожиданиям и дают «зеленый свет» на релиз. Если нужно, мы еще раз дорабатываем отдельные моменты перед выпуском.

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

В идеальных условиях и сильной команде, мы получаем отличный конвейер, который поставляет необходимый функционал.

Заключение

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

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

Наконец, автоматизация процессов и использование BDD делает контроль качества более прозрачным и систематизированным. Мы можем проверять продукт на каждом этапе, вовремя выявлять ошибки и обеспечивать высокое качество разработки.