Как агентству передать разработку на субподряд: бриф и приемка
Передавать разработку на субподряд удобнее с согласованным результатом этапа, ответственными и правилами изменений. Агентство отвечает за обещания клиенту, производственный партнер — за принятый объем реализации. Граница между ними должна быть понятна обеим командам до начала работы.
Для SEO-агентства, дизайн-студии или интегратора такой процесс особенно полезен, когда клиенту нужна разработка за пределами собственной команды. Неопределенные требования, разрозненные комментарии и поздняя выдача доступов затрудняют передачу даже простого проекта.
Ниже — пакет для передачи сайта или интеграции, таблица ролей и порядок приемки. Это проектные рекомендации; коммерческие условия и обязательства стороны согласуют для конкретного сотрудничества.
Выберите модель сотрудничества до оценки проекта
Сначала решите, кто продает работу, кто управляет клиентской коммуникацией и кто принимает результат. Слова «партнерство» и «аутсорс» могут обозначать разные отношения.
| Модель | Что передает агентство | Что нужно согласовать |
|---|---|---|
| Рекомендация исполнителя | Контакт и контекст задачи | Фиксация знакомства, дальнейшая коммуникация и вознаграждение |
| White label | Разработку под своим брендом | Представление команды, каналы общения, согласование ответов клиенту |
| Субподряд на этап | Ограниченный результат внутри проекта | Входные материалы, зависимости и приемка этапа |
| Усиление команды | Набор задач или загрузку специалиста | Кто ставит задачи, проверяет решения и планирует работу |
У NBM-IT эти варианты представлены на странице партнерства с агентствами и веб-студиями. Размер вознаграждения, сроки и другие условия стоит сверять там и фиксировать в договоренностях по проекту. Процесс передачи нужен для каждой выбранной модели, но глубина участия агентства будет различаться.
При white label согласуйте, может ли разработчик участвовать в технических встречах и от чьего имени. Для этапного субподряда определите, кто объединяет результаты разных исполнителей. Если одна команда делает интерфейс, другая — API, кто-то должен отвечать за проверку общего сценария.
Проверьте готовность запроса к передаче
Перед оценкой партнеру нужен контекст: какую задачу решает клиент, что уже согласовано, какие материалы готовы и что пока неизвестно. Полезно разделять подтвержденное требование и пожелание, которое только обсуждается.
Например, клиенту нужен каталог услуг с заявкой. Дизайн утвержден, тексты еще готовятся, CRM выбрана, но права доступа не выданы. Передайте именно эти статусы. Если написать «все готово», партнер построит план на предположениях, которые вскроются после старта.
Для предварительной оценки можно передать неполные сведения, обозначив ограничения. Для обещания даты запуска потребуются проверенные зависимости: содержание, доступы, согласование, внешние системы. Дата становится обоснованной, когда команда понимает, что и от кого ей нужно получить.
Если запрос пришел из холодной коммуникации, сначала уточните задачу и полномочия собеседника. Материал про outreach и привлечение запросов относится к этому предыдущему этапу. Передавать в производство стоит уже квалифицированную задачу с понятным следующим действием.
Пакет, который агентство передает разработчикам
Соберите материалы в одном месте и укажите версию согласованного объема. Ссылки на переписку полезны как история, но текущие требования должны быть доступны без чтения всех сообщений.
| Материал | Что в нем должно быть | Кто подтверждает |
|---|---|---|
| Бриф | Задача бизнеса, пользователи, главный сценарий и ограничения | Агентство и представитель клиента |
| Объем этапа | Страницы, функции, исключения и результат передачи | Агентство и производственный партнер |
| Макеты | Утвержденные экраны, мобильные варианты, состояния элементов | Ответственный за дизайн |
| Контент | Материалы, статус готовности, правила размещения | Владелец контента |
| Интеграции | Системы, поля, события, тестовые сценарии | Технические представители сторон |
| Карта доступов | Какие системы нужны, какие права и как выдаются | Владелец инфраструктуры |
| План приемки | Кто проверяет, где фиксирует замечания и что считает выполненным | Агентство и исполнитель |
| Правила изменений | Кто согласует влияние на объем, сроки и стоимость | Уполномоченные представители |
Для редизайна приложите адреса существующих страниц, условия переноса материалов и ограничения рабочего сайта. Для разработки по готовым макетам проверьте, есть ли ошибки форм, пустые состояния, длинный текст и мобильная навигация. Отсутствующие состояния нужно либо подготовить, либо поручить исполнителю с отдельным согласованием.
В интеграционном проекте приложите пример данных и ожидаемый результат. Например: обращение с конкретной формы создает объект в нужной воронке с согласованными полями. Такой сценарий позволяет оценить и принять работу. Формулировка «подключить CRM как у клиента» потребует дополнительного обследования.
Распределите роли на спорных границах
Назначьте по одному ответственному за решения со стороны агентства и исполнителя. Участников может быть много, но противоречивые комментарии должен объединять владелец согласования.
| Решение или действие | Агентство | Производственный партнер | Клиент |
|---|---|---|---|
| Бизнес-требования | Собирает и уточняет | Проверяет реализуемость | Подтверждает задачу |
| Техническое решение | Проверяет соответствие обещанному результату | Предлагает и обосновывает | Подтверждает ограничения своих систем |
| Контент и согласование | Организует передачу | Размещает по принятому объему | Предоставляет или утверждает материалы |
| Изменение объема | Собирает запрос и согласует условия | Оценивает влияние | Принимает решение по результату |
| Проверка этапа | Принимает у исполнителя | Демонстрирует и исправляет дефекты | Проверяет согласованные бизнес-сценарии |
| Публикация | Координирует дату и уведомления | Выполняет технические операции по договоренности | Выдает разрешение и нужные доступы |
Эта таблица — пример распределения, а не обязательная модель. Если агентство само выполняет публикацию или клиент принимает этап напрямую, измените соответствующие строки. Пустая ответственность за интеграционный тест или запуск опаснее различий в названиях ролей.
Отдельно договоритесь о внешней коммуникации. Кто отвечает на технический вопрос клиента, кто сообщает о задержке и кто согласует новую задачу? Разработчик может пояснить решение, но новое обещание по срокам должно пройти через ответственного за проект.
Как оценить этап и сохранить управляемый объем
Запросите предложение с результатами, допущениями, исключениями и зависимостями. Зафиксируйте, какие работы считаются обязательными, какие можно отложить, какие оцениваются после обследования. Для сравнения предложений используйте таблицу проверки смет на разработку сайта.
Не обещайте клиенту окончательную цену неизвестной интеграции до доступа к ее документации и настройкам. Можно выделить обследование: партнер проверяет интерфейс обмена, ограничения и тестовый сценарий, затем уточняет объем реализации. Результат обследования тоже должен быть конкретным документом или демонстрацией.
Для каждой новой просьбы фиксируйте:
- Что изменяется относительно согласованного результата.
- Какие части уже сделанной работы затрагиваются.
- Какое влияние ожидается на срок и оценку.
- Кто подтверждает изменение и когда оно включается в план.
Разделяйте дефект и расширение функции по критериям этапа. Если согласованная форма не передает данные, это повод исправить выполнение. Если появилась новая воронка или другой сценарий, сначала уточните объем. Спор лучше решать по зафиксированному поведению, а не по формулировке «быстрая доработка».
Доступы, исходники и публикация
Определите, где находятся репозиторий, тестовая среда, домен и рабочая инфраструктура. У каждого ресурса должен быть владелец, который может продолжить проект после смены исполнителя. Используйте отдельные учетные записи и права под задачи вместо передачи общего административного доступа.
Например, GitHub позволяет выдавать разные роли в репозитории организации. Защита веток может требовать согласование изменений и успешные проверки; доступность функций зависит от продукта и настроек. Выберите правила для вашего проекта и определите, кто может выпускать изменения в рабочую среду.
Секреты подключения передавайте через согласованный защищенный канал, отдельно от общего брифа. В документации нужны назначения доступов и способ их выдачи, а не открытые пароли. После завершения этапа проверьте, какие права остаются для поддержки и какие следует отозвать.
План публикации включает предварительную проверку, резервную копию нужных данных, ответственного за переключение и способ возврата к предыдущему состоянию. Зафиксируйте, что будет проверяться на рабочем домене: страницы, формы, файлы, интеграции и адреса перенесенного сайта.
Принимайте работу сначала внутри агентства
Перед клиентской демонстрацией пройдите сценарии самостоятельно вместе с исполнителем. Так можно отделить недоработку от изменения пожеланий и показать клиенту целостный этап.
Исполнитель передает ссылку на тестовую версию, перечень выполненных задач, известные ограничения и способ воспроизвести проверку. Замечание в общей системе должно содержать страницу, действие, ожидаемый и фактический результат. Для визуального дефекта приложите снимок экрана и параметры устройства.
Условный пример приемки формы: заполнить ее на мобильном устройстве, увидеть подтверждение, найти обращение в CRM и проверить источник. Если успешно прошла только отправка из браузера, весь бизнес-сценарий еще не принят. Подробные проверки такого этапа собраны в статье об интеграции сайта с CRM.
После исправлений повторите именно затронутые сценарии и связанные участки. Критерии готовности этапа должны быть известны заранее: допустимые ограничения, блокирующие дефекты, состав передачи и ответственный за окончательное решение.
Как проверить партнера на первом проекте
Для начала выберите ограниченный самостоятельный этап с понятной приемкой. Пилот должен показать процесс: уточнение требований, оценку, демонстрацию, работу с замечаниями и передачу результата. Слишком размытая задача проверит терпение участников, но даст мало сведений о качестве производства.
Оцените после завершения:
- Какие риски партнер назвал до старта и как они были обработаны.
- Насколько прозрачно менялись объем и план.
- Можно ли воспроизвести проверку результата по переданным материалам.
- Удобно ли агентству продолжить работу с исходниками и доступами.
- Как решались замечания и кто сообщал о препятствиях.
Отзывы и портфолио помогают предварительному выбору. Для обсуждения процесса подойдет чек-лист выбора подрядчика на разработку. По итогам пилота закрепите работающие правила в шаблоне передачи для следующих проектов.
FAQ
Обязательно ли скрывать производственного партнера от клиента?
Это зависит от выбранной модели. В white label заранее согласуйте представление команды и коммуникацию. В открытом субподряде технический партнер может участвовать напрямую. В любом случае клиент должен понимать, через кого принимаются решения и согласуются изменения.
Можно ли передать только часть разработки?
Да, если у этапа есть входные материалы, самостоятельный результат и ответственное лицо за объединение с остальным проектом. Для интерфейса и API заранее согласуйте контракт обмена и совместный тест. Иначе обе части могут быть готовы отдельно, но не работать вместе.
Что делать, если клиент пишет разработчику напрямую?
Сохраните техническую коммуникацию, если она разрешена правилами проекта. Запросы, влияющие на объем и сроки, фиксируйте в общей системе и передавайте ответственному за согласование. Решение не должно теряться в личной переписке.
Кто должен хранить исходники и управлять доменом?
Определите владельцев до начала работы и обеспечьте доступ уполномоченным представителям. Для передачи проекта нужны исходники, инструкции и возможность управлять инфраструктурой. Права и коммерческие условия фиксируются сторонами отдельно.
Источники
- NBM-IT: модели партнерства с агентствами.
- GitHub Docs: роли доступа к репозиторию организации.
- GitHub Docs: защита веток.
Источники проверены 2 октября 2026 года. Пакет передачи, таблица ролей и порядок пилота — рекомендации для организации работы; они не описывают результаты конкретного проекта NBM-IT.