Веб-приложения: этапы разработки и подводные камни
Чем веб-приложение отличается от мобильного? В чём его плюсы и минусы? В статье отвечаем на эти вопросы, а также рассказываем, в каких случаях веб-приложение принесёт пользу бизнесу и какие этапы входят в разработку.
Вы в блоге Surf. Мы более 12 лет сотрудничаем с крупными компаниями, создаем для них мобильные и веб-приложения, пишем backend и frontend. Разрабатывали IT-решения для KFC, SAP и Mars.
🏄 Больше контента о разработке IT-продуктов — в нашем Telegram-канале.
Чем веб-приложение отличается от мобильного?
Веб-приложение — это интерактивный сайт, который выполняет определённую функцию. При этом часть кода, обрабатывающего бизнес-логику, выполняется на сервере. В отличии от мобильного приложения, этот продукт не надо скачивать и устанавливать.
Внедрение веб-приложения оправдано, когда проект подразумевает сложную бизнес-логику и работу с большим объёмом данных.
Несколько примеров популярных веб-приложений: маркетплейс Ozon, веб-кабинет Тинькофф банка, сервис по подбору билетов Aviasales.
Плюсы и минусы веб-приложений
У веб-приложений есть ряд преимуществ относительно мобильных приложений:
- Можно открыть на любом устройстве с браузером — от смартфона до ноутбука.
- Так как обновления происходят на сервере, пользователи всегда взаимодействуют с самой свежей версией продукта.
- Бизнес получает контроль над хранением данных и настройкой процессов.
Но и минусы у таких решений тоже есть. Например, разработка займет больше времени и других ресурсов, чем создание простого веб-сайта со схожим функционалом.
Этапы разработки веб-приложений
Мы в Surf разбиваем работу над веб-приложением на 5 этапов:
1. Предпроектное исследование
2. Проектирование
3. Разработка
4. Тестирование
5. Передача проекта инхаус (опционально)
Ниже — кратко о том, что входит в каждый этап.
#1: Исследуем рынок и пользователей
Когда к нам приходит клиент, мы в Surf всегда начинаем с исследования рынка и пользователей.
- Для начала определяем целевую аудиторию: кто его пользователи? Что им нужно от сервиса? Бизнес-анализ и UX-исследования дают четкие ответы на эти вопросы.
- Потом продумываем пользовательские сценарии: для этого используем CJM (Customer Journey Map), анализируем потребности аудитории и приходим к пониманию, как она будет взаимодействовать с продуктом. Так мы видим, какие фичи необходимы на старте, а какие второстепенны.
Пример CJM, который сделала команда Surf для прорабов и строителей «Петровича»
- Проектируем архитектуру: этот этап влияет на всё дальнейшее развитие сервиса и помогает избежать типичных ошибок в начале работы. Уже заложена основа для роста и учтено, насколько большая нагрузка будет на приложение с учётом роста аудитории и добавления новой функциональности.
#2: Проектируем технический и пользовательский дизайн
Этот процесс в веб-разработке достаточно сложный. В нем участвуют команды с разной технической квалификацией. Есть два основных уровня:
Проектирование технического дизайна: на этом этапе строим программный продукт, соответствующий всем входящим техническим требованиям. Этот процесс можно вот так отразить на схеме:
Проектирование пользовательского дизайна: продумываем все сценарии и раскладываем действия пользователя на функциональные блоки.
- Тестируем прототип на реальных пользователях
- Собираем фокус-группу
- Ставим несложные задачи по взаимодействию с продуктом
- Контролируем весь этот процесс и собираем данные
С каждой итерацией прототип улучшается и мы постепенно приходим к хорошему UX — делаем навигацию понятнее, выносим всю важную информацию вперед и управляем aha moments.
Такой кликабельный черно-белый прототип в Figma или Invision — один из главных инструментов в проектировании пользовательского дизайна. На примере — прототипы мобильного приложения the Hole, разработанного Surf
При создании прототипов важна грамотная, при этом умеренная проработка деталей:
- Мы делаем элементы навигации, компоненты и основные блоки близкими к финальным — это помогает оценить пользовательский опыт во время тестирования.
- Типографику, цвета и анимации откладываем на следующий этап. Их прорисовка отнимает много времени — если бы мы проработали их сразу, нам было бы сложно потом вносить изменения.
#3: Пишем код
Сперва выбираем тех-стек.
Со стороны frontend
Для frontend-разработки подходят библиотеки и фреймворки — например, React, Angular, Vue.js, Svelte. С ними разработчик решает часть задач при создании продукта: это управление состоянием приложения, разбивка элементов интерфейса на компоненты.
Flutter использует один движок отрисовки для веб, Android и iOS приложений. Когда мы разрабатывали необанк на этом фреймворке, такой подход помог нам исключить проблемы с несовместимостью браузеров и ОС
Со стороны backend
Для backend-разарботки мы используем Kotlin, Golang и Python. В Surf мы выбираем язык программирования под проект в зависимости от его специфики, потребностей бизнеса.
Например, для ERP-системы KFC мы выбрали Kotlin. Этот язык обладает компактным и лаконичным синтаксисом, что помогло нам быстро написать приложение со сложной бизнес-логикой.
ERP система включает в себя аналитику, учет рабочего времени сотрудников, отчетность и стратегическое планирование.
Теперь менеджеры KFC экономят до 10 часов в неделю при помощи автоматизации рутины, а все данные эффективности ресторанов оцифрованы и хранятся на сервере — это помогает быстро принимать стратегические решения.
Менеджеры KFC управляют ресторанами через приложение в более чем 930 филиалах
#4: Тестируем, тестируем и еще раз тестируем
Сегодня почти в любом гаджете есть браузер, поэтому важно, чтобы интерфейс продукта корректно отображался на экранах с различным разрешением и соотношением сторон — от квадратных до Ultrawide.
Подтвердить, что это действительно так, можно только с помощью тестов.
В Surf мы используем тестирование, в том числе чтобы узнать:
- Корректно ли интерфейс приложения отображается во всех основных браузерах, в том числе устаревших
- Нет ли несоответствий при использовании различного железа
Для этого используем как цифровые эмуляторы, так и физические фермы устройств. Чтобы работать быстрее, применяем специальные программы:
- Charles и Proxyman — для чтения и изменения трафика. Хотя для чтения вполне подходит и стандартный DevTools в браузере, этими утилитами удобно подменять ответ, когда это необходимо.
- Postman — помогает найти ошибки в API.
- Browserstack — помогает быстрее тестировать веб-приложение в разных браузерах и версиях.
- Cypress — инструмент для end-to-end тестирования, который облегчает и уменьшает нагрузку на ручных тестах.
В тестировании необходимо учитывать много нюансов, чтобы не пропустить какой-то редкий, но при этом критический баг. Например, когда мы разрабатывали платформу видеостриминга The Hole — аналог Netflix для Medium Quality — мы обнаружили, что видео отказывалось воспроизводится в некоторых версиях браузеров. Оказалось, что причина была в конфликте с одним из плагинов.
Тщательное тестирование специфических сценариев поведения пользователей помогло нам найти несколько малозаметных багов во время работы над The Hole
#5: Передаем проект инхаус и оказываем поддержку
Многие клиенты хотят развивать продукт своими силами после разработки. В таких случаях мы бесшовно организуем передачу кода и процессов. Для этого мы:
- Тщательно документируем код
- Пишем подробный readme
Всё это помогает инхаус программистам легко разобраться в том, что до них написали разработчики, которые работали над проектом.
Иногда клиенты просят помочь сформировать команду. Тогда мы постепенно вводим ее в проект, контролируем качество работы и выходим из процесса только тогда, когда у клиента получается дорабатывать продукт без нашего участия.
... А ещё не забываем документировать в процессе разработки
Документация очень важна для бесшовной передачи проекта инхаус и дальнейшей поддержки.
Мы в Surf документируем весь проект максимально подробно. Вот лишь некоторые артефакты, которые появляются у нас в процессе работы:
- Концептуальная архитектура решения — описывает верхнеуровневый облик решения.
- Информационная модель — выделяет потоки данных в проекте.
- Функциональная схема — для детального описания каждой функции системы.
- Спецификация микро сервисных API — показываем, как сервисы обмениваются данными друг с другом и предоставляют их внешним потребителям.
А ещё ближе к завершению проекта мы описываем нужную инфраструктуру — определяем требования к железу и готовим схему развертывания ПО.
В результате получаем готовый к использованию продукт.
Сколько длится разработка большого продукта?
Для реализации большинства веб-приложений хватает 3–5 месяцев. Но что если у вас масштабный проект с десятками фич, ещё и для разных целевых аудиторий?
От начала работы до достижения всех KPI обычно проходит 30–36 месяцев.
- 6 месяцев команды разработки и дизайна проектирует полнофункциональный MVP
- 12 месяцев клиент дополняет приложение новыми фичами, которые не вошли в MVP
- 12–18 месяцев нужно бизнес-аналитику с командой, чтобы выкупить все ключевые метрики.
- Года через 3 проект выходит на плато эффективности. Это когда всё оптимизировано настолько, что кардинально улучшить показатели уже сложно.
Жизненный путь проекта можно сравнить с историей гонок Formula 1. В 1950-х годах инженеры делали многократные прорывы в скорости, когда вносили радикальные изменения в дизайн и технические характеристики машин. Но сегодня они нашли почти идеальную формулу гоночного автомобиля, и борьба зачастую идет за доли секунд.
Когда бизнес выходит на такую точку, кратный рост обычно происходит уже за счет управленческих изменений, а не технологических.
Подводя итог
Веб-приложения дают бизнесу еще один канал взаимодействия с аудиторией. Их основное преимущество — это универсальность: они одинаково хорошо работают и на смартфонах (особенно если это PWA), и на десктопе. А из минусов можно отметить сложность разработки.
Мы в https://structura.app/ кстати думаем тоже посматривать в сторону проектирования именно приложений а не сайтов)