и мазь от радикулита

я  бы начал с того апи, которое выставляется наружу.

Его проще  всего осмотреть, увидеть что там вообще используется и как оно живет.

я бы попросил доступ к продакшн логам, чтобы узнать6 что самое ценное и часто используемое. Остальное возможно не стоит внимания

Сочувствую, но у этой задачи нет правильного решения 🙂
Если не знать, кто, как и с какой целью будет расконсервировать, то невозможно понять, какой объем надо задокументировать.

Я бы быстро пробежался по выжившим участникам и сделал с ними интервью про самое сложное, подлое и неприятное в их опыте с проектом, и что они могут по этому поводу рассказать (причины, решения и тп). Это как книгу писать 🙂

Из чек-листа можно предложить только инструкции "как собрать", "как запустить" и "как использовать"

Я тимлид, поэтому опыт у меня уже собран 🌚

а, в смысле тебя попросили твою работу запаковать и положить на полку?

Запаковать, сделать чтобы работало хорошо без меня, и чтобы через три года можно было продолжить развитие

Тогда я немного удивлен вопросом, если честно. Кто же может лучше ТЛ знать, что надо знать о его проекте?

человек пришел делать продукт, а не консервировать его до восстановления финансирования

Я боюсь, что мне мой контекст может больше помешать, чем помочь

Для меня большинство вещей очевидно, понятно и прозрачно. Хочется какого-то строгого гайда как и что писать, чтобы из этого контекста вылезти

сваггер/джавадоки/подобное собрать. код должен быть хорошо задокументирован

> код должен быть хорошо задокументирован

никому код ничего не должен.

Хорошее документирование  кода в стартапе — вред и отставание от рынка.

не согласна, впоследствии загребешься потом с недокументированным кодом

Нужен баланс, да. Написать полдела, потом ещё поддерживать документацию в актуальном состоянии

Скажу про свой опыт. Я в разные годы принял и потом передал больше 10 здоровенных проектов, написанных левыми командами. Компания, в которой я работал, покупала их, распускала родные команды и передавала эти проекты моей команде. Потом я был вынужден передать все это другой своей команде. А потом третей. Там не было периода консервации, но во всех случаях был рестарт с другими совсем новыми людьми. Это чем-то похоже.

Когда я принимал проекты, то находился в роли расконсервирующего, так что вероятно это чем-то близко к твоей потребности. А поскольку я не все эти проекты потом тянул лично, то я собирал информацию от одних и отдавал другим, предполагая их потребности.

Танцевали во всех случаях от простого вопроса, что надо знать, чтобы быстро продолжить. В роли принимающего это легко. Попробуй "надеть эту шляпу" и подумать с позиции другого ТЛ, который придется расконсервировать

Я пока вижу это как-то так:
- Модуль за модулем прибраться в структуре проекта, выкинуть устаревшие вещи, пометить вещи, на которые нужно внимательнее посмотреть позже (неактуальная документация, устаревший код, штуки, которые могут стать скоро легаси)
- Обновить README, проверить его инструкции на чистой системе, убедиться, что покрыты основные кейсы и описан сценарий "как разрабатывать"
- Пройтись по всем внешним эндпоинтам и проверить актуальность документации для них. Описать странные юзкейсы, особенности работы, etc.
- Экспортировать трекер задач прямо в репозиторий 😈
- Пройти по всем модулям, задокументировать каждый, рассказать что часто меняется

> - Экспортировать трекер задач прямо в репозиторий 😈

это  очень грамотное решение

Очень многие куски кода ссылаются на трекер задач как на источник объяснения бизнес-логики, и я могу себе представить, что через N лет эти задачи уже пропадут

Хорошее начало. Дополню тем, что всегда оказывалось надо
1) общее описание архитектуры и принципов. Из чего вы исходили, когда что-то делали, как оно все должно работать вместе. Детали модулей можно почти всегда выяснить по коду, а вот общие принципы выявить тяжело;
2) наиболее проблемные области по текущему опыту. чтобы бы советовали сделать самим себе, если бы не прервались.
3) инструкция по расширению - грубо говоря, как добавить новую фичу или модуль

Сохранение всех задач, всех баг репортов, всех инцидентов, всей документации это было прямо обязательно, если передавать между конторами. Внутри конторы у нас все хранилось вечно. Если были какие-то форумы или иные каналы общения с пользователями/заказчиками - то их. В одном случае, сохранили всю почтовую переписку по проекту - из нее смогли потом многое уточнить. Сейчас я бы еще и все чаты выгрузил

В общем оказывалось, что важнее сохранить всю "первородную" документацию (оригиналы решений и обсуждений) и написать инструкцию по быстрому взлету (1-2-3), чем описать все частные детали. До последних часто вообще руки не доходили у новой команды - они часто все равно не точные (особенно если писались в спешке перед сдачей) или уже по коду проще разобраться было.

Все таки хотелось бы для себя понять путь эволюции средств коллективной работы над документами: 1. Текстовые и офисные файлы, обмен по почте;
2. Простые Вики
3. Онлайн редакторы
4. Опять Вики,  но посложнее
5. Гит
Что дальше?

@slystsev , а вы случайно не оформляли ваши соображения по этой теме в виде отдельной статьи? Я бы с удовольствием почитал!