Комментарии 17
Есть несколько способов делать mvp. Часто под mvp имею в виду только проверку гипотезы, забывая потом заменить тестовый продукт на нормальный (
Если mvp был нужен для проверки, то это нормально, но потом надо выкинуть его нахрен и стереть весь код. К сожалению эффективный менеджмент видит там "потенциал" и "деньги" и в итоге этот тестовый продукт становится тем самым легаси... В итоге в машине руль от самоката, тормоза от велосипеда, мотор от мопеда и 1000 недовольных пользователей. Которые перейдут к конкуренту, как только он появится. А он появится, ведь гипотеза оказалось доказанной, а решение кривыми.
Жаль, но в реальном мире я все чаще слышу, что менеджер продукта не должен "лезть в технику", хотя как раз именно такой человек, с пониманием и картинкой итогового результата, и должен был бы делать архитектуру...
К сожалению эффективный менеджмент видит там "потенциал" и "деньги"
Никто не заинтересован удвоить стартовые инвестиции и ждать еще полгода только лишь для того, чтобы переписать продукт с нуля.
Подразумевается, что тестовый продукт будет переписываться на "нормальный" в процессе следующих итераций. Но, подразумевая это, забывают заложить большую долю времени на техдолг и увеличить количество разработчиков.
Подразумевается, что тестовый продукт будет переписываться на "нормальный" в процессе следующих итераций.
Вообще не факт, что в конкретном случае это сделать возможно хотя бы принципиально. В общем случае, утверждение, что потенциальный спрос (наличие которого проверено MVP) может окупить разработку полноценного продукта - это, при нынешнем технологическом уровне отрасли разработки ПО , ровно такая же гипотеза, как и гипотеза о спросе. И ее тоже надо проверять на практике.
Если mvp был нужен для проверки, то это нормально, но потом надо выкинуть его нахрен и стереть весь код.
Такой MVP называют прототипом, на сколько я помню (как первый элемент в верхнем ряду). Его переписывают полностью.
MVP - это всё таки больше продукт, который можно развить (вот как в 3-м ряду).
Мысль то здравая и правильная, зачем минусят? :(
Потому что выглядит как записки графомана. Человек выше объяснил тоже самое одной картинкой. К тому же тема заезжена, и даже я, который программировал разве что в девятом классе на паскале, уже читал подобные рассуждения.
Лично я бы не минусил, а отнёсся нейтрально.
Эта картинка - МВП статьи. И если кому-то понятно общее видение и ситуация, и они относятся нейтрально, то есть люди, которым это совсем не понятно. Видимо, автор столкнулся со вторым "лагерем". Как и я. Скину статью коллегам, кстати
Ну только не надо обесценивать статью настолько, что "каждый школьник знает".
Картинка выше - это не то, о чем я писал в статье. Картинка передает смысл итеративной разработки через MVP. В же статьи написано, к чему такой подход может привести.
На своем опыте скажу, что тут или стагнация, как описал автор, или владелец находит инвестиции на реализацию качественного продукта, тем более, что MVPшкой гипотезы проверили, для инвесторов информация есть. то есть следующие шаги по статье это
оценить беклог, включая техдолг,
приоритизировать
понять кого берем
набрать
при этом надо четко понимать, что набор даже сильного разработчика вначале время разработки замедлит: он будет разбираться в том, что есть (док то нет) и дергать старичков. (правда если небольшое MVP, недолго)
Все это должно быть спланировано и запихнуто в план работ/финплан и так далее.
Брошенные и работающие MVP это настоящая боль техподдержки...ты просто каждый день живешь в БД на проде и редачишь данные, потому что нормально дорабатывать у компании якобы нет ресурсов, да и зачем, если есть дешевая техподдержка и денежки с клиентов капают.
И тут задействована большая цепочка от жалоб клиентов к личному менеджеру/горячей линии <=> техподдержка <=> dba'шники которые выполняют скрипты на проде и все тратят время на откладывание проблем на завтра одними и теми же костылями годами.
А эффективные менеджеры закрывают глаза на эти проблемы.
MVP тоже разный бывает. Можно сделать фронт на гуглформах и посадить студента в качестве бэка, это тоже mvp и для проверки многих гипотез вполне годно.
А можно собрать на старте MVP максимум экспертизы и включить в команду зрелого ментора, желательно имеющего опыт факапов, и проектировать сразу MVP+
Это дороже в моменте, но дешевле на длительной дистанции. Главное - убедить в этом менеджмент, поэтому ментор должен быть там в авторитете
Предлагаю немного о грустном:
Возможно, уже пришло время упоминавшейся выше "половине разработчика" (и целой армии таких же) осознать, что идея стартапа в ИТ уже не работает? Точнее так: работает, но стартап должен потом превратиться во что-то и за счёт кого-то.
Понять, что ИТ уже вырос из штанишек? И для мало-мальски успешного продукта нужен другой подход? Можно привести аналогии с кинематографом: можно снять вполне успешный низкобюджетник и даже отличиться на каком-нибудь фестивале. Но потом всё равно подключаются "взрослые дяди", которые "немного" вкладываются и получается кино на уровне (или, конечно же, не получается). А проталкивать идею, что "буду снимать полный метр на уровне голливуда чисто за счёт карманных денег" - ну это даже не смешно.
В общем, по-моему, ИТ уже вырос. Это немного грустно, но так есть.
он никогда не был маленьким. просто в 10х был бум стартапов и кому-то показалось, что команда продуктолог-разработчик отлично решает все-все проблемы любого продукта.
Я даже в популярных ТГ каналах до сих пор слышу апологетов такого подхода. И спорить с ними бесполезно, они просто пока не понимают, что как только продукт начнет расти, понадобится расширять команду и вся эта стройная конструкция опять сведется к так ненавидимому всеми (а зря, кстати) энтерпрайзу
Мне нравится ход ваших мыслей. Хотя с заключением я не соглашусь. Время еще не пришло.
Действительно, если хочешь снять фильм про Годзиллу и заработать денег, то никакой низкобюджетный формат не подойдет. Но если хочешь снять обучающее видео по сварке, то рынок открыт. Хочешь снять фильм про судьбу шахтера - рынок открыт, шахтеры с удовольствием его посмотрят, даже если фильм низкобюджетный.
В мире есть огромное количество сфер, куда IT проник не настолько глубоко, как в банки. И в этих нишевых сферах по-прежнему можно начинать со стартапов. Есть и новые возможности в уже почти оцифрованных сферах. Например, недавно в России появилась сфера кадрового электронного документооборота с цифровой подписью.
В том, что описано в статье, просматривается очень распространённая ошибка планирования. Суть её в том, что при разработке MVP все поочерёдно добавляют новые фичи и думают, что в этом и состоит вся разработка, и что так будет всегда. На самом же деле, этот подход работает ровно до того момента, пока ты не опубликуешь свой продукт. После публикации в плане не должно быть никаких нововведений в течение какого-то периода времени. Первые дни нужно будет потратить на хотфиксы ошибок, которые неизбежно появятся. Затем в течение ещё нескольких дней нужно будет вместо хотфиксов применить более хорошие решения. Суть в том, чтобы вместо расширения функционала сосредоточиться на повышении устойчивости того, что уже есть.
Пока разрабы всё это фиксят, ПМ, аналитики и прочие должны скорректировать дальнейший план, т.к. 100% поменяются приоритеты следующих фич. Что-то, возможно, даже выбросится из плана. Плюс по взаимодействию с юзерами сразу появятся задачи для дизайнеров.
Если этих вещей не предусмотреть, то разработчики так и будут разрываться между фиксами и фичами, пока у клиента не закончатся деньги.
"Отличный способ защитить себя от лишних трудозатрат, потери времени и денег – это создать минимальную ценность продукта и попробовать его продать"
Часто из ценного только уточненные требования пользователей. Архитектура и код могут не оказаться полезными в этот момент, значит это демо а не MVP
Много раз сталкивался что не проверяют, верно ли что MVP действительно Vitae
так что на картинке с машинками 3 случай тоже не MVP
если продукт это автомобиль (а не их производство), то MVP это тюнинг, новые колеса и т.п.
продукт не должен меняться СЛИШКОМ ДОРОГО
Прочитал с интересом! Но начинается с предпринимательского термина MVP, а дальше вся статья про разработку и проблемы разработки. MVP же нужен чтобы понять, можно вливать уже сотни миллионов или нельзя. Для этого ты быстро-быстро сделал этот mvp и дальше работаешь над каналами дистрибуциями, каналами привлечения и тд. У Стива Бланка это же расписано прям с табличками) Вот не увидел этого в статье вообще. Вы как то к PMF то приблизились? Если да, то бог бы с ними с этими техническими проблемами - нанимай нормального CTO и пусть он все разруливает. Или статья про то, что технические проблемы не позволили создать MVP (как работающую мини модель бизнеса) и вы не смогли перейти к "развитию потребителей" ?
MVP, остановись