Требования к интеграции — это не техническое задание на сорок страниц. Это двенадцать пунктов, которые помещаются на две страницы и которые целиком можно перенести в приложение к договору. Отсутствие любого из них почти гарантированно превращается в спор о доплате: не потому, что подрядчик хочет обмануть, а потому, что работа реально не была описана и, значит, не была посчитана.
Интеграция кажется простой, пока обе системы работают. Заказ уходит с сайта, доезжает до учёта, статус возвращается обратно — на демонстрации это выглядит как пятнадцать минут работы. Сложность живёт в исключениях: вторая система не ответила, ответила дважды, ответила через час, вернула половину полей. Именно там рождаются задвоенные заказы и пропавшие заявки, и именно эти сценарии в заданиях описывают реже всего.
Ниже — двенадцать пунктов с формулировками, которые можно скопировать, разбор самого важного из них, шесть приёмочных сценариев, которые владелец проходит сам без программиста, и расчёт, во что обходятся три ненаписанные строки на проекте за 260 000 ₽.
Двенадцать пунктов и спор, который каждый закрывает
Каждая строка таблицы — это фраза, которую подрядчик произносит на третьей неделе, если пункта в задании не было. Все двенадцать фраз реальны в том смысле, что они логичны: работа действительно не описана, значит, действительно не оплачена.
| Пункт | Что должно быть написано | Спор, который он закрывает |
|---|---|---|
| 1. Состав данных | Перечень полей с типами и обязательностью: 40 полей заказа, 12 полей клиента, справочник из 9 статусов | «Мы не знали, что нужен ещё и комментарий менеджера» |
| 2. Направление обмена | По каждому набору: откуда, куда, в одну сторону или в обе | «Обратный поток статусов — это отдельные работы» |
| 3. Хозяин каждого поля | Таблица: кто вправе менять значение и что делает вторая система | «У вас перетёрлись цены, но мы сделали ровно как в задании» |
| 4. Частота и способ запуска | По событию или по расписанию, с интервалом: заказ — сразу, остатки — каждые 15 минут | «Обмен раз в сутки тоже удовлетворяет заданию» |
| 5. Поведение при отказе | Таймаут, число повторов, куда ложится неотправленное, кто получает оповещение | «Про недоступность учётной системы в задании не было ни слова» |
| 6. Защита от дублей | Ключ операции: по какому полю получатель понимает, что заказ уже принят | «Дубли — это нормальное следствие повторной отправки» |
| 7. Журнал обменов | Что пишется по каждой операции, срок хранения 90 дней, поиск по номеру заявки | «Чтобы найти вашу заявку, нужны работы по анализу» |
| 8. Мониторинг | Какие датчики, какие пороги, кому и в какой канал уходит сигнал | «Мы не обязаны следить за вашим обменом круглосуточно» |
| 9. Тестовый контур | Копия базы, обезличенные данные, доступ заказчика, право останавливать системы | «Проверять будем на боевой, иначе плюс две недели» |
| 10. Критерии приёмки | Список сценариев с ожидаемым результатом, которые заказчик проходит сам | «Работает же — что вам ещё нужно» |
| 11. Права на код и доступы | Исходники, схема данных, ключи и учётные записи на юрлицо заказчика | «Код наш, поддерживать может только наша команда» |
| 12. Поддержка после запуска | Что входит, время реакции, ставка сверх лимита, срок гарантии | «Гарантия закончилась вместе с подписанием акта» |
Шесть пунктов из двенадцати — с пятого по десятый — это ровно те строки, из-за которых одна и та же связка стоит то 68 000 ₽, то 398 000 ₽. Разницу смет мы разбирали в отдельном материале про надёжную интеграцию против «просто связать»; здесь важно другое: если этих строк нет в задании, дешёвая смета формально верна, и претензий к подрядчику не будет.
Отдельного внимания стоит четвёртый пункт, про частоту. Он выглядит безобидно, а определяет и цену, и архитектуру. «По событию» означает, что данные уезжают в момент действия и требуют очереди, подтверждения обработки и защиты от повторов. «По расписанию раз в 15 минут» проще и дешевле в разработке, но добавляет к каждой операции до четверти часа задержки: для склада в горячий сезон это критично, для бухгалтерии — не имеет значения вовсе. Решение принимается по процессу, а не по привычке разработчика, и фиксировать его надо до сметы: перевод обмена с расписания на события после запуска — отдельный проект, а не правка.
Хозяин поля: пункт, ради которого пишут таблицу
Система, которая имеет право менять значение. Все остальные системы это значение получают, показывают и не редактируют. Если хозяин не назначен, поле рано или поздно будет переписано обеими системами по очереди, и правым окажется тот, кто записал последним.
Формулировка «данные синхронизируются в обе стороны» — самая дорогая фраза в задании на интеграцию. Она означает, что при расхождении победит случайный порядок событий. Классическая авария выглядит так: менеджер поправил цену в CRM, обмен увёз её в учёт, ночной регламент учёта пересчитал цену по прайсу и увёз обратно, а утром сорок заказов ушли по старым ценам. Формально обмен отработал безупречно в обе стороны.
Пункт пишется таблицей, а не текстом. Заполнить её обязан заказчик — подрядчик физически не может знать, кто в вашей компании прав по цене. На 40 полей заказа таблица занимает страницу и час обсуждения на трёх человек. Ниже — фрагмент, по которому видно формат.
| Поле | Хозяин | Что делает вторая система | При расхождении |
|---|---|---|---|
| Номер заказа | Сайт | Учёт хранит как есть, свой внутренний номер держит отдельно | Не перезаписывается никогда |
| Состав и количество | Сайт до подтверждения, учёт после | После подтверждения сайт только показывает | Побеждает учёт, изменение видно в журнале |
| Цена и скидка | 1С:УТ | Сайт получает готовую сумму и не пересчитывает | Побеждает учёт, заказ помечается «цена изменена» |
| Остаток на складе | 1С:УТ | Сайт показывает с задержкой до 15 минут | Побеждает учёт |
| Статус заказа | 1С:УТ | CRM показывает, менеджер не редактирует | Побеждает учёт |
| Телефон и имя клиента | CRM | Учёт принимает как есть, не нормализует | Побеждает CRM |
| Комментарий менеджера | CRM | В учёт не передаётся вовсе | Расхождения не возникает |
Карта связей трёх узлов: «Сайт», «CRM», «1С:УТ». Стрелки подписаны содержимым потока: сайт → CRM «заказ, 40 полей, событийно»; CRM → 1С «клиент: телефон, имя»; 1С → сайт «остаток, каждые 15 минут» и «цена, скидка»; 1С → CRM «статус заказа». Рядом с каждым узлом рамка со списком полей, хозяином которых он является: у сайта — номер заказа; у CRM — телефон, имя, комментарий менеджера; у 1С — цена, остаток, статус. Внизу подпись: «Комментарий менеджера в учёт не едет вовсе». Чертёжный стиль, всё по-русски.
Побочная польза от таблицы: пока её заполняют, выясняется, что часть полей не нужна ни одной системе, а часть дублируется в трёх местах с разными названиями. Обычно после этого разговора состав обмена сокращается на четверть, а вместе с ним и смета. Сопоставление справочников и нормализация — отдельная работа, и её объём виден только из такой таблицы.
Что писать про сбои: три числа вместо слова «надёжно»
«Система должна работать надёжно и стабильно» — фраза, по которой невозможно принять работу и невозможно предъявить претензию. Заменяется тремя числами и одним именем.
- Допустимая задержка доставки. Сколько времени может пройти между событием и его появлением во второй системе. Для заказа обычно 15 минут, для остатков — те же 15, для документа отгрузки — час. Число берётся из процесса: через сколько минут задержка начинает мешать человеку работать.
- Порог молчания обмена. Сколько времени обмен может не проводить ни одной операции, прежде чем это считается сбоем. Обычно 30 минут в рабочее время. Это порог для сигнала, а не для катастрофы: мониторинг обмена должен заметить остановку раньше, чем её заметит клиент.
- Время реакции и кто оповещается. «4 часа в рабочие дни» и конкретная должность внутри компании плюс канал подрядчика. Оповещение «на общую почту» равно отсутствию оповещения.
«Допустимая задержка доставки заказа из системы А в систему Б — 15 минут. Отсутствие успешно обработанных операций дольше 30 минут в рабочее время считается сбоем и влечёт оповещение ответственного со стороны заказчика и дежурного инженера подрядчика. Время реакции подрядчика — 4 часа в рабочие дни. Операции, не доставленные во время сбоя, доставляются автоматически после восстановления без ручного повторного ввода».
Последнее предложение в этой формулировке — самое дорогое и самое важное. Оно означает, что в проекте есть очередь и повторные попытки, а не просто отправка «в надежде, что дойдёт». Как устроена лестница повторов и почему бесконечный повтор опаснее честного отказа, мы разбирали в статье про очередь и повторные попытки.
Схема из шести блоков со стрелками: «Событие» → «Отправка» → развилка. Ветка «Ответ получен» ведёт в блок «Готово». Ветка «Таймаут или отказ» ведёт в «Очередь», из неё стрелка «Повтор с нарастающей паузой» обратно в «Отправку», рядом подпись «до 6 попыток». Из «Очереди» вторая стрелка в «Карантин» с подписью «после исчерпания попыток». Из «Карантина» стрелка в «Оповещение ответственному, реакция 4 часа». Сверху над схемой полоса с тремя числами: «задержка 15 минут», «молчание 30 минут», «реакция 4 часа». Чертёжный стиль, подписи по-русски.
Критерии приёмки, которые заказчик проверит сам
Приёмка интеграции проваливается, когда её проводит тот же человек, который писал код. Правильный критерий — сценарий, который владелец или руководитель отдела проходит своими руками, без программиста и без объяснений «ну тут нужно понимать». Шесть сценариев ниже закрывают и обычную работу, и три аварийных случая.
- 1Сквозной заказ
Оформите заказ на сайте как обычный покупатель. Найдите его в CRM и в учёте. Норматив — 15 минут. Если заказ находится, но часть полей пустая, это не приёмка, а половина приёмки.
- 2Двойное нажатие
Отправьте один и тот же заказ дважды подряд — так делает каждый третий покупатель на медленном интернете. В учёте должен появиться один документ. Если появилось два, в проекте нет ключа операции, и задвоенные заказы будут копиться постоянно.
- 3Отключённый получатель
Попросите остановить учётную систему на тестовом контуре на 20 минут и оформите за это время три заказа. После включения все три должны доехать сами. Если подрядчик отказывается проводить этот сценарий, аварийного поведения в проекте нет.
- 4Кривые данные
Проведите заказ без телефона и заказ с товаром, которого нет в справочнике. Оба должны уйти в карантин, ответственный — получить письмо, а обмен — продолжить работу с остальными заказами. Остановка всей очереди из-за одной плохой записи — брак.
- 5Поиск по номеру
Возьмите номер вчерашней заявки и найдите её путь в журнале обменов: когда ушла, когда принята, какой ответ пришёл. Норматив — 10 секунд и без обращения к подрядчику.
- 6Суточная сверка
Сравните число заказов на сайте и в учёте за вчерашний день. Числа совпадают или расхождение объяснено конкретными записями в карантине. Эта проверка потом становится ежедневной и делается автоматически.
Эти шесть сценариев переносятся в приложение к договору как есть, с ожидаемым результатом по каждому. Такое приложение занимает страницу и заменяет спор «работает или не работает» на проверяемый факт. Общая логика поэтапной приёмки, включая формулировки для актов, разобрана в материале про приёмку этапа проекта.
Права на код и доступы: формулировка против заложничества
Самая неприятная ситуация в интеграционных проектах — не сбой, а невозможность позвать другого подрядчика. Она возникает тихо: ключи к API созданы на почту разработчика, код лежит в его репозитории, схема обмена существует только у него в голове. Формально всё оплачено, фактически систему нельзя передать.
- «Исключительные права на созданный код, настройки и схему обмена переходят к заказчику с момента подписания акта по соответствующему этапу».
- «Исходный код, схема данных и инструкция по развёртыванию размещаются в репозитории заказчика. Передача — условие приёмки этапа, а не отдельная работа».
- «Все учётные записи, ключи доступа и токены создаются на юридическое лицо заказчика. Подрядчик получает доступ, а не владение».
- «При расторжении договора подрядчик передаёт актуальную версию кода, журнал изменений и список действующих доступов в течение 5 рабочих дней».
Если токен доступа к маркетплейсу, банку или телефонии выпущен на учётную запись подрядчика, то при любом расставании вы теряете обмен в тот же день, а при утечке отвечаете вы как оператор данных. Правило простое: ключи выпускает заказчик и выдаёт подрядчику, а не наоборот. Как это оформляется по шагам, разобрано в материале про доступы подрядчику при внедрении.
Три формулировки, которые чаще всего приводят к доплате
Если времени на все двенадцать пунктов нет, начните с замены трёх фраз. По опыту разбора чужих заданий именно они дают больше половины всех споров о деньгах.
| Как написано обычно | Чем заменить | Что это закрывает |
|---|---|---|
| «Интеграция сайта с 1С» | «Односторонняя передача заказа с сайта в 1С:УТ 11.5: 40 полей, событийно, с подтверждением обработки и повтором при отказе. Обратная передача статуса — отдельный пункт» | Спор о том, входил ли обратный поток статусов в цену |
| «Система должна работать стабильно» | «Допустимая задержка 15 минут, молчание обмена дольше 30 минут — сбой с оповещением ответственного, время реакции 4 часа в рабочие дни» | Спор о том, считается ли двухчасовое молчание сбоем |
| «Тестирование и отладка» | «Приёмка по 6 сценариям из приложения №2, три из них — аварийные. Сценарии проходит заказчик на тестовом контуре, а не подрядчик на боевой базе» | Спор о том, кто и на чём проверяет результат |
Сравнение в две колонки. Левая, серая, озаглавлена «Как написано обычно»: три карточки — «Интеграция сайта с 1С», «Система должна работать стабильно», «Тестирование и отладка». Правая, акцентная, озаглавлена «Проверяемая формулировка»: три карточки с числами — «40 полей, событийно, повтор при отказе», «задержка 15 минут, молчание 30 минут, реакция 4 часа», «6 сценариев приёмки, 3 аварийных». Под колонками подпись: «Разница между колонками — 147 000 ₽ доплаты на проекте за 260 000 ₽». Чертёжный стиль, всё по-русски.
Цена трёх ненаписанных пунктов
Модельный проект: интернет-магазин, связка «сайт — CRM — 1С:УТ», двусторонний обмен, 40 полей заказа, поток около 600 заявок в месяц. Смета подрядчика — 260 000 ₽, срок 4 недели. В задании описаны состав данных, направление и частота; отсутствуют хозяин поля, поведение при отказе и тестовый контур. Все три пункта всплывают между третьей и шестой неделей.
Ключевая мысль расчёта не в том, что подрядчик дорого берёт. Все три работы нужны, и все три стоят примерно столько же, если заложить их сразу. Разница в другом: заранее это плановые 132 000 ₽ в смете и решение владельца, а постфактум — внезапные 147 000 ₽, две недели срока и разговор на повышенных тонах в разгар проекта. Плюс 15 000 ₽ времени владельца, которого в плановом варианте нет вовсе.
Столбчатая диаграмма из двух столбцов в рублях. Левый — «Смета по заданию: 260 000 ₽», сплошной. Правый — «Фактически заплачено: 407 000 ₽», где нижняя часть 260 000 ₽ сплошная, а верхняя 147 000 ₽ разбита штриховкой на четыре сегмента с подписями: «хозяин поля 42 000 ₽», «поведение при отказе 46 000 ₽», «тестовый контур 44 000 ₽», «время владельца 15 000 ₽». Справа вертикальная подпись «+57 %». Ось — рубли, единицы подписаны.
Когда двенадцать пунктов писать не надо
Полный набор требований оправдан не всегда. Есть четыре случая, когда двухстраничное приложение к договору стоит дороже пользы от него, и честнее сказать об этом прямо.
- 1Разовая выгрузка. Перенести справочник товаров один раз при переезде — это не интеграция, а операция. Здесь нужны только состав данных и критерий «сошлись ли итоги».
- 2Пилот на 4–8 недель, который заведомо выбрасывается. Если по итогам проверки связка будет переписана целиком, платить за очередь, журнал и тестовый контур не нужно. Важно только письменно зафиксировать, что это пилот и что срок его жизни ограничен.
- 3Процесс, который изменится в ближайший квартал. Пока меняется сам процесс, требования к обмену устаревают быстрее, чем их согласуют. Сначала карта процесса, потом задание.
- 4Меньше сотни операций в месяц. При таком объёме выгрузка в таблицу и ручной перенос обходятся дешевле и надёжнее любого автоматического обмена: одна операция стоит минуты работы, а обмен — сотен тысяч рублей разово.
Но даже в этих четырёх случаях четыре пункта из двенадцати остаются обязательными: состав данных, хозяин поля, критерии приёмки и права на код с доступами. Первые три защищают от бессмысленной работы, четвёртый — от ситуации, когда пилот неожиданно оказался в эксплуатации, а исходников у вас нет. Такое случается чаще, чем планируется.
