​​Взгляд генерального директора на no-code MVP (Часть 2) Как | Low-Code

​​Взгляд генерального директора на no-code MVP (Часть 2)

Как руководитель стартапа должен оценивать отсутствие кода по сравнению с пользовательским кодом и принимать правильное решение?

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

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

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

В случае с кодом по сравнению с no-code лучше всего просто принять вероятность полной перестройки в будущем и включить это в свою дорожную карту. Это делает его математическим, а не техническим, что не так уж плохо. Это может не всегда получаться, но когда это происходит, это выглядит так: Стоимость no-code MVP + затраты на последующую перестройку - накладные расходы на поддержание пользовательского кода = затраты на достижение цели