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