Главная причина, по которой MVP-проекты сходят с рельсов — не техническая, а коммуникационная. Фаундер думает, что разработчик понял требование. Разработчик думает, что фаундер утвердил направление. Через шесть недель оба удивлены тем, что получилось.
Решение скучное: 30-минутное живое демо каждую неделю. Не статус-апдейт. Не сообщение в Slack. Демонстрация экрана с работающим софтом.
Я провожу еженедельные демо с каждым клиентом. Вот точный формат.
Формат
Длительность: 30 минут. Никогда дольше. Если занимает больше — скоуп на неделю был слишком большим.
Каденция: Один и тот же день, одно и то же время, каждую неделю. Четверг после обеда хорошо работает — даёт разработчику пятницу для отработки фидбека до следующего спринта.
Кто присутствует: Фаундер (или product owner) и разработчик. Больше никто, если они не принимают продуктовые решения.
Структура:
- Демо (15 мин): Разработчик показывает, что построено на этой неделе. Живьём, на реальном устройстве или стейджинг-URL. Не скриншоты.
- Фидбек (10 мин): Фаундер реагирует. «Да, правильно» / «Нет, кнопка должна делать X» / «Можем поменять порядок?»
- Следующая неделя (5 мин): Разработчик озвучивает, что будет строить. Фаундер подтверждает или переприоритизирует.
Что разработчик должен показывать
Показывайте работающие фичи, не прогресс. «Я работал над чекаутом» — это статус-апдейт. «Вот чекаут — я добавлю товар, пройду через оплату и покажу страницу подтверждения» — это демо.
Конкретно:
- Пройдите через фичу как пользователь
- Покажите на целевом устройстве (мобильном, если приложение mobile-first)
- Покажите крайние случаи: пустые состояния, длинный текст, медленное соединение
- Покажите, что НЕ готово: «Эта кнопка — заглушка, подключу на следующей неделе»
Что фаундер должен спрашивать
Не просто «выглядит хорошо». Спрашивайте:
- «Покажите, что будет, если [крайний случай]?» — пустая корзина, 50+ товаров, медленный интернет
- «Это финальный дизайн или заглушка?» — предотвращает предположения
- «Что самое рискованное на следующей неделе?» — поверхностит проблемы до того, как они станут проблемами
- «Что-то заблокировано или ждёт меня?» — разблокирует быстрее асинхронных сообщений
Записывайте фидбек во время демо. Отправьте списком в течение часа. Это создаёт бумажный след.
Красные флаги
«Покажу на следующей неделе»
Если фича была запланирована на эту неделю и не продемонстрирована — что-то пошло не так. Либо оценка была неверной (нормально — но обсудите), либо разработчик избегает показа незаконченной работы (ненормально — незаконченная работа, показанная рано, экономит время).
Скриншоты вместо живых демо
Скриншоты скрывают сломанные взаимодействия, медленную загрузку и проблемы адаптивности. Если разработчик регулярно показывает скриншоты, спросите: «Можем посмотреть живьём на стейджинге?»
«Работает, просто нужно подключить»
Значит UI есть, а бэкенд — нет. Или наоборот. «Подключить» — часто 40% работы. Не считайте неподключённые фичи готовыми.
Демо защищает обе стороны
Для фаундера: вы видите ровно то, за что платите, каждую неделю. Никаких сюрпризов на запуске.
Для разработчика: вы получаете фидбек до того, как строить дальше на неверных предположениях. Смена направления на 2-й неделе стоит 2 часа. На 8-й — 2 недели.
Я писал о скоупинге MVP для выхода за 12 недель и что происходит, когда модель Upwork ломается — обе проблемы предотвращаются еженедельными демо.
Минимально жизнеспособное демо
Если вы нанимаете разработчика и хотите ровно одну гарантию, вписанную в контракт, пусть будет эта:
Еженедельное 30-минутное живое демо работающего софта на стейджинге, каждый [день] в [время].
Всё остальное — таймлайн, скоуп, стиль коммуникации — вытекает из этого одного обязательства. Разработчик, показывающий вам работающий софт каждую неделю, не может скрыть проблемы. А проблемы, найденные рано — это проблемы, решённые дёшево.
Ищете разработчика, который проводит еженедельные демо по умолчанию? Напишите — каждый клиентский проект, который я беру, включает каденцию еженедельных демо с первой недели.