Не однозначный заголовок, но есть от чего. Не так давно я запустил большой проект на Nuxt JS 3. Было ли просто - нет, будет ли лучше - бесусловно. Тогда наверное у вас мои читатели вопрос, зачем это зачем писать если можно делать? Именно поэтому и родилась статья, позволяющая принять непростое решение.
Очень много компаний задумываются о том, а что будет если мы ошибемся с выбором и нам опять придется все начинать сначала. Руководители и продуктологи стоящие у истоков выбора стека продукта бояться совершить ошибку и есть от чего.
Есть ошибки которые можно поправить перевернув лист блокнота и начать сначала, другое дело ошибка в выборе стека при разработке программного. Можно сказать - это разный масштаб, который может привести к фатальным последствиям.
С предисловием все и поэтому теперь к самому главному, а менять ли стек продукта или часть стека когда половина продукта сделана и зачем это делать?
Мое обоснование за смену.
В начале пути создания продукта мы гонимся за скоростью выпуска MVP. Делаем много хорошего и плохого кода, отпускаем неточности в расчетах ресурсов в надежде быстрей получить желаемое. И именно в этот самый момент, от части по неопытности мы совершаем самую первую ошибку: "Я прочитал, мне понравилось. Попробовал - клево и просто. Давайте так и сделаем - это решит нашу проблему". Примерно так я мыслил еще каких то лет 5-6 назад.
Что же изменилось сегодня и зачем я говорю об этом.
Запустив несколько крупных продуктов с нуля (от идеи до промышленной эксплуатации) я нашел для себя ответ на поставленный в статье вопрос и возможно не открою Америку, что есть продукт, а есть MVP. Везде уже все написано и вот здесь я говорю о своем самом главном открытии:
Смена стека возможна в любой момент жизненного цикла продукта и зависит только от продуктовой команды. Зависит от ваших конечных целей и амбиций, а так же от текущей ситуации в развитии продукта.
Главным критерием оценки продукта всегда является отклик конечного пользователя. Если мы делаем интернет магазин, он должен приносить доход, а значит продавать и быть востребованным. Сделали мини приложение для склада - это продукт и не важно, что им пользуются всего 100 человек - это продукт для конкретного потребителя. Любой продукт должен удовлетворять заказчика и покрывать требования пользователя.
После запуска продукта даже в MVP идет переход в эксплуатацию. Мы активно правим ошибки собирая обратную связь от пользователя и развиваем свое детище, а на самом деле мы его начинаем убивать. Мы скрупулезно собираем и отсматриваем метрики, ищем лучшие пути но иногда это утопия.
Что делать?
Правильный ответ можно найти только в эксплуатационной части продукта. Когда MVP уже запущен, собраны первые метрики. В этот самый момент - скажите СТОП разработке на некоторое время (2-4 недели).
Остановка в разработке нужна по нескольким причинам их детально разберем чуть ниже. Сейчас же об остановке с точки зрения команды.
Когда делается MVP. все на драйве и готовы горы свернуть, чтоб сделать быстро. О качестве кода иногда конечно забывают, но дело в другом. Когда команда запустила продукт и уходит в его эксплуатацию наступаем период рутинного процесса.
Именно в этот момент и начинается медленное убийство своего продукта. Команда погружается в рутину дебага, поддержки и разбору клиентского опыта и фиксбага. О каких новых фишках может идти речь, если в backlog валится стопками задачи на исправление.
Поэтому и нужна пауза всем и всему. Она может быть как уже говорил не такой длинной, но команда сможет выдохнуть. Все переосмыслят сделанное, особо уставших сгоняйте в отпуск и это не будет критически для продукта.
Разбираем. Зачем нужна остановка после MVP?
Посмотрите на стек вашего продукта под призмой поддержи и дальнейшего развития. Вы уже эксплуатируете решение. Взгляните на метрики роста.
Выделим основные пункты и если на все вопросы ниже вы ответите "Да", то смена стека не приведет к гибели продукта, а наоборот позволит вырасти быстрей.
- Сможете ли вы быстро фиксить баги и обновлять прод среды без простоя.
- Хватит ли вам бюджетов на содержание облаков, кода ваш продукт будет весить за 10 гигов только в программном коде не считая сопутствующих данных которыми вы станине обладать через пару лет. Тут о базе данных, средах тестирования и отладки, средах для разработчиков и так далее.
- Готовы ли вы поддерживать тот продукт что написали если ключевая команда будет отключена от проекта. В данном моменте стоит задуматься о том, что если ключевой программист уходит не остановится ли все.
Рецепт которому я научился и понял что это работает.
Если хотя бы в одном из ответов на вопросы выше звучит "Нет", "Не знаю", стоит задуматься о стеке и очень внимательно на него посмотреть. Давайте расскажу чуть подробнее.
Фиксим баги без простоя
Стек должен на 100% отвечать - Да.
Ваш интернет магазин - это торговая площадка, она должна работать 24\7\365 и поэтому продукт должен быть быстро обновляемым. Причем обновление как backend так и frontend должны проходить незаметно для клиента так и сотрудников которые поддерживают продукт. О сотрудниках я говорю не о программистах, а о тех кто заливает контент, работает над продвижением и рекламными компаниями и другим персоналом.
Если говорить про программистов в данном моменте, то смотрим на их трудозатраты в часах для подготовки релиза, сроке тестирования и публикации релиза. Если все это занимает не более недели, программист ничего не копипастит и не пишет руками исправления в скриптах после теста в прод - то в целом можно сказать все хорошо. Правильно в этот момент TehLid -у собрать свою метрику. Если есть возможность улучшить - улучшаем прямо сейчас иначе потом будет поздно. Если не улучшается смотрите другие практики, но движения дальше быть не должно. Продукты и овнеры должны знать, что у вас проблемы и в дальнейшем они приведут к еще большим осложнениям.
Облачные ресурсы и сколько их надо
Что есть ресурсы - это деньги которые вы таратите на содержание в рабочем состоянии вашего продукта. Поднимаете докеры, крутите базы данных и так далее и тому подобное. Пока на сайте 1000 пользователей затраты максимум 30 тыс в год, если у вас 6000+ в день рекламного трафика плюс еще 4-5 органики, где итого уже 10+ то затраты кратно вырастут.
Готовы ли вы содержать такого монстра? Есть ли на это финансовый план и обоснование его, что вы это можете себе позволить без кредитов. Если прикинуть во сколько может обойтись через год эксплуатации интернет магазин к примеру с 10 тысячами товаров, приличной клиентской базой и объемом заказов от 100 в день, то это примерно так.
- База данных сайта основного контента, куда мы положим картинки тексты и еще что то про запас - 2-100 гигабайт
- База товаров - еще добавит 5-6 гигабайт.
- Клиентские данные - где заказы, документы и прочие данные еще 3-4 гига.
ИТОГО: 110 гигабайт диска.
Вы скажите что это не много, но постойте. Вы же работаете и растете. Как правило в день при таких объемах вы будете прирастать на 3-6% в месяц в худшем раскладе. Даже по самому нижнему порогу за 12 месяцев вы станете весить 1399,2 гига. И это только операционные данные.
Прикиньте столько надо на бэкап, минимум 1 тестовая среда, минимум 4 разработчика итого уже получается через год вам надо ... прилично много. Вот мы и почитали экономику. Возьмем калькулятор у моего одного из любимчиков провайдеров облаков и посмотрим сколько это в цифрах.
Дальше можно покрутить свои цифры тут, а если пройдете по ссылке и вам все понравится, напишите в комментарий о готовности заказа, скину промокод и по необходимости помогу все настроить.
Предоставлю консультацию по необходимым ресурсам, помогу все рассчитать и не прогадать. Вместе выберем оптимального провайдера по цене.
В любом случае все становится не таким радужным по деньгам и надо это все заранее планировать!
Нет тех кто стоял у истоков.
Это важный, но на сегодня не смертельный вердикт. При выборе стека продукта вы будете основываться на кадровый рынок и как правило вы выбираете, что то из ТОП сегмента на текущий год или минус один год. Очень часто я слышу вопросы: "Вот мы поискали и нашли топ 10 языков программирования" давайте на самом крутом и писать. Программисты есть все четко запилим продукт и будет клево.
Нет! Это фатальная ошибка выбора. Не надо гнаться за новизной - это не кросовки.
Новые языки программирования рождаются каждый день, но из старых проверенных временем решений. Нового уже почти никто не создается с нуля, создаются более удобные и простые для программиста языки.
Еще на заре свой рабочей практики я очень долго верил в язык программирования PHP. Он всегда мне казался самым крутым и доступным. Он и сейчас признан в обществе разработчиков. На нем работают крутые web приложения и к ним нет вопросов по функционалу, но есть эксплуатационные вопросы. Есть вопросы к тем кто на нем пишет и тот же рынок труда, к сожалению теряющий позиции. Вот пример 10 лидеров 2023-2024 на текущий момент:
Современный мир уходит в Go, Python, JS и другие, а причина проста - рынок труда и технологии. C++ & C# - они не умираемые ибо являются основной сред, поэтому о них я не говорю. Если бы мне предложили сейчас делать крутое приложение на PHP, я бы отказался, даже если бы на фронте был VUE.
Причин этому только одна - рынок труда. Программистов PHP сегодня уже не так много и они дорогие. Молодеж на современном стеке и это факт, не буду тратить место в статье на эту статистику.
Поэтому когда мы говорим о тех кто стоит у истоков продукта и когда вы стоите перед выбором стека - думайте не про топ, а про людей кто будет через 2-3 года в команде и как вы будете работать.
Подводим тоги
Когда можно менять стек - после MVP. Самый безопасный и простой способ. Вы уже поняли что продукт выстрелил. Вы понимаете экономику и кто с вами будет ближайшие пять лет.
Когда быть готовыми к замене стека если это не сделано после MVP - через 5 лет жизни продукта. Почему пять лет - это жизненный цикл продукта. Если через 5 лет вы не начнете новый виток жизненного цикла продукта, вас скушают конкуренты.
Через пять лет ваш продукт будет содержать в себе кучу легаси кода. Много не используемого функционала и артефактов от экспериментов с ошибками. Будьте готовы к этому.
Когда не готовы но надо - все что вы делали стало монстром управление которым вам обходится финансово дорого. Вы тратите деньги на программистов, поддержку, сервера в облаках, а финансовый результат компании показывает, что ИТ скушало 70% прибыли и все без новогоднего корпоратива.
Сам вывод собственно по статье.
Я долго шел к тому, чтобы быть способным на крутые изменения. Я менялся сам, менял представление других людей. Учился и учусь каждый день понимая, что только в знаниях сила.
Теперь я перестал бояться предлагать и говорить открыто о том, что становится очевидным мне с первых минут общения с заказчиком, когда они говорят о своей боли. Я понимаю, что всегда тяжело отказаться от того что работало годами, но морально устарело - это уход целой эпохи.
Есть множество примеров технологичных ИТ проектов которые меняют продукт снаружи с завидным постоянством в поиске новых лучших результатов. Внутри так же бурлит жизнь и очень многие меняют целые системы ЕРП в погоне за лучшим.
Не бойтесь анализировать, предлагать и быть решительными в своих действиях. Если вы не предложите и не сделаете шаг, никто этого не сделает.