Почему надо выкинуть ваш MVP

Перед релизом продукта в прод стоит рассмотреть возможность выкинуть ваш MVP и начать разработку сначала.

Но почему?

После того, как вы прошли все тестовые версии продукта или MTP, вы определяете, какие функции должны быть в вашем продукте. Это задает рамки для MVP. Но что делать с кодом, который реализует эти функции? Он уже есть, почему бы не использовать его? На самом деле, это плохой код, в этом и заключается проблема. Вы итерируетесь и получаете новые тестовые версии как можно быстрее. Это может быть день или неделя, чем короче, тем лучше. В таких условиях можно ли рассчитывать на качество кода, достойное продакшна? Нет. Если вы ничего не знаете о коде, это не страшно. Я расскажу вам, что даже если ваши разработчики отличные, они будут использовать костыли, чтобы создать новую тестовую версию. После нескольких итераций они будут строить одну функцию поверх другой, постоянно используя костыли. Но именно для этого и предназначен MTP: получить ваш код как можно быстрее, чтобы протестировать идею, которая затем станет вашим MVP.

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

Многие разработчики застряли в распространенной идее «нам нужен прототип как можно быстрее, сделайте это». Позже команда приходит и говорит: «Готово, но чтобы заставить прототип работать, мы немножко накостылили. Его нельзя использовать в производстве». Руководство отвечает: «Аудитории нравится, запустим в прод». Последнее предложение — кошмар для разработчика. Потому что в будущем, когда руководство захочет добавить новую функцию, и это займет в 10 раз больше времени, чем следовало бы. Виноватым окажетесь вы. А не код, который вас заставили запустить в производство. Несмотря на ваше предупреждение о его непригодности.

Чтобы начать проект с той ноги

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

Как я уже упоминал, лучший способ исправить это — выкинуть ваш MVP и переписать все до релиза. Это все равно MVP, но его функционал основан на желаниях клиентов. Вот главное: дом нуждается в прочном фундаменте, чтобы простоять много лет. Точно так же для бизнеса нужен прочный фундамент. В наше время этот фундамент — это технологии. Если ваш код начинается с плохих основ, он только ухудшится со временем. Если же вы начинаете с крепкого фундамента, поддерживать его будет намного проще. Он прослужит вам долгие годы. Чем больше людей касается вашего кода со временем, тем хуже он становится. Это так же работает в любом бизнесе, поэтому удерживание разработчиков также помогает поддерживать качество кода.

Что люди не понимают

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

Помните, что когда у вас есть набор функций MVP, выбросьте код и начните сначала.