Длинный проект редко остается внутри одного разговора, одного человека или одной команды. Меняются исполнители, заканчивается контекст чата, подключаются AI-агенты, появляются новые версии файлов. Самый неприятный сценарий - когда все материалы физически сохранились, но никто уже не помнит, почему проект устроен именно так.
Файлы не сохраняют историю решений
Можно передать последний HTML, архив исходников и несколько скриншотов, но этого недостаточно. Новый исполнитель увидит текущее состояние и закономерно начнет улучшать то, что кажется странным. При этом странность могла быть результатом пяти предыдущих экспериментов.
Без истории решений проект легко откатывается к уже проверенным неудачным вариантам.
Нужен документ состояния, а не пересказ всей переписки
Мы регулярно делаем handoff-документы в Markdown при переходе между чатами и этапами. Их задача не в том, чтобы сохранить каждую реплику. Наоборот, хороший handoff должен сжать историю до текущего рабочего состояния.
В нем важны цель проекта, актуальная версия, принятые решения, известные проблемы, незавершенные правки, расположение ключевых файлов и ограничения, которые нельзя потерять.
Особенно важны отрицательные знания
Обычно документация хорошо описывает, что нужно сделать, и плохо хранит, что уже пробовали и отвергли. Между тем именно эта информация экономит больше всего времени.
Например: масштабирование колесом удалили из-за конфликта со скроллом; автомобиль нельзя снова разворачивать; конкретный фон не должен перекрывать чертеж; стек разработки не нужно навязывать команде. Если такие решения не записать, новый исполнитель может вернуть их из лучших побуждений.
Ссылки должны вести к актуальным артефактам
Еще одна типичная проблема - документ формально есть, но ссылается на старую сборку. Поэтому handoff должен явно называть актуальный файл и версию, а также отделять действующие материалы от исторических.
Это особенно важно, когда проект состоит из нескольких архивов, прототипов и вспомогательных спецификаций. Нельзя заставлять следующую команду угадывать, какой из них главный.
Передача должна описывать границу следующей работы
Хороший документ заканчивается не историей, а точкой продолжения. Что уже принято? Что еще не сделано? Какие изменения обсуждались, но не успели попасть в сборку? Что нужно проверить первым?
Такая граница позволяет новой команде продолжить проект, а не начинать повторный аудит всего мира.
Handoff полезен даже если команда не меняется
Через несколько недель собственный проект тоже становится чужим. Решения, которые казались очевидными, забываются. Поэтому документ передачи полезен не только при смене исполнителя. Это периодический снимок состояния системы.
Для проектов с AI это особенно заметно: каждый новый контекст фактически является новым участником команды, которому нужно быстро восстановить картину без доступа ко всей истории размышлений.
Мы начали относиться к качественной передаче как к отдельному результату этапа. Код, макет или прототип отвечают на вопрос "что сейчас существует". Handoff отвечает на другой вопрос - "почему оно такое и откуда продолжать". Для длинного проекта второй вопрос иногда оказывается важнее первого.