Индивидуальные веб-приложения

Какие проблемы решают индивидуальные веб-приложения?

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

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

Готовое ПО или индивидуальная разработка?

Писать ПО с нуля нужно не для каждой потребности. В таких областях, как бухгалтерия, email-маркетинг или общее управление проектами, есть хорошие готовые продукты, и чаще всего правильный выбор — именно они. Индивидуальные веб-приложения имеют смысл, когда ваш процесс не укладывается в шаблон готовых продуктов, когда склеивание нескольких отдельных инструментов только усложняет работу или когда в процессе есть метод, который отличает вашу компанию.

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

Типичные сферы применения

Частые примеры индивидуальных веб-приложений:

• Системы предложений и заказов: приложения, которые готовят предложение по правилам товаров, цен и скидок и превращают утвержденное предложение в заказ.
• Порталы для дилеров и поставщиков: закрытые разделы, где ваши партнеры видят остатки, оформляют заказы и отслеживают счета.
• Клиентские порталы: экраны, на которых клиент следит за своей заявкой, договором или сервисной записью из своего аккаунта.
• Бронирование и планирование мощностей: системы, управляющие по календарю номерами, столиками, автомобилями или мощностью команды.
• Учет работ на выезде и заказ-нарядов: приложения, в которых команды техобслуживания и монтажа видят задачи и обновляют их статус.
• Заявки и цепочки согласования: процессы, требующие одобрения нескольких людей, такие как отпуск, закупка или согласование документа.

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

Разработка веб-приложения: от анализа потребностей до запуска

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

1. Изучение процесса: узнаем, как работа идет сегодня, кто в ней участвует и где она упирается, в разговоре с соответствующими членами команды.
2. Анализ потребностей и объем работ: собираем роли пользователей, экраны, бизнес-правила и системы, с которыми нужно связаться, в письменный объем работ.
3. Сценарии и прототип: рисуем главные экраны и переходы и проверяем процесс на прототипе вместе с пользователями.
4. Решение по архитектуре и технологиям: определяем модель данных, структуру размещения и используемые технологии исходя из потребностей проекта.
5. Поэтапная разработка: разрабатываем приложение модулями и в конце каждого этапа вместе просматриваем рабочую версию.
6. Тестирование: до запуска проверяем бизнес-правила, права доступа и поведение в разных браузерах.
7. Запуск и переход: переносим существующие данные в новую систему и планируем переход со старого порядка на новый.

О чем мы говорим при анализе потребностей?

Анализ потребностей — этап, закладывающий основу для индивидуальных веб-приложений. На этом этапе мы стараемся говорить не только с руководителями, но и с людьми, которые будут пользоваться системой каждый день. Реальные детали процесса, исключения и приемы, которые применяются на практике, чаще всего известны тем, кто фактически выполняет работу.

• Кто будет пользоваться приложением и какие операции сможет выполнять каждая роль?
• Какие данные вводятся вручную, а какие придут из других систем?
• Через какие состояния проходит запись и чье согласие нужно на каждом переходе?
• Какие бывают исключения: отмена, возврат, неполные документы, повторно открытая запись?
• Какие уведомления, документы и отчеты нужно формировать?

Разделение объема работ на этапы

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

Например, в системе предложений первым этапом могут быть создание и согласование предложения, а контроль остатков, связь с бухгалтерией и отчеты об эффективности можно оставить на следующие этапы. Какой модуль будет первым, мы решаем вместе, глядя на шаг, который больше всего отнимает время в вашей компании.

На что мы смотрим на этапе прототипа?

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

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

Архитектура и технологические решения для индивидуальных веб-приложений

Срок жизни приложения определяют не только экраны, которые видит пользователь, но и структура за кадром. Индивидуальные веб-приложения — это системы, которыми пользуются годами. Поэтому мы стараемся строить архитектуру простой под сегодняшние потребности и гибкой под завтрашний рост.

Технологии выбираются под проект

Мы не применяем одну и ту же технологию к каждому проекту. Для серверной части можно рассматривать такие варианты, как Laravel, Node.js, Django или .NET, для интерфейса — библиотеки вроде React или Vue, для данных — базы данных вроде PostgreSQL или MySQL. Выбор определяют потребности приложения, ваши существующие системы и то, кто будет развивать приложение в будущем.

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

Роли пользователей и модель прав

Индивидуальные веб-приложения часто объединяют пользователей с разными правами: торговый представитель видит своих клиентов, региональный директор — свой регион, а руководитель — все записи. Модель ролей и прав мы проектируем вместе с моделью данных; правила прав, добавленные позже, и усложняются, и легко оставляют лазейки. Если нужны насыщенные экраны отчетности и операций, их лучше планировать как отдельный модуль управления: это упрощает работу.

Что значит масштабируемая архитектура?

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

Частая ошибка при разработке веб-приложения — проектировать систему, которой будут пользоваться несколько десятков человек, под очень большую аудиторию. Это без нужды увеличивает и стоимость, и нагрузку на обслуживание. Наш подход — строить структуру, которая учитывает возможность роста, но подходит под сегодняшний масштаб.

Размещение и среды

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

Невидимые, но важные части разработки веб-приложения — это вывод новых версий в работу по повторяемому процессу и возможность вернуться к предыдущей версии, если что-то пошло не так. Такой порядок позволяет делать обновления меньше и менее рискованными.

Связь с существующими системами

Индивидуальные веб-приложения редко работают сами по себе. Обмен данными с бухгалтерской программой, ERP, CRM, платежной организацией или службой доставки входит в большинство проектов. Как будут устроены эти связи и какая система станет первоисточником каких данных, мы уточняем на этапе определения объема работ; подробности мы рассказали на странице API и интеграции систем.

Безопасность, скорость и удобство использования

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

Безопасность

Список OWASP Top 10, в котором перечислены самые частые критические риски веб-приложений, — один из источников, к которым мы обращаемся при разработке. В этот список входят такие риски, как ошибки контроля доступа, атаки внедрения, слабости аутентификации и неверная конфигурация. На практике это означает такие меры:

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

Если приложение обрабатывает персональные данные, на проектирование влияет и Закон Турции № 6698 о защите персональных данных (KVKK): какие данные и зачем собираются, кто имеет к ним доступ и как долго они хранятся, нужно продумать с самого начала. Об окончательном содержании юридических документов, например уведомления об обработке данных, мы советуем получить мнение юриста.

Скорость

Экран, который долго открывается, в бизнес-приложении, которым пользуются по много раз в день, превращается в серьезную потерю времени. Время загрузки страниц, способ вывода больших таблиц и скорость часто используемых запросов мы измеряем в ходе разработки. Показатели Core Web Vitals, описанные в материалах Google на web.dev, — хорошая отправная точка для оценки скорости, которую чувствует пользователь.

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

Удобство использования

Поскольку индивидуальными веб-приложениями каждый день пользуются одни и те же люди, влияние небольших дизайнерских решений велико. Быстрый ввод данных с клавиатуры, разумные значения по умолчанию, понятные сообщения об ошибках и обратимые операции напрямую влияют на то, примет ли команда приложение. Если есть пользователи, работающие на выезде, мы отдельно проверяем, как экраны ведут себя на телефоне и планшете.

Запуск, перенос данных и что дальше

В день запуска новой системы старый порядок не исчезает мгновенно. Очистка записей из файлов Excel или старого ПО и перенос их в новую структуру требуют такого же внимания, как сама разработка веб-приложения. Неполные, повторяющиеся или введенные в разных форматах данные нужно исправить до переноса.

На что нужно обратить внимание в переходный период:

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

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

Передача приложения вашей команде

Некоторые компании хотят заказать первую версию на стороне, а дальнейшую разработку вести собственной командой разработчиков. Если такая цель есть, процесс разработки веб-приложения нужно с самого начала выстраивать с учетом этого: читаемый код, понятные заметки по установке, автоматические тесты и передача доступа к репозиторию кода облегчают передачу. Мы советуем закладывать план передачи не в конец проекта, а в его начало.

Объем работ и подготовка в проектах индивидуальных веб-приложений

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

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

Что нужно подготовить

Если вы придете на встречу по разработке веб-приложения с такими сведениями, мы сможем провести анализ потребностей гораздо эффективнее:

• краткое описание того, как процесс идет сегодня, или простая схема хода работы;
• файлы Excel, формы и образцы документов, которыми вы пользуетесь сейчас;
• люди, участвующие в процессе, и их роли;
• список другого ПО, которым вы пользуетесь, и, если есть, контакты его технических ответственных;
• то, что обязательно должно быть на первом этапе, и то, что можно оставить на потом.

Частые ошибки

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

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

Чем индивидуальные веб-приложения отличаются от готового ПО?

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

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

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

Будет ли веб-приложение работать на телефоне?

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

Можно ли в будущем продавать приложение другим компаниям?

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

Можно ли перенести наши данные из Excel в новую систему?

Можно. Данные сначала очищаются и сопоставляются с новой структурой, затем проверяются пробным переносом.

Безопасны ли индивидуальные веб-приложения?

Безопасность зависит не столько от используемой технологии, сколько от дисциплины разработки. С контролем прав, шифрованным соединением, безопасным хранением данных и регулярными обновлениями индивидуальные веб-приложения можно эксплуатировать безопасно.

Давайте вместе изучим ваш бизнес-процесс

Для первого шага достаточно коротко рассказать о процессе, который вы хотите перенести в ПО. Мы вместе изучим процесс и откровенно обсудим, что вам больше подходит: индивидуальные веб-приложения или готовый инструмент. Вы можете связаться с нами через страницу контактов.