Хочу поделиться рабочим лайфхаком: как грамотно организовать документацию и постановку ТЗ, чтобы через полгода всё не превратилось в хаос из тикетов и устаревших тестов.
Мы привыкли к стандартной схеме:
Новые требования → Новое ТЗ → Доработка кода → Обновление тестов.
И вот здесь подвох: каждый раз пишется новое ТЗ, хотя проект остаётся старым. В итоге теряется целостность, а документация превращается в разрозненные куски.
💡 Решение простое: относиться к документации как к проекту.
Подобно тому как разработчик разбивает проект на классы, аналитики создают документы, описывающие сущности, бизнес-процессы, взаимодействие с внешними системами.
-И тут, самое главное, вместо написания нового ТЗ добавлять изменения прямо в существующие документы.
📍 Что это даёт?
1. Сохраняется целостность требований.
2. Документация становится настоящей «точкой истины».
3. ТЗ для разработчиков появляется автоматически — достаточно сравнить две версии документа.
Так мы получаем прозрачный процесс, удобную базу знаний для всей команды и избавляемся от «чёрного ящика» с кодом.
Вопрос к вам: как в ваших командах ведётся документация — по старинке или как проект? 👀