Всем привет)
Я Катя и я — аналитик (звучит немного как диагноз, возможно так оно и есть). Честно, я думала, что эта тема уже довольно очевидна для всех, но за этот год в разных проектах и на разных митапах я получила много подтверждений, что тема все еще очень болит. «Это же бюрократия, у нас и так всё работает!» / «Документация — это отлично, но у нас есть задачи поважнее» / «Катя, я пришла на проект, а у них ничего, а у нас аудит»

Эти фразы и еще много подобного я слышала так много раз, что кажется, время этой статьи пришло)

Мой путь от скептика к, как меня в шутку называют коллеги, «документатору‑злодею» выглядит так:

За 10 лет в ИТ меня несколько раз пытались «перевоспитать» (иногда это насилие случается до сих пор): убедить, что документация — это пустая трата времени. Были проекты с госзаказчиками, где документы существовали только для отчётов:

• ТЗ на 50 страниц, написанное в ворде, которое никто даже из заказчиков не читал.

• Спецификации в экселе, которые сломались при обновлении или не открывались из‑за устаревших версий. Или случайно изменялись в процессе кем‑то, но никто этого не заметил.

• Инструкции в папке «Архив_удалить».... можно продолжать до бесконечности.

Когда я была джуном — я почти купилась. Ну как не поверить, когда вся команда взрослых специалистов говорит, что «Это нам не надо»?

И жило это во мне ровно до тех пор, пока один из проектов не рухнул — не из‑за бага, не из‑за плохого кода, даже не из‑за плохой аналитики, а потому что ключевой сотрудник ушёл, и никто не знал, почему API X не используется, и вообще, что именно мы сделали и должны доделать.

С тех пор я изменилась. И сейчас я не просто за документацию — я за правильную документацию!

Что вообще относится к проектной документации? Для кого она нужна? (И почему вы ошибаетесь, если думаете — только для менеджеров или злых аналитиков)

Наверняка каждый хоть раз в карьере сталкивался с мнением: «Если не понятно, кому нужна документация — она не нужна».
Спойлер — это ложь и провокация, не видитесь на это! Вы просто ещё не столкнулись с ситуацией, когда документация вас спасёт (а она вас спасет и ни 1 раз!).

Вот кому реально нужна документация:

А вот самый страшный случай — когда документация пишется только потому, что так сказали...ну например, Заказчики.

Пример:

«Надо сделать 20 страниц по ГОСТ 34.601–90» — в 2026 году, в стартапе, с React + GraphQL“....и ты такой — оно нам точно надо? ”

Правильно мыслишь!
Это не адекватная документация. Это бюрократический монстр. Она не помогает, она убивает время. Тут пострадают все: и те, кто ее пишет, и те, кто ее должен «принять».

Документация = спасательный круг

Проектная документация не формальность и не статья на конфе для галочки, тем более не просто стопка бумаги для растопки!
Документация — это один из твоих главных инструментов устойчивости: проекта, продукта, команды, ну и что уж там — твоей психики!

Функции документации казалось бы очевидные, но, видимо, всё ещё не для всех (увы):

Документация — это не «надо сделать для галочки». Это «сделаю сейчас, чтобы не утонуть потом».

А что делать, если на проекте ничего не зафиксировано?

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

Ладно, когда так мыслят джуны, но когда это концепция лидов, то у меня много вопросиков. Так или иначе, по моему опыту примерно в 70% стартапов и средних проектов документации почти нет. Самое удивительное, что даже в биг техе это случается, но там возможен и обратный грех — чрезмерно избыточная и запутанная документация — потому что 100 веков назад Вася согласовал такой подход и теперь мы все так делаем.

Правильный подход — взять и начать с малого, так сказать «Есть слона по частям». Твоя первая цель — принятие и создание минимальной адекватной документации, первого документа, где ты зафиксируешь базовые знания о проекте/продукте/подходах команды.

Можно воспользоваться подходом к формированию MVD (Минимально жизнеспособная документация).

Не пиши 50-страничное ТЗ. Начни с 5 ключевых документов:

! Используй Confluence, Notion, Google Docs — не Excel, не Word, не PDF.

А теперь представь, что ты исследователь‑документатор и ты в поисках сокровищ (истины по проекту)

Проведи 10–15 коротких интервью (да‑да это только звучит как много):

• Сходи к разработчикам и уточни: «Как ты понимаешь, что фича готова?»

• Сходи к тестировщикам: «Что и как ты тестируешь? Как понимаешь, что работает корректно?»

• Сходи к поддержке: «Что чаще всего спрашивают пользователи?»

• Сходи к бизнесу: «Что для вас значит „успешно“?»

• Если еще и другие аналитики есть, то уточни: «как ты понимаешь что нужно дорабатывать и что то что сделала разработка соответствует тому, что бизнесу нужно?»

Записывай всё. Особенно, если кажется что что‑то очевидно и итак понятно всем. Именно это очевидно для всех с вероятностью почти 100% выстрелит команде и тебе лично в ногу, в самый не подходящий момент!

Еще один совет, который выручает: создай карту знаний

Нарисуй простую схему:

Пользователь → Действие → Система → Результат → Ответственный

Покажи команде и задай вопрос: «Это похоже на правду?»

Никогда не бойся спрашивать, даже если очевидно, даже если все кивали на прошлой встрече, даже если все сидят и не возражают! Хороший аналитик — это не тот кто и сам все знает или тот кто не спрашивает лишний раз! Хороший аналитик — это тот, кто не отстанет, пока не убедится что все понимает и это взаимно! Давайте просто зафиксируем мантру, что «Глупых вопросов НЕ существует!»

Сейчас ты не пишешь требования — ты восстанавливаешь реальность и причиняешь добро всем).

Преврати хаос в процесс и внедри минимальный workflow:

1. Любое новое требование — записывается в общий документ.

2. Любое решение — фиксируется с датой и именем.

3. Любое изменение — обновляется в документе.

Постепенное улучшение — твой главный инструмент

Не жди идеальной документации за один день или за эту неделю. Добавляй по 1–2 пункта в неделю — это лучше чем ничего! Через 2 месяца — у тебя будет живая, полезная, используемая документация.

Как мы ведём документацию в моей команде

Мы пришли к 7 правилам, которые работают:

1. Сквозная система знаний — всё в Confluence. Никаких Excel, Word, PDF.

2. Формат требований — строгий шаблон. Кросревью при онбординге — ускорило согласования на 40%.

3. Иерархия и статусы — Драфт → Согласовано → В работе → Реализовано.

4. Прослеживаемость — ЗНИ → Бизнес‑требование → Функциональное требование → Задача разработки → Тест → Инструкция.

5. Фиксация коммуникаций — Мы — душнилы. Пишем повестки, итоги, договорённости. В реестре.

6. Оценка ROI — Каждое требование: «Зачем бизнесу это нужно?» — и если нет ответа — не делаем.

7. Версионность — Изменил? Обновил? Написал: «Что поменялось, когда, почему». Спасает при спорах.

В заключение

Бюрократия — когда документы пишут ради формальности. Спасательный круг — когда документы пишутся, чтобы не утонуть, особенно в Agile проектах.

Ты не пишешь документацию, потому что «надо». Ты пишешь её, потому что не хочешь, чтобы твой проект утонул в хаосе изменений.

Документации не надо бояться! Пусть боятся тебя с документацией!