← Назад

Веб-разработка

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

3 мин чтения

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

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

Обычная первая фраза на встрече: «нужен сайт, чтобы клиенты оставляли заявки и видели статус заказа». В ней два разных проекта. Первая половина - сайт: рассказать о компании и собрать заявку. Вторая половина - уже приложение: у клиента появляется вход, у заказа появляется состояние, и кто-то должен это состояние менять. Разница не в размере и не в количестве страниц, и она сильно влияет на цену.

01Простой признак: на сайте читают, в приложении работают

Сайт можно открыть без входа, прочитать и закрыть. Данные на нём одинаковые для всех посетителей, а самое сложное действие - отправить форму. Приложение начинается там, где у человека появляется своя учётная запись и свои данные внутри.

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

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

Если ни один пункт не подходит, вам нужен сайт, и это хорошая новость: он дешевле, быстрее и проще в поддержке.

02Четыре вопроса, которые решают до кода

В приложении почти вся сложность решается не на этапе вёрстки, а на этапе договорённостей. Мы собираем схему до написания кода и утверждаем её с заказчиком, потому что переделывать её потом дороже всего.

  • Какие есть роли. Не «пользователь и админ», а честный список: кто заводит заявку, кто её выполняет, кто согласует, кто видит отчёт.
  • Какие есть состояния. Что происходит с заявкой от появления до закрытия, и какие переходы между состояниями разрешены, а какие нет.
  • Кто что видит. Для каждой роли: какие поля доступны, а какие не должны доходить до её экрана вовсе.
  • С чем надо связаться. Оплата, банк, служба доставки, бухгалтерия, CRM, API партнёра. Каждая внешняя система - отдельный кусок работы со своими сроками.

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

03Права доступа стоят дороже, чем кажется

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

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

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

04Из чего складывается цена

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

  • Число ролей. Каждая новая роль - это свои экраны, свои права и свои проверки, а не «ещё одна кнопка».
  • Число состояний и переходов между ними. Восемь переходов вместо трёх - это в разы больше случаев, которые надо описать и проверить.
  • Внешние системы. Подключение к банку или к API партнёра почти всегда дольше, чем кажется: чужая сторона живёт по своему расписанию.

Наши открытые цифры: сайт - от 3200 манат, веб-приложение - от 25 000 манат. Ориентир по сроку из сданного проекта: маркетплейс с двумя кабинетами, сделкой из шести состояний, файлами и обновлениями в реальном времени занял четыре месяца разработки плюс приёмочное тестирование на стороне заказчика.

05Когда приложение не нужно

Чаще, чем принято думать. Если клиенту достаточно узнать статус по звонку или по сообщению, а заявок в день немного, связка «сайт с формой плюс таблица или готовая CRM» решает задачу за долю стоимости и работает завтра, а не через несколько месяцев. Приложение окупается там, где ручная передача информации между людьми уже мешает: заявок много, сторон несколько, и ошибки стоят денег.

Честный порядок такой: сначала проверяем, закрывается ли задача сайтом и готовыми инструментами. Если да, мы так и говорим.

06Как это выглядит вживую

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

Ещё статьи