Прислано: @GavinBelson



Способ обосраться №2: сохрани MVP



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



MVP. Minimum Viable Product. Говоря об IT, это де-факто пре-альфа версия системы с которой начинается путь стартапа в массы. Технически MVP - это кусок невнятного кода, набросанный часто на коленке, в пене и в мыле, без какого-нибудь знания используемого тех. стека. Его задача - как можно быстрее пёрнуть в рынок и проверить - цепляет аудиторию или нет. Привлечь, так сказать, early adopters.



MVP - это не просто куча говнокода. Я больше скажу - при разработке MVP НАДО усиленно говнокодить. Код стайл - в топку. Деплои - в топку. Бэст практис - в топку. Бери всё, что попадётся под руку - лишь бы быстрее выкатить в продакшен. Умеешь быстро наговнячить на LAMP - говнячь! Надо запинать мобильную аппку, а ты знаешь только шарп (js) - бери Xamarin (Ract Native). Ажур даёт тебе хостинг для базы за копейку - отлично, берём. Никакой архитектуры, никаких правил - только скорость кабана, ужаленного в жопу и стремительно несущегося навстречу приключениям.



Если рынку оказывается похер, то MVP спокойно выкидывается и цикл начинается заново. Но вот если выстреливает - тут-то вожделенный кактус и сервируется на стол. Кушать подано!



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



Нанимаются люди, кодовая база начинает развиваться и дополняться, продукт быстро обрастает фичами. Работа кипит и только один факт омрачает светлое будущее стартапа: в основу кодовой базы положен тот самый MVP, являющийся куском отборного дерьмища, которое даже у студента на зачёте бы не приняли. Последствия предсказуемы.



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



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



Но в таком режиме невозможно работать вечно. Говнокод, говнодеплой, говноархитектура очень больно стреляют по ногам, убивая на хрен ту самую скорость, к которой ты так стремился. Они быстро превращают тебя в унылую хромую собаку, которая из последних сил ползёт за несущимся на всех парах паровозом. И когда твой бобик совсем подыхает - богатые конкуренты разрывают его на куски, а твоей головой начинают играть в футбол под всеобщее одобрительное улюлюканье. Это бизнес, детка.



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



Но делать это надо.



До связи.