Мне как человеку, который шарит за производство, а не продажи, было довольно интересно и полезно почитать, особенно 1 и 5 пункт, буду пробовать внедрять, спасибо!
Отличный вопрос! Действительно, многие сталкиваются с тем, что MVP, ориентированный на быстрый запуск, превращается в legacy-монстра. Именно поэтому огромное количество компаний, имеющих что-либо в digital-пространстве, являются таковыми (legacy-монстрами) — либо мне просто везло, и в крупных компаниях регулярно встречалось огромное количество плохого кода.
Здесь я вижу два пути.
Первый — принять это и продолжать работу. Ведь гораздо приятнее иметь компанию с огромной, но прибыльной кодовой базой, чем стартап с чистой архитектурой, но бесполезный и непопулярный.
Второй вариант: если стадия MVP пройдена и составлен план реализации функционала, можно выделить 2–8 недель перед внедрением новых функций на полный рефакторинг, заложить правильную архитектуру и подготовить проект к масштабированию (в некоторой степени игнорируя KISS и YAGNI). Однако обычно этот вариант неприменим, так как сроки горят, и людям (или заказчику) нужны новые функции.
Но также существуют и другие варианты (которые на моей практике встречались редко):
На стадии MVP или даже PreMVP заложить необходимое количество ресурсов на "техдолг".
Писать MVP с расчётом на масштабирование.
Если проект уже в продакшене, но кодовая база слабая, можно переписывать его постепенно (например, через Strangler Pattern — замещая модули по очереди). Этот вариант наиболее жизнеспособный (по мнению автора).
P.S. Это исключительно моё субъективное мнение, и я ничего не пропагандирую, в том числе и legacy-код.
Как мне кажется, это связано с мировоззрением основателя: он воспринимает проект не как стартап, а как уже состоявшийся успешный бизнес. В таких условиях крайне сложно выпустить на рынок минимальную версию продукта (MVP), составляющую даже 0,5% от его изначального видения, не говоря уже о меньшем.
Мне как человеку, который шарит за производство, а не продажи, было довольно интересно и полезно почитать, особенно 1 и 5 пункт, буду пробовать внедрять, спасибо!
Рад оказаться полезным!
Отличный вопрос! Действительно, многие сталкиваются с тем, что MVP, ориентированный на быстрый запуск, превращается в legacy-монстра. Именно поэтому огромное количество компаний, имеющих что-либо в digital-пространстве, являются таковыми (legacy-монстрами) — либо мне просто везло, и в крупных компаниях регулярно встречалось огромное количество плохого кода.
Здесь я вижу два пути.
Первый — принять это и продолжать работу. Ведь гораздо приятнее иметь компанию с огромной, но прибыльной кодовой базой, чем стартап с чистой архитектурой, но бесполезный и непопулярный.
Второй вариант: если стадия MVP пройдена и составлен план реализации функционала, можно выделить 2–8 недель перед внедрением новых функций на полный рефакторинг, заложить правильную архитектуру и подготовить проект к масштабированию (в некоторой степени игнорируя KISS и YAGNI). Однако обычно этот вариант неприменим, так как сроки горят, и людям (или заказчику) нужны новые функции.
Но также существуют и другие варианты (которые на моей практике встречались редко):
На стадии MVP или даже PreMVP заложить необходимое количество ресурсов на "техдолг".
Писать MVP с расчётом на масштабирование.
Если проект уже в продакшене, но кодовая база слабая, можно переписывать его постепенно (например, через Strangler Pattern — замещая модули по очереди). Этот вариант наиболее жизнеспособный (по мнению автора).
P.S. Это исключительно моё субъективное мнение, и я ничего не пропагандирую, в том числе и legacy-код.
Как мне кажется, это связано с мировоззрением основателя: он воспринимает проект не как стартап, а как уже состоявшийся успешный бизнес. В таких условиях крайне сложно выпустить на рынок минимальную версию продукта (MVP), составляющую даже 0,5% от его изначального видения, не говоря уже о меньшем.
Ахах, так и есть! Настоящий MBA (Master of Broken Apps) получаешь только с опытом 😅
Точно! Простое, быстрое и эффективное решение — именно то, что нужно!
Вот несколько бесплатных (или почти бесплатных) способов собрать фидбэк на 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-сервер – создать канал для первых тестировщиков и обсуждать идеи.
Главное: не ждите идеала – просто спрашивайте, слушайте и быстро итерируйте! 🚀
Спасибо за комментарий!
Действительно, стоило чётче обозначить цель статьи в начале — учту на будущее.