Зависимости проекта: как согласовать доступы, API и материалы до старта разработки

Редакция Romanov Lab · Опубликовано 13 октября 2026

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

Карта зависимостей показывает, что именно должно произойти до конкретного шага, кто это обеспечивает и как команда проверит готовность. Она отличается от общего списка задач: «получить доступ» ещё не объясняет, какую работу доступ разблокирует и что будет, если его не окажется вовремя.

Ищите зависимости от пользовательского результата назад

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

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

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

Разделите зависимости по характеру

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

• Доступы: тестовая среда, репозиторий, CMS, хостинг, нужные роли и сетевые ограничения.
• Данные: структура каталога, идентификаторы, изображения, подтверждённые тексты, учебные примеры.
• Системы: документация API, тестовый контур, поддерживаемые операции, ограничения и контакт технического владельца.
• Решения: правила обработки обращений, состав услуги, допустимый обходной процесс, критерии готовности.

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

Создайте карточку зависимости с проверяемым результатом

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

Например: «Для проверки передачи заявки нужен тестовый пользователь принимающей системы с правом создать обращение. Владелец — администратор системы. Готовность — команда создала учебную запись, увидела её в нужной очереди и смогла удалить по согласованным правилам». Это значительно конкретнее, чем «логин передан».

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

Проверьте доступ безопасным минимальным действием

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

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

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

Для API проверьте не наличие документации, а нужную операцию

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

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

• Есть ли тестовая среда или безопасный согласованный способ проверки?
• Доступна ли нужная операция в используемом продукте и тарифе?
• Какие поля обязательны и где взять их значения?
• Как связать одну запись между системами?
• Что происходит при повторном запросе и недоступности сервиса?
• Какие ограничения частоты, объёма или формата нужно учесть по документации поставщика?
• Кто отвечает на технические вопросы и сообщает об изменениях?

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

Отличайте обязательный блокер от работы, которую можно вести параллельно

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

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

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

Назначьте владельца разблокировки и путь эскалации

У блокера должен быть человек, который добивается результата, даже если выполняет действие другая сторона. Он уточняет запрос, проверяет ответ и сообщает о последствиях. «Ждём поставщика» — состояние, но не план действий.

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

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

Условный пример цепочки каталога

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

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

В этом условном примере проблема находится не в скорости программирования. Карта зависимостей позволяет увидеть последовательность и не подменять неизвестное случайными данными. Решение о сокращённом запуске принимает уполномоченный заказчик после объяснения последствий.

Размыкайте круговые ожидания через образец

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

Такой образец должен быть достаточно реалистичным, чтобы выявить ограничения. Абстрактный текст-заглушка лишь откладывает проблему. Назначьте владельца первого шага и зафиксируйте, какие предположения образец проверяет: объём, состав полей, длину названий или необходимость обязательной оговорки.

Проведите проверку готовности перед стартом зависимой работы

1. Критические зависимости названы и связаны с конкретными задачами.
2. У каждого результата есть владелец и проверяемый критерий.
3. Доступы проверены разрешённым действием.
4. Ключевые возможности внешних систем подтверждены.
5. Материалы пригодны для согласованного этапа.
6. Временные предположения помечены и имеют план проверки.
7. Для открытых блокеров выбран вариант продолжения или ожидания.

Руководство GOV.UK по конфигурации отдельно напоминает, что приложение зависит от окружающей среды и настроек. Поэтому карту стоит сохранять и после старта: она постепенно становится опорой для интеграционного тестирования и передачи проекта. Готовность — это подтверждённая возможность выполнить следующий шаг, а не количество отправленных запросов.