Составьте карту интеграций сайта

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

Если обмен пока не нужен, зафиксируйте это вместе с основанием. Не добавляйте интеграцию только потому, что она есть у другого сайта. Определение и базовые вопросы собраны в термине «Интеграция»; здесь вы заполните документ для своего проекта.

Шаг 1. Нарисуйте направления обмена

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

Учебный пример ниже вымышленный. Он не описывает инфраструктуру клиента или обязательный состав сайта.

Форма сайта → CRM → работа с обращением
Каталог учётной системы → каталог сайта
Сервис подписок → статус подписки на сайте

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

Шаг 2. Заполните карточку каждой стрелки

Используйте роли, например «ответственный за CRM» или «редактор каталога». Имена и контакты при необходимости держите в закрытом рабочем документе. Секреты, пароли и ключи доступа в карту не включайте.

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

Шаг 3. Разберите один поток до результата

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

Разделите состояния: посетитель нажал кнопку, сайт проверил данные, получатель подтвердил приём, запись появилась в нужном разделе, обращение поступило в обработку. Выберите, какое состояние подтверждает интерфейс сайта, а какие наблюдаются отдельно. Клик сам по себе не подтверждает доставку.

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

Шаг 4. Опишите три сбоя

Для каждой важной интеграции рассмотрите хотя бы три ситуации и заполните последнюю колонку своими решениями.

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

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

Шаг 5. Назначьте решения и зависимости

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

Для каждого неизвестного назначьте действие: получить документацию, уточнить поля, согласовать права, подготовить тестовую запись или проверить ограничение. Перенесите зависимости в реестр ограничений проекта. Стоимость и срок оценивайте после уточнения состава; название системы не заменяет объём работ.

Самопроверка

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

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

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

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