Срок запуска уже сорван, исполнитель пропал или исправляет одно и ломает другое. В такой ситуации опасно сразу искать «еще одного программиста на пару правок»: без приемки доступов, кода и незавершенных сценариев новый подрядчик будет угадывать состояние проекта, а бизнес — снова оплачивать неопределенность. Сначала нужно вернуть проекту управляемость, затем отделить критичный путь до запуска от второстепенного бэклога.
Проект почти готов — почему запуск все равно под угрозой
Фраза «осталось совсем немного» ничего не говорит о готовности сайта. Главная страница может выглядеть законченной, но форма заявки не отправляет данные, корзина неверно пересчитывает заказ, уведомления не доходят менеджеру, интеграция с CRM работает только вручную, а production-сборку никто не умеет повторить.
Для бизнеса это означает не только перенос даты. Растут расходы на рекламу и контент, сотрудники строят процессы вокруг функции, которой еще нет, а каждая новая правка способна затронуть уже работающий сценарий. Если исходники, домен или облачные сервисы находятся в личном аккаунте бывшего исполнителя, к техническому риску добавляется риск потери контроля над активами.
Кому это актуально
- компании, у которой разработчик или студия перестали отвечать до запуска;
- владельцу сайта, который получает новые обещания, но не видит проверяемого прогресса;
- бизнесу, где дизайн готов, а формы, каталог, оплата, личный кабинет или интеграции работают частично;
- команде, которая получила архив исходников, но не получила репозиторий, инструкцию сборки и схему окружений;
- заказчику, которому предлагают переписать все с нуля до проверки текущего кода.
Если сайт уже стабильно работает и задача состоит в безопасной передаче обслуживания, полезнее начать с материала как передать сайт новому подрядчику. Здесь фокус другой: проект еще не доведен до согласованного рабочего состояния.
Сначала вернуть управляемость, а не сразу дописывать
Зафиксировать текущую точку
До первой правки нужен короткий снимок состояния проекта. Он отвечает на четыре вопроса: что доступно, что запускается, что проверено и что мешает бизнес-сценарию. Полезно сохранить исходное состояние репозитория, перечень окружений, резервную копию базы и список воспроизводимых ошибок. Это не означает выкладывать секреты в общий документ: пароли и ключи передают через согласованный защищенный канал, а доступы выдают по ролям.
Результатом этапа должен быть не общий вывод «код плохой», а карта фактов. Например: сборка воспроизводится только на машине прежнего разработчика; тестовый стенд отстает от production; форма показывает успешную отправку, но backend отвечает ошибкой; заказ создается на сайте, но не появляется в учетной системе. Такие наблюдения можно проверить и превратить в задачи.
Отделить путь до запуска от пожеланий
В один список часто попадают блокирующие ошибки, косметические замечания и идеи на будущее. Из-за этого команда переключается между задачами, а дата запуска продолжает сдвигаться. Сначала стоит описать минимальный рабочий путь пользователя: открыть страницу, найти услугу или товар, отправить заявку либо оформить заказ, получить подтверждение, передать данные менеджеру и зафиксировать событие в аналитике.
Для каждого шага нужны критерий приемки и свидетельство проверки. Скриншота интерфейса недостаточно, если результат зависит от письма, webhook, очереди, CRM или платежного статуса. Проверяется вся цепочка, включая обработку ошибок и повторную отправку.
Не оценивать остаток работ по чужому списку
Старый бэклог полезен как исходный материал, но не как готовая оценка. Часть задач может быть выполнена только визуально, часть — потерять актуальность, а часть — скрывать зависимость от инфраструктуры или внешнего API. Поэтому стоимость и последовательность работ уточняют после просмотра кода, окружений и критичных сценариев.
Это не способ искусственно увеличить объем аудита. Наоборот, короткая техническая приемка помогает не включать в смету то, что уже работает, и не обещать точную цену там, где причина еще не локализована. Принципы разбиения задач на этапы подробнее разобраны в статье как собрать план доработки сайта.
Что нужно принять у прежнего исполнителя
Даже если связь нестабильна, запрос лучше оформить одним структурированным списком.
- Домены и инфраструктура. Кто владеет кабинетом регистратора, DNS, хостингом, облаком, CDN и сертификатами; какие доступы принадлежат компании, а какие — личному аккаунту исполнителя.
- Репозиторий и история изменений. Основные ветки, актуальный коммит, теги релизов, правила сборки, зависимости и место хранения артефактов.
- Окружения и выпуск. Production, тестовый стенд, CI/CD, команды миграций, порядок выкладки и понятный сценарий отката.
- Данные и файлы. Актуальная база, пользовательские загрузки, резервные копии, правила восстановления и ограничения по персональным данным.
- Интеграции. Почта, CRM, платежи, доставка, телефония, аналитика, внешние API, очереди и фоновые задания. Секреты не следует вставлять в обычную переписку или открытый таск-трекер.
- Требования и незавершенные сценарии. Последняя согласованная постановка, макеты, замечания приемки, список известных дефектов и решения, которые еще ждут заказчика.
Если чего-то нет, это не автоматический повод переписывать проект. Отсутствие каждого артефакта нужно превратить в отдельный риск и определить безопасный способ восстановления: перенести владение аккаунтом, воспроизвести сборку, описать ручной релиз, сделать контролируемую копию данных или заменить недоступный внешний сервис.
Как оценить остаток работ
Практичнее оценивать не «процент готовности», а конкретные контуры.
| Контур | Что проверяем | Какой результат нужен | | --- | --- | --- | | Доступы | владение доменом, сервером, репозиторием и сервисами | компания может управлять активами без личного аккаунта бывшего исполнителя | | Сборка и релиз | повторяемость сборки, миграции, конфигурация, откат | команда может воспроизвести выпуск и вернуть предыдущую версию при сбое | | Критичные сценарии | заявка, корзина, оплата, кабинет, поиск | сценарий проходит от действия пользователя до подтвержденного бизнес-результата | | Интеграции | почта, CRM, API, очереди, фоновые процессы | данные доходят, ошибки фиксируются, повторная обработка понятна | | Безопасность | роли, секреты, обновления, журналирование, резервные копии | закрыты критичные риски до публичного запуска | | Поддержка | мониторинг, ответственная роль, очередь задач, регламент | после запуска есть понятный процесс реакции и развития |
После проверки задачи удобно разделить на три группы: блокеры запуска, риски ранней эксплуатации и развитие после запуска. Сначала закрывают то, без чего нельзя безопасно принимать заявки или заказы. Затем — наблюдаемость, резервирование и обработку сбоев. Косметические улучшения и новые функции переходят в отдельный план, чтобы не маскировать ими незавершенность основы.
Типовой диагностический сценарий
Представим проект, где форма визуально работает и показывает сообщение «Отправлено». При проверке выясняется, что браузер действительно вызывает endpoint, но сервер не сохраняет обращение, письмо попадает не во все ящики, webhook в CRM не имеет повторной отправки, а цель аналитики срабатывает еще до подтверждения backend.
Быстрая замена текста кнопки проблему не решит. Нужно проследить одну тестовую заявку по всей цепочке, зафиксировать идентификаторы и время, локализовать точку потери, определить поведение при повторе и только затем менять код. Это пример метода диагностики, а не описание конкретного клиента или универсальной причины всех сбоев.
Какие риски закрывает приемка
- потерю домена, исходников или доступа к production после окончательного ухода исполнителя;
- запуск формы, корзины или оплаты, которые выглядят рабочими, но теряют данные;
- повторную оплату уже сделанного из-за отсутствия истории и критериев готовности;
- случайную поломку рабочего участка при срочной правке без резервной копии и отката;
- зависимость от одного человека, который один знает команды сборки и ручные операции;
- бесконечный «финальный рывок», в котором новые пожелания смешиваются с блокерами запуска.
Как это решает OpenStart
OpenStart может начать с технической приемки чужого проекта: проверить доступы, репозиторий, сборку, базу, окружения и критичные пользовательские цепочки. Затем команда фиксирует воспроизводимые проблемы и предлагает последовательность: что нужно стабилизировать немедленно, что необходимо для запуска, а что разумно вынести в развитие.
Работы выполняются поэтапно. Перед изменениями сохраняется исходное состояние и определяется способ отката; критичные сценарии проверяются до и после релиза; неизвестные зависимости не маскируются точной оценкой «по фотографии». Если проект можно безопасно завершить на текущей основе, доработка сайта обычно рациональнее полного переписывания. Если после запуска нужна регулярная очередь задач, мониторинг и контроль изменений, проект можно перевести на техническую поддержку.
Для уже работающего, но сложного старого кода дополнительно полезен разбор доработки чужого legacy-проекта. Публичные примеры направлений работ собраны в разделе кейсов OpenStart; конкретный кейс по незавершенному проекту в этой статье не заявляется.
Что запросить у подрядчика
Перед началом работ стоит получить ответы в проверяемом виде:
- какой коммит и какое окружение сейчас считаются актуальными;
- кто юридически и технически контролирует домен, сервер и внешние сервисы;
- можно ли повторить сборку по инструкции на чистом окружении;
- какие пользовательские сценарии реально пройдены от начала до конца;
- где хранятся резервные копии и когда проверялось восстановление;
- как выпускаются миграции и как выполняется откат;
- какие ошибки уже известны и чем подтверждается их исправление;
- какие интеграции требуют тестовых учетных записей или согласования с внешней стороной;
- что подрядчик считает блокером запуска, а что предлагает перенести в следующий этап;
- какой отчет и набор артефактов останутся у компании после завершения приемки.
Ответ «все почти готово» не заменяет репозиторий, доступ, тест и критерий результата. При этом отсутствие документации само по себе не доказывает, что код непригоден: это сигнал оценить риск и восстановить минимально необходимый контур управления.
Когда достаточно быстрой правки, а когда нужен аудит
Точечной доработки может быть достаточно, если ошибка воспроизводится, участок кода и владельцы доступов понятны, есть тестовый стенд, резервная копия и безопасный выпуск. Например, можно локализовать конкретную валидацию формы или неверное сопоставление поля интеграции и проверить цепочку после изменения.
Аудит нужен, когда нет актуального репозитория, сборка не повторяется, production заметно отличается от исходников, права и секреты распределены по личным аккаунтам, а ошибки возникают сразу в нескольких связанных сценариях. В этом случае попытка «просто дописать» увеличивает неопределенность. Первый полезный результат аудита — не объемный отчет ради отчета, а карта блокеров, рисков и ближайших решений.
Частые вопросы
Можно ли завершить сайт без прежнего разработчика?
Часто — да, если компания может восстановить контроль над доменом, инфраструктурой, кодом и данными. Но сначала нужно проверить фактическое состояние проекта. Без репозитория или доступа к production путь может включать восстановление артефактов и перенос владения сервисами.
Обязательно ли переписывать проект с нуля?
Нет. Решение зависит от воспроизводимости сборки, качества критичных участков, совместимости зависимостей и стоимости устранения рисков. Переписывание оправдано только после сравнения с поэтапным завершением и стабилизацией текущей основы.
Почему нельзя сразу назвать точную стоимость?
По внешнему виду нельзя увидеть состояние backend, базы, инфраструктуры и интеграций. Сначала проверяют доступы и критичные сценарии, затем дают оценку по конкретному объему и отмечают неизвестные зависимости.
Что делать, если бывший исполнитель не передает доступы?
Зафиксировать, какие аккаунты оформлены на компанию, обратиться к регистратору, хостингу или владельцу сервиса по их официальной процедуре и не пытаться обходить контроль доступа. Параллельно нужно определить, какие компоненты можно восстановить из законно доступных копий. Юридические вопросы передачи прав стоит решать с профильным специалистом.
Как понять, что проект действительно готов к запуску?
Не по числу закрытых задач, а по проверке согласованных пользовательских и операционных сценариев: заявка или заказ доходят до ответственного сотрудника, ошибки видны, данные сохраняются, резервное восстановление и откат понятны, а компания контролирует ключевые аккаунты.
Следующий шаг
Если разработчик не доделал сайт, соберите ссылки на окружения, список доступных аккаунтов, адрес репозитория и три-пять главных сценариев, которые сейчас не проходят. OpenStart может провести приемку чужого кода, локализовать блокеры и подготовить поэтапный план до запуска без обещаний переписать или «починить все» вслепую.