🏚 Ты пришёл на проект, а документации нет. 5 шагов, чтобы выжить и всё описать Привет! Представь: ты выходишь на новый проект. Команда встречает тебя словами: «Документация? Ну, где-то что-то было, но оно устарело. А код смотри, там всё понятно». Знакомо? Для многих аналитиков это стресс. Для меня когда-то тоже. Но потом я понял: отсутствие документации — это не катастрофа, а твой карт-бланш. Ты можешь не разбирать чужие ошибки, а выстроить всё с нуля так, как удобно тебе и команде. Главное — знать, с какой стороны подходить к этому "монстру". Личный пример: На одном проекте мне досталась система, которой было 10 лет. Документации ноль, ключевой разработчик уволился год назад, а код помнят только два сеньора, которые уже одной ногой на выход. Первое желание было — сбежать. Второе — сесть в позу и начать требовать документы у заказчика. Не помогло. Тогда я пошёл другим путём. Взял блокнот, подошёл к одному из сеньоров и сказал: «Слушай, я понимаю, что ты занят. Но если я буду задавать тебе тупые вопросы каждый час — мы оба сойдём с ума. Давай так: я сейчас пишу список того, что мне нужно понять. Ты помечаешь, что можешь объяснить, а я потом сам копаю код и прихожу только с уточнениями». Он выдохнул и согласился. Мы разбили систему на модули и за месяц по кусочкам восстановили архитектуру. Через полгода у нас была актуальная документация, которой пользовалась вся команда. Вот алгоритм, который родился из того опыта. 🗺 1. Составь карту "белых пятен" Не пытайся объять необъятное. Сядь и выпиши всё, что тебе нужно узнать, чтобы начать работать. Раздели на категории: ▫️ Что точно знают люди (можно спросить у команды). ▫️ Что можно вытащить из кода (структура БД, API, логика). ▫️ Что знает только бизнес (бизнес-правила, цели, логика процессов). ▫️ Что никто не знает (зона риска, требует исследований). Этот список станет твоей дорожной картой. 🕵️‍♂️ 2. Используй "метод археолога" Не задавай общие вопросы. Конкретизируй. Вместо «Расскажи, как работает модуль Х» спроси: «Я вижу в коде функцию Y. Для чего она нужна? Какие данные принимает и откуда?». Копай слой за слоем. Код — это твой главный источник правды (даже если он страшный). 📝 3. Фиксируй сразу, а не потом Увидел что-то новое в коде? Услышал объяснение от коллеги? Сразу записывай. Не надейся на память. Используй Wiki, Notion, Confluence — что угодно, лишь бы было доступно команде. Даже если запись будет корявой, её можно потом отредактировать. Главное — не потерять. 🤝 4. Преврати команду в соавторов Не будь "одиноким писцом". Вовлекай разработчиков в процесс. Например, после того как ты что-то задокументировал, покажи им: «Я тут набросал схему модуля, посмотрите, всё ли так?». Люди охотнее поправят готовое, чем будут писать с нуля. И чувствуют причастность. 🎁 5. Показывай пользу документации для команды Разработчики не любят писать документы, потому что не видят в этом пользы для себя. Покажи им обратную связь. Например: «Я описал, как работает этот кусок кода. Теперь, когда придёт новый человек, ему не надо будет дёргать вас. Он просто прочитает». Или: «Я зафиксировал бизнес-правила. Теперь, если прилетит изменение, мы сразу поймём, где и что править». Когда команда видит, что документация облегчает им жизнь, они начинают помогать. 🎓 Суть не в том, чтобы восстановить документацию "потому что так надо". Суть в том, чтобы создать живой, полезный инструмент, который помогает команде работать быстрее и меньше ошибаться. А отсутствие документов на старте — это просто отсутствие мусора, который мешал бы тебе построить своё. Вопрос к вам: А вам приходилось разбираться в системах без документации? Какой был самый неожиданный источник информации? Или, может, есть история про "легендарного разработчика, который уволился и унёс всё в голове"? Делитесь в комментариях! #BA #SA