В FINN мы выросли с 0 до 20 000 автомобильных подписчиков, расширились до США, и все это всего за два года. Эта статистика вызывает в памяти одно слово: скорость. Мы были быстры, и то, как мы это сделали, тоже не секрет. Если хотите узнать, читайте здесь:
- Как немецкий стартап достиг 4 млн. евро ARR за один год | автор Иштиак Зафар | Medium
- Иштиак Зафар ・・・ Medium
- Устранение сбоев в работе базы данных
- Поддержание доверия к нашим данным
- Собственность
- Контроль доступа
- Государственные машины
- Переход на про-код в проекте «Зеленый дракон» 🐉
- Снизить риск до минимума
- Применяйте хорошие инженерные практики
- Сокращение сбоев до минимума
- Где мы находимся сегодня?
- Исправление ошибки в производстве GIF | Gfycat
- Что дальше?
- Заключение
Как немецкий стартап достиг 4 млн. евро ARR за один год | автор Иштиак Зафар | Medium
Иштиак Зафар ・・・
Medium
Medium Вся эта скорость была сопряжена с определенными издержками. Технология в значительной степени опиралась на такие инструменты, как Airtable, Make (Integromat), Retool и другие. Мы построили множество микросервисов, автоматизировали рабочие процессы, что позволило нам автоматизировать множество процессов, связанных с электронной коммерцией и подпиской на автомобили.
В начале 2021 года мы оформили 1000-ю подписку на автомобили, и темпы роста не замедлились. Примерно в середине 2021 года мы продавали по 70 подписок на автомобили ежедневно: наш рекорд составил 242 автомобиля за день! Только представьте себе! К концу 2021 года мы перешагнули отметку в 10 тысяч подписок! С точки зрения роста все выглядело отлично, но технология уже была на пике и проявляла признаки борьбы.
Эти два года быстрого создания прототипов и экспериментов помогли нам узнать, что работает хорошо, а что нет, но дело в том, что прототипы ненадежны, они часто ломаются и плохо масштабируются.
Наша ситуация в то время выглядела примерно так:
- Ограничения базы данных (Airtable)
- Проблемы с синхронизацией
- Чрезмерное использование инструментов без кода, таких как Make, для критически важных бизнес-целей
- Чрезвычайная связанность на уровне данных
- Отсутствие права собственности на модель данных
- Отсутствие процесса контроля доступа и изменений
- Сложный процесс тестирования
Как и в случае со всеми прототипами, наступает определенный момент, когда мы понимаем, что он больше не работает для нас, и мы начинаем создавать более совершенные продукты, вдохновленные этими прототипами и полученными знаниями. Поздняя половина 2021 года показала, что FINN переросла свои прототипы с низким кодом и нуждалась в чем-то лучшем.
 |
|---|
| Кредиты изображений — https://jasonmorrissc.github.io/post/2022-02-24_no-code/ |
Устранение сбоев в работе базы данных
В первые дни нашей работы мы выбрали базу данных Airtable. Причины: Простота использования, легкость изменения схемы, быстрый откат и восстановление моментальных снимков. Мы выбрали Airtable, потому что с ней могли работать все (а не только инженеры). Вскоре у нас была база данных с более чем 40 таблицами, а таблица «автомобили» имела почти 400 полей! (Очень неэффективно, мы знаем.) К этому добавились десятки автоматизированных рабочих процессов, читающих и изменяющих эти данные, и вскоре наша база данных сдалась. Airtable поставляется с ограничением в 5 запросов в секунду на базу. Мы постоянно били по этой цели и начали получать более 100 таймаутов в день.
Мы быстро организовали действующий отряд. Этот отряд был назван «No Time to Timeout»-squad, по мотивам недавно вышедшего фильма о Джеймсе Бонде «Не время умирать», с одной целью: сократить ежедневные таймауты Airtable до 0. Решение:
- Определить данные, которые слабо связаны между собой, и перенести их в отдельные базы, чтобы ими можно было управлять независимо друг от друга.
- Создать копии на чтение для данных, которые используются в масштабах всей компании, например: автомобили и данные, связанные с подпиской.
- Определить процессы, требующие больших затрат на чтение, и перевести их на чтение из копий на чтение (это внесет небольшой застой в данные, но пока сойдет).
- Определите процессы, требующие больших затрат на запись. Для этого нам пришлось реализовывать решения в каждом конкретном случае. Например, для автопарка мы реализовали функцию diffing, которая сравнивает последние изменения, присланные производителями автомобилей, с последними изменениями и обновляет только те автомобили, данные которых изменились. Для остальных мы выполняли пакетные операции записи.
Это позволило сократить время ожидания до нуля, но это был только первый шаг к созданию стабильной системы.
Поддержание доверия к нашим данным
У нас начались проблемы с синхронизацией. Множество источников данных в сочетании с отсутствием права собственности на данные и процесса контроля изменений привели к возникновению множества проблем с качеством данных. Слишком много людей изменяли данные напрямую, а частичное обновление данных, необходимых для определенных процессов, только усугубляло ситуацию.
Собственность
Это было время для внедрения принципа собственности. Команды получили право собственности на определенные наборы данных, например, команда User Acquisition владеет лидами, Operations владеет автомобилями и управлением подписками, Finance владеет данными, связанными с деньгами, и так далее.
Контроль доступа
Контроль доступа к данным на чтение и запись был решен путем сокращения прямого доступа к базе данных, где это возможно, и вместо этого предоставления данных через микросервисы, написанные командами, владеющими данными. Эти API были не общими CRUD API, позволяющими делать все, что угодно, а скорее API, управляемыми намерениями, которые открывали только определенную часть набора данных, в зависимости от того, что вам нужно было сделать.
Государственные машины
Мы начали определять машины состояний для наших критически важных объектов, таких как автомобиль и подписка. Мы должны были определить, «Что» данные могут быть изменены, «Когда» и «При каких условиях». План состоял в том, чтобы повысить согласованность данных, сделав невозможным изменение данных таким образом, чтобы это привело к конфликтам. Например, чтобы пометить подписку как активную, необходимо сначала проверить команду управления и доставки автомобилей, действительно ли они передали автомобиль. А в финансовом отделе необходимо проверить, был ли внесен залог. Вот один из наших проектов для машины состояния подписки:
Переход на про-код в проекте «Зеленый дракон» 🐉
Вышеупомянутые проблемы сделали кристально ясным, что мы не сможем масштабироваться. Более того, вскоре мы должны были расширяться в США, и ситуация становилась все более напряженной. Нам нужна была надежная система, поскольку мы просто не могли позволить себе постоянно находиться в режиме пожаротушения. Откуда взяться времени на новые функции, если все инженерные усилия уходят на поддержание текущей системы?
Мы решили строить новые системы на основе проверенных временем технологий и отойти от имевшихся у нас бескодовых/малокодовых решений. Мы установили несколько основных инженерных принципов, которым необходимо следовать. Это было очень непросто, потому что нам нужно было сохранить компанию и бизнес до тех пор, пока новые системы не приступят к работе.
Снизить риск до минимума
По словам моей коллеги Андреа: Миграция никогда не бывает легкой, и вряд ли она проходит так гладко, как мы надеялись. Нашей целью было снизить риск до минимума, чтобы мы могли быстро реагировать на проблемы, которые могут возникнуть.
Мы разработали стратегию «Думай 10x». Идея заключалась в том, чтобы начать с малого, всего с 10 автомобилей, которые планируется продать, а затем увеличивать масштаб в 10 раз на каждом этапе. 10 автомобилей → 100 автомобилей → 1 000 … 100 000 автомобилей. Этот амбициозный проект был назван «Зеленый дракон».
Первый этап, названный «MVP 10», должен был сосредоточиться на одной части всего процесса подписки на автомобили и запустить в эксплуатацию всего 10 автомобилей, на которые была оформлена подписка с помощью новой системы на нашем сайте.
Применяйте хорошие инженерные практики
Хорошие системы строятся на хороших принципах. Они направляют нас и помогают принимать решения, когда мы сомневаемся. В FINN нам нужны были хорошие принципы для нашего нового этапа, когда мы удвоим технологический потенциал и сделаем наши критически важные системы лучше. Вот инженерные принципы, которые мы заложили в FINN:
- Сохранять простоту: мы хотим решить сегодняшнюю проблему простым способом с прицелом на завтра, а не решать завтрашнюю проблему сегодня.
- Принимать ошибки: Мы работаем в унаследованной среде, где сбои — обычное дело. Мы не хотим бороться с ошибками, мы хотим принять их и проектировать с учетом неудач.
- Сделайте его видимым: Наши сервисы должны говорить с нами, рассказывать нам о том, что происходит, и показывать, насколько хорошо они работают. Мы не хотим ничего выяснять, мы хотим, чтобы нам рассказывали.
- Устранить сложность: Мы не можем изменить то, как работают наши партнеры, но мы можем изменить то, насколько легко им работать с нами.
- Клиент на первом месте: Наши клиенты полагаются на то, что мы предоставим им наилучший возможный опыт, но они также доверяют нам управление своими данными и информацией.
- Данные всегда доступны: мы никогда не хотим мешать людям читать наши данные и всегда должны предоставлять им возможность сделать это без каких-либо усилий.
- Ясный код лучше умного: Мы стремимся к читаемому коду, который легко понять и изменить. Наша цель — написать не наименьшее количество кода, а наибольшую ясность. Магия здесь нам не другОпять же, заслуга в создании этих принципов принадлежит Андреа 🙂
Сокращение сбоев до минимума
FINN является сторонником автоматизации, и мы не хотели нарушать это. Все в FINN знают, как работать с платформой автоматизации Make (ранее Integromat) и используют ее для автоматизации своей работы. Поскольку данные больше не будут столь открытыми, нам нужно было обеспечить возможность для наших коллег использовать новую систему, не выходя из Make. Мы создали пользовательские приложения на Make, которые позволили нашим коллегам использовать наши новые основные API.
Нашим коллегам также нужны пользовательские приборные панели, отображающие различные данные для обеспечения их повседневной работы, такой как контроль и управление ежедневными поставками, управление повреждениями, урегулирование инцидентов и обслуживание клиентов. Им нужны части данных о подписке, данные об автомобилях, финансовые данные и многое другое. Им также необходимо иметь возможность выполнять некоторые действия с этими данными. Для этого мы создали для них приборные панели с помощью Retool, чтобы им не требовался прямой доступ к данным, как в старой системе FINN. Это позволило нам установить валидацию и проверку данных и разрешить запись данных только через наши API, ориентированные на намерения. Это помогло нам сохранить согласованность данных и одновременно упростить доступ к ним.
Где мы находимся сегодня?
Смягчение наших проблем, чтобы заставить текущую систему работать и дать нам немного передышки, чтобы сосредоточиться на разработке новой системы, наверняка напоминает этот известный мем:
Исправление ошибки в производстве GIF | Gfycat
Смотрите и делитесь GIF-файлами «Исправление ошибки в производстве» на Gfycat.
gfycat.com К счастью, благодаря отличной командной работе между отделами и многочисленным группам по устранению неполадок, мы смогли стабилизировать наши текущие системы. Мы восприняли этот проект Green Dragon как возможность показать, на что способны настоящие технологии во всей своей красе. Все были очень энергичны и полны энтузиазма в разработке систем, которые поддержат FINN на следующем этапе роста! Мы вышли на рынок 28 июня 2022 года с фазой MVP 10, а 30 июня продали нашу первую подписку на автомобиль «Зеленый дракон», и мы не сбавляем темп. Огромный респект Андреа Периццато за то, что он возглавил эту инициативу ❤.
Что дальше?
Мы идем полным ходом, перестраивая технологию, на которой работает FINN. Следите за этой темой, чтобы узнать больше о наших технологиях и следующих этапах, которые мы запускаем!
Заключение
No-code — это круто и быстро, он привел нас туда, где мы сейчас находимся, намного быстрее, чем наши конкуренты, но он не поможет нам попасть туда, куда мы хотим. Мы вступили в следующую фазу роста, где мы используем то, чему научились за последние два года, и делаем это еще лучше, надежнее и масштабируемее. Мы внедрили передовые методы, которые будут направлять нас на этом пути, и мы будем продолжать борьбу, пока не достигнем 100 000 подписок на автомобили».
Если вам понравилась эта статья, поставьте лайк и поделитесь ею с другими — это будет очень полезно!
Если вы хотите читать больше на подобные темы, о программной инженерии, продуктивности и т.д., подписывайтесь на меня! Буду очень признателен.
Общайтесь со мной на LinkedIn, я всегда рад поговорить о технологиях, архитектуре и дизайне программного обеспечения.
Наконец, FINN набирает сотрудников! Если вы хотите стать частью этого сумасшедшего роста и работать вместе с потрясающими коллегами, загляните на нашу страницу карьеры или просто свяжитесь со мной 🙂 FINN очень разнообразен и инклюзивен, также рассмотрите нашу программу Women in Tech ❤.