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

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

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

• Повторяющиеся ошибки, неясные статусы и отсутствие плана работ — более серьёзные признаки

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

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

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

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

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

Какие признаки показывают, что поддержка организована плохо

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

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

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

Что должно входить в техническую поддержку

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

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

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

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

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

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

Как принять сайт на поддержку от другого подрядчика

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

Обычно процесс включает пять шагов:

1. Собрать управляемые доступы к сайту, серверу, домену, репозиторию, резервным копиям и внешним сервисам

2. Составить карту интеграций и ответственных за связанные системы

3. Зафиксировать критичные сценарии: заявка, заказ, оплата, авторизация, личный кабинет и обмен данными

4. Провести первичную диагностику кода, инфраструктуры, обновлений и известных ошибок

5. Сформировать отдельную очередь критичных, плановых и профилактических задач

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

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

Что делать, если прежний подрядчик не передаёт доступы

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

Последовательность действий:

• подтвердить, кто указан владельцем домена

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

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

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

• связаться с владельцами платёжных, логистических и других внешних сервисов

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

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

Почему две команды не должны поддерживать один контур

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

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

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

Что подготовить для первой оценки новой поддержки

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

Подготовьте:

• адрес сайта и используемую редакцию CMS

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

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

• список интеграций и внешних сервисов

• ближайшие задачи развития

• сведения о текущем подрядчике или внутренней команде

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

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

От чего зависит стоимость поддержки

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

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

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

Какой формат поддержки подходит разным сайтам

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

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

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

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