Подхват проекта — аудит
Проверим проект до того, как вы подпишете большой контракт на подхват или смену подрядчика. Разберём код, доступы, продакшен, интеграции, релизы, документацию и риски. На выходе — понятная картина состояния и план следующих шагов.
Что такое аудит перед подхватом
Аудит перед подхватом — это отдельный, более короткий формат работы. Его цель — за несколько дней получить честную картину состояния проекта и принять информированное решение: менять подрядчика, отложить подхват, ограничиться узкой работой или передать проект внутренней команде. Аудит не заменяет полноценный подхват и не включает в себя разработку новых функций или большие изменения в проде.
Разбор кода, инфраструктуры, доступов, релизного процесса, интеграций, данных, безопасности и документации. Карта рисков с приоритезацией. Список доступов, которых не хватает. План стабилизации на первые недели. Рекомендации по дальнейшему формату работы и список решений, которые вам предстоит принять.
Разработка новых функций, большой рефакторинг, изменение архитектуры, массовые миграции данных, юридическое сопровождение спора с прошлым подрядчиком, обещание найти все скрытые дефекты или гарантировать итоговую смету без доступа к критичным частям проекта.
Когда стоит начать с аудита
Если совпали два-три пункта — стоит сначала разобраться, что реально под капотом, и только потом подписывать большой контракт.
Есть подозрение, что текущая команда не справляется, но доказательств для разговора и решения пока не хватает.
На вопросы о состоянии проекта приходят общие ответы. Понять реальный риск по отчётам команды не получается.
Кто владеет аккаунтами, где лежат секреты, как выкатывается релиз — собрать целую картину невозможно без отдельной диагностики.
Регрессии возвращаются, фиксы держатся недолго. Понять, где источник, без независимого взгляда — нечем.
Есть часть проекта, по которой нужно принять обоснованное решение, а не выбирать «по ощущениям».
Запланированный релиз вызывает сомнения. Хочется понять, что может пойти не так, и какие риски снять до выпуска.
Если человек уйдёт, проект встанет. Нужно понять, что в первую очередь перенести из его головы в документы и процессы.
Перед большим договором на подхват, поддержку или развитие хочется проверить состояние не глазами предлагающей стороны.
Кому аудит не подойдёт
Называем заранее, чтобы не тратить ваше время и не создавать ложных ожиданий.
Если задача — сегодня же закрыть конкретный баг без разбора контекста, это не аудит. Для острых ситуаций с горящим продакшеном есть отдельный формат срочного входа.
Если у вас нет подтверждённого доступа хотя бы на чтение к коду, серверу, базе и ключевым аккаунтам, и получить его невозможно, аудит превращается в «угадайку». Это не наш формат.
Если основная задача — выиграть спор по правам на код или акт сдачи работ, это зона юриста. Технический аудит может стать частью аргументации, но не заменяет юридическое сопровождение.
Никакой аудит не гарантирует обнаружения всех скрытых дефектов. Мы честно описываем периметр и говорим, что осталось вне зоны проверки и почему.
Что проверяем
Конкретный периметр обсуждаем на старте. Ниже — список того, что мы обычно смотрим в проекте перед подхватом.
Как устроен код, какие ветки активны, насколько стабильна история изменений, где живут хотфиксы и незавершённая работа.
Состояние зависимостей, актуальность версий, известные уязвимости в используемых пакетах, замороженные обновления.
Что и где развёрнуто, как описана инфраструктура, где хранятся env-файлы, как устроена конфигурация сервисов.
Какие версии работают на проде и на тесте, совпадают ли они с тем, что в репозитории, есть ли вообще тестовый контур.
Состояние базы, история и применимость миграций, регулярность и проверенность бэкапов, наличие сценариев восстановления.
Какие обмены критичны, где идут потери и ошибки, как организовано версионирование и совместимость с внешними клиентами.
Как собирается и выкатывается код, что делается руками, есть ли rollback и кто им владеет на практике.
Кто владеет аккаунтами по документам и кто фактически имеет доступ, где хранятся секреты, оформлены ли ключевые сервисы на заказчика.
Что собирается, куда складывается, кто получает алёрты, какие инциденты были за последние месяцы и как они были разобраны.
Что задокументировано, что устарело, что живёт только в переписке и в голове конкретных людей.
Что вы получаете после аудита
Артефакты остаются у вас даже в случае, если дальше работаете не с нами.
Короткий письменный разбор по разделам аудита с приоритезированными находками и пометками о том, что осталось вне периметра проверки.
Таблица: риск, вероятность, влияние, приоритет, ответственный. Разнесена по слоям — код, данные, доступы, инфраструктура, релизы — чтобы видеть, где горит первым.
Что и в каком порядке имеет смысл запросить у текущей команды или восстановить со стороны заказчика как владельца проекта.
Что где развёрнуто, какие сервисы участвуют, какие обмены идут, где живут данные. Опорная схема для любых дальнейших решений.
Список работ, которые имеет смысл сделать первыми, с оценкой трудоёмкости. Это не обязательство нам — планом можно воспользоваться с любой командой.
Поддерживать текущую архитектуру, стабилизировать, частично переписать или менять подрядчика — с аргументами из отчёта, а не «по ощущениям».
Что не запускаем до получения дополнительных доступов или юридической ясности. Это часть отчёта, а не оговорка постфактум.
Процесс
Сценарий повторяется от проекта к проекту: контекст, доступы, разбор, сводка, отчёт. Без этапа «давайте сразу что-нибудь поправим».
Контекст проекта, цели аудита, ограничения, критичные риски, ответственные. По запросу подписываем NDA.
Репозиторий, серверы, БД, CI/CD, кабинеты интеграций. Объём доступов согласовываем заранее, без избыточных прав.
Код, инфраструктура, релизы, данные, безопасность, интеграции и документация. Фиксируем находки и вопросы по ходу.
Раскладываем находки по приоритетам, отделяем критичные риски от вторичных, фиксируем то, что требует отдельного решения владельца.
Отчёт, план стабилизации, варианты следующего шага. Решение — за вами. Дальнейшее сотрудничество не обязательно.
Что не входит в аудит
Эти ограничения мы соблюдаем сами, чтобы аудит оставался диагностикой, а не растягивался в неуправляемый формат работы.
Любая новая функция требует контекста, тестирования и релизного процесса. В рамках аудита это не делаем, даже если кажется, что «по дороге одну штуку поправить».
Архитектурные изменения — это отдельный согласованный этап. В аудит они не входят и не могут быть протащены под видом «небольших правок».
Переписывание и миграции требуют бэкапов, репетиции на копии и плана отката. В формате аудита мы их не запускаем и не предлагаем как часть стандартного результата.
Спор с прошлым подрядчиком по правам и актам — зона юриста. Технический аудит может стать частью аргументации, но не заменяет юридическое сопровождение.
Глубина аудита ограничена временем и доступами. Часть проблем виден только в проде под нагрузкой или через продолжительное наблюдение. В отчёте честно говорим, что осталось вне периметра.
Если ключевые части проекта остались недоступны на момент аудита, итоговую смету на длинные работы назвать честно нельзя. Даём диапазон по стабилизации и оценку ближайших шагов.
Какие решения помогает принять
Аудит — это инструмент для принятия решений. Ниже — типовые вопросы, которые после аудита перестают быть субъективными.
На основании отчёта понятно, насколько риск замены сравним с риском продолжения с текущей командой.
Решение по модулю принимается с цифрами и аргументами, а не по принципу «нам не нравится текущий код».
В отчёте — приоритезированный список того, что важно вернуть в зону вашего владения и в каком порядке.
Технические находки переведены на язык бизнес-рисков: где может встать продажа, где — операционный процесс, где — поддержка.
По итогам аудита понятно, какие риски стоит снять до релиза и можно ли выпускать его без дополнительных подготовительных шагов.
В отчёте — оценка того, насколько проект готов к передаче внутрь и каких документов и доступов не хватает для этого.
Срочный подхват, плановый подхват, поддержка или отдельная интеграционная работа — выбираем формат на основании отчёта, а не на основании первоначальных ожиданий.
Доступы и материалы для старта
Часть пунктов выглядит банально, но именно они задают точность и скорость аудита.
Типовые результаты аудита
Конкретный результат зависит от проекта. Ниже — типовые варианты, которые встречаются в реальных аудитах.
Состояние позволяет начать передачу проекта без отдельной стабилизации.
Сначала закрываем критичные риски, потом возвращаемся к продуктовым задачам.
Релиз или изменение в проде стоит откатить до устранения причин.
Без них дальше двигаться рискованно, в отчёте — список и приоритет.
Профильная диагностика обменов, API и webhooks выходит за объём общего аудита.
Бэкапы есть, но восстановление не проверялось — это отдельная работа.
Проект готов к передаче внутренней команде по чек-листу из отчёта.
Рефакторинг конкретного куска экономнее, чем продолжать его поддерживать.
Часть проекта в спорной юридической ситуации — сначала юридическая ясность.
Ближайший релиз требует подготовительных шагов, без которых рисков слишком много.
Для каких проектов подходит
Аудит подходит большинству проектов, которые мы подхватываем. Ниже — ссылки на отдельные страницы по типам подхвата, чтобы вы сразу видели специфику вашего случая.
Корпоративные сайты, e-commerce, веб-приложения и внутренние сервисы.
iOS, Android и кроссплатформенные на Flutter или React Native.
Боты, Mini Apps, внутренние боты команд.
Django, FastAPI, Flask, Celery, API и фоновые задачи.
CRM, 1С, платежи, webhooks, очереди, ETL и обмены.
УТ, ERP, КА, ЗУП, Бухгалтерия — конфигурации, расширения и обмены.
Bitrix24, amoCRM, кастомные CRM и CRM в составе продукта.
Backend, личные кабинеты, billing, подписки, роли и multi-tenant.
Подрядчик пропал, релиз горит, продакшен нестабилен.
Проект после одиночного разработчика или небольшой команды.
Если вы уже решили менять подрядчика
Если решение о смене подрядчика принято и нужен не только аудит, а полноценная передача проекта под контроль — начните с общей страницы подхвата проекта.
Если ситуация уже острая, есть отдельная страница про срочный подхват проекта. Если проект достался после одиночного исполнителя — подхват после фрилансера. Если основной риск в обменах и API — подхват интеграций и API.
FAQ
С короткой стартовой сессии и заявки на аудит. Обсуждаем, что за проект, кто текущий подрядчик, какие сценарии критичны, какие доступы уже на вашей стороне и что именно вы хотите понять перед решением о смене команды. По запросу подписываем NDA. Дальше — технический разбор по согласованному периметру. Условия дальнейшего сотрудничества обсуждаются после отчёта, а не до.
Да. Аудит — отдельный формат и существует именно для этого. По итогам у вас остаётся письменный отчёт, карта рисков, карта доступов, схема инфраструктуры и интеграций, план стабилизации и список первых решений. Дальше вы выбираете: возвращаетесь к текущему подрядчику с конкретным списком, ищете другую команду, передаёте отчёт внутреннему техническому руководителю или продолжаете работу с нами. Никаких обязательств на подхват у вас нет.
Доступы хотя бы на чтение: репозиторий, серверы и инфраструктура, база, CI/CD, кабинеты интеграций. Плюс контекст: список текущих проблем, прошлые договорённости с подрядчиком, критичные сценарии, контакты ответственных. Чем полнее доступы и контекст, тем точнее и быстрее аудит. Если части доступов нет, на старте отдельно фиксируем, какие выводы возможны без них, а какие — нет.
Зависит от размера проекта, состояния документации и полноты доступов. Конкретные сроки не называем заранее, потому что аудит без аудита — это та же история, которая привела вас в текущую ситуацию. После стартовой сессии предлагаем реалистичный формат и периметр. Если хотите ограничить объём — обсуждаем узкий аудит по конкретному модулю.
Да, базовый аудит можно сделать на read-only доступах: чтение репозитория, базы, логов, мониторинга, конфигов. Этого достаточно, чтобы построить картину состояния, риски и список недостающих доступов. Изменения в проде без подтверждённых прав мы не делаем. Если каких-то частей не видно даже на чтение, в отчёте фиксируем, какие выводы возможны без них, а какие — нет.
Code review разбирает код: качество, паттерны, потенциальные ошибки. Аудит перед подхватом смотрит шире: код, инфраструктура, доступы, релизный процесс, интеграции, документация, операционные риски, владение аккаунтами. Цель не «оценить уровень кода», а понять, что досталось, где риски, какие доступы нужны и какой формат работы дальше уместен. Code review может быть частью аудита, но не равен ему.
Да. Отчёт остаётся у вас и предназначен для принятия решений, в том числе с другим подрядчиком или внутренней командой. Структура отчёта рассчитана на то, что его читает не только владелец, но и технический человек, который будет дальше работать с проектом. Если ваша внутренняя команда захочет уточняющую встречу по отчёту — это отдельный короткий формат.
В отчёте честно скажем: точечный рефакторинг, поэтапная замена или переписывание выбранных частей. Решение принимаете вы, исходя из бизнес-приоритетов. Полное переписывание не предлагаем по умолчанию — оно почти всегда длиннее и дороже, чем кажется, и в первые месяцы продукт всё равно работает на старом коде, который кто-то должен поддерживать.
После аудита можем дать оценку ближайших шагов и диапазон по стабилизации. Финальная смета на длинные работы зависит от доступа ко всем критичным частям проекта и от решений, которые вы примете по итогам отчёта. Точная цифра без аудита — это нечестно по отношению к вам и почти всегда нерелевантна реальной ситуации в проекте.
По итогам аудита решаются практические вопросы: менять подрядчика сейчас или сначала стабилизировать текущую работу, чинить архитектуру или переписывать отдельный модуль, какие доступы забирать в первую очередь, можно ли выпускать ближайший релиз, передавать ли проект внутренней команде, какой формат работы нужен дальше — срочный подхват, плановый, поддержка или интеграционная работа.
Заказать аудит перед подхватом
Опишите проект, текущего подрядчика, доступы, стек и что нужно понять до смены команды. Вернёмся с конкретикой и предложим формат аудита.
Аудит перед подхватом
Поля помечены под аудит перед подхватом: что за проект, какой стек, какие интеграции и доступы, что нужно понять до смены команды.
Заявка придёт на hi@khaiam.ru. Можно написать сразу в Telegram .
Заявка отправлена
Если задача срочная, можно сразу написать в Telegram .