Веб-сервисы · Приоритетное направление

Разработка веб-сервисов

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

Обсудить задачуЧто входит

Результат проекта

  • 01Архитектура проверена на первой рабочей версии
  • 02Доступ разграничен по ролям и защищён
  • 03Развитие идёт итерациями, без переписывания с нуля

Состав решения

Что входит в проект

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

Подробности

Как устроена работа

01

Цель сервиса и пользователи

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

  • Что делается вручную сегодня
  • Кто и как часто будет пользоваться
  • Измеримый признак успеха

02

Роли и сценарии

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

  • Матрица ролей и прав
  • Отдельный сценарий для каждой роли
  • Ограничение доступа к чужим данным

03

Архитектура

Выбираем структуру приложения под ожидаемую нагрузку и планы развития. Модульность важнее универсальности: добавление нового раздела не должно затрагивать половину системы.

  • Разделение на понятные модули
  • Запас по нагрузке без переусложнения
  • Возможность заменить часть, не ломая целое

04

Модель данных

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

  • Сущности и связи между ними
  • История изменений там, где она нужна
  • Правила удаления и архивации

05

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

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

  • Проверка прав на стороне сервера
  • Журнал действий пользователей
  • Минимум хранимых персональных данных

06

API

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

  • Заранее описанный контракт
  • Понятные коды ошибок
  • Документация в актуальном состоянии

07

Платежи

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

  • Разовые платежи и счета
  • Обработка неуспешной оплаты
  • Доступ, привязанный к статусу оплаты

08

Аналитика и эксплуатация

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

  • Метрики использования по разделам
  • Сбор ошибок и оповещения
  • Резервные копии и восстановление

Этапы

Понятный маршрут проекта

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

  1. Этап 01

    Discovery

    Описанные роли, сценарии и границы первой версии

  2. Этап 02

    Архитектура и прототип

    Схема системы, модель данных и кликабельный прототип

  3. Этап 03

    Разработка MVP

    Рабочая первая версия в тестовом окружении

  4. Этап 04

    Релиз и план развития

    Сервис в эксплуатации и согласованный бэклог доработок

Из чего складывается
стоимость

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

Получить оценку

На стоимость влияет

  • Количество ролей и сценариев
  • Сложность бизнес-логики и правил
  • Число интеграций с внешними системами
  • Требования к нагрузке и доступности
  • Объём и чувствительность данных
  • Наличие платёжных сценариев

Вопросы

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

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

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

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

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

Вам. Репозиторий передаём вместе с документацией и доступами. Никакой привязки к нам как к подрядчику в коде нет — дальнейшее развитие можно вести своей командой.

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

Смотрите также

Связанные услуги

Разработка веб-сервисов

Обсудим задачу?
Ответим с оценкой.

Услуга подставится в заявку автоматически — выбирать её заново не придётся.

Получить оценкуНаписать в Telegram