Кто отвечает за стык двух систем, если работают разные подрядчики

Подготовлено 23 октября 2026 года

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

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

Разберите стык без поиска виновного

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

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

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

Назовите владельца каждого решения

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

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

Согласуйте доступные свидетельства

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

Уточните смысл каждого подтверждения. Сообщение адаптера о начале отправки не подтверждает приём рабочей системой. Наличие записи у получателя ещё не объясняет, почему конкретный сотрудник её не видит. Участники должны понимать, какое звено проверяет представленный экран или запись.

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

Определите порядок совместной проверки

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

1. Владелец источника готовит обезличенный пример и подтверждает готовность исходного события.
2. Исполнитель адаптера показывает, что получил и что передал по согласованным правилам.
3. Владелец получателя проверяет приём и доступность результата в своей системе.
4. Ответственный за эксплуатацию помогает сопоставить события и установить незавершённые действия.
5. Принимающий специалист сверяет общий пользовательский результат с заданием.

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

Оформите неизвестную причину как вопрос

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

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

Если исход операции неизвестен, это также нужно сохранить. Повторная отправка не становится безопасной из-за того, что участники не нашли ответ. Сначала согласуйте, как установить исход и кто уполномочен продолжать. Изменения на чужом участке без его владельца в такой разбор не включаются автоматически.

Как использовать матрицу перед оценкой

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

Один пользовательский путь:
Источник и его ответственный:
Адаптер и граница его работы:
Получатель и его ответственный:
Кто утверждает состав данных и статусы:
Кто предоставляет допустимые доступы:
Кто готовит общий пример:
Чем подтверждается каждый переход:
Кто принимает конечный результат:
Кто разбирает незавершённые операции:
Пустые строки и ответственные за уточнение:

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