Сайт помогает людям понять ваше предложение и связаться с вами. Веб-приложение помогает выполнить задачу в браузере. Многим проектам нужны оба варианта: открытое описание услуг и защищённый раздел для текущих обращений и заказов.
Это практическое различие для планирования, а не строгая техническая граница. На сайте могут быть калькулятор, форма записи или чат. У веб-приложения могут быть открытые страницы. Количество анимаций мало говорит о том, какое решение вам нужно.
Важны работа, которую должны выполнять пользователи, и ответственность за их данные. Следующие семь вопросов помогут определить границы проекта до получения первого предложения на разработку.
1. Людям нужно получить информацию или завершить рабочий процесс?
«Сравнить услуги и договориться о разговоре» — задача прежде всего для сайта. «Загрузить документ, ответить на уточняющие вопросы и отследить согласование» — уже рабочий процесс.
Сформулируйте предложение от лица пользователя: «Как клиент я хочу …, чтобы …». Если оно сводится к «узнать о нас больше», сложная архитектура приложения не нужна. Если дальше появляются несколько состояний и участников, стоит подробнее спланировать процесс. Различие определяется задачей, а не желаемым названием продукта.
2. Система должна помнить состояние обращения?
Контактная форма передаёт сообщение. Портал может хранить, каких документов не хватает, что уже проверено и кто выполняет следующий шаг. Это разные требования.
Если человеку нужно вернуться и продолжить работу, в план входят сохранение данных, возобновление и история изменений. Продумайте и прерывания: что произойдёт при ошибке загрузки или закрытии окна? Такие малозаметные ситуации определяют, будет ли портал удобен в ежедневной работе.
3. Все пользователи видят одну и ту же информацию?
Открытые страницы услуг обычно показывают всем одинаковый контент. В приложении клиент может видеть только свои заказы, сотрудник — несколько обращений, руководитель — дополнительные отчёты.
Один только вход по паролю эту задачу не решает. Для каждой записи нужно определить, кто вправе её читать и изменять. Если нужны разные права, заложите их реализацию и проверку с самого начала. Это относится и к скачиваниям, и к прямым ссылкам, а не только к видимым пунктам меню.
4. Данные должны оставаться согласованными с другими системами?
Иногда достаточно ссылки на существующий сервис записи. Но если расписание, сведения о клиентах или статусы должны совпадать в нескольких приложениях, интеграция становится отдельной частью проекта.
Составьте небольшой список: какая система считается основной для каждого вида данных? Кто может запускать изменения? Что происходит при сбое? «Подключим позже» — рискованный подход, если именно это подключение должно обеспечить обещанную пользу.
5. Есть ли подходящее готовое решение?
Если сервис записи, интернет-магазин или система заявок уже хорошо закрывают ваши потребности, собственное приложение не обязательно будет лучшей инвестицией. Проверяйте готовую программу на своём процессе, включая исключения. Привлекательного списка функций недостаточно.
Индивидуальная разработка становится интереснее, когда ваш процесс существенно отличается от стандартного, нужно объединить несколько систем или удобство работы даёт важное преимущество. Но и тогда лучшим решением может оказаться собственный интерфейс поверх существующих сервисов.
6. Ваше предложение должны находить через поисковики?
Для открытых услуг и экспертных статей видимость в поиске — отдельная цель. Закрытые клиентские документы, наоборот, не должны появляться в выдаче. Разделите эти области по содержанию, навигации и правилам доступа.
Веб-приложение само по себе не вредит SEO. Google умеет обрабатывать JavaScript, но по-прежнему рекомендует отдавать содержимое с сервера или предварительно формировать страницы; не каждый бот исполняет JavaScript. Поэтому открытые страницы должны быть доступны без входа, иметь понятные адреса и содержать сам текст. Источник: Google о JavaScript и поиске.
7. Кто будет поддерживать решение после запуска?
Приложению с текущими клиентскими процессами нужны ответственные за доступы, ошибки, резервные копии и изменения. Сайту с редакционными материалами тоже требуется обслуживание, но его объём часто отличается.
Назначьте со своей стороны человека, который может принимать решения и оценивать проблемы. В предложении на разработку уточняйте не только реализацию, но и обслуживание, обязанности сторон, экспорт данных и действия при сбоях. Ежемесячный счёт сам по себе не объясняет, какие услуги в него входят.
Матрица решений по вашим ответам
Это наш инструмент планирования, а не тест с баллами. Один обязательный клиентский процесс может оказаться важнее шести простых информационных страниц.
| Главная потребность | С чего логично начать | Что ещё проверить |
|---|---|---|
| Объяснить услуги и получать подходящие заявки | Сайт | Контент, способ связи, скорость загрузки, видимость в поиске |
| Записывать на приём по установленным правилам | Сайт с системой записи | Доступность времени, подтверждение, отмена, передача данных |
| Вести документы и статусы отдельно для каждого клиента | Клиентский портал или подходящая готовая программа | Права, загрузки, статусы, восстановление |
| Объединить несколько внутренних инструментов в одном процессе | Веб-приложение с интеграциями | Ответственность за данные, интерфейсы, ошибки |
| Предложить цифровой продукт множеству платящих пользователей | Веб-приложение | Аккаунты, оплата, поддержка, эксплуатация |
| Открыто рассказывать об услугах и сопровождать заказы | Сайт и защищённая часть приложения | Понятный переход между двумя областями |
Три пожелания, которые часто мешают выбору
«Должно ощущаться как приложение». Это может означать удобство работы, а может — установку и доступ без интернета. Уточните реальную ситуацию использования. Прогрессивные веб-приложения могут получать дополнительные возможности, например установку и офлайн-режим; доступность зависит от реализации и платформы. Обычное веб-приложение устанавливать не требуется. Источник: MDN о Progressive Web Apps.
«Потом мы хотим расширять всё». Предусмотрите вероятные подключения, но не оплачивайте заранее каждое воображаемое будущее. Зафиксируйте, какое расширение действительно вероятно и по каким признакам вы поймёте, что оно понадобилось.
«У конкурента есть портал». Сначала выясните, какой повторяющийся вопрос отнимает время у вашей команды. Возможно, достаточно понятного сообщения о статусе. Возможно, действительно не хватает общей рабочей среды. Решение можно принять на конкретных обращениях.
Что включить в первоначальное описание задачи
Если планируется автоматизация, стоит дополнительно разобраться, когда вместо ИИ достаточно обычных правил. Выбор веб-приложения ещё не определяет способ автоматизации.
Опишите основную группу пользователей, одну полную задачу, необходимые сведения и задействованные системы. Добавьте обычный ход работы и типичное исключение. Тогда подрядчики смогут предложить сопоставимые решения, а не разные по объёму наборы функций.
Для дальнейшего планирования посмотрите наши веб-приложения и индивидуальную разработку. Если пока непонятно, нужно ли собственное приложение, именно этот выбор должен стать частью первого разговора.