Каждую неделю разбираем новое про нейросети и автоматизацию для бизнеса: инструменты, кейсы, ошибки. Подпишитесь, чтобы не пропустить.
[ChannelSubscribe]
Чем веб-приложение отличается от сайта
Веб-приложение - это программа, которая работает в браузере. Открывается по ссылке, ставить ничего не надо, данные хранятся на сервере.
Разница с сайтом не в размере и не в красоте, а в том, что делает человек. На сайте он смотрит: читает описание услуги, изучает цены, оставляет заявку. В веб-приложении он работает: заходит под своей учётной записью, добавляет записи, считает, выгружает отчёт, видит только своё.
Простой тест на один вопрос: нужен ли пользователю личный вход? Если да - вы описываете веб-приложение. Личный кабинет, где клиент видит свои заказы, - уже оно. Калькулятор с сохранением расчётов - оно же. Лендинг с формой заявки - нет, это сайт.
Путаница дорого стоит. Заказчик говорит «нужен сайт с личным кабинетом», подрядчик считает как сайт, а по факту делается приложение - и на середине выясняется, что бюджет и срок были посчитаны не про то.
Когда веб-приложение оправдано, а когда избыточно
Признаки, что вам действительно нужно приложение:
- У каждого пользователя своя картина. Клиент видит свои заказы, сотрудник - свои задачи. Общая страница для всех тут не работает.
- Действия повторяются много раз в день. Раз в месяц заполнить форму - это форма. Каждый день вести десятки записей - это приложение.
- Данные надо считать и связывать. Не просто хранить, а показывать в разрезах, суммировать, сравнивать.
- Нужны роли и права. Менеджер видит одно, руководитель другое, клиент третье.
Признаки, что избыточно: задача укладывается в таблицу, которую ведут два человека; всё нужное уже умеет готовый сервис; процесс ещё не устоялся и меняется каждую неделю. В последнем случае разработка почти всегда преждевременна - вы оплатите автоматизацию процесса, который через месяц станет другим.
Отдельный случай - когда веб-приложение нужно, но не целиком. Часто хватает готовой системы плюс небольшой надстройки под ваш кусок процесса. Это дешевле и быстрее, чем своя разработка с нуля.
Из чего состоит веб-приложение
- Интерфейс. То, что открывается в браузере: экраны, формы, таблицы, кнопки. Здесь живёт удобство, и именно сюда чаще всего уходит время на переделки.
- Серверная часть. Логика: кто что может, как считается, что происходит после нажатия. Пользователь её не видит, но она определяет, работает продукт или нет.
- База данных. Где хранятся записи. От того, как устроена структура, зависит, легко ли будет добавлять новое через год.
- Интеграции. Оплата, почта, мессенджеры, телефония, ваши внутренние системы. Каждая связка - отдельная работа и отдельный источник неожиданностей.
- Учётные записи и права. Вход, роли, разграничение доступа. Кажется мелочью, пока не выясняется, что клиент видит чужие данные.
Если задача сводится к тому, чтобы руководитель видел цифры в одном месте, полноценное приложение может и не понадобиться - иногда хватает дашборда без программиста.
Мы делаем такие продукты как заказную разработку и по опыту скажем: сложность проекта обычно определяется не количеством экранов, а числом ролей и интеграций.
Этапы разработки: что за чем
Шаг 1. Разбор задачи. Кто пользователи, что каждый из них делает, какие данные ходят между ними. На выходе - описание, по которому можно оценить объём. Без этого любая оценка будет угадыванием.
Шаг 2. Прототип. Схемы экранов без дизайна: что где расположено и что происходит по нажатию. Дешёвый способ увидеть логику до того, как её начали писать. Переделать прототип - это часы, переделать готовый экран - недели.
Шаг 3. Дизайн. Как это выглядит. Здесь же решается, как продукт будет вести себя на телефоне.
Шаг 4. Разработка. Интерфейс, сервер, база, интеграции. Обычно кусками: сначала главный сценарий целиком, потом остальное.
Шаг 5. Проверка. Не только «работает ли кнопка», но и что происходит при странных действиях пользователя: пустые поля, двойное нажатие, обрыв связи.
Шаг 6. Запуск и первые недели. Реальные пользователи находят то, чего не находит проверка. Это нормально и должно быть заложено в план.
Порядок можно ужимать, но не переставлять. Написать сначала, а разобраться потом - самый дорогой из возможных путей.
Где обычно уезжает срок
Невыясненные требования. Договорились «сделать личный кабинет», а на середине выяснилось, что там ещё выгрузка в бухгалтерию и три роли. Лечится подробным разбором на первом шаге.
Интеграции. Чужой сервис может не иметь нормального способа подключения, отдавать данные с задержкой или ломаться в самый нужный момент. Проверять доступность связок нужно до старта, а не в середине.
Согласования на стороне заказчика. Экраны ждут решения по неделе, а календарь идёт. Это не техническая проблема, но по срокам она бьёт сильнее многих технических.
Изменения по ходу. Нормально, если управляемо: новое пожелание либо заменяет что-то из плана, либо сдвигает срок. Ненормально, когда добавляется молча и бесплатно - тогда проект не заканчивается никогда.
Что подготовить до первого разговора
- Кто пользователи и что каждый делает. Три-четыре роли и по пять действий на каждую. Этого достаточно для первой оценки.
- Пример данных. Реальная таблица или несколько записей в том виде, в котором вы их сейчас ведёте. Один пример объясняет больше, чем страница текста.
- С чем связывать. Оплата, почта, телефония, ваши системы. Названия и то, есть ли к ним доступ.
- Что считается успехом. Одно предложение: «менеджер перестал вести заказы в таблице» или «клиент видит статус сам и не звонит». Без этой фразы легко сделать формально рабочий продукт, который не решает исходную задачу.
Подготовка занимает пару часов и сокращает первый этап в разы. Тот же список пригодится, если вы решите строить не приложение, а автоматизацию поверх готовых систем.
Хотите собрать связку целиком - от разбора задачи до работающего продукта? ClaudeLab ставит шаги вместе и доводит до результата.
Четыре ошибки, из-за которых проект дорожает
- Делать всё сразу. Попытка запустить полный функционал одним куском растягивает срок и откладывает первую пользу. Правильнее выпустить главный сценарий и достраивать по мере использования - тем же принципом строится и разработка программного обеспечения на заказ в целом.
- Экономить на разборе задачи. Самый дорогой способ сэкономить. Непонятые требования всплывают в разработке, где их исправление стоит в разы дороже.
- Менять подрядчика на середине. Иногда неизбежно, но всегда дорого: новая команда тратит время на чужой код и почти никогда не соглашается отвечать за то, что было до неё.
- Оставлять продукт без сопровождения. Приложение живёт, пока его поддерживают. Через полгода без обновлений оно превращается в источник проблем.
Своя разработка или готовое решение
Готовые сервисы закрывают большинство типовых задач и запускаются быстро. Их слабое место - вы принимаете чужую логику. Пока она близка к вашей, всё хорошо.
Своя разработка оправдана в трёх случаях: процесс нестандартный и менять его нельзя, нужна плотная связка с внутренними системами, данных и ролей столько, что готовые тарифы перестают быть удобными.
Есть и промежуточный путь, который часто оказывается лучшим: взять готовое ядро и дописать недостающее. Так закрывается большая часть нестандартных требований без разработки с нуля.
Что запомнить
Веб-приложение - это не большой сайт. Это другой тип продукта, где человек работает, а не читает. Проверяется одним вопросом про личный вход.
Дальше всё решает подготовка. Час на описание ролей и действий экономит недели на переделках, а первый выпуск главного сценария даёт пользу раньше, чем полный функционал через полгода.