Веб-сервис отличается от сайта тем, что в нём работают, а не только читают. Личный кабинет клиента, CRM для отдела продаж, система заявок между филиалами, внутренний портал для сотрудников — всё это веб-приложения с ролями, данными и бизнес-логикой. Ошибка в таком продукте стоит дороже, чем неудачный баннер: она останавливает процесс, на котором компания зарабатывает.
Разберём, как устроена разработка веб-сервиса под ключ: какие этапы проходит проект, от чего зависят сроки, где обычно возникают риски и как их снижать, что должно быть в техническом задании и что происходит после запуска. Пишем по опыту проектов, в которых нам приходилось сначала разбираться в процессах клиента, а уже потом проектировать интерфейсы.
Когда бизнесу нужен свой веб-сервис
Заказная разработка оправдана не всегда. Если задачу закрывает готовая SaaS-система с разумной настройкой, обычно выгоднее взять её. Свой сервис стоит делать, когда:
- процесс уникален и в коробочные продукты не укладывается без костылей;
- сотрудники работают в пяти таблицах и трёх мессенджерах, а данные теряются между ними;
- нужна глубокая интеграция с вашими системами: учётом, складом, телефонией, внутренними базами;
- сервис — часть продукта для клиентов, и от него зависит выручка;
- лицензии готового решения при вашем масштабе обходятся дороже собственной разработки и поддержки.
Пример такой задачи — CRM для внутреннего взаимодействия сотрудников агрохолдинга Урал Агро Групп. Внутренние процессы крупной компании редко совпадают с логикой готовой CRM, поэтому создание веб-сервиса для бизнеса такого масштаба начинается с разбора того, как люди работают на самом деле.
Этапы разработки веб-сервиса
Названия этапов у разных подрядчиков отличаются, но суть одна. Так выглядит наш процесс.
- Аналитика и разбор процессов. Интервью с владельцами процесса и конечными пользователями, разбор текущих инструментов, сбор требований и ограничений. На выходе — описание ролей, ключевых сценариев и данных, с которыми работает система. Здесь же часто выясняется, что половину болей решает не новый функционал, а изменение процесса.
- Техническое задание и архитектура. Требования превращаются в ТЗ, которое понимают и бизнес, и разработчики. Параллельно проектируется архитектура: модель данных, интеграции, требования к нагрузке и безопасности, где и как будет развёрнут сервис.
- Прототип и дизайн интерфейсов. Сначала кликабельный прототип ключевых сценариев: его можно показать будущим пользователям и поймать ошибки логики до разработки. Затем — дизайн-система и макеты экранов. В рабочих сервисах дизайн оценивается не красотой, а скоростью выполнения задач: сколько кликов до результата, насколько понятны статусы, как выглядят пустые состояния и ошибки.
- Разработка и интеграции. Работа идёт итерациями по одной-две недели, после каждой — демонстрация работающего функционала. Интеграции с внешними системами начинаем как можно раньше: именно они чаще всего преподносят сюрпризы.
- Тестирование и перенос данных. Функциональное тестирование, проверка ролей и прав, нагрузочное тестирование при необходимости. Отдельная задача — перенос данных из старых систем и таблиц: их нужно очистить, сопоставить и проверить, что ничего не потерялось.
- Запуск, обучение и развитие. Пилот на части пользователей, обучение сотрудников, инструкции, сбор обратной связи. После запуска начинается развитие: сервис, которым реально пользуются, почти сразу обрастает новыми запросами.
MVP: с чего начинать
MVP — минимальная версия продукта, которая решает главную задачу и позволяет проверить гипотезу на реальных пользователях. Для внутреннего сервиса это, например, только приём и маршрутизация заявок без аналитики и отчётов. Для клиентского — регистрация, основной сценарий и оплата, без программы лояльности и рекомендаций.
Ошибка, которую мы часто видим: MVP понимают как «всё то же самое, только хуже». На деле это узкий, но полноценный продукт. Он должен работать надёжно, просто в нём меньше функций.
MVP — не «всё то же самое, только хуже», а узкий, но полноценный продукт: он работает надёжно, просто в нём меньше функций.
Разработка веб-приложения на заказ через MVP снижает риск: вы раньше получаете обратную связь, тратите меньше на функции, которые никому не нужны, и принимаете решения о развитии на данных, а не на предположениях.
От чего зависят сроки
Назвать срок без анализа можно только очень приблизительно. На реальный график влияют:
- Число ролей и сценариев. Сервис для одного типа пользователей и сервис, где работают клиенты, менеджеры, склад и бухгалтерия с разными правами, — задачи разного порядка.
- Интеграции. Особенно с системами, у которых нет документации или нормального API. Иногда сначала нужно договориться с подрядчиком, который поддерживает эту систему.
- Качество исходных данных. Перенос из аккуратной базы занимает дни, из десятка разрозненных таблиц — недели.
- Скорость решений на стороне клиента. Согласование макетов, ответы на вопросы, доступы к системам. Неделя ожидания ответа — это неделя сдвига срока.
- Требования к безопасности и инфраструктуре. Работа с персональными данными, размещение в контуре компании, требования службы безопасности.
Сроки для нас — показатель качества работы, поэтому мы фиксируем их по этапам, а не одной датой в конце проекта. Так отклонения видны сразу, а не за неделю до дедлайна.
Риски и как их снижать
Риски в заказной разработке довольно типовые. Важно не делать вид, что их нет, а заранее решить, что с ними делать.
- Размытые требования. «Сделайте удобно» — не требование. Снижается этапом аналитики, прототипом и приёмочными критериями для каждой функции.
- Разрастание объёма. По ходу работы появляются новые идеи, и проект не заканчивается никогда. Решение — бэклог и правило: новое уходит в следующий релиз, если не заменяет что-то из текущего.
- Интеграции, которые не работают как описано. Начинать с технического прототипа интеграции в первые недели, а не в конце.
- Сопротивление пользователей. Сотрудники продолжают работать в старых таблицах. Помогает вовлечение ключевых пользователей в проектирование, пилот и обучение.
- Зависимость от подрядчика. Код в репозитории заказчика, документация по архитектуре и развёртыванию, доступы к инфраструктуре у компании.
- Нет ответственного на стороне клиента. Нужен владелец продукта, который принимает решения и имеет на это полномочия.
Что должно быть в техническом задании
ТЗ на веб-сервис — не формальность для договора, а рабочий документ, по которому команда разрабатывает и принимает функционал. Минимальный состав:
- Цели проекта и метрики, по которым будет понятно, что сервис работает.
- Роли пользователей и их права.
- Пользовательские сценарии: кто, что и в какой последовательности делает.
- Описание сущностей и данных: заявки, клиенты, товары, документы, их статусы и связи.
- Интеграции: с какими системами, какие данные, в каком направлении, как часто.
- Нефункциональные требования: нагрузка, время отклика, безопасность, резервное копирование, браузеры и устройства.
- Требования к инфраструктуре: облако или серверы компании, окружения для тестирования.
- Состав MVP и план следующих релизов.
- Критерии приёмки: как проверяем, что функция готова.
Если ТЗ нет, его не обязательно писать заранее самим. Мы обычно формируем его на этапе аналитики вместе с клиентом. Так документ получается точнее, а оценка — реалистичнее: чем полнее описаны требования, тем точнее бюджет.
Поддержка и развитие после запуска
Запуск веб-сервиса — середина проекта, а не конец. В первые недели всплывают сценарии, которые не учли, пользователи просят доработки, меняются процессы. Поддержку стоит планировать заранее. Обычно в неё входят:
- исправление ошибок и гарантийные обязательства;
- мониторинг доступности и производительности, резервное копирование;
- обновление зависимостей и закрытие уязвимостей;
- развитие по бэклогу: новые функции, отчёты, интеграции.
Хорошая практика — ежемесячно смотреть на данные использования: какими функциями пользуются, где люди застревают, что можно автоматизировать дальше. Часть рутинных операций со временем имеет смысл отдать ИИ — например, классификацию входящих заявок или черновики ответов.
Про наш подход к проектам подробнее — на странице о студии.
Частые вопросы
Чем веб-сервис отличается от сайта?
Сайт в основном показывает информацию и собирает заявки. Веб-сервис — это приложение в браузере, где пользователи выполняют действия с данными: оформляют заказы, ведут клиентов, согласуют документы. У него есть роли, права, бизнес-логика и интеграции с другими системами.
Сколько времени занимает разработка веб-сервиса под ключ?
Зависит от числа ролей, сценариев и интеграций. Реалистичный срок можно назвать после этапа аналитики. Чтобы быстрее получить результат, имеет смысл начинать с MVP, который закрывает главную задачу, и развивать сервис релизами.
Нужно ли готовое ТЗ, чтобы начать проект?
Нет. Если ТЗ нет, его составляют на этапе аналитики вместе с подрядчиком: интервью с пользователями, разбор процессов, описание сценариев и интеграций. Такое ТЗ обычно точнее, чем написанное заранее без участия разработчиков.
Кому будет принадлежать код?
Это условие стоит закрепить в договоре. Правильная схема — исключительные права на код у заказчика, репозиторий и инфраструктура оформлены на компанию, есть документация по развёртыванию. Тогда вы не зависите от одного подрядчика.
Что выгоднее: готовое SaaS-решение или своя разработка?
Если процесс типовой и готовая система закрывает его настройкой, обычно выгоднее SaaS. Своя разработка окупается, когда процесс уникален, нужны глубокие интеграции или сервис — часть продукта, на котором вы зарабатываете.
