Начните с действия, ради которого нужен продукт
У приложения легко придумать десятки экранов: профиль, история, уведомления, кабинет администратора, рекомендации. Но список экранов не отвечает на главный вопрос: что человек сможет сделать лучше после запуска?
Сформулируйте один маршрут: «Клиент выбирает услугу, передаёт исходные данные и получает подтверждение записи». Укажите, кто этот клиент, в какой ситуации приходит и что считается завершением. Покупатель, поставщик, курьер и партнёр могут участвовать в одном продукте, но каждой роли нужны свои действия и права. Проверьте, какие из них необходимы для первого законченного сценария, а какие можно добавить позже.
Запишите, как задача решается сейчас. Это даст основу для сравнения: сколько шагов, ожидания и ручной работы было до появления приложения.
Соберите целый маршрут
Первая версия может быть небольшой, но пользователь должен пройти выбранный путь до результата. Для записи недостаточно показать календарь: нужно проверить доступность времени, сохранить выбор, сообщить статус и дать сотруднику увидеть обращение.
Разделите функции на три группы: без них сценарий не работает; они нужны для безопасной эксплуатации; их можно добавить после проверки спроса. Авторизация иногда относится к первой группе, иногда вообще не нужна. Резервное копирование, контроль доступа и обработка ошибок могут не впечатлять на демонстрации, но остаются необходимой частью работы.
Часть внутренних операций допустимо выполнять вручную. Например, нестандартную заявку может согласовать сотрудник. Важно обозначить эту границу и не показывать автоматическое подтверждение там, где решения ещё нет.
Проверьте самое дорогое предположение
У каждого проекта есть неизвестность, способная изменить стоимость. Клиенты готовы проходить новый процесс? Учётная система позволяет получать нужные данные? Можно ли рассчитать цену по правилам?
Для пользовательского сценария проверкой может стать интерактивный прототип и несколько предметных разговоров. Для интеграции — получение тестовой записи из существующего сервиса. Для расчёта — проверка правил на согласованных примерах.
Результат должен влиять на решение: продолжить, упростить маршрут или отказаться от дорогой части. Красивый прототип сам по себе не подтверждает платёжеспособный спрос и готовность внешней системы к подключению.
Договоритесь, что значит «готово»
В задании нужны роли, источники данных, интеграции, объём контента, поддерживаемые устройства и зависимости от клиента. Отдельно перечислите то, что переносится на следующий этап.
Критерий «работает удобно» слишком расплывчат. Лучше: тестовый пользователь создаёт заявку, видит её статус, сотрудник получает карточку, повторное нажатие не создаёт дубль. Добавьте проверку неверных данных и недоступности внешнего сервиса.
Новые идеи сохраняйте в отдельном списке. Включайте их в текущий объём после обсуждения влияния на цену и срок. Так замысел развивается, а выпуск остаётся управляемым.
Спланируйте решение после запуска
До старта определите, кому покажете продукт и какое поведение будете наблюдать. Для сервиса записи — сколько людей начали путь, завершили его и потребовали помощи. Для внутреннего инструмента — удалось ли сотруднику выполнить операцию и сколько вмешательств понадобилось.
Назначьте дату разбора результатов и ответственного. Условия следующего этапа могут включать подтверждённую потребность в повторном использовании и отсутствие критических препятствий в основном маршруте.
Бюджет запуска должен включать проверку, исправления и передачу доступа владельцу. Если всё потратить на первую демонстрацию, до пригодного к работе продукта может остаться неоплаченный этап.