Техническое задание: как оценить интеграции, перенос данных и возврат

Короткий вывод: зачем оценивать интеграции, миграцию и возврат ещё на этапе ТЗ

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

Какие интеграции зафиксировать в ТЗ до начала разработки: API, вебхуки и SSO

Любая интеграция — это точка потенциального отказа. Если в ТЗ не описан хотя бы один из трёх элементов (протокол, формат данных, механизм аутентификации), подрядчик будет импровизировать, а вы — платить за переделку.

1. Протоколы и версии API. Укажите конкретную версию API, с которой работает интеграция. Например, REST API v2.1 с авторизацией через OAuth 2.0. Если сервис обновляется — пропишите, какая версия поддерживается и что происходит при deprecation старой версии. Без этого пункта обновление одного сервиса способно сломать всю цепочку за один деплой.

2. Вебхуки и события. Зафиксируйте список событий, которые вызывают срабатывание вебхуков: создание сделки, изменение статуса оплаты, обновление профиля. Для каждого события укажите формат payload (JSON или XML), формат timestamp (ISO 8601) и механизм retry при неудачной доставке. Рекомендуем прописать exponential backoff с максимальным количеством попыток — пять — и таймаутом между ними.

3. SSO и аутентификация. Если проект подключается к корпоративному SSO (SAML 2.0, OpenID Connect), в ТЗ должен быть описан flow авторизации, список передаваемых атрибутов и поведение при истечении сессии. Для каждого токена зафиксируйте срок жизни и процедуру обновления.

> По стандарту RFC 6749 (OAuth 2.0), refresh token должен иметь ограниченный срок жизни, и ТЗ должен содержать процедуру его обновления без участия пользователя.

4. Sandbox и тестовые стенды. В ТЗ пропишите требование к песочнице: доступ к тестовому окружению API, тестовые учётные записи и критерии успешного прохождения smoke-тестов перед промышленным развертыванием. На ormobil.com мы рекомендуем проводить полный цикл тестирования в sandbox не менее трёх дней до прода.

Проверить, не сломает ли обновление SaaS-сервиса текущие интеграции, можно по этой инструкции.

Что проверить в ТЗ при переносе данных между сервисами: форматы, потери и совместимость

Перенос данных — вторая по частоте причина перерасходов. Мы выделили четыре блока, которые обязательно должны быть в ТЗ.

1. Форматы и кодировки. Укажите формат на стороне источника (CSV, UTF-8, разделитель «;») и формат на стороне приёмника. Если форматы различаются — опишите правила маппинга полей. Например: поле «ФИО клиента» в 1С соответствует полям «first_name» + «last_name» в CRM. Отсутствие этого описания — гарантия ручной доработки после загрузки.

2. Объём и структура данных. Зафиксируйте количество записей (например, «до 500 000 контактов»), размер вложения (до 2 ГБ) и иерархию (родитель-дочерний элемент, many-to-one). Если данные содержат вложенные объекты — опишите глубину вложенности и правила сериализации.

3. Потери и дедупликация. Определите, что происходит с дублями: приоритет записи, правило слияния, логирование конфликтов. Пропишите допустимый процент потерь — например, «0% потерь для финансовых транзакций, до 0,5% для аналитических данных». Без этого критерия приёмка превращается в бесконечные споры.

4. Проверка целостности. В ТЗ должен быть описан механизм верификации: контрольные суммы (checksum), сверка количества записей до и после, логирование ошибок в отдельный файл. Конкретная метрика — совпадение count записей источника и приёмника на уровне 100% для критичных данных.

Как проверить потерю данных при переносе из мобильного приложения в CRM — читайте в отдельном разборе.

Таблица проверки: критерии оценки интеграций и миграции в техническом задании

Мы составили сводную таблицу, по которой можно проверить ТЗ перед согласованием. Каждый критерий — это вопрос, на который должен быть прямой ответ в документе.

Риски: что происходит, если не прописать возврат и откат в ТЗ

Отсутствие описания процедуры возврата — это не просто «некрасиво». Это прямая угроза бюджету и срокам.

1. Потеря данных без возможности восстановления. Если миграция выполняется без транзакционности и снапшотов, откатить частично загруженные данные невозможно. По данным нашего анализа, в 2025 году средняя стоимость восстановления после неудачной миграции составляет от 3 до 7 рабочих дней и 25–35% исходного бюджета проекта.

2. Неработающие интеграции после обновления. Когда в ТЗ не прописаны версии API и механизмы deprecation, обновление одного сервиса может сломать цепочку интеграций. Восстановление занимает от 2 до 5 дней, если подрядчик не документировал зависимости.

3. Штрафы за нарушение SLA. Если проект работает с финансовыми данными или персональными данными (152-ФЗ «О персональных данных»), отсутствие процедуры отката может привести к нарушению обязательств перед контрагентами и регуляторами.

4. Блокировка приёмки. Заказчик вправе не подписать акт, если в ТЗ не описана процедура возврата. Это закономерный исход: без механизма отката невозможно подтвердить, что система работает в штатном режиме.

Что такое техническое задание на интеграции?

Техническое задание на интеграции — это документ, который описывает протоколы, форматы данных, механизмы аутентификации и процедуры отката для связей между сервисами. Он фиксирует, как именно CRM, API и облачные системы обмениваются данными и что происходит при сбое.

Какой минимальный набор интеграций нужно описать в ТЗ?

Минимум три блока: протокол и версия API, формат и события вебхуков, механизм аутентификации (SSO или OAuth). Для каждого блока нужно указать формат данных, таймауты и процедуру retry.

Что будет, если не прописать возврат данных в ТЗ?

Если в ТЗ не описана процедура отката, при неудачной миграции данные могут быть утеряны без возможности восстановления. Средняя стоимость восстановления — от 25 до 35% исходного бюджета проекта и от 3 до 7 рабочих дней.