Веб-приложения: этапы разработки и подводные камни

Чем веб-приложение отличается от мобильного? В чём его плюсы и минусы? В статье отвечаем на эти вопросы, а также рассказываем, в каких случаях веб-приложение принесёт пользу бизнесу и какие этапы входят в разработку.

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

Внедрение веб-приложения оправдано, когда проект подразумевает сложную бизнес-логику и работу с большим объёмом данных.

Несколько примеров популярных веб-приложений: маркетплейс Ozon, веб-кабинет Тинькофф банка, сервис по подбору билетов Aviasales.

У веб-приложений есть ряд преимуществ относительно мобильных приложений:

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

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

Мы в Surf разбиваем работу над веб-приложением на 5 этапов:

1. Предпроектное исследование

2. Проектирование

3. Разработка

4. Тестирование

5. Передача проекта инхаус (опционально)

Ниже — кратко о том, что входит в каждый этап.

Когда к нам приходит клиент, мы в Surf всегда начинаем с исследования рынка и пользователей.

• Для начала определяем целевую аудиторию: кто его пользователи? Что им нужно от сервиса? Бизнес-анализ и UX-исследования дают четкие ответы на эти вопросы.

• Потом продумываем пользовательские сценарии: для этого используем CJM (Customer Journey Map), анализируем потребности аудитории и приходим к пониманию, как она будет взаимодействовать с продуктом. Так мы видим, какие фичи необходимы на старте, а какие второстепенны.

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

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

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

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

• Тестируем прототип на реальных пользователях
• Собираем фокус-группу
• Ставим несложные задачи по взаимодействию с продуктом
• Контролируем весь этот процесс и собираем данные

С каждой итерацией прототип улучшается и мы постепенно приходим к хорошему UX — делаем навигацию понятнее, выносим всю важную информацию вперед и управляем aha moments.

При создании прототипов важна грамотная, при этом умеренная проработка деталей:

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

Сперва выбираем тех-стек.

Со стороны frontend

Для frontend-разработки подходят библиотеки и фреймворки — например, React, Angular, Vue.js, Svelte. С ними разработчик решает часть задач при создании продукта: это управление состоянием приложения, разбивка элементов интерфейса на компоненты.

Со стороны backend

Для backend-разарботки мы используем Kotlin, Golang и Python. В Surf мы выбираем язык программирования под проект в зависимости от его специфики, потребностей бизнеса.

Например, для ERP-системы KFC мы выбрали Kotlin. Этот язык обладает компактным и лаконичным синтаксисом, что помогло нам быстро написать приложение со сложной бизнес-логикой.

ERP система включает в себя аналитику, учет рабочего времени сотрудников, отчетность и стратегическое планирование.

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

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

Подтвердить, что это действительно так, можно только с помощью тестов.

В Surf мы используем тестирование, в том числе чтобы узнать:

• Корректно ли интерфейс приложения отображается во всех основных браузерах, в том числе устаревших
• Нет ли несоответствий при использовании различного железа

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

• Charles и Proxyman — для чтения и изменения трафика. Хотя для чтения вполне подходит и стандартный DevTools в браузере, этими утилитами удобно подменять ответ, когда это необходимо.
• Postman — помогает найти ошибки в API.
• Browserstack — помогает быстрее тестировать веб-приложение в разных браузерах и версиях.
• Cypress — инструмент для end-to-end тестирования, который облегчает и уменьшает нагрузку на ручных тестах.

В тестировании необходимо учитывать много нюансов, чтобы не пропустить какой-то редкий, но при этом критический баг. Например, когда мы разрабатывали платформу видеостриминга The Hole — аналог Netflix для Medium Quality — мы обнаружили, что видео отказывалось воспроизводится в некоторых версиях браузеров. Оказалось, что причина была в конфликте с одним из плагинов.

Многие клиенты хотят развивать продукт своими силами после разработки. В таких случаях мы бесшовно организуем передачу кода и процессов. Для этого мы:

• Тщательно документируем код
• Пишем подробный readme

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

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

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

Мы в Surf документируем весь проект максимально подробно. Вот лишь некоторые артефакты, которые появляются у нас в процессе работы:

• Концептуальная архитектура решения — описывает верхнеуровневый облик решения.
• Информационная модель — выделяет потоки данных в проекте.
• Функциональная схема — для детального описания каждой функции системы.
• Спецификация микро сервисных API — показываем, как сервисы обмениваются данными друг с другом и предоставляют их внешним потребителям.

А ещё ближе к завершению проекта мы описываем нужную инфраструктуру — определяем требования к железу и готовим схему развертывания ПО.

В результате получаем готовый к использованию продукт.

Для реализации большинства веб-приложений хватает 3–5 месяцев. Но что если у вас масштабный проект с десятками фич, ещё и для разных целевых аудиторий?

От начала работы до достижения всех KPI обычно проходит 30–36 месяцев.

• 6 месяцев команды разработки и дизайна проектирует полнофункциональный MVP
• 12 месяцев клиент дополняет приложение новыми фичами, которые не вошли в MVP
• 12–18 месяцев нужно бизнес-аналитику с командой, чтобы выкупить все ключевые метрики.
• Года через 3 проект выходит на плато эффективности. Это когда всё оптимизировано настолько, что кардинально улучшить показатели уже сложно.

Веб-приложения дают бизнесу еще один канал взаимодействия с аудиторией. Их основное преимущество — это универсальность: они одинаково хорошо работают и на смартфонах (особенно если это PWA), и на десктопе. А из минусов можно отметить сложность разработки.