Срок запуска сорван, исполнитель перестал отвечать, а форма показывает «Отправлено», хотя обращения не доходят. Опасно сразу нанимать нового разработчика «на несколько правок»: без приёмки он будет восстанавливать состояние проекта по догадкам, а компания рискует повторно оплатить уже сделанное. Сначала нужно вернуть контроль над сайтом, кодом и данными, затем проверить путь заявки или заказа целиком и только после этого оценивать доработку.
Почему внешний вид не подтверждает готовность
Готовые страницы не означают, что сайт можно запускать. За аккуратным интерфейсом могут скрываться неработающая отправка писем, неверный расчёт заказа, потеря данных при передаче в систему учёта клиентов и заявок или отсутствие резервной копии. Пользователь увидит подтверждение, но сотрудник не получит обращение.
Фраза «почти готово» тоже бесполезна. Последние задачи часто затрагивают серверную часть, права доступа, платежи и внешние сервисы. Полезнее описать основной путь пользователя:
- Пользователь заполняет форму или оформляет заказ.
- Сайт проверяет и сохраняет данные.
- Обращение доходит до ответственного сотрудника.
- Пользователь получает правдивое подтверждение.
- Результат корректно фиксируется в аналитике.
Принимать нужно не набор страниц, а сквозные пользовательские сценарии с проверяемым результатом.
Сначала зафиксируйте состояние проекта
До любых правок нужен снимок текущего состояния. Он поможет отделить прежние ошибки от новых. Зафиксируйте, какая версия находится на рабочем сайте и испытательном стенде, где лежат исходники, какие сценарии проходят и какие ошибки воспроизводятся.
Для каждой ошибки запишите адрес страницы, последовательность действий, ожидаемый и фактический результат. Формулировка «после отправки появляется сообщение об успехе, но запись не создаётся и письмо не приходит» пригодна для проверки. Вывод «всё сломано» не позволяет ни оценить работу, ни подтвердить исправление.
Учётные данные передают через защищённый канал, а права ограничивают необходимым объёмом. До правок нужны законно доступные копии кода и базы, безопасное место для проверки и способ возврата к прежней версии.
Что принять у прежнего исполнителя
Запрос на передачу лучше отправить одним списком. Компании нужны не личные пароли исполнителя, а контроль над собственными активами и надлежащим образом оформленные доступы.
- Домен и размещение. Кабинет регистратора, управление доменными записями, хостинг или облачная площадка, сертификаты защищённого соединения.
- Исходный код. Репозиторий с историей изменений, актуальная версия, перечень зависимостей и инструкция по сборке.
- Среды проекта. Рабочий сайт и испытательный стенд, их различия, порядок публикации и возврата версии.
- Данные и файлы. Актуальная база, пользовательские материалы, резервные копии и порядок восстановления.
- Внешние сервисы. Почта, платежи, доставка, телефония, аналитика, система учёта клиентов и заявок, программные интерфейсы и фоновые задания.
- Требования. Последняя согласованная постановка, макеты, замечания приёмки и перечень известных ошибок.
Отсутствие документа не означает, что проект нужно переписывать. Это отдельный риск: сборку воспроизводят, сервис переносят в корпоративную учётную запись или составляют минимальную инструкцию. Доступ восстанавливают только по официальным процедурам сервисов, а права на код и данные обсуждают с юристом.
Как проверить ключевые сценарии
Начните с действий, ради которых существует сайт: заявки, заказа, оплаты, записи, входа в личный кабинет или получения документа. Для каждого сценария определите начало, ожидаемый итог и место, где результат можно подтвердить.
Например, сообщение после отправки формы подтверждает только изменение интерфейса. Нужно убедиться, что серверная часть приняла данные, обращение сохранилось, уведомление дошло, а система учёта клиентов и заявок создала запись без потери обязательных полей. Если внешний сервис недоступен, ошибка должна быть заметна, а порядок повторной передачи — понятен.
Для заказа сверяют сумму на сайте, в платёжной форме и учётной системе, исключают повторное списание и проверяют уведомления. Испытания проводят на стенде и в тестовых режимах сервисов. На рабочем сайте допустимы только согласованные безопасные действия с возможностью отмены.
Как оценить остаток работ
Оценка по проценту готовности создаёт ложную точность. Разделите проект на контуры и для каждого запишите текущее состояние, необходимый результат, зависимости и способ проверки.
| Контур | Что проверяют | Условие готовности | | --- | --- | --- | | Доступы | домен, сервер, код, сервисы | компания управляет активами | | Сборка и публикация | зависимости, настройки, возврат версии | выпуск можно повторить | | Сценарии | заявка, заказ, оплата, кабинет | действие даёт подтверждённый результат | | Интеграции | почта, учётная система, программные интерфейсы | данные доходят, ошибки видны | | Данные и защита | роли, копии, секреты, журналы | критичные риски закрыты |
После проверки задачи делят на три группы:
- Препятствия для запуска. Потеря заявок, неверная оплата, отсутствие контроля над доменом, невозможность восстановить данные.
- Риски первых недель. Недостаточные журналы ошибок, ручные операции, слабые уведомления о сбоях.
- Развитие. Косметические улучшения, новые страницы и функции, без которых основной сценарий уже работает.
Сначала устраняют препятствия, затем снижают риски эксплуатации. Идеи развития выносят в отдельный план, чтобы они не отодвигали запуск. Подробнее об оценке — в статье как собрать план доработки сайта.
Точную стоимость называют, когда известны границы задачи и способ проверки. Если сборка не запускается или версия кода неизвестна, сначала оценивают короткое обследование с перечнем фактов и решений.
Когда нужна правка, а когда обследование
Точечной правки достаточно, если ошибка повторяется, актуальный код найден, есть резервная копия и стенд, а публикация и возврат версии понятны. Например, неверно сопоставленное поле формы можно проверить до и после изменения.
Обследование нужно, если рабочий сайт не совпадает с репозиторием, сборка зависит от компьютера прежнего разработчика или ошибки затрагивают несколько сценариев. Быстрая правка здесь увеличит неопределённость.
Предложение переписать всё с нуля без проверки текущего кода — гипотеза, которую нужно сравнить с поэтапным завершением проекта.
Решение о переписывании принимают после сравнения рисков, сроков и стоимости. Даже проект с неполной документацией может быть пригоден для завершения. Подробнее — в материале о доработке чужого проекта без поломок.
Критерии готовности к запуску
Перед запуском проверьте, что:
- компания управляет доменом, размещением, репозиторием и ключевыми сервисами;
- актуальная версия кода определена, сборка и публикация воспроизводятся;
- заявка, заказ или другой основной сценарий проходит от действия пользователя до результата у сотрудника;
- ошибки не скрываются за ложным сообщением об успехе и оставляют след для диагностики;
- резервные копии создаются, порядок восстановления и возврата версии известен;
- права ограничены по ролям, секреты не хранятся в открытых документах и коде;
- назначен ответственный за реакцию на сбои и проверку обращений после запуска.
Необязательные улучшения можно выпустить позже, если они не влияют на безопасность, данные и основной результат. Если основу можно сохранить, доработка сайта разумнее переписывания. После запуска проект можно передать на техническую поддержку.
Частые вопросы
Можно ли завершить сайт без прежнего разработчика?
Да, если компания законно контролирует домен, код, размещение и данные. Сначала проверяют актуальную версию и сборку, затем отдельно оценивают недоступные части.
Обязательно ли переписывать проект с нуля?
Нет. Варианты сравнивают после проверки кода, зависимостей, данных и ключевых сценариев с учётом стоимости завершения и поддержки.
Почему нельзя сразу назвать точную цену?
По интерфейсу не видно состояние серверной части, базы и внешних сервисов. Сначала определяют зависимости и проверяемый объём, затем оценивают конкретные задачи.
Что делать, если исполнитель не отдаёт доступы?
Проверьте, на кого оформлены договоры и учётные записи, затем обратитесь к сервисам по официальной процедуре. Не обходите контроль доступа; вопросы прав согласуйте с юристом.
Как понять, что сайт действительно готов?
Компания должна контролировать ключевые учётные записи, получать заявки или заказы, видеть ошибки и уметь восстановить данные либо вернуть предыдущую версию.
Что делать дальше
Соберите адреса рабочего сайта и испытательного стенда, перечень доступных учётных записей, ссылку на репозиторий и три–пять главных сценариев, которые не проходят. Не отправляйте пароли обычным письмом и не начинайте с несогласованных изменений на рабочем сайте.
Результатом приёмки должны стать карта доступов, список воспроизводимых ошибок, препятствия для запуска, риски первых недель и отдельный перечень улучшений. OpenStart может проверить чужой проект, определить безопасную последовательность доработки и подготовить сайт к запуску без обещаний «починить всё» по внешнему виду. Примеры направлений работ собраны в портфолио OpenStart.