Разработка веб-приложений: основные этапы

Разработка веб-приложения проходит через пять этапов: анализ требований и техзадание, прототип с UI/UX, непосредственно разработку frontend и backend, тестирование вместе с интеграциями и запуск с поддержкой. Для B2B-проекта в Москве весь цикл занимает от полутора до четырёх месяцев — срок зависит от сложности обмена данными с учётными системами и количества правок на этапе дизайна.

из каких этапов состоит разработка веб-приложения

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

1. ✓анализ и техническое задание — фиксируют, что должно делать приложение, кто им пользуется и с какими системами оно обменивается данными;
2. ✓прототип и UI/UX-дизайн — собирают каркас экранов и проверяют логику на будущих пользователях до того, как потрачен бюджет на код;
3. ✓разработка frontend и backend — параллельно пишут интерфейс и серверную логику, здесь же закладывают API для 1С или других систем;
4. ✓тестирование вместе с интеграциями — проверяют не только интерфейс, но и обмен данными с учётной системой на реальных сценариях, а не на тестовой базе;
5. ✓запуск и техническая поддержка — приложение выходит в прод, дальше нужен человек, который следит за сервером, обновлениями и растущей нагрузкой.

Для мобильных продуктов процесс строится по той же схеме, только вместо веб-фронтенда — iOS, Android или кросс-платформенная сборка: подробнее на странице разработка мобильных приложений.

как этапы пересекаются на практике

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

Отдельный вопрос — кто занимается приложением после запуска. Веб-приложение, которое сдали и забыли, живёт до первого изменения в структуре 1С: поменялось наименование справочника, добавилось новое поле — и обмен данными тихо ломается, а заметят это не разработчики, а пользователи, когда остатки перестанут сходиться.

почему разработка веб-приложения останавливается на середине проекта

Отдел продаж заказывает портал для дилеров: форма заявки, остатки на складе, статус отгрузки. Через три месяца после старта интерфейс готов почти полностью, дизайн утверждён, формы работают — но раздел «остатки» показывает тестовые данные, потому что обмен с 1С обсудили только на этапе тестирования, а не в техзадании.

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

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

где чаще всего теряют время

Три места в проекте почти всегда становятся узким горлом:

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

как исправить ситуацию, если разработка встала

Первый шаг — не «доделать быстрее», а найти точную точку разрыва. Обычно это один из трёх узлов: формат данных 1С не совпадает с тем, что ждёт приложение; обмен спроектирован как разовая выгрузка, хотя нужен постоянный синк; или в команде веб-разработки просто нет человека, который раньше работал с 1С.

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

что входит в минимальный рабочий контур

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

Такой контур можно запустить за одну-две недели, а расширять уже на работающем приложении. Если своей экспертизы по 1С не хватает, разумнее подключить специалиста именно на интеграцию, не останавливая фронтенд-команду: в ukved этим занимается отдельное направление — интеграция приложения с 1С, работа идёт через штатные механизмы обмена, а не через прямые запросы к базе в обход учётной системы.

что делать, если проблема повторяется в каждом проекте

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

Рабочий вариант — с самого начала собирать проект как связку: подрядчик по вебу или мобильной разработке плюс специалист, который понимает структуру 1С и её объектный состав. Тогда API для обмена данными проектируют один раз, с двух сторон сразу, а не переделывают через три месяца после старта.

Для корпоративных заказчиков в ukved есть готовый формат такой связки — B2B-приложение с 1С, где интеграция закладывается в архитектуру на этапе техзадания, а не добавляется постфактум, когда фронтенд уже готов.

как предотвратить провал ещё на старте проекта

Три пункта в техзадании снимают большую часть риска. Первый — явно описать, какие данные приходят из 1С, в каком формате и как часто обновляются: раз в сутки или в реальном времени — это разная архитектура и разная цена. Второй — назначить одного ответственного за интеграцию с обеих сторон, а не оставлять вопрос «на потом», когда фронтенд уже сдан. Третий — заложить в план отдельный этап тестирования обмена данными на реальной, а не демонстрационной базе, с теми объёмами, что будут в проде.

Если приложение хранит персональные данные сотрудников или клиентов дилера, это тоже часть техзадания, а не решение постфактум: требования 152-ФЗ к обработке персональных данных (152-ФЗ) касаются и веб-, и мобильных приложений, если они собирают ФИО, телефон или адрес.

Альтернативный путь для части проектов — не строить отдельное веб- или мобильное приложение с нуля, а собрать интерфейс сразу на 1С:Мобильной платформе: тогда обмен данными с учётной системой не отдельный этап с рисками, а часть платформы изначально.

как выбрать между веб- и мобильным приложением на старте

Однозначного правила нет, но два вопроса обычно снимают сомнения. Где сотрудники или партнёры будут пользоваться приложением: если это офис и стационарный компьютер — веб-версии достаточно, если склад, поездки к клиентам или работа без стабильного интернета — нужна нативная мобильная разработка с офлайн-режимом. И второй вопрос: нужен ли доступ без установки, по ссылке, для внешних контрагентов, которых не хочется просить ставить приложение. Часто рабочим решением оказывается связка: веб-версия для администраторов и внутренних пользователей, мобильное приложение — для тех, кто вне офиса.

сколько стоит разработка приложения с интеграцией 1С

Цена складывается из тех же пяти этапов, и интеграция — не бесплатное дополнение, а отдельная статья бюджета: проектирование обмена, тестирование на реальных данных, доработка при изменениях в структуре 1С. Ниже — ориентир по вариантам реализации для B2B-задач.

что влияет на итоговую стоимость

Помимо этапов на цену напрямую влияют три фактора. Количество интеграций — обмен с 1С почти всегда сложнее, чем кажется на старте, потому что затрагивает не только остатки и заказы, но и права доступа: разным дилерам должны быть видны разные цены и разные склады. Глубина администрирования — простой каталог с формой заявки стоит иначе, чем портал с личным кабинетом, историей заказов и выгрузкой документов. И объём тестирования — если приложением пользуются внешние контрагенты, а не только сотрудники, ошибку в остатках увидит клиент, а не коллега из соседнего отдела, поэтому тестовый контур обычно шире.

Разработка мобильного приложения в ukved начинается от 500 000 руб. и включает все пять этапов — от техзадания до запуска. Отдельно считается серверная инфраструктура для 1С, если её ещё нет: аренда сервера 1С — от 3 300 руб/мес, а сопровождение и доработки после запуска — от 3 800 руб/час. Актуальные условия — на странице цены и тарифы.

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

Сколько времени занимает разработка веб-приложения для B2B?

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

Чем веб-приложение отличается от мобильного при работе с 1С?

Технически интеграция с 1С устроена похоже в обоих случаях — через API. Разница в сценарии использования: веб-версия удобна в офисе и не требует установки, мобильное приложение нужно там, где важен офлайн-режим — на складе, в поездках к клиентам, у курьеров.

Можно ли обойтись без отдельной веб-разработки и сделать всё на 1С:Мобильной платформе?

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

Сколько стоит разработка приложения с интеграцией 1С?

Мобильная разработка в ukved начинается от 500 000 руб. и включает все этапы — от техзадания до запуска. Итоговая цена зависит от числа интеграций, глубины админки и объёма тестирования; отдельно считается серверная инфраструктура для 1С.

Что будет, если пропустить полноценное тестирование интеграции с 1С?

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