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

Короткий ответ: к старту разработки нужны шесть вещей — сформулированная бизнес-цель с измеримой метрикой, описание пользовательских сценариев, контент (тексты, товары, услуги, цены), доступы к вашим системам, принятые организационные решения и один ответственный с вашей стороны. Последний пункт важнее всех остальных: проекты умирают не от сложной техники, а от недельных пауз на каждое согласование. Ниже — чек-лист по каждому блоку.

Цель и метрика: зачем бизнесу приложение

«Хотим приложение» — не цель. Цель звучит как изменение числа: «перевести 30% записей из телефона в онлайн», «поднять повторные покупки с 1,4 до 2 в год», «разгрузить регистратуру на 20 часов в неделю». Из цели выводится метрика успеха первой версии — одна, максимум две. Она же ответит на вопрос «окупилось ли» через три месяца после релиза.

Если цель не формулируется — это нормальная ситуация для старта, но тогда первым шагом идёт продуктовая диагностика, а не разработка. Проверьте также, не решается ли задача более простым инструментом: сайтом, CRM или Telegram-каналом — критерии есть в статье о том, когда малому бизнесу нужно приложение.

Сценарии и контент

Сценарий — это история от первого экрана до целевого действия: «клиент открывает приложение → выбирает мастера и время → оплачивает → получает напоминание». Таких историй у первой версии обычно три-пять. Не нужно писать их «правильно» — достаточно описать своими словами, как процесс устроен сейчас и что должно измениться. Формализацией займётся продуктовая команда на этапе брифа или ТЗ.

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

Доступы и интеграции

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

Люди и решения

Назначьте одного человека с правом принимать решения по продукту — и заложите его время: обычно 3–5 часов в неделю на согласования, демо и ответы. «Коллективное руководство» чатом директоров — гарантированная остановка проекта на первом же разногласии. Второе решение — бюджетное: определите вилку, которую готовы инвестировать, и формат работы. Мы работаем в двух форматах — заказная разработка и партнёрство; рамка бюджета помогает сразу предложить адекватный состав.

Чек-лист готовности к старту

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

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

Частые вопросы