Этапы разработки веб-приложения: от процессов до запуска

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

Этап 1. Бизнес-задача и границы

Формулировка «нужен портал» не определяет проект. Нужна проблема: обращения теряются, согласование занимает несколько дней, клиент постоянно спрашивает статус или сотрудники вручную собирают документы.

На старте фиксируют:

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

Если граница слишком широкая, выбирают один процесс. Подход к выбору разобран в статье о первой автоматизации бизнеса.

Этап 2. Пользовательские сценарии

Сценарий описывает действие от начала до результата. Например: клиент создает заявку, сотрудник принимает ее, запрашивает уточнение, выполняет работу и публикует результат.

Для каждого сценария нужны:

1. 1Роль пользователя.
2. 2Входное событие.
3. 3Обязательные данные.
4. 4Основные шаги.
5. 5Решения и права.
6. 6Ошибки и исключения.
7. 7Проверяемый итог.

Сценарии выявляют вопросы, которые не видны на макете: кто может вернуть заявку, что делать при недоступности внешнего сервиса и какие данные остаются после удаления пользователя.

Этап 3. Модель данных и статусов

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

Модель данных должна поддерживать процесс, а не копировать текущую таблицу один к одному. Если в одном столбце хранятся разные понятия, их разделяют. Если один объект имеет несколько версий, это отражается явно.

На этом же этапе определяют источник истины для данных, приходящих из внешних систем.

Этап 4. Прототип

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

Проверяется:

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

Для клиентского портала полезно заранее использовать структуру ТЗ на личный кабинет.

Этап 5. Архитектура и интеграции

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

Для интеграций составляется карта событий, контракт полей, правила повторов и журналы. Подробно этот контур описан в материале о проектировании интеграции сайта с CRM.

Также определяются:

• среды разработки, тестирования и production;
• хранение секретов;
• резервные копии;
• журналирование;
• мониторинг;
• процесс миграций базы;
• способ отката релиза.

Этап 6. Первый рабочий контур

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

Не стоит откладывать безопасность, резервное копирование и журналы «на потом». Они являются частью работоспособности. А расширенные отчеты, редкие роли и декоративные настройки могут дождаться обратной связи.

Этап 7. Тестирование

Проверяются не только отдельные кнопки, но и процесс целиком:

• обычный сценарий;
• недостаточные права;
• пустые и пограничные данные;
• повторное действие;
• временная недоступность API;
• параллельная работа пользователей;
• восстановление после ошибки;
• уведомления;
• корректность журналов.

Критерии приемки должны быть понятны бизнесу: какой пользователь что делает и какой результат видит.

Этап 8. Подготовка запуска

До переключения production создают резервную копию, проверяют миграции, домен, SSL, уведомления и мониторинг. Назначается ответственный за решение о запуске и порядок возврата на старый сценарий.

План включает:

1. 1Что переносится.
2. 2Кто выполняет шаг.
3. 3Как проверяется результат.
4. 4Сколько длится техническое окно.
5. 5При каком условии запускается откат.
6. 6Как пользователи узнают об изменении.

Этап 9. Наблюдение после релиза

Первые часы и дни требуют повышенного контроля. Команда следит за ошибками, временем ответа, очередями, действиями пользователей и критичными сценариями.

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

Этап 10. Развитие

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

Страница разработки веб-приложений и внутренних сервисов показывает основные направления: CRM, кабинеты, интеграции и автоматизация.

Частые вопросы

Нужно ли сразу готовить полное техническое задание?

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

Когда нужен отдельный прототип?

Если система имеет несколько ролей, новые сценарии или сложные данные. Для простой административной функции может хватить схемы и компонентов существующего интерфейса.

Можно ли запускать без тестового окружения?

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

Кто принимает решение о готовности?

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