Сарайчик или музей: как выбирать между быстрым MVP и идеальной архитектурой
Habr ·
В разработке почти всегда приходится выбирать между быстрым решением и технически идеальным. И почти всегда правильный ответ находится где-то между крайностями. За последние годы я видел два почти зеркальных примера. Первый сервис буквально дышит на ладан. Операционка съедает больше половины времени команды, релизы заставляют нервничать, а часть конструкции держится на подпорках и знаниях нескольких старожилов. Но сервис коммерчески успешен. Он нашёл аудиторию, приносит деньги и продолжает расти. В соседнем мире команда построила решение, которое можно ставить в музей. Красивые контракты, современный стек, продуманная архитектура и почти физическое удовольствие от того, насколько всё правильно устроено. Только стоимость разработки оказалась в разы выше потенциальной прибыли — и сервис закрыли. Прощаться со вторым проектом бывает даже тяжелее, чем с первым. В него вложено столько сил, что хочется продолжать уже не ради продукта, а чтобы оправдать предыдущие инвестиции. Эти два случая хорошо показывают неприятную вещь: коммерческий успех не доказывает качество технического решения. Но и техническое совершенство ничего не говорит о ценности продукта. Технический долг — не моральная категория
В разработке почти всегда приходится выбирать между быстрым решением и технически идеальным. И почти всегда правильный ответ находится где-то между крайностями. За последние годы я видел два почти зеркальных примера. Первый сервис буквально дышит на ладан. Операционка съедает больше половины времени команды, релизы заставляют нервничать, а часть конструкции держится на подпорках и знаниях нескольких старожилов. Но сервис коммерчески успешен. Он нашёл аудиторию, приносит деньги и продолжает расти. В соседнем мире команда построила решение, которое можно ставить в музей. Красивые контракты, современный стек, продуманная архитектура и почти физическое удовольствие от того, насколько всё правильно устроено. Только стоимость разработки оказалась в разы выше потенциальной прибыли — и сервис закрыли. Прощаться со вторым проектом бывает даже тяжелее, чем с первым. В него вложено столько сил, что хочется продолжать уже не ради продукта, а чтобы оправдать предыдущие инвестиции. Эти два случая хорошо показывают неприятную вещь: коммерческий успех не доказывает качество технического решения. Но и техническое совершенство ничего не говорит о ценности продукта. Технический долг — не моральная категория