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

Дело в том, что, хотя интернет коллективно решил, что девиз «Действуй быстро и ломай» мёртв — убит регуляторами, этическими нормами, экологическими проблемами и общим взрослением технологической индустрии — на практике он по-прежнему процветает. Девиз не умер. Он просто научился быть более сдержанным.

Призрак в машине

Эта фраза появилась в Facebook как явное культурное требование. Это был не просто забавный слоган; он был заложен в операционную ДНК компании через такие механизмы, как правило 45 минут (новые сотрудники должны стать продуктивными в течение 45 минут) и культуру, которая отмечала выпуск кода, а не бесконечные дебаты. Философия была соблазнительной: скорость создаёт конкурентное преимущество, а конкурентное преимущество равно выживанию. Действуй быстро, делай итерации на основе обратной связи из реального мира, не увязай в перфекционизме.

Для стартапов на ранней стадии с ограниченными ресурсами и экзистенциальным давлением это имело смысл. У вас было три месяца «пробега». У вас не было времени на презентацию из 47 слайдов о потенциальных крайних случаях.

Затем наступил 2014 год. Марк Цукерберг объявил, что Facebook официально переходит от «действуй быстро и ломай» к «действуй быстро с устойчивой инфраструктурой». Это было представлено как взросление, философская эволюция. Компания взрослела. У неё были миллиарды пользователей. Теперь ломать что-либо означало ломать что-либо для миллиардов людей.

Техническая индустрия одобрительно кивала. «Да, мы вышли за рамки этого этапа», — казалось, соглашаются все. В профилях LinkedIn перестали указывать «быстрые темпы» как основное значение компании (или, по крайней мере, стали более осторожными в этом). В Medium писали статьи о смерти сбоев. Этические нормы стали отдельной категорией консалтинга.

Но спросите у основателя, как они на самом деле работают, и часто вы услышите нечто другое.

Парадокс настойчивости

Вот что я подозреваю: философия «действуй быстро и ломай» не умерла, потому что она работает — по крайней мере, в определённом контексте и на определённом этапе роста компании. Что изменилось, так это то, что нам стало неудобно говорить об этом вслух.

Вместо этого стартапы сегодня практикуют своего рода философскую гимнастику. Они скажут вам, что они «ориентированы на клиента» и «руководствуются данными», одновременно выпуская функции, которые не были протестированы с реальными пользователями. Они обещают «устойчивый рост», сохраняя при этом темпы сжигания средств, которые заставили бы венчурного партнёра плакать. Они говорят об «ответственной инновации», используя флаги функций, чтобы незаметно проводить A/B-тестирование изменений, которые могут иметь регуляторные последствия.

Инфраструктура изменилась. Основные ценности? Не так сильно, как мы думаем.

Рассмотрим, что на самом деле происходит в большинстве инженерных сред стартапов:

Сжатые сроки. Компании серии А всё ещё исходят из предположения, что лучше выпустить сейчас и исправить позже, чем выпускать позже и быть идеальными. Сроки сдвинулись (у вас немного больше трёх месяцев), но принцип остаётся прежним.

Непрерывное развёртывание. Флаги функций стали повсеместными. Вы можете развернуть код, не выпуская его пользователям, что позволяет командам двигаться быстрее, управляя рисками. Механика стала более сложной, но философия — быстро вывести код в продакшн — осталась той же.

Блэмис-постмортемы. У большинства стартапов сейчас есть некая версия этой культуры, когда поломка чего-либо не обязательно является событием, заканчивающим карьеру, если вы это исправите и извлечёте уроки. Это поощряет риск ради скорости.

Празднование исполнения вместо идеального планирования. Я участвовал в питчингах, где основателей хвалили за «быстрый выпуск» и критиковали за «чрезмерное обдумывание». Образ мышления «код побеждает аргументы» всё ещё жив; просто теперь он называется «тестируй и учись».

Ничего из этого не является изначально неправильным. Вопрос в том, делаем ли мы это осознанно или же мы спящим шагом идём к той же динамике, которую, как мы заявляли, преодолели?

Анатомия рецидива

Давайте разберём, как это проявляется на практике. Вот шаблон, который я вижу постоянно:

1. Амбициозные сроки, установленные давлением на сбор средств
2. Инженерная команда идёт на скрытые компромиссы (скорость важнее полировки)
3. На тот момент компромиссы кажутся временными
4. Что-то ломается
5. Происходят постмортемы
6. Уроки документируются
7. Давление сроков усиливается
8. Цикл повторяется

Интересно, что второй цикл не ощущается как повторение первого. Он кажется новой ситуацией с новыми ограничениями. И технически это так. Но основная динамика — приоритет скорости выхода на рынок над структурной стабильностью — сохраняется.

Вот конкретный пример из мира обработки платежей: известный мне финтех-стартап обрабатывает транзакции с помощью резервной системы, которая никогда фактически не тестировалась в продакшне под нагрузкой. Знает ли команда об этом? Да. Исправят ли они это? Вероятно. Когда? Когда либо (а) достигнут порога нагрузки, либо (б) давление со стороны сбора средств или партнёрства заставит это сделать. До тех пор они живут в зоне «вероятно, всё в порядке», где на самом деле работает большинство стартапов.

Это не злонамеренность. Это даже не халатность в чистом виде. Это рациональный ответ на реальные ограничения. У вас ограниченное время, ограниченные деньги и неограниченные вещи, которые вы могли бы создать. Вы выбираете, что оптимизировать, и в условиях стартапа скорость обычно побеждает.

Невысказанный алгоритм

Вот что я думаю на самом деле: большинство стартапов действуют в соответствии с неявным алгоритмом, который выглядит примерно так:

ЕСЛИ (у_нас_есть_финансовый_запас) ТОГДА
    СТАВЬ_В_ПРИОРИТЕТ выпуск_новых_функций
    ТЕРПИ техническую_задолженность
    ПРИНЦИПИАЛЬНО принимай_обоснованные_риски
ИНАЧЕ ЕСЛИ (нам_нужен_доход_или_партнёрство) ТОГДА
    УСКОРЯЙ сроки_выпуска
    СЖАТЬ окна_тестирования
    УВЕЛИЧИВАЙ аппетит_к_риску
КОНЕЦ ЕСЛИ

Этот алгоритм не фигурирует в вашем инженерном справочнике. Он не задокументирован в вашей вики Confluence. Но он реализован на каждой встрече по приоритизации, каждом планировании спринта, каждой беседе «мы сделаем это правильно в следующем квартале», которая постоянно откладывается.

Дух «действуй быстро и ломай» сохраняется, потому что основные условия, которые его создали, не сильно изменились. У вас всё ещё больше идей, чем времени. Вы всё ещё сталкиваетесь с императивом «добиться соответствия продукта и рынка до того, как закончатся деньги». Вам всё ещё нужно доказать, что ваша экономика единиц работает, прежде чем вы сможете инвестировать в инфраструктуру, которая сделает всё стабильным.

Что изменилось, так это упаковка. Теперь у нас есть лучшие инструменты (флаги функций, поэтапное развёртывание, хаотическая инженерия) и лучший язык («действуй быстро со стабильностью» вместо «ломай»). Но фундаментальный компромисс — скорость против стабильности, прогресс против осторожности — всё ещё является центральным напряжением в жизни стартапа.

Где философия даёт сбой

Теперь вот где, я думаю, критики имеют право на свою точку зрения: руководство по принципу «скорость важнее стабильности» отлично работает, пока не перестаёт.

В 2014 году, когда Цукерберг объявил о переходе к «действуй быстро с устойчивой инфраструктурой», это было не просто философское размышление. Это была необходимая эволюция. Вы не можете управлять системой, обслуживающей миллиарды людей, с той же небрежностью, с какой подходите к сетевому приложению для колледжа. Стоимость поломок возрастает с вашей базой пользователей, вашей значимостью в жизни людей и вашим регуляторным воздействием.

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

Неудобная правда: философия «действуй быстро и ломай» работает для стартапов в определённых категориях (низкие ставки, высокая терпимость к сбоям, B2C-приложения для потребителей) и катастрофически терпит неудачу в других (финтех, здравоохранение, инфраструктура, всё, что регулируется).

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

Современная итерация: действуй быстро с ограждениями

Так что же такое современная инкарнация, если «действуй быстро и ломай» мертва, но на самом деле нет?

Я бы назвал это «действуй быстро с ограждениями». Это синтез старой философии с новыми ограничениями. Вот как это выглядит на практике:

Лучшая наблюдаемость. Вы что-то ломаете, но обнаруживаете поломку за секунды, а не узнаёте об этом от пользователей. У большинства современных стартапов есть