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