Когда ты как бы Игорь, но ютубу виднее 🙂

Спасибо, получилось. Вот...

Добрый день!
Подскажите пожалуйста, есть ли какие-то инструменты, методики или наработки, которые помогают собрать и описать всю информацию по огромному проекту? Мне нужно свести базу знаний по всему проекту, который включает в себя разные департаменты.
Сегментарно я уже собрала инфу, а сейчас на стадии «я даже не знаю, что не знаю».  
Буду благодарна за советы  или рекомендации.

Да просто разошлите всем участникам проекта письмо: «Уважаемые коллеги, МНЕ НУЖНО чтобы вы прислали мне ВСЮ ИНФОРМАЦИЮ по такому-то проекту.»
Потом прям почтовый ящик пакуйте в .zip и раздавайте всем желающим на флешке.
Если информация окажется НЕ ВСЯ - значит какой-то уважаемый коллега не выполнил просьбу, хотя вы чётко указали, что ВАМ НУЖНО.
Следует его показательно наказать.

Идея хорошая) А если мы рассмотрим ситуацию, когда сторонние люди не могут описать сразу все и это не является их приоритетной задачей? Я прихожу с какими-то конкретными вопросами. Мне на них отвечают, но спустя время выясняется, что есть ещё вагон информации, о которой я не спросила (потому что даже не знала) и мне не рассказали (ну ты же об этом не спрашивала).
Логичным выглядит собирать все итерациями короткими. Всплывает что-то - идёшь с новыми вопросами уже. Но вдруг есть другие способы?

Я жонглирую открытыми вопросами и провокациями + постоянно сверяюсь с инфой из других источников (код, реестры кода/проектов/тикетов, инфа от других людей)
Много даёт поиск противоречий в информации и раскапывание того что там на самом деле

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

Есть ещё клевый вопрос, после того, как опросите по вашему списку. Называется: "О чем я ещё забыл у вас спросить? Что ещё, по вашему мнению, важно, а я это упускаю? Может быть, что-то очень очевидное? "
Иногда даёт очень хороший результат

Дельный совет, спасибо)

Звучит интересно) обязательно попробую🙂

Буду рада, если и у вас он "выстрелит"

+ за эту технику. Круто срабатывает и в проблемных продуктовых интервью

Начните с создания глоссария, постепенно переходя к реестру процессов, попутно создавайте ER-диаграммы (не нужно точно следовать структуре таблиц в БД)
Для особо сложных процессов рисуйте sequence диаграммы.
Если проект большой, как вы говорите, то вас ждёт увлекательный год (примерно), полный открытий.

Готовьтесь к тому, что на многие вопросы ответов не будет и разработчикам придётся прибегнуть к реверс инжинирингу.

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

Спасибо за информацию! Очень полезно.

Внезапно оказалось, что пишу с личного аккаунта. Продолжу с рабочего.

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

Нашей команде очень подошёл подход "Документация как код". Т.е. разработчики пишут свой код, документируют его, аналитик в формате RST в том же репозитории пишет документацию, сотрудники тех. поддержки как и саппорт в формате RST пишут нюансы своей работы и в конечном итоге автоматически всё это конвертируется в html, заливается на сервер с документацией и знания всех членов команды теперь доступны из единого и удобного интерфейса.

В качестве генератора документации мы используем Sphinx.

Отличный подход! А что вы бы посоветовали, если все эти процедуры нужно провести отдельно взятому человеку? В условиях, что никто из специалистов документацию сам не пишет? Ну или практически не пишет.