В мае 2023 года «Фланту» исполнилось 15 лет. За это время из небольшого предприятия двух друзей-студентов, которые мечтали поставить GNU/Linux на каждый рабочий стол, мы выросли в команду опытных и уважаемых в индустрии DevOps-инженеров и активно трансформируемся в продуктовую компанию с собственной экосистемой продуктов.
В этой статье мы хотели порефлексировать о переходе от сервисной компании к созданию собственных продуктов, рассказать, как эти продукты развивались и что с нами произошло за последние 5 лет.
Сразу обозначим свой «символ веры». Услуга DevOps as a Service (DaaS) была, есть и будет основой нашей продуктовой линейки. Именно благодаря инженерам, которые 24/7 обслуживают сотни клиентских кластеров, мы можем получать максимально быстрый фидбэк по своим продуктам, тестировать новые релизы и собирать кучу новых идей для дорожной карты. То есть в нашем случае услуга, как бы странно для классических продуктовых компаний это ни звучало, является одним из ключевых компонентов продуктовой разработки.
Первые 10 лет: как мы искали свою суперсилу
Первые 10 лет проскочим довольно быстро, хотя именно они заложили основу того «Фланта», который существует сегодня. Мы уже писали статью к своему десятилетию — в ней все рассказано гораздо подробнее. Остановимся лишь на том, что особенно важно в контексте этого материала.
В 2008 году два друга — студенты одной кафедры и тезки — основали «Флант». Всё было пропитано духом авантюризма: любовь к Open Source, романтика, мечты о Linux на каждой рабочей станции. Кстати, именно тогда мы написали свой первый продукт — панель управления . С самого начала мы то и дело писали небольшие утилиты для собственных нужд.
Дальше был долгий период становления бизнеса — причем без поддержки инвесторов и внешней помощи. Мы постепенно определялись с направлением работы: сначала обслуживали «всё под Linux», потом ограничились шестью направлениями, затем — четырьмя. Где-то тут появился и наш первый международный сертификат — мы стали авторизованным партнером Canonical.
В 2015 году мы признали, что основным фокусом все это время были веб-приложения, и «официально» отказались от остальных видов деятельности. А еще спустя небольшое время сузили услуги до обслуживания инфраструктуры на Kubernetes. Да, в Kubernetes и Docker мы поверили практически сразу после их появления, потому что до этого сами, как и некоторые другие игроки рынка, пытались сделать жизнь лучше похожими, но сделанными собственноручно решениями. В частности, у нас был внутренний проект по созданию инструментов для удобного управления изоляцией на базе Linux cgroups…
Когда же мы сделали ставку на Kubernetes, это тоже потребовало определенных «обвязок» — ведь ни для кого не секрет, что технология молода, сложна и очень быстро меняется. Чтобы автоматизировать нетривиальные процессы установки и настройки инфраструктуры, реализации CI/CD, мы регулярно писали скрипты, операторы и какие-то мелкие утилитки для упрощения работы. В частности, было два интересных проекта: dapp (теперь уже werf) и shell-operator.
werf мы начали разрабатывать в 2016 году — он помогал выстроить процессы CI/CD для приложений наших заказчиков быстро и эффективно, а также предлагал унифицированный подход для их дальнейшей поддержки и совершенствования.
А shell-operator позволял писать операторы для K8s на Shell/Bash или Python. Оба инструмента мы в итоге выложили в Open Source и они остаются полностью открытыми по сей день. Подробнее об этих проектах мы ещё расскажем ниже.
В 2017 году мы сделали ставку на Okmeter как систему мониторинга инфраструктуры. До этого наши инженеры уже перепробовали самописные скрипты и веб-приложения, Cacti, Zabbix и другие инструменты, но все было не то. И мы поняли: надо либо делать какое-то полноценное внутреннее решение, либо искать что-то готовое. Делать свое с нуля было бы долго и сложно, а достойный инструмент был нужен «уже вчера»: как минимум, от качества мониторинга зависели штрафные санкции, зафиксированные в SLA, а как максимум — уровень сервиса и наша репутация.
И хотя мы тогда этого не понимали, именно werf, shell-operator и Okmeter стали основой нашей будущей продуктовой экосистемы — причем все они появились в жизни «Фланта» примерно в одно время, в 2016-2017 годах. В последующих разделах статьи мы разберем, как эти продукты эволюционировали, как мы переосмыслили свой подход к их развитию и что с ними происходит сейчас. А в завершении расскажем, какие еще важные события произошли в жизни «Фланта» за последние пять лет.
werf: первый большой Open Source-проект, CNCF и капитан Флинт
В 2016 году мы начали работать над внутренним инструментом под названием dapp, который автоматизировал сборку Docker-контейнеров. Со временем он вырос в решение для управления всем жизненным циклом поставки программного обеспечения в Kubernetes. Это был не первый Open Source-проект «Фланта», но по масштабам он заметно превосходил все предыдущие.
Dapp стал не просто какой-то небольшой утилиткой, он оказался связующим звеном для ряда других решений и процессов, превратившись в важный инструмент, который наши инженеры ежедневно использовали в работе. В нем мы реализовали свое видение того, «как делать правильно»: годами мы накапливали лучшие практики, оттачивали процессы CI/CD и наконец сумели автоматизировать их с помощью собственного программного решения.
Когда ты оказываешь услуги, самое лучшее, что можно сделать для повышения эффективности — это унифицировать процесс оказания услуг. Dapp как раз выступил в качестве единого каркаса для построения процессов CI/CD в разных проектах, имеющих разные особенности и требования.
Со своей задачей утилита справилась: реализация CI/CD-пайплайнов была значительно упрощена, а инженеры получили что-то вроде тюбика клея, который позволял объединять и адаптировать под каждый проект стандартную связку популярных инструментов: Docker, Git, Helm, Container Registry, Kubernetes. Так у нас появился полноценный внутренний продукт.
Кстати, именно таким путем изначально рождались все наши продукты: мы делали что-то под себя, а потом понимали, что ценность в этом есть и для внешнего сообщества.
Из dapp в werf
Однако с dapp возникла небольшая проблема: название со временем стало все больше ассоциироваться с разными блокчейнами. Поэтому 22 октября 2018 года мы начали придумывать для него другое название. Конечно, за основу взяли морскую тематику, моду на которую в DevOps-тусовке ввел Docker, а потом поддержал знаменитый «Кормчий» — и речь не про старину Мао😁 По итогам обсуждений мы остановились на названии werf (на русском произносим как «верфь»).
Как мы выбирали название для werf
Первым вариантом был flint. Тут и знаменитый пират, и перекличка с Flant, и даже Flant Integration. Но в топик тут же набежали хейтеры (такова демократия!), которым новое название не понравилось:
Чтобы не зацикливаться на герое «Острова сокровищ», мы даже пошли изучать статью на Википедии про морские термины. Но основная часть терминов из статьи уже была занята в доменной зоне io. Мы почти отчаялись, и даже поступило предложение потроллить своим названием всех морячков из экосистемы K8s.
Конечно, не обошлось и без Евгения Ваганыча и превращения айсберга в assberg… Попробовали даже рынду😁 И тут Тимофея осенило (он, кстати до сих пор работает над werf):
werf — слово голландское и означает оно, собственно, верфь. Ту самую, судостроительную. На всякий случай пробежались по пиратским напиткам и оскорблениям вроде bastardo и даже был вариант kuklos — но вспомнились разные белые колпаки и он тут же отпал.
В 2019 году мы зарелизили документацию на русском языке, а 14 января 2020 вышла стабильная версия 1.0 — и werf стала взрослым проектом.
Однако мы не только выложили werf в Open Source — со временем мы передали все права в Cloud Native Computing Foundation, некоммерческую организацию, которой принадлежат права и на Kubernetes. Официально передача прав состоялась 13 декабря 2022 года. При этом мы до сих пор управляем развитием проекта и являемся его ключевыми мейнтейнерами.
werf остается полностью некоммерческим Open Source-проектом, который делает наше производство более эффективным и за годы своего существования сформировал вокруг себя устойчивое сообщество внешних пользователей.
Развитие werf как продукта
Процесс развития werf — классика для технических Open Source-инструментов, которые выросли из внутренних проектов: мы собираем хотелки со своих инженеров, мониторим вопросы в чате werf (eng-версия), выступаем с докладами на российских и международных конференциях, пишем статьи, проводим опросы. Это — наш feedback loop и главный источник пополнения бэклога. Кроме того, команда разработки werf постоянно следит за конкурирующими решениями в российском и международном коммьюнити.
Несмотря на то, что главной целью werf изначально были ускорение и автоматизация наших внутренних процессов, мы уже достаточно давно развиваем ее не только для себя — постоянно находясь в поиске баланса между удовлетворением собственных потребностей и запросов от сообщества.
Утилита пришлась по душе пользователям, сегодня у нее уже 3,6k звезд на GitHub — можно поставить звездочку и от себя.
Кстати, если вы используете werf в работе, напишите нам в чат или в комментариях под этой статьей — мы хотим описать несколько кейсов и вообще поговорить о том, как ее используют за пределами «Фланта».
Дополнительные источники
-
Самоучитель по CI/CD с werf для разработчиков
-
Первые шаги с werf: собираем и деплоим простое приложение в Kubernetes
-
werf — наш инструмент для CI/CD в Kubernetes (обзор и видео доклада)
Deckhouse: от Bash-скриптов до полноценной Kubernetes-платформы
Вернемся к другому нашему Open Source-проекту — shell-operator. Мы обслуживали инфраструктуру клиентов и постоянно писали скрипты для автоматизации различных задач, в том числе связанных с K8s. Операторы — рекомендованный способ автоматизации задач в Kubernetes, и со временем мы пришли к логичному пониманию, что нам нужен инструмент, который упростит и ускорит автоматизацию небольших задач силами DevOps-инженеров и системных администраторов. Обычно они знают Python и Shell/Bash, а вот Go, нативный язык для операторов под Kubernetes, — гораздо реже.
Так появился shell-operator, который позволяет подписаться на события от объектов Kubernetes, а когда получает их, автоматически запускает какую-то внешнюю программу (например, Bash- или Python-скрипт) и передает в нее информацию о событии.
Из shell-operator в Deckhouse
Вообще, изначально shell-operator был неотъемлемой частью куда большего продукта — будущей Kubernetes-платформы. Но мы увидели в нем явный потенциал для прямого применения другими инженерами и решили выделить в отдельный проект, опубликовав как Open Source на GitHub в 2019 году.
В то же самое время, благодаря существованию shell-operator, мы написали кучу модулей и операторов для настройки и автоматизации задач, связанных с Kubernetes. Делая многочисленные автоматизации на Bash, мы сразу четко осознавали, что это лишь временное решение — некий proof of concept. И когда это решение прошло проверку и заработало в реальных кластерах так, как нам надо, мы планово перешли к его переделке в нормальный вид — стали переписывать его на Go.
О какой будущей платформе идет речь? Обслуживая многочисленные Kubernetes-кластеры, мы естественным образом пришли к созданию собственного K8s-дистрибутива, который собрал бы все наши скрипты, патчи, интеграции и другие дополнения в единую систему.
Первый коммит в свою Kubernetes-платформу, тогда еще закрытый внутренний проект под названием antiopa, мы сделали 24 сентября 2017 года. Создавая его, мы не стремились повторить путь других международных проектов или импортозаместить их — мы просто упаковывали в удобный (для себя же) формат тот опыт с Kubernetes, который накопился за годы работы с этой технологией.
В основу разработки платформы были заложены три принципа:
-
Она работает с ванильным Kubernetes. Никаких доработанных напильником форков, которые надо поддерживать и развивать отдельно от эталонной ветки, получая постоянные проблемы с синхронизацией функций и закладывая в инфраструктуру бомбу замедленного действия в виде кастомной версии K8s. Мигрировать с такой самоделки на ванильный Kubernetes потом будет мучительно.
-
Платформа должна быть Open Source-продуктом.
-
Все компоненты платформы должны обновляться максимально автоматически: вышла новая версия, запускаешь обновления — получаешь обновленный набор инструментов, в которых сохранены все настройки и учтены особенности новых версий всех компонентов, зависящих друг от друга.
5 августа 2019 года мы стали выбирать название для это Kubernetes-платформы: в то время это был внутренний инструмент для использования в DaaS-командах, которые обслуживали клиентов, но мы уже понимали, что наша разработка может заинтересовать и более широкий рынок. В обсуждении всплывали самые разные варианты — от «Штурвала» и «Штурмана» до QUbertenas (не спрашивайте😅) и KFC (kubernetes flant cluster), но в итоге мы остановились на Deckhouse (корабельная рубка).
В апреле 2020 года произошла первая обособленная от услуги DevOps as a Service продажа программного решения. Так мы подтвердили гипотезу о том, что отечественная Kubernetes-платформа может быть востребованной не только на клиентских проектах по обслуживанию Kubernetes-инфраструктуры.
Выход в Open Source и бизнес-модель
28 июля 2021 года Deckhouse уже появился в публичном репозитории на GitHub, были официально анонсированы две версии: бесплатная Community Edition и платная Enterprise Edition. Со стороны это может показаться чем-то довольно простым — вот есть исходники, вот они залетают на GitHub — но внутри была проделана колоссальная работа.
Что мы подготовили к публичному релизу:
-
Переработали и дополнили техническую документацию.
-
Создали телеграм-канал и чаты для общения с пользователями бесплатной версии.
-
Создали сайт deckhouse.io (на двух языках).
-
Написали руководство по началу работы с продуктом (Getting Started).
-
Начали собирать команду продаж Deckhouse (до этого мы продавали только услуги DaaS).
Уже 6 августа 2021 года, спустя неделю после выхода в Open Source, Deckhouse прошел сертификацию CNCF, а в декабре был включен в реестр отечественного ПО. Примерно в то же время в команде Deckhouse появился первый продакт-менеджер.
В 2022 году мы прошли проверку на соответствие рекомендациям PCI Security Standards Council, сертифицировались для работы с «Ред ОС», Astra Linux и AlterOS.
2023 год тоже был богат большими событиями. В феврале команда разработки добавила в Deckhouse модуль Virtualization на основе KubeVirt, который позволяет управлять виртуальными машинами с помощью Kubernetes, а в марте — модуль Delivery на основе werf и Argo CD для непрерывной поставки приложений в Kubernetes. Вовсю кипит работа над Deckhouse UI и сертификацией ФСТЭК.
Бизнес-модель Deckhouse и переосмысление понятия «продукт»
Бизнес-модель напрашивалась сама собой: мы верим в идеалы Open Source и хотим его продвигать, поэтому казалось естественным, что код Deckhouse будет открыт. Делать свое облако с Deckhouse и продавать его было бы слишком трудозатратно, а вот продавать лицензию на софт по модели Open Core — самое то для компании, которая любит Open Source.
В платной версии Deckhouse EE есть набор дополнительных фич, но она полностью основана на бесплатной версии (CE). То есть Deckhouse CE — реально работающая платформа, на которую мы даже помогаем переехать с enterprise-версии тем клиентам, которые перестают у нас обслуживаться в рамках услуги DevOps as a Service.
Кстати, если вы используете Deckhouse Community Edition — напишите нам в чат или в комментариях к этой статье, нам интересно, как CE запускается и работает без нашего участия, какие проблемы возникают и т.п.
Публичный релиз и начало продаж Deckhouse очень сильно повлияли на всю компанию — вот что мы поняли:
-
Нужна отдельная команда для второй линии поддержки. Раньше на этой линии дежурили разработчики платформы, но теперь они «переехали» на третью и даже четвертую линии.
-
Чтобы соответствовать ожиданиям рынка и потребностям клиентов, необходимо наращивать команду разработки.
-
Продуктовая работа — это не только разработка ПО. Это и огромная обвязка вокруг продукта: упаковка, документация, сайт с контентом, презентации и КП для клиентов, постоянный мониторинг конкурентов и сравнение с конкурентами по запросу от потенциальных клиентов, культура проведения клиента по воронке продаж, пилотные внедрения, фиксация результатов, работа над болевыми точками клиента, пиар и маркетинг, постоянная рефлексия.
Дополнительные источники
-
Устанавливаем Kubernetes-платформу Deckhouse в закрытом окружении. Пошаговая инструкция
-
Как устроена разработка Kubernetes-платформы Deckhouse (обзор и видео доклада)
-
Российский Kubernetes, какой он? Знакомимся с платформой Deckhouse
Покупка Okmeter и мониторинг инфраструктуры
История Okmeter для нас — еще одна ступенька взросления компании. Одно дело — создавать собственные продукты и оказывать услуги, и совсем другое — купить готовый проект и начать вести его самостоятельно.
Как мы уже упоминали, Okmeter был сторонним проектом, который мы с 2017 года использовали для мониторинга в рамках услуги DaaS. Какое-то время мы были основными пользователями системы — возвращались с обратной связью, делились своим опытом и подходами к мониторингу, просили добавить какие-то фичи и т.п. У нас даже были своя инсталляция Okmeter (хотя в основном он продавался по модели SaaS) и отдельный личный кабинет, в который мы заводили своих клиентов.
Спустя несколько лет после начала работы с Okmeter мы поняли, что нам хочется все больше и больше влиять на процесс разработки инструмента и он хорошо вписывается в экосистему продуктов, которые мы уже планировали активно развивать. Мы пообщались с основателями Okmeter и оказалось, что у них есть идеи для новых продуктов, за которые им хотелось бы взяться более активно (кстати, недавно мы как раз написали обзор на их новый инструмент — Coroot.). Сделка была взаимовыгодной: команда Okmeter получала ресурсы для разработки новых продуктов, а мы дополняли свою экосистему классным и хорошо известным нам готовым решением и могли развивать его так, как нам интересно.
В мае 2021 года мы провели сделку, в результате которой Okmeter окончательно стал нашим стандартом для мониторинга железа, серверов, баз данных, приложений.
Так как мы уже продолжительное время были сильно завязаны на Okmeter и уже хорошо знали его, сделка не казалась чем-то страшным. Конечно, определенные проблемы были: например, Okmeter базировался на самописном ядре хранения и обработки метрик, в котором был настоящий винегрет из технологий хранения данных — Elasticsearch, Kafka, Cassandra, PostgreSQL и т.д.
К весне 2023 года мы перевели все хранение данных на Grafana Mimir. Это заняло у нас примерно год: пришлось долго разбираться в чужом коде, обсуждать, как Okmeter будет развиваться дальше, переносить данные — да и ресурсы разработки были ограничены. Переход на новое ядро прошел бесшовно и незаметно для клиентов: мы сконвертировали и заменили все данные на лету. Okmeter стал работать ощутимо стабильнее.
Первые несколько месяцев после покупки были очень увлекательными: у тебя есть готовый код, но нет прежней команды команды разработки, только возможность консультироваться с ней. И тут выясняется, что в коде куча нюансов и всяких неочевидных моментов. Но за пару месяцев мы освоились с кодом, и дальше уже работа пошла гораздо быстрее.
Сейчас Okmeter включен в единый реестр российского ПО и существует в двух вариантах: on-premise и SaaS. Кроме того, он входит в состав Deckhouse EE.
Дополнительные источники
-
Мимо тёщиного дома я без метрик не хожу (обзор и видео доклада)
-
Мониторинг PostgreSQL. Расшифровка аудиочата Data Egret и Okmeter
Что еще случилось за последние пять лет
Помимо работы над тремя продуктами, мы продолжали развивать свое DaaS-направление и совершенствовать понимание бизнес-потребностей клиентов. Последнее давалось с трудом, потому что мы в первую очередь компания инженеров и больше привыкли к общению с техническими командами. Итак, что же еще у нас произошло за последние пять лет?
Осенью 2018 года наши инженеры начали получать первые международные сертификаты Certified Kubernetes Administrator (CKA), которые выдает Cloud Native Computing Foundation (CNCF). Это позволило наладить внешнюю, объективную проверку навыков наших инженеров и дать им дополнительный инструмент для повышения собственной профессиональной ценности. В январе 2019 года мы получили «корочки» для всей компании, став первым Kubernetes Certified Service Provider (KCSP) и Silver Member в CNCF из России.
В мае того же года мы начали активно выходить на крупный бизнес и запустили услугу «Kubernetes для enterprise». В рамках этой услуги мы предлагали крупным компаниям развёртывание и поддержку кластеров Kubernetes с применением своих лучших практик, а также обучение инженеров заказчика работе с этими кластерами. При этом за эксплуатацию рабочих нагрузок, размещенных внутри кластеров, отвечали внутренние команды клиента, а мы сопровождали и оказывали поддержку исключительно по K8s.
Но по-настоящему фокусироваться на enterprise-сегменте мы начали только спустя пару лет. И тут же столкнулись с проблемой: мы не умели работать с enterprise, не понимали его. Мы привыкли продавать свои услуги в СМБ-сегменте и говорить на языке простых технических и финансовых выгод: «Мы сделаем вот так и получится вот это». С крупными клиентами такой подход работает хуже: во-первых, в процесс переговоров вовлекается гораздо больше лиц, принимающих решения, а во-вторых, сами потребности enterprise могут быть очень далеки от понятных и прозрачных потребностей небольших компаний.
Мы начали выращивать собственные компетенции, но процесс шел слишком долго. И стало понятно, что это не очень продуктивный подход — нам нужен качественный прорыв. В 2022 году появилась такая возможность: компания Oracle ушла из России, и мы пригласили ее команду продаж во «Флант». Специалисты из Oracle имели огромный опыт взаимодействия с enterprise-сегментом, обладали обширными наработанными связями, а потому сумели в кратчайшие сроки выстроить работу с крупными клиентами и у нас.
Параллельно с развитием технической и бизнес-части «Фланта» росла и команда. В апреле 2021 года, за несколько месяцев до публичного релиза Deckhouse, нас уже было больше 100 человек — и с тех пор мы выросли еще вдвое. По состоянию на июнь 2023 года флантовцев уже более 200. Причем мы не останавливаемся: например, у нас идет активный наем Golang-разработчиков в продуктовые команды.
DaaS мы тоже никогда не забывали. И хотя там все менялось не так бурно — за долгие годы мы наработали огромный опыт, у нас сложились свои отработанные подходы и практики — возможности для улучшений есть всегда.
Во-первых, мы начали передавать отдельные направления в специализированные команды, чтобы DevOps-инженеры не отвлекались на лишние задачи. Например, выделенная команда полностью занимается поддержкой платформы Deckhouse, которая входит в состав услуги DaaS.
Во-вторых, у нас начали складываться гильдии — неформальные горизонтальные объединения специалистов по разным направлениям из разных команд. Такие объединения делятся узкой экспертизой, вырабатывают стандарты и подходы к работе, обмениваются новостями индустрии. Например, участники гильдии по базам данных могут брать на себя соответствующие задачи в своих командах или консультировать коллег.
В-третьих, постоянно эволюционируют и наши процессы работы над клиентскими проектами, система менеджмента. Состояние системы на 2019 год зафиксировали и подробно описали в своих докладах наш основатель Дмитрий Столяров и менеджер проектов Сергей Гончарук. А об изменениях последних трех лет все тот же Сергей рассказал в своей недавней статье «Большая перемена: как за 3 года мы пересмотрели управление проектами во „Фланте”».
Не забывали мы и про Open Source. В 2018 году мы выложили в открытый доступ плагин Grafana Statusmap panel, который позволяет отобразить состояние набора объектов за выбранный промежуток времени (и на сегодня его скачали более 35 миллионов раз!), и kubedog, Go-библиотеку и CLI на её основе для отслеживания событий ресурсов Kubernetes. В апреле 2022 года выпустили утилиту trdl для непрерывной и безопасной доставки обновлений (мы используем её для werf, но проект может оказаться полезным и отдельно от нее).
Кроме того, мы активно работаем над многими международными Open Source-проектами — например, в 2023 году наконец довели до релиза два KEP (полноценных фичи) в рамках системы аутентификации Kubernetes. Первый добавил API для просмотра атрибутов текущего пользователя после завершения процесса аутентификации, а второй обеспечивает удобный способ конфигурации OIDC и является крупнейшим обновлением в аутентификации за последние годы.
Дополнительные источники
-
Управление распределенной командой в режиме многопроектности (обзор и видео доклада)
-
Большая перемена: как за 3 года мы пересмотрели управление проектами во «Фланте»
-
Kubernetes 1.26: обзор нововведений, включая первый KEP «Фланта»
Итог
Хотя прошло уже 15 лет, мы все так же продолжаем бурно расти и развиваться. У нас есть амбициозные цели — как по найму, так и по доле рынка, на которую мы рассчитываем.
При этом нашей главной ценностью остается команда — мы стремимся, чтобы каждый сотрудник «Фланта» мог свободно предлагать свои идеи, задавать острые вопросы, открыто обсуждать радости и печали. По нашему убеждению, только такая прозрачность по отношению к команде позволяет «Фланту» делать качественные востребованные технические продукты и поддерживать высочайший уровень инженерной культуры.
Именно поэтому мы прикладываем так много усилий, чтобы при качественно выстроенных комфортных процессах и зрелом подходе к ведению бизнеса сохранять атмосферу молодости, свободы, энтузиазма и творчества — то, что принято называть духом стартапа.
За все годы существования компании мы не раз пересматривали систему менеджмента, коммуникации, подходы к организации работы. В итоге, как нам кажется, мы нашли свой дзен: очень теплую и человечную удаленку, в которой горизонтальные связи между участниками команды не только сохраняются, но и укрепляются и даже переходят в оффлайн — мы знаем это, потому что в одном из наших Slack-каналов постоянно мелькают фото с личных встреч флантовцев в разных городах и странах.
И насколько бы амбициозными ни были наши планы, мы знаем, что они осуществляются только благодаря точечному вкладу каждого участника команды. Хотим поблагодарить всех, кто был с нами раньше, кто сопровождает нас в этом большом и увлекательном путешествии прямо сейчас, кто доверяет нам свою инфраструктуру и верит в наши продукты или, например, просто читает статьи в нашем блоге. Все это стало возможным только благодаря вам!
P.S. Ну что, встретимся в новой статье еще через 5 лет?😉
Автор: Тимур Тукаев
