Интерфейсы (контракты)
Interface Contracts
01.3 Interface Contracts
Большинство разрывов в реальных системах находятся не внутри процессов, а на их стыках — там, где один элемент передаёт управление или данные другому, и это "между" никому явно не принадлежит. Контракт интерфейса — инструмент STAF для работы именно с этим "между".
Что такое интерфейс в системе
Интерфейс — это точка, где один элемент системы передаёт что-либо другому:
данные, управление, результат, ответственность. Каждая связь типа output → input
между двумя преобразованиями является интерфейсом.
Интерфейсы особенно уязвимы по трём причинам:
Ответственность размыта. Первый актор "уже закончил", второй "ещё не начал". Если что-то теряется или искажается при передаче — непонятно, чья зона.
Формат не согласован. Первый элемент передаёт то, что производит; второй ожидает то, что ему нужно. Если эти два описания не совпадают явно — несовпадение обнаруживается поздно и дорого.
Задержка невидима. Между моментом, когда один элемент произвёл выход, и моментом, когда другой начал его обрабатывать, может пройти часы, дни или недели. Эта задержка часто не фиксируется нигде — и оказывается причиной, которую не видит ни один из участников.
Контракт интерфейса: три обязательных элемента
Контракт интерфейса в STAF — это явное соглашение о трёх вещах.
1. Что передаётся (What)
Конкретное описание выхода первого элемента как входа второго. Важно, что описание должно быть сделано с точки зрения получателя, не отправителя: "заявка, готовая к рассмотрению экспертом" — это описание с точки зрения получателя; "заявка, прошедшая техническую проверку" — с точки зрения отправителя. Это не одно и то же, и несовпадение — источник разрыва.
2. Кто отвечает за передачу (Who)
Явное назначение ответственного за то, что передача произошла и что переданное соответствует контракту. Это не тот же самый ответственный, что за производство выхода или за обработку входа — хотя может совпадать. Важна явность: "передача является частью ответственности координатора проектов".
3. Когда и как (When & How)
Условие передачи: триггер (когда передача происходит), способ (как именно), и допустимые задержки. Пример: "сводный отчёт направляется донору в течение 5 рабочих дней после окончания квартала по электронной почте". Этот элемент превращает "мы передаём" в "мы передаём именно так и именно тогда".
Три диагностических разрыва на интерфейсах
STAF выделяет три характерных класса разрывов, которые возникают именно на интерфейсах, а не внутри отдельных элементов.
Разрыв несоответствия формата
Первый элемент производит выход в одном формате, второй ожидает другой. На практике это выглядит как: "мы отправляем Excel, они открывают в другой системе и данные теряются" или "мы передаём утверждённый список, но команда ожидает приоритизированный".
Характерный признак: задержки и ошибки возникают не внутри процессов, а между ними, и каждая сторона считает, что "всё сделала правильно".
Разрыв потери при передаче
Что-то производится, но не доходит до следующего шага или доходит в деградированном виде. Классический пример: данные собираются (запас существует), но не используются для принятия решений (связь "информирует" отсутствует). Данные "уходят к донору", но не влияют на планирование — это разрыв потери на интерфейсе между отчётностью и планированием.
Разрыв задержки на интерфейсе
Передача происходит, но с задержкой, которую не осознают ни отправитель, ни получатель. В системах с несколькими последовательными интерфейсами эти задержки накапливаются — и причиной финального опоздания оказываются не отдельные шаги, а сумма "потерянного времени" в промежутках.
Контракты и петли обратной связи
Контракты интерфейсов особенно важны там, где передача является частью петли обратной связи. Если результаты одного цикла должны информировать следующий, но контракт передачи не определён — петля де-факто разомкнута, даже если формально все шаги существуют.
Пример из практики: ежеквартальные отчёты собираются и направляются донору (шаги существуют), но нигде не определено, что содержание отчётов поступает на вход планирования следующего цикла (контракт отсутствует). Петля обратной связи "результаты → планирование" является разомкнутой не потому что кто-то принял такое решение, а потому что никто не определил контракт интерфейса в этой точке.
Контракты как предмет верификации
Контракты интерфейсов — отдельный предмет верификации с носителем системы, помимо самих элементов и связей. Вопросы для верификации:
- Совпадает ли то, что один участник считает "выходом", с тем, что другой считает "входом"?
- Кто конкретно несёт ответственность за то, что передача произошла?
- Случаются ли ситуации, когда "всё сделано", но следующий шаг не начался? Почему?
Расхождение в ответах двух участников одного интерфейса — это прямой индикатор разрыва, который методом анализа документов обнаружить невозможно.
Контракт интерфейса как инструмент снижения задержек
Один из наиболее частых результатов явного определения контрактов — обнаружение задержек, которые раньше не осознавались как задержки. Когда "когда и как" написано явно ("в течение 5 рабочих дней после события X"), это создаёт наблюдаемое ожидание. Без явного контракта та же самая задержка является "нормальным рабочим процессом".
Это не только диагностика — это инструмент дизайна. Переопределение контракта (например, заменить "ручная передача по запросу" на "автоматическая передача при наступлении условия") — вмешательство уровня 10 по шкале точек рычага (изменение задержки), без изменения самих элементов и их ответственных.
STAF 1.0 · SysMindLab · 2026