Функциональная схема приложения: как описать логику до разработки

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

Что показывает схема

• Роли пользователей: клиент, менеджер, курьер, администратор
• Модули или блоки функций: каталог, корзина, заказы, оплата, профиль, отчёты
• Основные потоки: путь пользователя от входа до результата
• Данные, которые передаются между блоками
• Внешние системы: оплата, учёт, SMS, карты, служба доставки
• Ключевые статусы и переходы между ними

Уровни детализации

Карта модулей

Верхний уровень: прямоугольники модулей и стрелки связей. Помогает оценить объём работ и разделить проект на этапы.

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

Для каждой роли — последовательность шагов. Клиент: открыл каталог, выбрал товар, добавил в корзину, указал адрес, оплатил, получил уведомление. Курьер: получил заказ, подтвердил, забрал, доставил, отметил оплату.

Схема состояний

Для важных сущностей — список статусов и разрешённых переходов. Заказ: новый, подтверждён, собирается, передан курьеру, доставлен, отменён. Отдельно указывается, кто может переводить в каждый статус и что при этом происходит: уведомление клиенту, списание остатка, возврат денег.

Как составить схему

1. Перечислите роли и для каждой запишите главные задачи одной фразой.
2. Опишите основной сценарий каждой роли по шагам.
3. Сгруппируйте шаги в модули.
4. Отметьте, где нужны данные из внешних систем и куда данные должны уйти.
5. Нарисуйте статусы ключевых сущностей.
6. Добавьте исключения: отмена, ошибка оплаты, отсутствие товара, повторная попытка.
7. Пройдите по схеме вместе с будущими пользователями.

Нотации и инструменты

Для бизнес-процессов распространена нотация BPMN, для сценариев и состояний — диаграммы UML. Но строгая нотация не обязательна: важнее, чтобы схему понимали все участники. Подойдут онлайн-доски и редакторы диаграмм, где можно рисовать вместе и оставлять комментарии.

Пример для сервиса записи

Роли: клиент, специалист, администратор. Модули: каталог услуг, расписание, запись, напоминания, оплата, отчёты. Сценарий клиента: выбрать услугу, выбрать специалиста, выбрать время, подтвердить, получить напоминание, прийти или перенести. Статусы записи: создана, подтверждена, перенесена, отменена клиентом, отменена салоном, завершена, неявка. Внешние системы: Telegram для уведомлений, платёжный сервис для предоплаты. Уже на этом уровне видны вопросы: можно ли записаться к специалисту без выбора услуги, что делать с предоплатой при отмене салоном.

Типичные ошибки

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

Как схема экономит деньги

Перерисовать стрелку на схеме легко, а переписать логику в готовом коде — долго и дорого. Многие переделки возникают потому, что заказчик и команда по-разному понимали один и тот же сценарий. Схема выносит это расхождение на поверхность до начала программирования.

Что делать со схемой дальше

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