Сдача проекта разработчиком: чек-лист инженера, а не PM

Проект считается закрытым, когда последний коммит ушёл в прод. Это рабочее определение для джуниора.

Для меня проект закрыт, когда я могу объяснить новому владельцу три вещи за 20 минут — и больше не получать звонки. Я научился этому не сразу. А после того, как один проект «вернулся» ко мне через 8 месяцев с вопросом, на который не было ответа ни в одном тикете.

Разница между «готово» и «закрыто»

«Готово» — это продакшен. Работает. Задачи закрыты. Договор выполнен.

«Закрыто» — это когда проект живёт без тебя. Когда следующий разработчик, следующий аналитик или сам клиент через год понимает, как устроено всё важное, без звонка тебе.

Разница маленькая на словах. На практике — полгода неожиданных ночных сессий.

У PM'а другие метрики. Сдали в срок, приняли акт, оплатили. Для него закрытие — административный момент. Для меня — технический и коммуникационный. Клиент получил продукт. Вопрос в том, кто теперь отвечает за то, что он работает.

Правильная сдача проекта разработчиком — это передача не кода, а понимания.

Что ты уносишь с собой, уходя с проекта

Уходя с проекта, ты забираешь три вещи. Клиент об этом не думает, потому что не знает, что они существуют.

Первое — контекст архитектурных решений. Почему сделано именно так. Какие варианты рассматривались. Почему headless, а не монолит. Почему Elasticsearch, а не просто SQL LIKE. Этот контекст не в коде. Не в git-истории. Он в голове.

Второе — карта опасных мест. Каждый проект в продакшене имеет три-пять точек, где изменения сломают что-то нетривиальное. Неочевидные зависимости. Кэш, который надо греть после деплоя. Bitrix-компонент, который работает только при определённой конфигурации OPcache. Следующий разработчик не знает об этих местах. Он найдёт их сам — в 3 часа ночи.

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

Все три пункта нужно передать явно. Иначе они остаются у тебя, и ты платишь за это своим временем.

Технический паспорт: три страницы, которые спасают ночь через год

Я называю это технический паспорт проекта. Три страницы максимум. Иначе не читают.

Страница первая: архитектурная карта. Сервисы, что с чем общается, где живут данные. Не схема для конференции — схема для человека, который завтра будет разбираться в инциденте. Там же: нестандартные решения с причинами. «Мы используем Redis не для сессий, а для очереди notify — потому что RabbitMQ был бы избыточен при данном RPS».

Страница вторая: карта опасных мест. Конкретные файлы, таблицы, компоненты. С пояснением: что сломается, если тронуть без понимания. Это не документация кода — это предупреждения для человека, который будет работать с кодом без тебя.

Страница третья: открытые решения. Компромиссы, которые остались в коде. Что планировалось переделать, но не переделали. С коротким пояснением почему. Это честность перед следующим разработчиком. И перед клиентом.

Три страницы. Пишу их за два-три часа в конце проекта. Один раз мне это сэкономило, по самым скромным подсчётам, часов сорок консультаций за следующий год.

Разговор с клиентом о закрытии

Большинство сдач проекта выглядят так: «Всё работает? Отлично. Оплата прошла? Хорошо. Удачи».

Я провожу отдельную встречу — закрытие. Час, иногда меньше. Темы: что передаётся и кому. Кто теперь отвечает за что. Где лежит технический паспорт. Что делать, если что-то сломается в первые 30 дней.

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

Отдельно: я фиксирую всё письменно. Не «чтобы прикрыться» — а чтобы через год не разбираться, кто что сказал.

Пример: что мы оставили после headless-миграции 28k SKU

Последний крупный проект — headless-архитектура для каталога с 28 000 SKU на Bitrix + Next.js. Когда мы закрывали проект, в технический паспорт вошло следующее.

Архитектурная карта: где живёт каталог (Bitrix iblock 40), как Next.js тянет данные через REST-прокси, почему не через GraphQL. Где Elasticsearch и что он индексирует. Схема инвалидации кэша — не очевидная точка: инвалидация идёт по вебхуку из Bitrix, если вебхук не пришёл — данные устаревают тихо.

Карта опасных мест: три пункта. OPcache на сервере Bitrix сбрасывается при деплое — это нормально. Но если конфигурация OPcache поменяется, Bitrix начинает подгружать компоненты каждый раз заново — TTFB уходит с 0.4s к 2.1s. Второй пункт: инвалидация кэша Next.js через ISR работает только при наличии переменной REVALIDATE_SECRET в окружении. Если переменная пропадёт — страницы перестанут обновляться без ошибки. Третий: Elasticsearch не синхронизируется с Bitrix-товарами автоматически при batch-импорте. Нужен явный триггер через cron или вебхук.

Открытые решения: синхронизация инвентаря между Bitrix и внешним WMS написана через polling — должна была быть через event-driven, не успели. Это следующий шаг при масштабировании.

Весь паспорт — две с половиной страницы. Клиент передал его следующей команде через четыре месяца. Мне не позвонили.

Когда я считаю проект закрытым

Последний коммит в проде — это начало закрытия. Не конец.

Проект закрыт, когда:

технический паспорт написан и передан
встреча-закрытие проведена, итоги зафиксированы письменно
у клиента есть ответы на три вопроса: кто поддерживает, где опасные места, что планировали но не сделали

Это занимает от одного дня до трёх. Зависит от размера проекта.

Я уже писал про то, как закрывать риски вместо тикетов в ежедневной работе. Это про другой момент — про финальную передачу. Большинство инцидентов, которые возвращаются ко мне через полгода, — это информация, которую я не передал в конце. Не потому что скрыл. Потому что думал, это очевидно. Это не очевидно.

Достаточно один раз получить звонок через восемь месяцев — и это становится привычкой.