All streams
Search
Write a publication
Pull to refresh

Comments 12

Было бы неплохо где-то в начале статьи более внятно написать что же вы пытались сделать, просматривая по диагонали трудно это понять зато бросается в глаза длинное введение :)

В целом же абсолютно согласен - MVP в идеале нужно выкатывать за месяц или даже за пару недель - и начинать опрашивать публику насчет полезности, жизнеспособности, желаемых фичей. Не беда если сначала найдут десятки поводов придраться - но зато будут радоваться когда вы их быстро правите.

Про фичи которые оказываются не нужны - это классическая прям проблема многих начинаний. 90% времени потрачено на то что 90% пользователей даже не заметят.

А какие варианты есть (бесплатные) по опросе публики и фидбэку?

Самое банальное, что я встречал -- кнопка в интерфейсе, ведущая на гугл/яндес-форму

Точно! Простое, быстрое и эффективное решение — именно то, что нужно!

Вот несколько бесплатных (или почти бесплатных) способов собрать фидбэк на MVP:

1. Опросы и формы

  • Google Forms – простой и бесплатный инструмент для сбора ответов.

  • Typeform (бесплатно до 10 ответов в месяц) – более интерактивный и удобный для респондентов.

  • Tally.so – бесплатный аналог Typeform с неограниченным количеством ответов.

2. Соцсети и коммьюнити

  • Reddit, T, I, VK, Facebook-группы, Telegram-чаты – ищите тематические сообщества и спрашивайте мнение.

  • Indie Hackers, Product Hunt (Discuss) – площадки, где можно получить фидбэк от стартаперов и первых пользователей.

3. Пользовательские интервью

  • Calendly (бесплатно для простого расписания) – чтобы записывать респондентов на короткие звонки.

  • Discord / Telegram – можно быстро пообщаться с заинтересованными людьми.

4. Анализ поведения

  • Hotjar (бесплатно до 35 сессий/день) – запись действий пользователей на сайте.

  • Google Analytics – смотрите, какие страницы популярны, а где люди уходят.

5. Ранний доступ и тестирование

  • BetaList – бесплатно заявить о предстоящем запуске и собрать подписчиков.

  • Discord-сервер – создать канал для первых тестировщиков и обсуждать идеи.

Главное: не ждите идеала – просто спрашивайте, слушайте и быстро итерируйте! 🚀

Спасибо за комментарий!

Действительно, стоило чётче обозначить цель статьи в начале — учту на будущее.

Интересный факт — что такое mvp понимаешь только с провалом проекта) Welcome to the club, body

Ахах, так и есть! Настоящий MBA (Master of Broken Apps) получаешь только с опытом 😅

Основная причина провала мвп - это его услуги и функциональность, которые даром не нужны.

Как мне кажется, это связано с мировоззрением основателя: он воспринимает проект не как стартап, а как уже состоявшийся успешный бизнес. В таких условиях крайне сложно выпустить на рынок минимальную версию продукта (MVP), составляющую даже 0,5% от его изначального видения, не говоря уже о меньшем.

Спасибо за опыт. Есть вопрос - как во время остановиться и переписать проект нормально, когда mvp пошло в прод и начало обрастать фичами? Ведь плохо заложенный фундамент в виде быстрых решений - в перспективе проблемы на рабочей версии. После mvp даем срок заказчику на тест и потом пишем нормально новый проект? Просто это частая проблема, когда mvp становится боевым проектом.

Рад оказаться полезным!

Отличный вопрос! Действительно, многие сталкиваются с тем, что MVP, ориентированный на быстрый запуск, превращается в legacy-монстра. Именно поэтому огромное количество компаний, имеющих что-либо в digital-пространстве, являются таковыми (legacy-монстрами) — либо мне просто везло, и в крупных компаниях регулярно встречалось огромное количество плохого кода.

Здесь я вижу два пути.

Первый — принять это и продолжать работу. Ведь гораздо приятнее иметь компанию с огромной, но прибыльной кодовой базой, чем стартап с чистой архитектурой, но бесполезный и непопулярный.

Второй вариант: если стадия MVP пройдена и составлен план реализации функционала, можно выделить 2–8 недель перед внедрением новых функций на полный рефакторинг, заложить правильную архитектуру и подготовить проект к масштабированию (в некоторой степени игнорируя KISS и YAGNI). Однако обычно этот вариант неприменим, так как сроки горят, и людям (или заказчику) нужны новые функции.

Но также существуют и другие варианты (которые на моей практике встречались редко):

  1. На стадии MVP или даже PreMVP заложить необходимое количество ресурсов на "техдолг".

  2. Писать MVP с расчётом на масштабирование.

  3. Если проект уже в продакшене, но кодовая база слабая, можно переписывать его постепенно (например, через Strangler Pattern — замещая модули по очереди). Этот вариант наиболее жизнеспособный (по мнению автора).

P.S. Это исключительно моё субъективное мнение, и я ничего не пропагандирую, в том числе и legacy-код.

Sign up to leave a comment.

Articles