Наш опыт быстрого роста от 0 до 100М — неудачи и правильные решения
Всем привет. Меня зовут Сэм, соучредитель и технический директор Qonversion.
Сегодня я поделюсь некоторыми практическими советами, как технически и организационно подготовиться к быстрому росту, настроив необходимые процессы в стартапе.
Я искренне верю, что быстрый рост рано или поздно произойдет с каждым проектом. Эта статья основана на опыте моей команды, пережившей быстрый рост в период с апреля 2020 года по апрель 2021 года, когда количество пользователей увеличилось с нуля до 100 миллионов в месяц. За это время мы многому научились и продолжаем успешно развиваться даже сегодня. На момент написания этой статьи наша пользовательская база насчитывает более 150 миллионов пользователей.
Контекст быстрого роста
Прежде чем мы перейдем к конкретным шагам и рекомендациям, я хотел бы упомянуть четыре основные характеристики стартапа, которые формируют контекст быстрого роста.
1. Короткий срок службы
При запуске проект не имеет репутации. Это, с одной стороны, является преимуществом. Это дает свободу экспериментировать и делать ошибки; ничто из того, что вы делаете, не повлияет на имидж вашей компании. Ваши серверы, которые постоянно отключены, не будут упоминаться в СМИ или анонсироваться на больших страницах. С другой стороны, отсутствие репутации означает отсутствие доверия. С нулевой репутацией проще уйти в минус и потерять клиента.
2. Поиск воспроизводимой и масштабируемой бизнес-модели
В начале развития стартапа очень важно найти бизнес-модель, приносящую прибыль. У вас может быть слабый продукт и нехватка рабочей силы, но вам нужно понять, что принесет вам миллионы. В конечном итоге об этом вас попросят инвесторы и предприятия, а это значит, что вам нужно будет разработать множество функций. Множество функций для проверки идей продукта.
3. Быстрый рост
Быстрый рост сам по себе означает изменение контекста развития. Вчерашние задачи становятся неактуальными, а завтрашние вызовы становятся для вас фатальными, так как они не были включены в ваш процесс. Быстрый рост — это только часть конкретного состояния вашего стартапа. Вы не можете просто сосредоточиться на том факте, что вы собираетесь быстро расти.
4. Неопределенность
Неопределенность также является важным фактором, который необходимо учитывать наряду с быстрым ростом. Конечно, сейчас клиентская база нашего стартапа может расти на 8% каждую неделю, но полтора года назад мы не концентрировались на прогнозах темпов роста. У нас была небольшая команда (хотя и примерно такого же размера, как и сейчас), небольшая клиентская база и вечно насущный вопрос: «Увидим ли мы вообще рост?» Нашей основной задачей в то время была разработка функций, которые подготовили бы почву для этого роста.
Учитывая такие факторы, как высокая неопределенность, необходимость выпуска новых функций для миллионов пользователей и команда всего из нескольких человек, как проект может расти и масштабироваться так быстро?
Ответ прост: нельзя. У вас всегда будут недовольные стороны и расходы. Все, что вы можете сделать, это уменьшить эти расходы и попытаться свести их к нулю.
Ниже приведены рекомендации, основанные на нашем собственном опыте, и стоит сказать несколько слов о Qonversion и нашем собственном контексте.
Qonversion — это мобильная инфраструктура и API для мобильных приложений с подпиской. Наши SDK предоставляют API для работы с платежными системами Apple и Google, в частности с платежным клиентом Google и Apple App Store. Кроме того, он поставляется с аналитикой, тестированием, антивирусными тестами, триггерной автоматизацией для отправки push-уведомлений клиентам, возвращающихся пользователей и так далее. Вся эта инфраструктура обслуживается командой из семи технических специалистов.
Вот наш контекст: у нас есть технически сложный продукт (по сути ПО как услуга с целым набором функций), труднопрогнозируемая нагрузка на инфраструктуру и небольшая команда.
Парадигмы мышления стартапа
Развитие большинства стартапов основано на двух подходах, по сути, на двух парадигмах мышления. Один хочет предвидеть большинство проблем, которые могут возникнуть в проекте, а другой хочет быстро получить результаты.
Как это делают архитекторы, или «Долго, но качественно»
Когда я говорю о том, что хочу предвидеть большинство проблем, я имею в виду прекрасное чувство при запуске проекта. Неважно, что это за проект: презентация, пет-проект или новая услуга в вашей компании без существующих гайдлайнов. Это чувство и желание делать что-то по-другому, учитывать весь прошлый опыт, проектировать адаптируемую архитектуру, выбирать правильные инструменты и подходы. Мысль «Я не тороплюсь и сделаю все правильно», вероятно, знакома некоторым из вас. Долгосрочно, но качественно.
Так делают архитекторы. Архитектор — перфекционист — человек с системным мышлением. Им нравится делать все с исключительным качеством и адаптируемостью, через детализированные системы и с учетом результатов предыдущих проектов. Этот человек очень систематичен, при этом все его дела аккуратно организованы и правильно структурированы.
Как это делают хакеры: «быстро, но не гибко»
Есть и другой подход, более ориентированный на продукт, включающий разработку проекта и решение только бизнес-вопросов.
Вот как это делают хакеры. Хакер — это X-образный инженер, который знает довольно много инструментов. Они могут быстро и буквально за выходные построить целую систему. Однако отказоустойчивость, гибкость и потенциал обслуживания этой системы останутся под вопросом.
Это, конечно, все абстрактно-говоря. Я предполагаю, что эти парадигмы мышления обычно не представляются столь экстремальными. Нам по-прежнему важно помнить об этих экстремальных мыслях, чтобы понимать, как мы действуем в любой момент времени.
Нет правильной или неправильной парадигмы
История усеяна примерами как первой парадигмы, когда стартапы добивались феноменальных результатов, потратив время на создание своих проектов, так и примеров второй парадигмы, когда разработчики Airbnb запускали свое приложение буквально за один уик-энд, проверяя идею.
Учитывая, что вы работаете в стартапе, вы не можете работать с двумя парадигмами одновременно. В крупной компании может быть команда роста, которая быстро валидирует те или иные фичи, а может быть, наоборот, строго выстроенный, стабильный процесс разработки. В стартапе вы выбираете тот или иной подход. Опять же, очень важно подчеркнуть, что здесь нет правильного или неправильного; вам нужно идти по тому пути, который вы предпочитаете больше всего на первом этапе развития.
Qonversion, в частности, начался с API для мобильных приложений; это был любимый проект любимого проекта. К нему не было абсолютно никаких требований, и он был разработан достаточно быстро, буквально за выходные, но нам потом пришлось долго перестраивать эту парадигму. Труднее всего нам было понять, что парадигма мышления, с которой мы начали, все еще продвигала проект вперед по инерции к тому времени, когда нам нужно было его перестроить.
Как структурировать процессы в стартапе и поддерживать быстрый рост
1. Выберите подходящую вам парадигму мышления
Выбор мыслительной парадигмы означает определение оптимального соотношения времени обработки задачи и времени, необходимого для выполнения самой задачи.
Минимальная теоретическая цифра, которую я установил, составляет около 20% для обработки. Все, что меньше 20%, будет означать, что вы слишком быстро итерируете, сосредоточены исключительно на результате, не обращая внимания на качество. Есть более точные метрики, такие как процент возврата задачи, количество найденных багов после релиза и так далее. В стартапе эти показатели не так важны из-за того, что вы работаете в нестабильной экосистеме.
2. Определите свои приоритеты
Важно установить командные приоритеты на ближайшие три-шесть месяцев. Трудно предсказать, что произойдет через шесть месяцев, поэтому каждые три месяца вам нужно собирать вместе техническую команду, команду по продукту и бизнес-группу, чтобы обсудить направление, в котором движется проект. Одна ключевая проблема, которая часто возникает в стартапе, — это рассогласование видений, когда техническая команда делает что-то качественное, много лет, а бизнес-команде нужно быстро проверить идею. По большей части нам удавалось избегать этих проблем, но были функции, которые мы разрабатывали довольно долго, вместо того, чтобы быстро выпустить их на рынок для проверки концепции.
3. Создайте карту рисков
Существует довольно много подходов к построению карты рисков, но если кратко, то это соотношение вероятности выполнения задачи и влияния этой задачи на метрики: простои сервиса, потеря клиентов, отказ клиентов от использования сервиса. , и другие.
4. Прогнозировать перспективы роста
После того, как вы составили карту рисков, расставили задачи по приоритетам и определили свой подход к решению проблем, вам необходимо спрогнозировать перспективу роста вашего проекта в два, пять и десять раз.
Десятикратная цифра может показаться амбициозной, однако на практике в стартапе такой рост может наступить через несколько месяцев. Услуги B2B могут привлечь крупных клиентов с огромной пользовательской базой, и агентство может связаться с вами. Вот почему необходимо прогнозировать перспективы роста в 10 раз и пытаться предвидеть, какие системы потерпят неудачу при таком росте.
Именно такое прогнозирование в апреле прошлого года дало нам возможность расширить нашу инфраструктуру в течение года. Рефакторинг, который мы сделали в то время, был частично неоправдан с точки зрения бизнес-показателей, но все же позволил нам быстро масштабироваться в нужное время.
5. Держите руку на пульсе
После того, как вы определили свою парадигму мышления, вы можете продолжать действовать в рамках того же подхода, но не забывайте обращать внимание на сигналы от различных частей вашего бизнеса и технической команды о том, что что-то может идти не так. Система поддержки может быть перегружена, что может означать, что ваш бизнес вырос, а техническая сторона дела запутана. Когда вы определяете свою карту рисков и расставляете приоритеты, легко понять, что происходит с кодовой базой в данный момент.
6. Исправьте свои потери
В процессе рефакторинга вы иногда можете преждевременно переключиться на масштабируемые системы, потому что не понимаете, будет ли рост. Вы можете сделать это неправильно, а можете, наоборот, начать делать фичу MVP, а спрос на нее может оказаться очень высоким и вам нужно сделать это хорошо. Важным советом здесь является умение фиксировать убытки, причем делать это смело и быстро.
Одна из наших ключевых ошибок заключалась в том, что мы пытались запустить довольно большие функции в производство, когда мы не могли исправить убыток в течение двух или трех недель разработки. Вместо этого мы продолжали увеличивать временные рамки. Вот почему вы должны быть синхронизированы и все время держать руку на пульсе.
7. Научитесь корректировать свою парадигму мышления
Если вы проверяете гипотезу и решили в течение спринта разработать функцию, запустить ее в производство и посмотреть на аналитические показатели, вам нужно научиться корректировать свою парадигму мышления. Для этого хорошо подходят хакатоны, ежеквартальные, двух-трехнедельные рефакторинги кода, когда вся ваша команда прекращает всякую разработку продукта и фокусируется исключительно на качестве и тестах.
Периодически переключаясь с мыслительной парадигмы создания функций MVP на более долгосрочную перспективу построения устойчивости системы, вы научитесь делать это быстро.
У нас был положительный опыт создания функции за два дня, которая прошла проверку. Следующее, что вы знаете, мы восстановили его. И наоборот, когда мы на месяц остановили всю разработку продукта и провели рефакторинг системы.
Важность людей
Говоря о технических подходах, на которых строится ваша разработка, нужно затрагивать самое главное — людей. Люди обеспечивают быстрый рост вашего проекта.
1. Доверие
90% стартапов закрываются или сталкиваются со множеством проблем, потому что небольшая команда не создает культуру или отношения, которые должны способствовать быстрому росту. Прежде всего приходит доверие. Фукуяма проделал большую работу по анализу каталитических стран Западной Европы и некоторых азиатских и неазиатских стран, в которых доверие играло ключевую роль в построении мощной системы.
2. Поддержка (обзоры кода, тесты, брифинги)
Помимо доверия друг другу и создания комфортных условий для работы в небольшой команде, вам необходимо поддерживать друг друга. Поддерживая друг друга, мы уменьшаем вероятность ошибки.
Под этим я подразумеваю сосредоточение внимания на тривиальных вещах, которым абсолютно не уделяется внимания при создании стартапов на ранних стадиях из-за нехватки времени. Это включает в себя проверки кода, которых нет в 90% стартапов, с которыми я разговаривал, тесты, совместные брифинги, а также брифинги бизнес-команд, брифинги продуктовых команд и всеобщий контроль. Я увидел нечто совершенно нетипичное для российского рынка на Qonversion, когда наш CEO раз в месяц рассказывал о бизнесе, о показателях и делился всеми метриками. Если мы все видим одну и ту же картину, мы все можем поддерживать друг друга.
3. Больше рискуйте
Из-за того, что у вас небольшая команда, важно увеличивать свои риски, брать на себя все больше и больше ответственности и быть все более и более активным. Это может увеличить вероятность ошибок, но помните, вам доверяют, и вас поддержат. Рисковать.
4. Создавайте корпоративную культуру с первого дня
Когда дело доходит до всего этого, вы должны помнить, что культура стартапа должна развиваться с первого дня. Об этом часто забывают из-за контекста быстрого роста, когда необходимо прокачать множество функций, чтобы заработать эти миллионы. Культура команды всегда может принять ту форму, которая вам не понравится, и изменить ее к тому времени будет достаточно сложно. Или вообще не будет никакой культуры.
5. Будьте терпимы к ошибкам, но избегайте их повторения
Когда вы создаете среду, в которой люди быстро растут и берут на себя больше обязанностей, вы должны быть терпимы к ошибкам. Толерантность к ошибкам означает, что вы не можете выговаривать людей, вы не можете привлекать людей к ответственности за ошибки и вы не можете сказать: «Что, ты не мог хотя бы проверить код перед его выпуском?» Однако это не означает, что мы должны поощрять ошибки.
Еще одно правило, которое вытекает из стремления исправлять ошибки быстрее и проявлять терпимость, состоит в том, чтокаждая ошибка, которую вы исправляете в стартапе, прокладывает путь для новой ошибки, и эта новая ошибка помогает вам развиваться быстрее.
6. Общайтесь
Вам нужно много общаться. Небольшие команды и стартапы часто из-за нехватки времени пренебрегают классическими подходами, с которыми знакомы многие люди в корпорациях, — сеансы один на один, совместные мероприятия, неформальное общение и многое другое. Отчасти я могу относиться к такому подходу: в условиях неопределенности, когда стартапу нужно сосредоточиться на выживании, становится довольно сложно уделять столько времени командному общению.
Если вы в конечном итоге выживете, вы вполне можете оказаться в группе людей, изолированных друг от друга. В будущем вам придется сломать эту структуру и создать что-то новое, нечто большее, чем продукт, который у вас есть. Транзакционная модель коммуникации не сработает, потому что компании и продукты создаются людьми в сплоченных коллективах.
Напоследок хотелось бы оставить такой интересный факт: до 2012 года Facebook был большим монолитом с бинарником около двух гигабайт. Сборка этого двоичного файла займет 15 минут, а выпуск — еще 15 минут. Это не помешало Facebook стать одним из самых быстрорастущих стартапов, проведя к этому времени IPO и продолжая перестраиваться. Airbnb, с другой стороны, быстро сделал MVP, а затем систематически и методично перестроил свою систему. Это восходит к предпосылке, что нет правильных или неправильных подходов, мы просто не всегда можем обращать внимание на то, что нужно в стартапе.
В заключение
В заключение хочу еще раз подчеркнуть важность осознания вашего подхода. В какой-то степени подход определяет результат. Подобно тому, как наша осознанность в жизни определяет наши отношения с людьми, так и осведомленность о вашем подходе и вашем отношении к продукту будет определять его качество.
Вы должны точно знать, когда нужно выбросить кодовую базу, над которой вы работаете, или когда стоит потратить больше времени на разработку компонента.
Способность переключать парадигмы мышления также важна — это то, что определяет гибкость как проекта, так и вашей команды. Быстрый рост означает быстрые вызовы и смену контекста, и это качество, которым вы должны стараться овладеть с самого начала.
