Что подготовить до начала разработки цифрового продукта

Сформулируйте изменение, а не набор экранов

Цель «сделать мобильное приложение» ничего не говорит о результате. Полезнее описать, что должно измениться после запуска: сократится время обработки заявки, клиент сможет выполнить операцию без менеджера, редакция будет быстрее публиковать материалы.

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

• какой процесс сейчас работает плохо
• для кого ситуация должна измениться
• какое поведение пользователя считается успехом
• каким показателем можно проверить результат

Опишите пользователей и реальные сценарии

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

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

Проведите инвентаризацию контента и данных

Контент редко появляется сам к моменту запуска. Нужно определить владельцев текстов и изображений, объём миграции, источники данных и формат обновления. Для нового сайта полезно заранее собрать примеры самых длинных заголовков, таблиц и нестандартных материалов.

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

• какие материалы переносим, переписываем или удаляем
• какие URL и SEO-данные необходимо сохранить
• кто отвечает за актуальность каждого типа данных
• есть ли персональные или чувствительные данные

Соберите информацию об интеграциях

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

Если API нет или он ограничен, это может изменить архитектуру, оценку и состав первого релиза. Такие ограничения лучше обнаружить до того, как дизайн будет утверждён вокруг недоступного сценария.

Определите границы первого релиза

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

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

Один завершённый путь пользователя полезнее десяти наполовину работающих разделов.

Назовите ограничения вслух

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

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

Что отправить команде для первой оценки

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

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