Разработка сложных веб-сервисов и отраслевых платформ

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

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

Что делает веб-сервис сложным

Сложность почти никогда не в количестве экранов. Она в четырех вещах.

Что происходит с состояниями

Что мы делаем

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

Что мы делали и делаем

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

Нагрузка и надежность

Вопрос «выдержит ли» задают в самом начале, и отвечать на него надо честно: до реальных данных это оценка, а не факт.

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

Где здесь искусственный интеллект

В сложных сервисах модели работают на стыках, где раньше сидел человек.

• Разбор входящего. Заявки и документы приходят текстом, файлами, сканами. Модель приводит их к структуре и заполняет карточку, а человек проверяет.
• Подбор и сопоставление. Кому показать заявку, какие позиции считать одинаковыми, какой исполнитель ближе по профилю. На объеме это решается лучше, чем фильтрами.
• Модерация и спорные ситуации. Предварительная фильтрация нарушений и подсветка проблемных случаев для человека. Решение остается за человеком, но разбирать он будет десятки случаев, а не тысячи.
• Поддержка пользователей. Ответы по правилам сервиса и помощь при заполнении. В многосторонних сервисах львиная доля обращений — это «как у вас тут устроено».
• Аналитика словами. Вопрос к данным без построения отчета — особенно полезно, когда разрезов много и заранее все не предусмотреть.

Сроки и стоимость

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

Публичная часть и рабочая часть

У многих таких сервисов две половины, и их проектируют по разным правилам.

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

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

Ошибка — делать обе половины по одному шаблону. Публичная часть, спроектированная как рабочая, выглядит казенно и не продает. Рабочая часть, спроектированная как публичная, красива и неудобна.

Как мы оцениваем такие проекты

1. Считаем стороны и роли. Каждая новая сторона — это не «плюс несколько экранов», а отдельный набор сценариев, прав и уведомлений.
2. Считаем состояния и переходы. Число переходов между состояниями предсказывает объем работы лучше, чем число экранов.
3. Считаем правила и расчеты. Формулы, коэффициенты, исключения. Каждое правило требует проверки и тестов, иначе оно сломается при первом же нестандартном случае.
4. Считаем внешние стыки. Каждая интеграция — это не только подключение, но и обработка того, что она отвалилась, ответила медленно или вернула ерунду.
5. Считаем модерацию и поддержку. Инструменты для разбора спорных ситуаций — полноценная часть системы, а не «админка, которую сделаем в конце».

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

• Оценивают по счастливому пути. «Заявка, отклик, сделка» — это пять экранов. Отмены, споры, возвраты, сроки и повторы — это еще столько же работы, и о них вспоминают на третьем месяце.
• Запускают все стороны сразу. В сервисах с двумя сторонами одна всегда должна прийти первой. Запуск обеих одновременно обычно заканчивается пустой площадкой.
• Откладывают права. «Потом настроим» не работает: в многосторонних сервисах права определяют логику, а не наоборот.
• Копируют чужой интерфейс. Похожий сервис в другой отрасли решает другую задачу. Заимствуется форма, а вместе с ней приезжают чужие ограничения.
• Не думают про модерацию. Любой сервис с внешними пользователями получает мусор, спам и злоупотребления. Инструменты для этого нужны с первого дня, а не после первого инцидента.

Отрасли, где это чаще всего нужно

• Логистика и перевозки. Заявки, перевозчики, ставки, статусы в пути, документы. Много сторон, много состояний и обязательные стыки с внешними системами.
• Строительство и подряд. Тендеры на работы, подрядчики, этапы, акты, претензии. Правила отбора и расчеты здесь всегда свои.
• Сельское хозяйство и переработка. Партии, качество, лаборатория, приемка, расчет по фактическим показателям. Цена зависит от параметров, а не от прайса.
• Энергетика и ЖКХ. Приборы учета, показания, начисления по нормативам и тарифам, работа с потребителями и подрядчиками.
• Медицина и лаборатории. Направления, исследования, результаты, доступ для пациента и для врача. Требования к данным жесткие, и это влияет на архитектуру.
• Профессиональные сообщества и отраслевые ассоциации. Реестры участников, проверки, взносы, публичная часть и закрытая для членов.

Что остается у вас

Код в вашем репозитории, доступы к серверам на ваши учетные записи, схема состояний и модель данных как документ, инструкции по развертыванию. Стек распространенный: PHP или Python, PostgreSQL или MySQL, обычный современный фронтенд — поддержит любой грамотный разработчик.

Размещение — на вашей инфраструктуре или на российском хостинге. Если в сервисе есть персональные данные, обработка по 152-ФЗ закладывается при проектировании: в публичных сервисах это особенно важно, потому что данные вносят сами пользователи.

Дальше по теме