Growth hacking, low-code и другие магические кнопки: как 2019–2020 приучили нас верить в лёгкий рост
Серия «Бизнес-диагностика в IT». Эпоха, когда эксперименты стали важнее результата, а демократизация — важнее архитектуры
После 2015–2016, когда все гонялись за единорогами и сжигали деньги ради роста, и 2017–2018, когда культ клиента и тотальный сбор данных превратились в новую религию, индустрия подошла к 2019 году с очень неудобным вопросом: а что дальше?
Дешёвые деньги внезапно (для многих) кончились. А инвесторы больше не верили в красивые лозунги, команду на вайбе и драйв «растём любой ценой». Компании собирали всё больше данных, но толком почти не использовали, за редкими исключениями. И вот иллюзия быстрого роста разбилась о реальность, а иллюзия магических данных, которые нужны как новая нефть, — о скандалы и регуляторов.
Нужно было что-то новое, ещё одна магическая кнопка, которую можно нажать, чтобы стать успешным.
И она появилась, даже сразу несколько. Причём две из них — на первый взгляд совершенно разные — выросли из одного корня: желания обойти сложность, ускорить процессы и получить результат без той мучительной работы, которая нужна для построения устойчивых систем.
Такое явление, как growth hacking, обещало, что правильное мышление (фаундера и команды) и бесконечные эксперименты в погоне за быстрыми результатами здесь и сейчас заменят стратегию. А low-code обещал, что визуальные конструкторы и так называемые «гражданские разработчики» заменят программистов.
И то и другое звучало как долгожданная магия, а вместе — как беспроигрышная комбинация. Но и то и другое привело во многих компаниях к тому, что ритуалы вокруг этих явлений и имитация их наличия стали важнее самой сути.
Часть первая. Growth hacking: когда «состояние ума» стало оправданием
Термин «growth hacker» придумал Шон Эллис ещё в 2010 году, чтобы описать маркетолога, который вместо традиционных дорогих каналов использует эксперименты, данные и творческий подход к росту. Тогда это был честный ответ стартапов на ограниченные бюджеты: нет денег на телевизионную рекламу — будешь искать другие точки входа, тестировать гипотезы, считать конверсии и искать неочевидные точки роста.
К 2019 году эта идея потихоньку превратилась в культ. Причём не столько в культ экспериментов, сколько в культ особого «состояния ума». Как объясняли консультанты и гуру того времени, growth hacking — это не просто набор тактик, а способ мышления (mindset). Причём это особый способ мышления, доступный не всем. Если ты «в теме», то проводишь A/B-тесты, строишь воронки, рассказываешь об этом на конференциях и имеешь красивые цифры и графики, значит, ты — на передовой. Ты — не как эти скучные ребята с «тут всё неоднозначно» или «нужно планирование».
Таким образом, правильная по своей сути практика тестов на быстром цикле обратной связи для построения долгосрочной стратегии устойчивого роста очень легко подменилась просто ритуалами взрывных тестов для красивых цифр.
Ритуал первый: A/B-тесты ради тестов.
В здоровой версии A/B-тест — это проверка конкретной гипотезы, которая должна привести к измеримому улучшению ключевой метрики. В ритуальной версии тесты стали проводить потому, что «так надо», или заменять ими любую другую деятельность, потому что «без тестов мы не растем». Причём часто тестировались вещи, которые невозможно напрямую и без остальных совокупных признаков признать как показатель, влияющий на бизнес: цвет кнопки, расположение логотипа, формулировка подзаголовка. Даже если один вариант выигрывал, разница была статистически незначимой. Или, что хуже, победа одной метрики (скажем, кликабельности) достигалась за счёт другой (например, качества лидов).
Но это детали, так как инерция рынка и растущая покупательская способность на тот период позволяли оплачивать и эти незначительные эксперименты.
Ритуал второй: дашборды и бесконечная метричная одержимость.
«Нам нужен ещё один дашборд».
Статус-репорты, отчёты по воронкам, когортный анализ, DAU, MAU, LTV — всё это прекрасные инструменты, и у них действительно есть тактическое и стратегическое назначение.
Только если они не подменяются ритуалом data-driven мышления, где главное, чтобы дашбордов было побольше, а всё остальное уже технические детали их обслуживания. Ты смотришь на графики, двигаешь карточки в досках, строишь прогнозы и чувствуешь, что ты — data-driven. При этом связь между твоими действиями и бизнес-результатом может быть такой же нулевой, как и в пресловутых A/B-тестах в никуда. А может быть даже отрицательной, если быть очень честными.
Один из авторов тематических блогов в 2020 году дал убийственно точное определение:
«Под growth hacking стали подразумевать поиск короткого пути найти новых пользователей, вместо того чтобы планировать и запускать продуманные и управляемые кампании, ориентированные на рост. Это значит, что фокус падает на максимально дешёвые быстрые победы, а не долгосрочную выгоду».
То есть growth hacking стал легализованной ленью. Вместо долгой и скучной работы над продуктом, удержанием и юнит-экономикой всё вылилось в поиск одного взрывного хака. А так как хаками очень быстро хочется похвастаться, они моментально копируются конкурентами и не создают устойчивого преимущества из-за повторяемости. Но дофамин от первой быстрой победы так сладок, что компании продолжали гоняться за ними, словно наркоманы за следующей дозой.
А всё потому, что человеческая психика устроена таким образом, что моментальная выгода сегодня кажется нам важнее долгосрочной выгоды в будущем. Это биология, доставшаяся от предков, которым нужно было выжить здесь и сейчас, а не скучно планировать на следующие 10 лет. Так что growth hacking идеально попал именно в яблочко.
Agile как верный служитель культа
Отдельно стоит сказать про agile. Потому что, как и изначальная идея growth hacking, гибкие методологии управления проектами — Scrum, Kanban и другие — сами по себе прекрасны. Для небольших команд, работающих над сложными продуктами в условиях неопределённости, agile был настоящим спасением от бесконечной бюрократии согласований.
Зародившийся аж в 2001 году, к 2019–2020 agile стал жертвой собственного успеха и популярности. Вместо объективной методологии он превратился в набор ритуалов, которые можно купить, сертифицировать, а если и этого вам не хватает, то ещё и нанять коуча для надёжности. И получилось, что все эти активности больше не требуют ни ума, ни ответственности — только дисциплины исполнения.
Ещё в 2018 году один из авторов оригинального agile-манифеста Мартин Фаулер бил тревогу: «На поверхности мир agile выглядит прекрасно — он стал мейнстримом. Но реальность тревожна, потому что многое из того, что делается, — это ненастоящий agile, пренебрегающее ценностями и принципами». Он тогда же ввёл термин Agile Industrial Complex — таким образом описав индустрию, которая насаждает методы, процессы, сертификации и коучей, вместо того чтобы довериться команде (что было вообще изначальным и главным принципом оригинального манифеста 2001 года).
Как это выглядело на практике? Если вы в IT, то вы сами, скорее всего, видели это не раз.
- Дейлики превратились в отчётную систему, где все просто ставят галочки и двигают карточки. Коллеги друг друга не слушают, потому что встреча в календаре — фон.
- Спринты длиной в две недели стали необъяснимым ритуалом. В изначальной идее за это время нужно было сделать работающий результат и принять решение — идём дальше или нет. А на практике две недели превратились в горизонт бесконечного планирования. Задачи переносятся из спринта в спринт, никто не помнит, почему вообще эта задача возникла, и таким образом две недели превращаются в полгода.
- Ретроспективы — это шанс честно сказать, что идёт не так. Но когда команда понимает, что изменения всё равно не произойдут (потому что «это не влезет в следующий спринт»), ретроспектива превращается в ритуал наклеивания стикеров на доску Miro, согласного кивания, что надо иначе, но обычно ничего не меняется после.
Из интересного, уже к 2023 году удовлетворённость agile-методологиями в компаниях упала с 71% до 59% за год. Основная причина заключалась в том, что гибкость методологии оказалась не настолько гибкой, когда дело касалось специфичных условий каждого бизнеса. Стали появляться гибридные модели agile, приходилось создавать самодельные фреймворки или вообще отказываться от методологии в целом. И, печальным образом, изначальная гибкость во многом превратилась в ритуальную бюрократию.
Что осталось в наследство
Из эпохи growth hacking и agile-ритуалов мы вынесли несколько токсичных привычек, которые до сих пор живы в 2026 году.
- Вера в волшебную кнопку. В 2015 и эпоху дешёвых денег все ждали, что если денег много, то будет успех. Потом — в 2018, что данные принесут успех. Теперь — что AI принесёт успех. Каждый раз новая надежда, новый культ, а механизм один — ищем лёгкий путь.
- Подмена системы ритуалами. Когда вместо сути появляется повторяемость процесса без цели: дейлики, потому что они в календаре, спринты в две недели, потому что «так сказали», тесты для подтверждения уже имеющихся гипотез и идей, а дашборды для количества и имитации принятия решений по данным.
- Культ занятости. И это стало идеальным оправданием. Неважно чем. Важно, что мы не стоим на месте, а движемся! Даже если не туда, куда нужно.
- Страх перед тишиной. Если никто не проводит эксперименты — значит, мы не растем. Если нет внезапного спайка на графике — значит, мы отстаём и конкуренты нас уже обходят. Многие компании настолько погружены в свои ритуалы, что боятся остановиться и подумать.
Часть вторая. Low-code: демократизация, которая не случилась
Параллельно с культом экспериментов набирал силу другой тренд — low-code. Его идея звучала ещё более заманчиво: а что, если для того, чтобы создавать цифровые продукты, программировать вообще не обязательно? Что если любой «гражданский разработчик» (citizen developer) — менеджер, аналитик, дизайнер — сможет собрать приложение из готовых блоков без единой строчки кода?
Сам термин «low-code» придумала аналитическая компания Forrester в 2014 году. До этого были визуальные среды разработки, RAD-инструменты, конструкторы сайтов вроде Wix — но всё это воспринималось как игрушки для энтузиастов или очень нишевых специалистов. Тот же Webflow, который в 2019 получил особое внимание, на своей заре в 2013–2014 считался максимально нишевым продуктом для энтузиастов и фрилансеров.
В 2019–2020 ситуация кардинально изменилась.
Почему low-code выстрелил именно тогда?
Можно честно сказать, что потому что время пришло.
- Во-первых, IT-отделы устали от тяжёлых legacy-систем. Исследования тех лет показывали, что до 86% времени IT тратится просто на поддержание их текущего состояния. На инновации не оставалось ни сил, ни времени, ни желания. Low-code обещал переломить этот тренд и позволить бизнес-пользователям создавать решения для своих задач самостоятельно, не дожидаясь дорогостоящих и медленных программистов.
- Во-вторых, спрос на приложения (особенно мобильные) в 5 раз превышал возможности IT-отделов. Low-code казался единственным способом закрыть этот разрыв. А подстёгивающая всех цифровая трансформация сделала скорость критическим фактором для принятия решений.
- В-третьих, разработчики, которые действительно могут собрать с нуля логику кастомного решения, были дороги и дефицитны. Low-code обещал расширить пул «создателей» за счёт тех, у кого достаточно контекста в бизнес-процессах, но недостаточно технических навыков.
- В-четвёртых, цифровая трансформация пробуксовывала. А low-code давал надежду на «демократизацию» — что новые продукты смогут создавать не только элитные инженеры, но и обычные «синие воротнички» от программирования.
И это ещё не все.
Инвесторы и аналитики ухватились за эту надежду. Forrester прогнозировал годовой рост рынка low-code в 40%. Gartner добавил специальную категорию в свой Magic Quadrant, предполагая, что low-code-решения станут популярными даже для enterprise-сегмента. Тот самый Webflow наконец-то получил инвестиции в серии A в $72 млн в 2019, а через два года его оценили уже в $2,1 млрд.
Но как позже быстро выяснилось, демократизация разработки — это просто красивое слово, а реальность на самом деле куда сложнее.
Где обещание разбилось о реальность
Low-code оказался идеальным инструментом для прототипирования. Быстро собрать работающий макет, показать инвестору, проверить гипотезу — да, это он умеет. Но прототип — это не продукт. А когда прототип начинает превращаться в продукт, возникают те же самые проблемы, от которых пытались убежать.
- Масштабирование. То, что работало для 10 пользователей, начинает давать сбои на 3000 и умирает под нагрузкой 10 000. Без разработчика, который залезет в код и перестроит архитектуру, уже не обойтись.
- Vendor lock-in. Вы строите бизнес на платформе, которая в любой момент может изменить правила игры, например повысить цены или убрать ключевые фичи, как сделал тот же Webflow в 2022 году. И перейти на другую платформу вы не можете. Точнее, можете, но это значит, что придётся переписать всё с нуля и перестроить бизнес-процессы, которые уже завязаны на инструмент одного вендора.
- Технический долг. Low-code также не отменяет инфраструктуру, которую нужно поддерживать. Со временем из-за ограниченности базовых компонентов вы всё равно придёте к необходимости писать кастомный код. Но теперь этот кастомный код будет встроен в платформу, и последствия его изменений предсказать гораздо сложнее.
- Отсутствие стандартов и лучших практик. То, о чём мало кто говорит, — low-code решения не имеют стандартов. Разные отделы используют разные low-code инструменты, данные не шарятся, процессы становятся несовместимыми. А когда система ломается, отладка превращается в настоящий кошмар, где без разработчика уже теперь точно не обойтись.
Вернёмся обратно на мгновение снова к Webflow. Платформа, которая начиналась как демократичный инструмент для всех, к 2023–2025 году стала дороже и ориентированной на корпоративных клиентов. Цены выросли впервые с 2016 года, лимиты на бесплатном тарифе ужались, а от некоторых встроенных функций отказались в пользу сторонних интеграций. И вот здесь пользователи забеспокоились, а не попали ли они в тот самый вендор-лок?
Low-code позволил решать внутренние задачи для некоторых компаний, но не породил новой волны успешных стартапов. Были единичные истории вроде Pixate (купили и закрыли), LocalTown, NewCo — все они умерли от классических болезней, которые убивали продукты ещё в том же 2015: не нашли рынок, не до конца изучили проблему, не хватило фокуса. Low-code ускорил создание прототипа, но не дал ответа на главные вопросы: «что собрать?», «кому это нужно?» и «как это масштабировать?»
Потому что ответ кроется не в технологии.
Что осталось в наследство от low-code
- Иллюзия контроля. Low-code дал иллюзию, что «не нужно знать код». И для типовых задач это действительно так. Но для сложных задач, к сожалению, нет. И разрыв между «прототип работает» и «продакшен не падает» оказался огромным.
- Вендор-лок как норма. Компании строили бизнес на чужих платформах и обнаруживали, что выгрузить данные или перейти к другому вендору невозможно без потери функциональности.
- Подмена «демократизации» маркетингом. Low-code платформы, став успешными, начали вести себя как любой enterprise-вендор — повышать цены, менять условия, ориентироваться на крупных клиентов. Демократизация оказалась маркетинговым словом, а не устойчивым свойством.
Low-code как предтеча: почему мы до сих пор наступаем на одни и те же грабли
Важно отметить, что low-code не появился из воздуха. Он был просто одной из ступеней в долгой эволюции желания «упростить программирование».
Если посмотреть на это с высоты 2026 года, становится очевидно: low-code, Copilot и вайбкодинг — это звенья одной цепи. В каждом случае мы пытаемся срезать угол, убрать «лишнюю» сложность и сделать так, чтобы создавать продукты могли все, без глубокого понимания того, как они устроены. И в каждом случае мы натыкаемся на одну и ту же стену: инструмент ускоряет исполнение, но не отменяет необходимость думать.
- Low-code был первой массовой попыткой «объяснить компьютеру, что делать» через визуальные блоки, а не через код. Ты не пишешь, а собираешь. И это работало для прототипов, но разваливалось под нагрузкой, потому что за визуальной простотой не было архитектурной сложности.
- Copilot (и его аналоги) пошли дальше — теперь ты вообще не собираешь блоки, а описываешь задачу словами. «Сделай красиво», «добавь функционал», «почини баг». Но код, который он генерирует, часто ошибочен. А когда работает — качество, как правило, среднее, потому что языковые модели отражают среднее использование языка, а не хорошую инженерную практику. И это перекликается с тем, что писали про low-code ещё в 2019 году: инструмент даёт иллюзию контроля, но не даёт контроля на самом деле.
- Вайбкодинг — это уже совсем обожаемая магия AI. Здесь даже не нужно формулировать задачу конкретно. Просто можно кодировать на вайбе: «сделай», «почини», «улучши». Это та самая желанная кнопка «сделай мне успешный бизнес». Но именно здесь разрыв между ожиданием и реальностью становится максимальным.
И что мы видим в итоге? Каждый раз одна и та же история, где новый инструмент обещает демократизацию, ускорение и лёгкость. Мы бросаемся его внедрять, потому что это кажется «правильным» и «передовым», и проводим ритуалы вокруг него, пока медийное пространство заполняется контентом и людьми, которые рассказывают вдохновляющие истории. Мы верим, что он решит наши проблемы, а потом оказывается, что нужно системное мышление, понимание архитектуры, нужно уметь задавать правильные вопросы — и это внезапно перестаёт звучать как магия.
Так что low-code был не просто самостоятельным трендом, а лишь шагом к тому, чтобы всё-таки когда-то понять, что просто кодить на вайбе, конечно, весело, но не выдерживает никакой критики в долгосрочной перспективе.
Общий итог: что мы вынесли из этой эпохи
Growth hacking и low-code — при всём их внешнем различии — выросли из одного весьма понятного и хорошо объяснимого желания получить быстрый результат без системной работы.
Несмотря на свои изначальные правильные идеи, и тот и другой тренд дали иллюзию контроля над сложностью, которую можно решить на раз-два. И тот и другой привели к тому, что многие компании оказались утопленными в собственных ритуалах вокруг этого.
Growth hacking как явление дал нам веру в «волшебную кнопку», культ занятости, страх перед тишиной, подмену системы дашбордами и дейликами.
Low-code подарил иллюзию, что сложные системы можно собрать из готовых блоков, вендор-лок как новую норму, и внезапное понимание, что «прототип работает» — это не конец истории, а только её самое начало.
Сейчас, в 2026 году, мы пожинаем плоды этих иллюзий. Важно помнить, что и growth hacking, и low-code не злой умысел по своей сути. Они были правильным ответом на реальные боли — сложность, медлительность, дефицит ресурсов. Но проблема не в ответе и не в инструментах. Проблема в интерпретации, адаптации и применении — как повод перестать думать, как оправдание для ритуалов, как замену стратегии.
Вопросы для самодиагностики
Если вы узнаёте себя в этих историях, вот несколько вопросов, чтобы проверить, насколько глубоко в вас сидят старые привычки.
- Сколько A/B-тестов вы провели за последний месяц — и сколько из них привели к реальному росту ключевых метрик? Если тесты есть, а рост стоит на месте, вы не тестируете — вы имитируете активность.
- Ваши дейлики — это синхронизация или отчёт? Спринты заканчиваются релизом или переносом задач? Если задачи переносятся из спринта в спринт, вы не в agile — вы в бесконечном планировании.
- Вы используете low-code для прототипов или для продакшена? Если второе — готовы ли вы к тому, что через год всё придётся переписывать с нуля?
- Знаете ли вы, как выгрузить данные из вашей low-code-платформы? Если нет — вы в vendor lock-in. Поздравляю.
- Ваша компания растёт или просто «занята»? Честный ответ на этот вопрос дороже любого дашборда.
В следующем посте
Мы переходим к эпохе 2021–2022 — ковидному буму, бесконечному найму, удалёнке и зарплатам, не привязанным к результату. И к тому, как мы оказались в точке, где занятость перестала означать эффективность.
А пока — ответьте себе: какая из этих эпох оставила в вас самый глубокий след? И что вы с этим делаете сейчас?
Если хотите нырнуть в детали с цифрами, кейсами и академическими исследованиями, читайте полные версии на сайте: