Спасение застрявшего проекта: наш подход «сначала аудит»

Спасательные работы начинаются с письменного аудита, а не с кода. Прежде чем что-то трогать, мы отвечаем на бумаге на три вопроса: что действительно работает, что только выглядит работающим и что загорится на следующей неделе.

Категория «только выглядит работающим» удивляет людей чаще всего. Дашборд на моковых данных. Платёжный вебхук, который возвращает 200 и не делает ничего. Тесты, которые проходят, потому что проверки закомментировали перед дедлайном. Это не редкость: это обычный осадок проекта, застрявшего под давлением.

Мы никогда не переписываем в первую неделю. Переписывание, предложенное до аудита, — это догадка со счётом, и она выбрасывает единственный актив, который у застрявшего проекта ещё есть: накопленное знание о том, что бизнесу на самом деле было нужно, — закодированное, пусть и скверно, в существующем коде.

Клиент получает прямой отчёт с уровнями критичности и путь: либо стабилизировать на месте, либо сделать минимальную переработку, которая приносит пользу. Обычно первое: восстановить бэкапы, починить пограничные баги, сделать деплой воспроизводимым — и только потом обсуждать архитектуру. Проект, который можно выкатить во вторник днём без церемоний, уже наполовину спасён.

Тот же подход мы применяем к собственным продуктам — так у этого сайта появился свой аудит, и поэтому несколько утверждений, которые раньше стояли на этой странице, здесь больше нет.