Что делать, если текущий подрядчик по разработке сайта не устраивает?

Что важно учесть перед принятием решения о смене подрядчика:

• Медленная работа сама по себе не всегда означает, что подрядчика нужно менять

• Сначала нужно сравнить фактический результат с договорённостями и приоритетами

• Новой команде нужен вход в проект, а не только список срочных задач

• Две команды не должны одновременно менять один код и один рабочий контур

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

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

Сначала нужно отделить реальную проблему от общего недовольства

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

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

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

Когда смена подрядчика действительно оправдана

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

Насторожиться стоит, когда подрядчик:

• регулярно срывает договорённости без объяснения причин и нового плана

• не может показать, что сделано, что осталось и какие риски есть у проекта

• выпускает изменения, после которых повторяются ошибки в связанных функциях

• отказывается передавать или фиксировать доступы, код и значимые материалы

• не разделяет исправление недостатка и новую доработку

• предлагает принимать важные решения без описания последствий для сайта

• сохраняет знания о проекте только в личной переписке или памяти одного специалиста

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

Как оценить текущее состояние проекта до передачи

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

Для первичной оценки обычно проверяют:

• состав выполненных и незавершённых работ

• актуальные требования, макеты и историю согласованных изменений

• состояние кода и способ его хранения

• домен, хостинг, административную часть сайта и связанные сервисы

• работающие интеграции и источники данных

• критичные пользовательские сценарии

• действующие лицензии, модули и внешние сервисы

• известные ошибки и технические ограничения

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

Как сохранить контроль над доступами и материалами

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

Проверьте контроль над:

• доменом и корпоративной почтой, к которой он привязан

• хостингом и инфраструктурой сайта

• административной частью сайта

• репозиторием исходного кода

• резервными копиями

• лицензией CMS и платными модулями

• сервисами оплаты, доставки, аналитики, рассылок и интеграций

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

Студия может организовать покупку лицензии или включить её в смету. При этом лицензию следует зарегистрировать на компанию-заказчика как на конечного пользователя, а порядок оплаты и продления закрепить в договоре

Почему не стоит поручать один сайт двум подрядчикам одновременно

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

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

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

Как выбрать новую команду для входа в проект

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

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

Почему новая оценка может отличаться от оценки прежнего подрядчика

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

Бизнес-задачи → Сценарии → Данные → Интеграции → Архитектура → Разработка → Тестирование → Стоимость

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

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

Что зафиксировать при передаче проекта

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

Полезно собрать:

• список доступов и ответственных за них

• актуальный исходный код и данные о репозитории

• перечень реализованных, незавершённых и спорных задач

• документы по договору, смете, требованиям и изменениям

• список интеграций и критичных пользовательских сценариев

• сведения о лицензиях, модулях и внешних сервисах

• актуальную резервную копию

• список известных ошибок, ограничений и технических рисков

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

Неудовлетворённость текущим подрядчиком — повод навести порядок в проекте, а не просто найти нового исполнителя. Безопасная смена начинается с диагностики, контроля над доступами и ясного списка того, что уже сделано, что требует исправления и что нужно развивать дальше

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