Как создать веб-сервис, чтобы он не застрял в разработке на год и не оказался никому не нужен? Идти от проверки к вложениям: сначала гипотеза и сценарий, затем кликабельный прототип и тест на людях, потом минимальная версия на реальных пользователях и только после этого — развитие. У нас этот путь до первых пользователей занимает 12–16 недель. Ниже — каждый шаг: что на нём делается, сколько длится, что нужно от вас и где без профессиональной команды начинаются дорогие ошибки.
Шаг 0. Сформулируйте гипотезу, а не список функций
Большинство затяжных проектов начинается со списка «что должно быть в сервисе» на 60 пунктов. Начинать нужно с одной фразы: кто пользователь, какую задачу он сейчас решает неудобно и как поймём, что сервис помог. Например: «дилеры заказывают через менеджера по телефону; если 70% заказов пойдут через кабинет, менеджеры освободятся под продажи». Цифру в такой фразе вы ставите сами — это ваша метрика успеха.
- Кто пользователи и сколько ролей: клиент, партнёр, менеджер, администратор.
- Один ключевой сценарий, ради которого всё затевается.
- Метрика, по которой через 2–3 месяца после запуска станет ясно, работает ли сервис.
- Человек с вашей стороны, который знает процесс и принимает решения.
Этапы разработки веб-сервиса: карта пути
Ниже — этапы в том порядке, в каком мы проводим их в проектах разработки веб-приложений и PWA. Сроки — для формата MVP и полноценного сервиса.
- Бизнес-аналитика — 2 неделиИнтервью с участниками процесса, роли, сценарии, исключения, приоритеты первой версии. На выходе — схема процессов и построчная смета.
- Архитектура и прототип — 2 неделиСхема данных, API, кликабельный прототип всех экранов ключевого сценария.
- Дизайн-система — около 2 недельКомпоненты, состояния, адаптивы — чтобы новые экраны потом собирались быстро и одинаково.
- Разработка спринтами — 6–8 недельДвухнедельные спринты с демо на тестовом стенде. Первая рабочая версия — через две недели после старта разработки.
- Нагрузка и запуск — 1–2 неделиНагрузочные тесты, мониторинг, перенос данных, обучение сотрудников, передача кода и документации.
Итого 12 недель до MVP с одним сценарием и 1–2 ролями, 16–20 недель — до сервиса с полной логикой, личным кабинетом, интеграциями с 1С и платежами.
Шаг 1. Бизнес-аналитика: описать процесс, а не экраны
Типичное ТЗ описывает, какие кнопки будут на экране. Аналитика описывает, что происходит в жизни: кто инициирует заказ, кто согласует, что делать, если товара нет на складе, кто отменяет оплату. Именно исключения потом съедают сроки, если их не нашли заранее.
У нас аналитика — отдельный этап с фиксированной ценой. На выходе вы получаете сценарии, схему данных, прототип и смету по строкам. С этим пакетом можно идти и к другому подрядчику — он ваш. Если ТЗ у вас уже есть, мы всё равно проверяем его на аналитике и дополняем ролями и исключениями. Почему мы не начинаем с анкеты на десятки вопросов, рассказали в статье о ТЗ и брифе на сайт.
Шаг 2. Прототип и тест на пользователях
Кликабельный прототип — серые экраны без графики, связанные переходами. По нему можно «пройти» сервис на телефоне и компьютере, показать его сотрудникам, клиентам, инвестору. Главная ценность — правки на этом этапе ничего не стоят, тогда как та же правка после программирования превращается в задачу на спринт.
Если идея ещё не проверена, имеет смысл заказать прототипирование интерфейсов отдельно: прототип сервиса до 40 экранов с ролями и UX-тестом на 5–8 пользователях — от 450 000 ₸ и около 2 недель. По итогам теста видно, где люди теряются, а смета разработки становится точнее, потому что все экраны и состояния уже нарисованы.
ПРАВИЛОСпорить о кнопках дешевле на сером прототипе, чем в готовом коде.
Шаг 3. MVP: одна роль, один сценарий, реальные пользователи
MVP — не «половина сервиса, сделанная наспех», а полноценная версия одного ключевого сценария. Функция попадает в первую версию, если без неё нельзя проверить гипотезу. Всё остальное — в список следующих спринтов.
Веб-сервис мы делаем на Laravel и Vue как PWA: он ставится на телефон иконкой, отправляет push и открывается без сети с ранее загруженными данными. Это закрывает большинство задач приложения без публикации в App Store и Google Play. Если же гипотеза именно про мобильный сценарий — камера, геолокация в фоне, аудитория в основном на iPhone, — логичнее разработка MVP мобильного приложения на Flutter за 8–10 недель. Бэкенд при этом один, и веб-версию можно добавить позже. Разницу между прототипом, MVP и пилотом мы разбирали в отдельной статье.
Как разработать веб-приложение и не потерять контроль
Разработка спринтами нужна не ради модного слова. Каждые две недели вы видите живой сервис на тестовом стенде, принимаете готовые задачи и меняете приоритеты следующего спринта. Проблема видна через две недели, а не в день сдачи.
| Этап | Кто нужен со стороны подрядчика | Что нужно от вас |
|---|---|---|
| Аналитика | Аналитик, тимлид | Интервью с участниками процесса, доступы к 1С и CRM |
| Прототип и дизайн | UX-дизайнер, аналитик | Решения по сценариям в тот же день |
| Разработка | Проектный менеджер, два разработчика, QA | Демо раз в две недели, приёмка задач |
| Запуск | Вся команда | Данные для переноса, сотрудники на обучение |
Отдать проект подрядчику и ждать результата через четыре месяца. Без человека, который ходит на демо и принимает решения, сервис собирают по предположениям, и после запуска начинаются переделки.
Шаг 4. Запуск веб-сервиса и первые пользователи
Последние 1–2 недели — не «залить на сервер». Это нагрузочное тестирование, мониторинг и резервные копии, перенос данных из Excel или старой системы, обучение сотрудников, передача кода и документации. Запускаем в будний день, когда команда на связи, а первые 30 дней правки по вине разработчика бесплатны.
- Ключевой сценарий пройден на тестовом стенде реальными сотрудниками.
- Роли и права проверены: клиент не видит чужие данные.
- Данные из старых таблиц перенесены и сверены.
- Интеграции с 1С, CRM, платёжным шлюзом работают на боевых доступах.
- Настроены мониторинг, резервное копирование и уведомления об ошибках.
- Сервис размещён на хостинге, оформленном на вашу компанию.
- Код в вашем репозитории, документация по API и развёртыванию передана.
- Пользователям отправлена инструкция и понятно, куда писать о проблемах.
- Метрика успеха считается автоматически с первого дня.
Шаг 5. Развитие по данным, а не по предположениям
После запуска MVP через несколько недель уже видно, где пользователи застревают и что просят. Новые роли, отчёты и интеграции становятся задачами ближайших спринтов: через две недели функция на тестовом стенде. Так сервис растёт от MVP до полноценного формата без переделок, потому что архитектура и API с самого начала проектировались под рост.
Чтобы развитие шло по данным, договоритесь заранее, что смотреть. Минимальный набор для веб-сервиса: сколько пользователей дошли до целевого действия, на каком шаге сценария бросают, сколько обращений в поддержку приходится на одну операцию и как изменилась нагрузка на сотрудников, ради которых всё затевалось. Если метрика из шага 0 растёт — расширяйте роли и интеграции. Если нет — сначала разберитесь, где сценарий ломается, и только потом добавляйте новые функции.
Отдельно решите, что выносится в админку. Справочники, статусы, тексты уведомлений и настройки процессов, которые меняются чаще раза в месяц, должны редактироваться без разработчика — иначе каждая мелочь будет ждать спринта.
Расскажите идею сервиса за 30 минут — пришлём план этапов и смету MVP за один рабочий день.
Обсудить веб-сервисЧто делать на этой неделе
Запишите гипотезу одной фразой, выберите ключевой сценарий и назначьте человека, который будет принимать решения. С этими тремя вещами можно идти на аналитику или сразу на прототип. Бюджет форматов — от 5 000 000 ₸ за MVP, от 9 000 000 ₸ за «Сервис», от 15 000 000 ₸ за «Платформу» на тысячи пользователей. Начать с аналитики или прототипа значит потратить несколько недель на то, чтобы основные миллионы ушли в правильный продукт.
Сколько времени занимает создание веб-сервиса?
MVP с одним сценарием и 1–2 ролями — около 12 недель, сервис с полной логикой, кабинетом и интеграциями — 16–20 недель. Первая рабочая версия на тестовом стенде появляется через две недели после старта разработки.
Можно ли создать веб-сервис без ТЗ?
Да. Двухнедельная бизнес-аналитика заменяет ТЗ: на выходе сценарии, схема данных, прототип и построчная смета.
Что выбрать для запуска: веб-сервис или мобильное приложение?
Если сценарий не требует глубокой работы с телефоном, PWA дешевле и не проходит ревью сторов. Когда понадобится нативное приложение, оно подключится к тому же API.
Кому принадлежит код после запуска?
Вам: код хранится в вашем репозитории с первого дня, аккаунты и хостинг оформляются на компанию, документация входит в работы.