Какие черты стартапа сохранить при масштабировании: кейс IT-отдела Flowwow

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

Все больше данных

В быстрорастущей компании объем информации увеличивается в разы и для ее обработки нужна сложная IT-инфраструктура со своим дата-центром. На старте работы прототип нашего маркетплейса размещался на одном сервере, который был предоставлен компании благодаря гранту.

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

Это стало первой поворотной точкой в трансформации. А вот что было дальше.

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

• Увеличивался и поток посетителей сайта и мобильных версий продукта, что привело к росту базы данных. Та, что мы использовали с момента начала работы, перестала справляться, и потребовалось выстроить систему — репликацию базы данных, чтобы их было столько, сколько нужно.

• Базы были разделены на основную, в которую пишутся заказы, и несколько дополнительных, из которых читаются данные для каталогов, личного кабинета клиентов, и так далее. Их количество составило 10 штук.

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

В стартапах обычно работают до 10 сотрудников. Они тесно взаимодействуют друг с другом, и каждый из них четко понимает свои задачи и зону ответственности. С увеличением бизнеса команда в компании превращается в многоуровневую цепочку, которая пропорционально росту сложных задач становится больше. И такие большие изменения не могут пройти безболезненно.

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

Мы старались все изменения проводить через открытые коммуникации и объяснять сотрудникам:

• что происходит — какие процессы трансформируются, и почему это необходимо;

• как именно будет меняться работа;

• какие появятся возможности у сотрудников и как они могут ими воспользоваться.

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

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

Разные квалификации

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

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

Например, нам требовался архитектор базы данных. Мы знали, что есть определенные слои проблем с базами данных, но у нас не было представления о нужном решении и потенциальных навыках нового сотрудника. Поэтому мы открыли вакансию с расплывчатым описанием, смотрели отклики и проводили собеседования, чтобы со временем понять, кто подойдет на эту должность. Испытательный срок помогал окончательно определиться, соотносятся ли все ожидания с реальностью. Так мы успешно нашли нужных людей.

В переходный период от стартапа к корпорации мидл-разработчики составляют примерно 80% команды и выполняют базовые задачи. Около 15% приходится на сеньор-специалистов, в том числе тимлидов, которые решают сложные вопросы.

Джуны появляются позже, когда не хватает работников на технические позиции. Тогда компании выгоднее взять неопытных специалистов и обучить их, чем указывать в вакансии зарплату на 20–30% выше рыночной. Во Flowwow сейчас нет потребности в джуниор-специалистах в разработке. Однако в течение последнего года компания активно нанимала таких сотрудников в отдел аналитики.

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

Например, на старте работы маркетплейса сотрудники выбрали для себя Spotify-модель, придуманную в одноименной компании: разделились на кросс-функциональные команды по направлениям продукта, которых к началу этого в нашей IT-структуре уже более 30. Появились команды работы с клиентским продуктом, финансовой инфраструктуры, админки для селлеров, чатов и другие.

«Налог» на коммуникацию

С ростом команды увеличивается и количество взаимосвязей, необходимых для решения рабочих задач. Это занимает время и негативно влияет на производительность.

То же самое касается найма и адаптации новых сотрудников. С таким объемом процессов им приходится дольше входить в курс дела и обучаться. Например, когда наша компания была стартапом, разработчик начинал писать код и проявлять эффективность в первую неделю работы, однако сейчас онбординг занимает не меньше трех месяцев.

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

Стабильность дороже скорости

Требования к стабильности работы продукта в корпорации жестче, чем в стартапе. Это связано с тем, что в крупной компании увеличивается стоимость минуты простоя. Если в стартапе невозможность доступа к сайту или приложению может пройти незаметно для пользователей, то в большой структуре даже простой в пару минут способен негативно повлиять на прибыль и репутацию компании.

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

По прогнозам ожидалось увеличение трафика в 10 раз, однако он оказался намного больше. В этот день компания потеряла потенциальную прибыль.*

Чтобы обеспечить стабильность и качество решений, корпорации тратят больше времени на внедрение фичи, чем стартапы. Например, разработчика попросили добавить на сайт кнопку. Чтобы он приступил к ее внедрению, понадобится пройти как минимум три этапа:

• обосновать пользу этой кнопки, объяснить, как она улучшит продукт и сколько денег потенциально принесет компании;

• обсудить с дизайнером, как кнопка будет выглядеть и в каком месте расположится;

• составить описание задачи и передать в разработку.

Дальше кнопке выставят приоритет относительно других задач и определят дедлайн.

Команда получает задачи на одну-две недели (средняя длительность одного спринта), выполняет, сдает, получает новую загрузку — и так по кругу. Когда задача наконец выполнена, кнопка уходит на тест и после успеха этой манипуляции начинается не совсем быстрая процедура выкладки на прод.

В таких бизнесах, как наш, кроме строгого соблюдения выставления задачи на спринт, есть свои особенности работы. Например, во время праздников у компании пиковые по нагрузке периоды и IT-департамент начинает подготовку к ним в среднем за два месяца. В это время технические отделы не принимают в работу другие задачи, которые могут сместить фокус с главного приоритета.

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

Что не брать из стартапа

Вот элементы стартап-подхода, которые могут навредить в более структурированной корпоративной среде.

1. Приоритизация скорости внедрения. Для стартапов характерно стремление выполнить задачу любой ценой, что позволяет быстро тестировать новые подходы. Однако в крупном бизнесе каждое техническое решение требует тщательной проработки.

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

Внедряя новые сервисы, важно проанализировать:

• какие альтернативы существуют на рынке,

• насколько они эффективны,

• как новое решение работает под нагрузкой,

• сколько стоит эксплуатация на рынке,

• получится ли найти специалистов, которые смогут его обслуживать.

2. Зависимость от одного сотрудника. В стартапе уход главного разработчика может привести к долгосрочному простою, так как часто в небольших проектах процессы зациклены на одном или двух специалистах.

Такие сотрудники — носители экспертизы, которая не фиксируется на внутренних ресурсах компании. В крупных компаниях такая практика разрушает проект и может привести к нестабильности бизнес-процессов.

Бизнес конструирует процессы с учетом уменьшения бас-фактора (англ. bus factor — фактор автобуса, в буквальном значении — это число сотрудников, чье гипотетическое попадание под автобус нарушит работу компании). Процессы и важная информация документируются, что позволяет распространять экспертизу среди разных специалистов. Это позволяет сохранять устойчивость при увольнении отдельных сотрудников.