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

Описание контекста и проблемного поля

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

Карта заинтересованных сторон

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

Пользовательские сценарии и User Stories

Основной артефакт, который определяет будущую функциональность, — это набор пользовательских сценариев. Я описываю шаги пользователей, их цели и ожидаемый результат. На основе сценариев формирую User Stories с критериями приемки. Эти материалы служат исходной точкой для разработки, тестирования и планирования релизов.

Функциональные и нефункциональные требования

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

Прототипы и схемы пользовательских интерфейсов

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

Архитектурные схемы на уровне анализа

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

Карты процессов и диаграммы потоков данных

Если продукт связан с несколькими ролями или системами, я обязательно фиксирую карту процессов. Она позволяет увидеть, как данные проходят через систему, какие этапы автоматизируются, где возникают точки контроля, а где может появиться узкое место. Для технических команд я дополняю эти материалы диаграммами потоков данных.

План релизов и предварительная декомпозиция задач

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

Критерии приемки и Definition of Done

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

Риск-анализ и прогноз ограничений

В начале проекта я также готовлю список рисков: технических, организационных, продуктовых. Для каждого фиксирую вероятность, влияние и возможные меры реагирования. Такой документ помогает команде заранее готовиться к возможным проблемам и корректировать план при необходимости.

Итоговый набор артефактов как опора для команды

В целом набор артефактов зависит от масштаба продукта, но я всегда стремлюсь создать прозрачную структуру: контекст, требования, сценарии, визуализацию, архитектуру, риски и план. Этот комплект обеспечивает управляемость проекта, позволяет быстрее согласовывать решения и формирует общее понимание того, что именно мы создаем и зачем.