1. Опишите проблему и необходимое изменение
Опишите происходящее сегодня наблюдаемыми словами. Кто начинает работу? Какая информация требуется? Где процесс замедляется, дублирует усилия, теряет видимость или создаёт предотвратимый риск? Приведите пример вместо ярлыка вроде «нам нужна панель управления».
Затем опишите желаемое операционное изменение. Например, команда видит один достоверный статус, завершает согласование без сообщений, готовит отчёт из управляемых данных или предоставляет клиенту целостный путь самообслуживания. Не обещайте числовой результат до появления базовой линии.
Зафиксируйте, почему задача важна сейчас. Срок, изменение бизнеса, растущий объём, разрушающийся обходной процесс или новая потребность клиента влияют на последовательность и допустимый первый масштаб.
2. Нанесите на карту пользователей, решения и исключения
Перечислите людей, которые выполняют, согласовывают, поддерживают работу или зависят от неё. Одних должностей недостаточно: опишите, что каждый должен узнать или завершить. При необходимости включите клиентов и партнёров и укажите владельца бизнес-процесса.
Проследите типичный процесс от события до результата. Отметьте передачи, согласования, задержки, параллельные записи и места человеческого суждения. Затем добавьте исключения: недостающую информацию, дубликаты, изменения после согласования, недоступные системы и случаи эскалации.
Такие сценарии являются более сильной основой для дизайна и приёмки, чем плоский перечень функций. Они показывают, где уместна автоматизация, а где продукт должен поддержать человека, а не заменить решение.
3. Определите системы, данные и ограничения
Назовите используемые инструменты и записи, включая таблицы и неформальные каналы. Для каждого важного источника уточните владельца, актуальность, доступ и систему, которая должна остаться авторитетной. Известные API, выгрузки и ограничения поставщика полезны, но при необходимости исследуются во время начального этапа.
Опишите ограничения, способные изменить дизайн: права, конфиденциальность, хранение, языки, доступность, устройства, связь, хостинг, закупки, сроки и внутреннюю поддержку. Ограничение — не просто техническое препятствие; оно может определять, что значит пригодный продукт для организации.
Отделите подтверждённые факты от предположений. Это делает неопределённость видимой и позволяет запланировать точечное исследование или технический тест вместо того, чтобы встроить догадки в масштаб проекта.
4. Определите минимальный полезный выпуск
Минимально жизнеспособный продукт должен быть целостной частью ценности, а не набором недоделанных экранов. Выберите одну группу пользователей, одно решение, один процесс или один сервисный результат, который можно довести от начала до конца. Укажите, что сознательно исключено и какие факты оправдают расширение.
Формулируйте приёмку наблюдаемым языком: пользователь завершает задачу с нужными правами; запись синхронизируется с названным источником; исключение видно ответственному; отчёт прослеживается до исходных данных. Слова «современный», «умный» и «простой» бесполезны без проверяемого определения.
Заранее решите, как собирать факты после выпуска. Это могут быть доля завершений, усилия на исправление, обращения в поддержку, время процесса, качественная обратная связь или категории сбоев. Метрики должны помогать следующему решению, а не служить красивой отчётностью.
- Решать один полный и ценный процесс
- Делать важные исключения и состояния отказа пригодными для работы
- Явно определять, что остаётся за границами выпуска
- Давать факты для следующего продуктового решения
5. Соберите бриф, который вызывает полезные вопросы
Объедините описание проблемы, результат, пользователей, примеры процессов, системы, заметки о данных, ограничения и гипотезу первого выпуска в одном кратком документе. Добавьте ответственных участников и реальный срок, если он существует. На подтверждающие материалы лучше дать ссылки, чем заполнять бриф скриншотами без объяснения.
Разговор с партнёром должен проверять этот бриф. Ожидайте вопросов о владельцах, исключениях, доступе, внедрении и условиях, при которых проект перестаёт быть оправданным. Ответственный партнёр может предложить настройку, интеграцию или меньшую перемену вместо полностью индивидуального продукта.
Результатом раннего исследования должно стать более ясное решение: что создавать первым, что исследовать, как продукт соединяется с текущей работой и какими рисками нужно активно управлять. Оно не должно давать ложную уверенность в неизменном списке функций.