Stalar Vision 
Тендеры и лиды
Информация
Сайт редко становится сложным сразу.
Обычно всё начинается вполне разумно: несколько страниц, форма обратной связи, каталог услуг, контакты, новости. Потом появляется ещё одна форма. Затем статус заявки. Потом сотрудники просят уведомления в Telegram. Следом — личный кабинет, импорт из Excel, роли пользователей, история изменений и интеграция с CRM.
Формально проект всё ещё называют сайтом.
Фактически он уже начинает работать как информационная система.
Именно этот переход часто замечают слишком поздно. Пока каждая новая задача выглядит как «небольшая доработка», архитектура постепенно обрастает исключениями, ручными операциями и зависимостями. В какой-то момент бизнес уже пытается автоматизировать полноценный процесс средствами системы, которая изначально проектировалась только для публикации страниц.
Ниже — семь признаков, по которым можно понять, что одного сайта становится недостаточно и задачу уже стоит рассматривать как веб-приложение.
Представим небольшую компанию.
Сначала на сайте есть форма заявки. Менеджер получает письмо и связывается с клиентом.
Через несколько месяцев заявок становится больше. Менеджер начинает переносить их в Excel. Статусы обсуждаются в Telegram. Итоговая стоимость хранится в CRM. Если клиент что-то меняет, информацию приходится обновлять сразу в нескольких местах.
Потом возникает вопрос: какая версия данных актуальна?
В таблице один статус, в CRM другой, а последнее решение вообще осталось в переписке.
На этом этапе проблема уже не в форме на сайте. Компания фактически создала распределённую информационную систему — только без единого центра управления данными.
Вот здесь и проходит одна из главных границ между сайтом и приложением.
На обычном сайте данные в основном публикуются.
Это тексты, изображения, услуги, товары, статьи, контакты.
В приложении данные начинают жить по определённым правилам.
Например, заявка проходит состояния:
черновик → отправлено → на согласовании → одобрено
Заказ может двигаться так:
создан → в обработке → выполнен → закрыт
Документ может быть создан, проверен, возвращён на доработку и снова отправлен.
Как только у объекта появляется жизненный цикл, нужно определить:
какие состояния существуют;
какие переходы между ними разрешены;
кто может выполнять эти переходы;
что происходит при ошибке;
какие действия должны сохраняться в истории.
Это уже не просто работа с контентом.
Это бизнес-логика.
Для обычного сайта часто достаточно двух типов участников:
посетитель и администратор.
Но по мере развития проекта появляются другие роли.
Например:
сотрудник создаёт заявку;
руководитель её согласовывает;
бухгалтер видит финансовые данные;
оператор меняет статусы;
клиент видит только свои записи;
администратор управляет пользователями.
На этом этапе недостаточно просто спрятать часть интерфейса.
Если пользователь не имеет права согласовать заявку, сервер тоже должен запретить такое действие — даже если кто-то попытается вызвать его напрямую.
Иначе получается не система прав доступа, а только визуальная иллюзия безопасности.
Как только в требованиях появляются формулировки вроде:
этот сотрудник может видеть данные, но не может их менять;
или:
руководитель видит все заявки отдела, а сотрудник — только свои,
проект уже начинает требовать полноценной ролевой модели.
У обычного сайта пользователь чаще всего совершает одно простое действие:
отправляет форму;
звонит;
оставляет заявку;
делает заказ.
В приложении возникает последовательность.
Например:
сотрудник создаёт заявку;
система проверяет данные;
руководитель получает уведомление;
руководитель принимает решение;
система сохраняет результат;
сотрудник получает уведомление;
при отказе заявка возвращается на доработку.
Это уже workflow.
И здесь есть важное различие:
«кнопка работает» и «процесс работает корректно» — не одно и то же.
После нажатия кнопки «Согласовать» система может быть обязана:
проверить права пользователя;
проверить текущий статус заявки;
убедиться, что переход разрешён;
записать изменения;
сохранить событие в историю;
отправить уведомление;
вернуть пользователю актуальное состояние;
корректно обработать сбой.
Интерфейс в таком проекте — лишь верхний слой.
Основная сложность находится в правилах, которые стоят за ним.
Один из самых заметных сигналов — ручное копирование информации между разными системами.
Например:
сайт → Excel → Telegram → CRM → снова Excel.
Пока операций мало, такой процесс может выглядеть вполне терпимо.
С ростом объёма возникают:
дубли;
ошибки копирования;
разные версии данных;
потерянные сообщения;
забытые статусы;
зависимость процесса от конкретного сотрудника.
Здесь возникает ещё одна важная проблема — исчезает единый источник истины.
Если статус заказа хранится одновременно в таблице, CRM и переписке, становится непонятно, какой из них актуален.
В хорошем прикладном решении должен существовать основной источник данных, а остальные системы либо получают из него информацию, либо синхронизируются с ним по определённым правилам.
Тогда ручные операции можно постепенно заменять интеграциями:
заявка автоматически создаётся в системе;
Telegram получает уведомление;
CRM обновляется через API;
документ формируется автоматически;
статус меняется в одном месте и распространяется дальше.
В этот момент веб-приложение становится центром процесса, а не просто точкой входа.
На обычном сайте редко критично знать, кто именно исправил заголовок страницы.
В бизнес-системе такой вопрос возникает постоянно.
Кто изменил сумму?
Когда заявка была согласована?
Кто вернул документ на доработку?
Почему статус изменился?
Какие данные были до изменения?
Здесь уже нужен не просто технический лог, а бизнес-аудит.
Пользователю обычно важно видеть не:
POST /request выполнен в 14:32
а:
Иван Петров изменил сумму со 120 000 ₽ на 145 000 ₽ и повторно отправил заявку на согласование.
Такая история помогает:
разбирать ошибки;
восстанавливать последовательность событий;
понимать ответственность;
анализировать спорные ситуации;
поддерживать прозрачность процесса.
Если вопрос «кто это изменил?» звучит регулярно, аудит лучше закладывать в архитектуру заранее.
На информационном сайте ошибка обычно означает неудобство.
Например, неправильно заполненную форму.
В приложении ошибка может привести к:
повторному заказу;
неверной сумме;
ошибочному статусу;
пропущенному сроку;
повторному уведомлению;
неправильному согласованию;
потере данных.
Поэтому появляются дополнительные требования:
проверки входных данных;
ограничения переходов;
подтверждение критичных операций;
защита от повторных действий;
обработка конфликтов;
транзакционность.
Простой пример: пользователь дважды нажал кнопку «Создать заказ».
Хорошая система не должна создавать два одинаковых заказа только потому, что запрос был отправлен повторно.
Или два сотрудника одновременно открыли одну заявку. Один уже изменил её статус, а второй работает со старой версией. Система должна заметить конфликт, а не молча перезаписать данные.
На этом уровне требования уже становятся архитектурными.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13755 тендеров
проведено за восемь лет работы нашего сайта.
Сначала новое поле добавляется за час.
Потом ещё одна функция — за день.
Через некоторое время каждая доработка начинает звучать примерно так:
Сначала нужно обновить старый модуль, потом проверить совместимость с интеграцией, затем изменить форму, а после этого убедиться, что не сломалась другая часть.
Это один из самых тревожных признаков.
Он не означает, что старая технология плохая.
Чаще причина проще: проект вырос из первоначальной задачи.
Когда сайт создавался, от него требовались страницы и формы.
Через два года бизнесу уже нужны роли, процессы, история, автоматизация и интеграции.
Архитектура осталась прежней, а задача изменилась.
В этот момент стоит сравнить стоимость очередной серии обходных решений со стоимостью архитектурного пересмотра.
Иногда дальнейшая доработка старой схемы по-прежнему выгоднее.
А иногда продолжать её расширять уже дороже, чем выделить отдельное приложение.
Эти семь признаков — не формальная методика и не технический стандарт.
Скорее это диагностическая эвристика.
Условно можно ориентироваться так:
1–2 признака
Скорее всего, обычного сайта с отдельными доработками ещё достаточно.
3–4 признака
Имеет смысл провести технический разбор: посмотреть на данные, роли, интеграции и будущие требования.
5 и более признаков
Высока вероятность, что система уже фактически работает как приложение и её стоит проектировать соответствующим образом.
Важно не количество галочек само по себе, а то, насколько критичны процессы, которые за ними стоят.
Слово «веб-приложение» часто ассоциируется с огромной корпоративной системой и многомесячной разработкой.
Это необязательно так.
Приложение может быть небольшим:
личный кабинет для нескольких десятков клиентов;
интерфейс согласования заявок;
система формирования коммерческих предложений;
внутренний сервис учёта;
панель мониторинга;
небольшая система уведомлений;
инструмент обработки документов.
Главное отличие — не количество экранов.
Приложение обслуживает процесс.
Ещё один важный момент: если сайт вырос из своей первоначальной модели, это не значит, что его обязательно нужно удалить и переписать целиком.
Часто разумнее разделить систему.
Например:
публичный сайт остаётся как есть;
рядом появляется отдельный backend;
добавляется личный кабинет;
создаётся административный интерфейс;
часть операций выносится во внутренний сервис.
То есть переход можно делать постепенно.
Это особенно полезно, если текущий сайт уже индексируется, имеет трафик и нормально выполняет свою публичную функцию.
Не каждый бизнес-процесс нужно автоматизировать.
Если задача проекта состоит в том, чтобы:
показать услуги;
рассказать о компании;
публиковать материалы;
принимать простые обращения;
предоставить контакты;
то отдельное приложение может оказаться лишней сложностью.
Для многих компаний обычная CMS — более рациональное решение.
Больше кода не означает больше пользы.
Хорошая архитектура — это не самая сложная архитектура, а та, которая соответствует реальной задаче.
Перед тем как добавлять очередной крупный функциональный блок, полезно описать четыре вещи.
Например:
клиент;
заявка;
заказ;
документ;
сотрудник.
Например:
новая → в работе → согласована → завершена
Какие роли существуют и какие действия доступны каждой из них.
Что сотрудники переносят между таблицами, мессенджерами, CRM и другими системами.
Если описание этого процесса уже занимает несколько страниц, вероятно, речь давно идёт не просто о доработке сайта.
Не с переписывания.
Сначала стоит взять один реальный рабочий процесс и пройти его от начала до конца.
Например:
клиент отправляет заявку → менеджер получает её → проверяет данные → согласовывает условия → меняет статус → отправляет ответ.
После этого полезно ответить:
где появляются данные;
где они хранятся;
кто их изменяет;
какие системы участвуют;
где возникает ручной труд;
где чаще происходят ошибки;
какие операции повторяются.
Иногда после такого разбора оказывается, что проблему решает одна небольшая интеграция.
Иногда достаточно изменить административный интерфейс.
А иногда действительно становится понятно, что нужен отдельный сервис.
Главное — сначала проектировать процесс, а уже потом выбирать технологию.
Граница между сайтом и веб-приложением проходит не по React, WordPress, Python или конкретному фреймворку.
Она проходит по характеру задачи.
Пока система в основном публикует информацию, сайт остаётся сайтом.
Когда появляются состояния, роли, процессы, история действий, интеграции, автоматизация и бизнес-критичные операции, проект фактически становится приложением.
И чем раньше это замечено, тем меньше приходится строить временных решений, которые впоследствии всё равно приходится переделывать.
Перед следующей крупной доработкой полезно задать один вопрос:
мы действительно добавляем ещё одну страницу — или уже пытаемся автоматизировать бизнес-процесс средствами сайта?
Если второе, возможно, пришло время проектировать уже не просто сайт, а веб-приложение.
