Подрядчик перестал отвечать, а сайт остался между макетами, тестовым сервером и незавершёнными интеграциями. Самая рискованная реакция — срочно найти исполнителя «на несколько правок» и сразу выпустить найденную сборку. Готовая главная страница не доказывает, что заявки доходят в систему управления отношениями с клиентами (CRM), оплата меняет статус заказа, доступы принадлежат компании, а проект можно восстановить после ошибки.
Правильная последовательность другая: сохранить текущее состояние, вернуть контроль над цифровыми активами, проверить воспроизводимость проекта и пройти критичные сценарии. После этого можно решить, что выгоднее и безопаснее — закончить текущую реализацию, заменить отдельные компоненты или пересобрать ограниченную часть.
Не оценивайте готовность в процентах. Оценивайте сценарии: что пользователь может сделать от начала до подтверждённого результата и что мешает безопасному запуску.
Первые действия: остановить потерю контроля
Зафиксируйте текущее состояние
Сохраните адреса рабочего и тестового контуров, версию кода, дату последнего изменения и перечень известных ошибок. Если несколько людей продолжают менять проект, временно назначьте одного ответственного за сборку. Иначе новый подрядчик будет исследовать систему, которая меняется во время диагностики.
Не удаляйте найденные файлы и не обновляйте зависимости «на всякий случай». Сначала нужна копия исходного состояния, с которым можно сравнивать последующие изменения.
Соберите доступы и проверьте владельцев
Обычно нужны доступы к:
- домену и настройкам DNS;
- хостингу, облаку и серверу;
- базе данных и пользовательским файлам;
- репозиторию исходного кода;
- системе управления сайтом;
- аналитике и почтовым службам;
- CRM, оплате и другим внешним интеграциям;
- магазинам лицензий и аккаунтам сторонних сервисов.
Наличие пароля не равно владению активом. Компания должна иметь возможность восстановить доступ к домену, репозиторию, облачному проекту и платёжному кабинету без исчезнувшего разработчика.
Не пересылайте секреты в общем чате. Используйте защищённое хранилище, проверьте владельцев учётных записей и после приёмки смените ключи, которые мог знать прежний подрядчик.
Сделайте резервные копии до экспериментов
До переноса сервера, обновления зависимостей или изменения базы сохраните код, базу, пользовательские файлы и конфигурацию окружения. Копия полезна только тогда, когда известно, где она хранится, чем защищена и как её восстановить.
Проверять восстановление лучше на отдельном контуре. Попытка впервые развернуть копию поверх единственной рабочей версии создаёт новый риск вместо защиты.
Отделите внешний вид от фактической готовности
Макеты и свёрстанные страницы показывают только часть продукта. Пользовательский путь может обрываться после формы, заказ — не попадать в CRM, а административная часть — работать только под учётной записью бывшего исполнителя. Исходный код иногда остаётся на сервере, но без репозитория, истории изменений и инструкции по сборке.
Составьте список действий, ради которых существует сайт:
- для корпоративного сайта — отправка заявки и получение её менеджером;
- для магазина — поиск товара, корзина, оплата, заказ, чек и обмен с учётной системой;
- для личного кабинета — регистрация, подтверждение, права пользователя и восстановление доступа;
- для сервиса — ключевая операция, запись результата и уведомление ответственного.
Для каждого сценария запишите ожидаемый итог и место, где его подтверждает бизнес. Это превращает фразу «почти готово» в проверяемую карту.
Порядок технической приёмки
1. Переведите обещания в критерии
Соберите договор, постановки, макеты и переписку, но не считайте их доказательством готовности. Каждый пункт превратите в наблюдаемый результат.
Вместо «есть интеграция с CRM» запишите: «после отправки формы в CRM создаётся обращение с контактами, страницей-источником и выбранной услугой; назначается ответственный». Вместо «есть мобильная версия» — перечень ключевых сценариев, которые проходят на телефоне.
2. Проведите инвентаризацию компонентов
Зафиксируйте систему управления сайтом или программную основу, версии языка и базы, сторонние модули, фоновые задания, очереди, кэш, сеть доставки контента (CDN), поиск и внешние API.
Отдельно отметьте компоненты без понятного владельца, лицензии, документации или поддержки. Инвентаризация нужна не ради схемы, а чтобы оценка учитывала реальные зависимости и стоимость эксплуатации.
3. Проверьте воспроизводимость сборки
Новый подрядчик должен понять, можно ли развернуть проект из репозитория на чистом тестовом окружении. Для этого нужны команды сборки, миграции базы, зависимости и перечень переменных окружения без публикации их значений.
Если рабочая версия существует только на сервере, любая правка особенно рискованна. Сначала создают контролируемую историю изменений и восстанавливают процесс сборки, затем меняют функциональность.
4. Пройдите критичные сценарии
Проверяйте не отдельные кнопки, а цепочки:
- форма → сервер → письмо или CRM → уведомление менеджера;
- корзина → оплата → заказ → чек → учётная система;
- регистрация → подтверждение → личный кабинет → восстановление доступа.
Для каждой цепочки нужны безопасные тестовые данные, ожидаемый результат и сотрудник, который подтвердит итог. Не создавайте фиктивные производственные лиды и реальные списания без согласованного порядка.
5. Оцените безопасность и эксплуатацию
Проверьте права пользователей, открытые служебные разделы, журналы ошибок, резервные копии, мониторинг доступности и срок сертификатов. Секреты не должны лежать в публичном репозитории или тексте задачи.
Если происхождение кода и зависимостей неясно, до первого релиза полезно проверить состав пакетов и неожиданные изменения. Но список потенциальных угроз не заменяет приоритет: сначала закрывают подтверждённые блокеры и риски критичных сценариев.
6. Получите план ближайшего результата
Итог диагностики — не длинный перечень замечаний, а очередность работ. Для каждого пункта нужны:
- влияние на запуск;
- зависимость от других задач;
- критерий приёмки;
- известные ограничения оценки;
- решение о выпуске;
- для рискованных изменений — копия, окно релиза, проверка и откат.
Такой план можно сравнивать между подрядчиками и передавать следующей команде.
Как оценить остаток работ без «готово на 80%»
Последняя часть проекта часто включает самые связанные функции: оплату, перенос данных, права, обмен с учётной системой и выпуск на рабочем домене. Поэтому остаток делят на три очереди.
Блокеры запуска
Без них нельзя безопасно принимать заявки, платежи или пользовательские данные. Сюда относятся недоступные корпоративные активы, невоспроизводимая сборка, неработающий критичный сценарий и отсутствие возможности восстановиться после ошибки.
Важные задачи после запуска
Они влияют на удобство, скорость, аналитику и работу сотрудников, но имеют временный безопасный обходной путь. Такой обход должен быть записан вместе с ответственным и сроком пересмотра.
Развитие
Новые функции и улучшения не следует смешивать с восстановлением базовой работоспособности. Иначе запуск постоянно отодвигается, а оценка блокеров растворяется в пожеланиях.
Подрядчик может сначала оценить ограниченную диагностику, если неизвестно состояние базы, интеграции или сборки. Обещание точной стоимости всей переделки до знакомства с проектом обычно скрывает неопределённость, а не устраняет её.
Доделывать или переписывать
Сохранять текущую реализацию разумно, если:
- критичные сценарии воспроизводятся;
- проект разворачивается из контролируемого источника;
- основные зависимости поддерживаются;
- права на код и модули понятны;
- изменения можно выпускать по частям;
- стоимость исправления соразмерна ближайшему результату.
Замену отдельных компонентов рассматривают, если сборка невоспроизводима, одна правка регулярно ломает другие части, ключевые зависимости больше не поддерживаются или права на код неясны.
Даже в этом случае не обязательно начинать весь сайт заново. Сначала определяют границы замены, миграцию данных, совместимость и переходный период. Решение должно следовать из диагностики и стоимости владения, а не из предпочтений нового разработчика.
Когда можно обойтись без отдельного аудита
Для простого сайта без интеграций, если у компании есть исходники, доступы и несколько понятных визуальных правок, достаточно проверяемой постановки и приёмки. Большой аудит будет несоразмерен задаче.
Предварительная диагностика нужна, когда проект принимает платежи или персональные данные, связан с несколькими системами, не разворачивается из репозитория, лишён документации либо должен запускаться после нескольких смен исполнителей.
Что запросить у нового подрядчика
До согласования большого бюджета попросите:
- карту критичных пользовательских и внутренних сценариев;
- перечень доступов и владельцев активов без самих секретов;
- список компонентов, версий, лицензий и интеграций;
- результат проверки сборки на тестовом контуре;
- реестр проблем с приоритетами и влиянием на запуск;
- план первого безопасного релиза и отката;
- границы оценки и список неизвестных данных.
Презентация интерфейса не заменяет техническую передачу проекта. Полезный результат можно проверить, сохранить у компании и передать другой команде.
Как может помочь OpenStart
Самостоятельно можно собрать материалы, вернуть корпоративные доступы и описать обязательные сценарии. Специалист нужен, если требуется исследовать чужой код, восстановить сборку, проверить интеграции или безопасно изменить связанную систему.
OpenStart начинает с инвентаризации и критичных сценариев. Команда помогает восстановить управляемый контур — репозиторий, тестовое окружение, копии, зависимости и очередь задач — а затем оценивает ближайший проверяемый этап. Цель не в том, чтобы заранее продать полную переделку, а в том, чтобы вернуть бизнесу контроль и маршрут до запуска.
Следующий шаг
Соберите ссылку на текущую версию, доступные материалы, обязательные сценарии и известные ограничения. Передайте этот пакет OpenStart на первичную диагностику: команда отделит блокеры запуска от задач развития и подготовит поэтапный план доработки без обещаний вслепую.