Технический аудит превращает «не работает» в факты — и показывает, как довести проект до результата
Фиксируем конкретную версию проекта и проверяем её по требованиям ТЗ: код, Git, сборка, сервер, БД, интеграции, логи и пользовательские сценарии. Результат нужен юристу как доказательная база, а технической команде — как карта продолжения. Если проект целесообразно спасать, после фиксации мы можем не ограничиваться отчётом, а сами исправить и доделать его.
Почему «у меня ошибка 500» — слабое описание для IT‑спора
Нужно установить, какая версия проверяется, почему эта функция должна существовать, при каких условиях проявляется ошибка и кто имел доступ к системе после передачи.
Версия
Commit, tag, дата архива, production release и способ подтверждения неизменности исследуемой копии.
Окружение
Runtime, БД, зависимости, конфигурация, внешние сервисы и ограничения доступа.
Ошибка
Точные шаги воспроизведения, журналы, API‑ответы, скрин/видео и фактический эффект.
Обязательство
Пункт ТЗ, переписка об изменении или критерий приёмки, которому результат не соответствует.
Сначала сохраняем доказательства, затем можем сами переходить к исправлению
Это ключевой смысл связки ПравДок. Пока идёт спор, код нельзя бездумно менять. После фиксации спорной версии юридическая и техническая команды согласуют границу: что сохраняется как доказательство, а что уже можно безопасно ремонтировать.
Сохранили версию, логи, окружение и соответствие ТЗ.
Понимаем, что заказчик вправе использовать и что нужно получить у подрядчика.
Если это рационально, наша техническая команда стабилизирует существующую систему, реализует недостающее или пересобирает проблемный слой.
Как из «бот работает плохо» получается проверяемая матрица
MAX‑бот + CRM + платёжный шлюз
| Требование | Статус | Фиксация | Юридическое значение |
|---|---|---|---|
| п. 4.2 — одна заявка в CRM | FAIL | webhook №1 создаёт карточку, retry создаёт дубль; приложены логи и видео | результат не соответствует заявленному сценарию |
| п. 5.1 — оплата | FAIL | endpoint отсутствует, кнопка ведёт в заглушку | функция фактически не реализована |
| п. 6.3 — роль юриста | PARTIAL | просмотр есть, изменение чужой заявки не ограничено | частичное исполнение; значимость зависит от ТЗ |
| п. 8.1 — передача исходников | BLOCKED | заказчику передан ZIP, Git‑история недоступна | проверяем содержание обязанности о передаче |
| п. 9.2 — экспорт PDF | PASS | 3 тестовых сценария, файлы совпадают с шаблоном | подтверждает выполненную часть |
Что сохраняем до вмешательства нового исполнителя
- полный Git clone с историей и remote;
- commit/tag исследуемой версии;
- архив production и контрольные хеши;
- дамп БД и список миграций;
- конфигурацию runtime и веб‑сервера;
- логи приложения, cron, очередей и интеграций;
- видео ключевых пользовательских сценариев;
- API‑запросы и ответы на ошибочных сценариях;
- состояние домена, DNS и сертификатов;
- список внешних аккаунтов и владельцев;
- документацию сборки и deployment;
- матрицу ТЗ с доказательствами по каждому спорному пункту.
Секреты и персональные данные не публикуются в отчёте. Токены, пароли и ключи фиксируются безопасным способом; после передачи инфраструктуры чувствительные секреты обычно требуется ротировать.
Технический аудит не равен судебной экспертизе
Досудебный технический разбор
Помогает понять состояние проекта, сформировать вопросы подрядчику, выбрать доказательства, оценить rescue и подготовить позицию. Его процессуальный вес зависит от формы документа и обстоятельств.
Судебная экспертиза
Назначается судом в процессуальном порядке. Вопросы, объекты исследования и эксперт определяются в рамках дела. Наш предварительный аудит не подменяет её.
Реальные дела, где техническая экспертиза была решающей
А60‑65155/2024
Эксперт разделил дефекты вёрстки и программирования; часть заявленных недостатков не относилась к предмету договора, учитывался доступ третьих лиц и срок предъявления претензий. Постановление от 07.05.2026.
А40‑280334/2022
В споре о веб‑разработке исследовались макеты, структура сайта и результаты по нескольким заказам; техническое исследование сопоставляло фактически выполненные элементы с договором и заданием. Постановление от 15.02.2024.
Что должно быть в полезном техническом выводе
| Неудачно | Рабочая фиксация |
|---|---|
| «Бот не работает» | На версии X при команде Y система возвращает Z вместо результата из п. 4.2 ТЗ; приложены шаги, лог и видео. |
| «CRM не интегрирована» | Webhook вызывается дважды, что приводит к дублированию сущности; сохранены request ID и журнал CRM. |
| «Код неполный» | В переданном комплекте отсутствуют миграции и модуль, без которых сборка не проходит на чистом окружении. |
| «Всё надо переписывать» | Перечислены компоненты, которые пригодны для сохранения, компоненты с техническим долгом и компоненты, которые безопаснее заменить. |
Что получает юрист из технического аудита
Доказательная карта
Для каждого существенного пункта: источник требования, исследованная версия, способ проверки, фактический результат и приложенный материал. Это позволяет формулировать претензию конкретно.
Карта неопределённости
Отдельно отмечается то, что нельзя подтвердить: нет доступа к API, отсутствует архив старой версии, сторонний сервис недоступен. Мы не превращаем предположение в технический факт.
Частые вопросы о технической фиксации
Нужно ли нотариально осматривать сайт?
Зависит от характера доказательства и риска изменения информации. Нотариальная фиксация может быть полезна в отдельных ситуациях, но не заменяет техническую копию кода, базы и журналов, если спор касается внутренней работы системы.
Зачем считать SHA‑256 файла?
Хеш помогает идентифицировать конкретную копию и позже показать, что исследовался именно этот набор данных. Он не доказывает качество программы и используется только как элемент фиксации версии.
Можно ли провести аудит, если Git недоступен?
Да, но выводы будут ограничены доступными объектами: production, архивом, БД, логами, API и пользовательскими сценариями. Ограничение должно быть прямо указано.
Аудит скажет, сколько процентов проекта готово?
Можно посчитать долю проверенных требований, но это не всегда равно стоимости выполненной работы. Критическая функция и десять мелких функций имеют разную ценность, поэтому денежные выводы делаются отдельно.
Зафиксируем проект до изменений
Опишите проект и конфликт. Если доступы ещё есть, не удаляйте старую версию и не проводите миграцию до создания полной резервной копии.
Опишите вопрос — юрист разберётся
Напишите, что произошло, когда узнали и какой результат нужен. Остальное уточнит специалист.