Всего три года назад Gismart была маленькой компанией, сотрудников которой можно было пересчитать по пальцам. За год она увеличилась вдвое, а потом начала расти в геометрической прогрессии. Сегодня над музыкальными приложениями Gismart работают 120 человек. В какой-то момент основатели задумались, как стартапу в период роста не превратиться в классическую вертикальную корпорацию, и решили взять за основу плоскую структуру управления. О том, что из этого вышло, группа руководителей Gismart рассказала dev.by.
В беседе приняли участие сооснователь и CTO Gismart Александр Минец, руководитель бэкенд-разработки Сергей Батюков и директор инжиниринга Сергей Щегрикович.
«Потом нас стало 40, но производительность в 4 раза не увеличилась. Почему?»
Откуда взялось предубеждение против классической иерархической структуры? Чем для стартапа она нехороша?
Александр Минец. Какое преимущество у маленьких команд? Скорость и подвижность. Так как все близки друг другу, то решения принимаются быстро, продукты на рынок выкатываются тоже быстро. Когда компания растёт, появляются дополнительные расходы на переговоры и согласования. И если не взять контроль в свои руки, то много времени будет тратиться на непонятные переключения и синхронизацию. Но как сохранить дух маленькой команды, когда команда уже немаленькая? Это челлендж.
Был период, когда мы росли по чуть-чуть. Пытались не разрушить наш стартапчик, аккуратно вводили в команду по 1-2 человека. Но критическая масса всё равно наросла, и когда мы увидели перспективу на годы вперед (не только симуляторы музыкальных инструментов, но и сегмент мэйнстрим-продуктов в области развлечений), то поняли, что нам необходимо гораздо больше людей. Соответственно надо было продумать, как с такими размерами двигаться вперёд.
Сергей Щегрикович. Интуитивно кажется, что при росте компании надо выстраивать какую-то иерархию, ставить людей в подчинённую позицию. В каких-то сферах это, наверное, и правильный подход. Но в ИТ-индустрии, особенно в продуктовых компаниях, это не очень работает, поэтому мы решили пойти другим путём.
Мы сохранили структуру относительно независимых продуктовых команд и добавили к ним сервисные команды, которые обслуживают потребности продуктовых. Основная идея такой модели — оставить свободу инициатив и принятий решений именно тем людям, которые работают в продуктовых командах.
Вы в какой-то момент почувствовали, что становитесь вертикалью, и нажали на тормоз?
Александр Минец. Не совсем так, вертикальными мы никогда не были. Когда-то нас было 10 человек, и мы выдавали определённое количество фичей. Потом нас стало 40, но производительность в 4 раза не увеличилась. Мы призадумались: что происходит? Где рост 4x?
Сергей Щегрикович. Вопрос в том, как при росте команды сохранить скорость изменений и не получить эффект bottleneck (бутылочного горлышка). Если мы ставим менеджера во главе какого-то направления, то он как раз и становится этим узким местом. Менеджеру приходит миллион е-мэйлов, и он волей-неволей затормаживает принятие решений.
Круто, когда нет менеджеров, ответственных за какое-то направление, а есть продуктовая команда, вокруг которой всё строится. Именно команда даёт ценность компании, и надо сделать так, чтобы ей было удобно работать и чтобы она быстро давала фичи.
Стали смотреть по сторонам и выбирать: есть одна модель, есть другая. В итоге за образцы выбрали модель SAFe (Scaled Agile Framework) — набор правил и предписаний для внедрения agile-принципов в больших организациях и ту, что сформировалась у компании Spotify. Решили взять лучшее из обеих моделей.
Главный принцип — быстрый фидбэк. C незапамятных времен рецепт разработки правильной фичи такой: напиши первую версию и выброси, получи быстрый фидбэк и перепиши нормально.
«Никто не ходит и не спрашивает, что ему делать»
Давайте нарисуем структуру вашей компании. Продуктовые команды — по названиям основных продуктов?
Александр Минец. Да. У нас пять продуктовых команд: Piano team, Guitar team, Beat Maker team, Karaoke team и Edutainment team. Каждая команда ведёт 1-3 проекта. Во главе каждой команды стоит Project Manager, во главе каждого продукта — Product Owner. Плюс есть есть сервисы, которые обслуживают все команды: это Back-end, Business Intelligence и маркетинг. Над командами стоят сооснователи, которые решают бизнес-задачи.
Планы по дальнейшему росту есть?
Да. К концу года должны вырасти до 150 человек. У нас появляется всё больше новых проектов, открываются новые продуктовые направления, количество сотрудников будет расти пропорционально.
Эти люди вольются в уже существующие команды?
Кто-то вольётся в уже существующие, но также планируем формировать новые. У нас такой подход: мы наполняем команды, а когда чувствуем, что они стали слишком большими, забираем от каждой команды часть людей и формируем новую.
Как части этой структуры взаимодействуют между собой?
Каждая команда фокусируется на своих продуктах, пытается развивать их в своём направлении, а Business Owners следят, чтобы все направления сходились в одной точке. Поэтому мы и выбрали SAFe: мы ожидаем, что этот фреймворк поможет нам синхронизировать команды (чтобы одна и та же работа не дублировалась) и держать основной вектор. Чтобы всё было рационально.
Вот есть пять продуктовых команд, куча разных проектов, а по факту ребята работают с одной кодовой базой. Продукты разные, а база у всех одна. Тут можно и нужно синхронизироваться — тогда появляются моменты общего планирования, фича доставляется не в один продукт, а в несколько.
Сергей Щегрикович. Другой пример: одни команды делают фичи, а другие берут на себя технический долг. По прошествии времени встаёт вопрос: где работа одной команды, а где другой? Благодаря SAFe мы видим, какая команда сделала техдолг для другой команды, и почему их фичи выйдут только в следующем месяце.
Вертикальная структура для этих целей кажется более рациональной, в ней проще контролировать процессы и избегать повторов.
Не факт. Контроль, с одной стороны, это хорошо. С другой стороны, он убивает инициативу, скорость и поворотливость. Тут надо найти золотую середину, чтобы и сохранить контроль над процессами, и дать возможность командам самостоятельно принимать решения, без участия менеджеров. Сейчас ребята, видя ближайшие релизы, имея всю необходимую информацию, не ходят и не спрашивают, что и в какой последовательности им делать. Они и так знают, что им делать и как.
Контроль — это не самоцель. Когда в компании есть доверие, то контроль — это просто наблюдение за тем, что происходит.
Когда обсуждается бизнес-задача на уровне фаундеров, вы же не идете к разработчикам и не спрашиваете их мнение, брать или не брать инвестиции, выпускать ли новый продукт.
Понятно, что хай-левел остается за фаундерами, иначе и быть не может. Допустим мы хотим войти на рынок караоке, вопрос: как нам это сделать? Сначала получаем видение бизнес-оунеров, потом подключаем к обсуждению команды.
А я, допустим, как разработчик сижу и думаю: оно мне надо? Я, может, не люблю караоке.
Если у разработчика идея вызывает такое отторжение, он, наверное, подойдёт к кому-нибудь и попросит перевести его в другую команду. Скажет, я хочу делать «гитару», а не караоке. И всё, переведём.
Инициатива снизу — профит на ровном месте
Приведите примеры удачной инициативы снизу в Gismart.
Сергей Батюков. Например, снизу, из бэкенд-команды, пришла идея попробовать CDN (Content Delivery Network) — систему, которая позволяет распределённо, независимо от географического положения, быстро и надёжно доставлять контент пользователям.
Наши мобильные приложения, по сути, являются потребителями массивного контента с бэкенда — медиафайлов, картинок и т.д. На это тратится большое количество ресурсов — процессорное время, сервера, трафик. CDN — это технология, которая позволяет сэкономить 90% ресурсов на бэкенде. Находится ли пользователь в Бразилии или Индонезии, наш контент доходит до него из локального кэша очень быстро. CDN позволяет нам экономить порядка 5 терабайт трафика в месяц.
Александр Минец. Так было не всегда. Сначала мы использовали более простые решения, но люди из бэкенд-команды вышли с инициативой CDN и сказали, что лучше сделать вот так.
Ещё пример: тестировщики как-то озвучили проблему с текущими системами тестирования приложений. Девелоперы делали бета-версию приложения, заливали её на сторонний сервис, который потом раздавал её тестировщикам, и с этим постоянно возникали какие-то сложности. Пока зальёшь, пока скачаешь… Кто-то предложил написать свой сервис для загрузки бета-приложений. Мы его написали и тем самым сократили время доставки и загрузки бета-версий наших приложений в 2-3 раза. Послушали идею, написали и на ровном месте получили профит.
Думаете, в вертикально структурированной компании это предложение не прошло бы? В Wargaming нам недавно рассказывали, как раскачивают инициативу в рамках классической структуры.
Александр Минец. Насколько быстро можно было бы поменять процесс для всего отдела QA? Мне кажется, пришлось бы долго ждать. В случае с CDN надо было бы доказать сначала, что он сильно нужен. Потом обосновать, почему именно этот CDN, а не другой. У нас это произошло достаточно быстро, и уже сейчас, спустя месяц-два, мы видим результаты.
Сергей Щегрикович. В пример можно привести ещё разработку для Android, там ребята самостоятельно перешли на язык котлин. Если они видят, как выполнять задачу лучше, то сразу принимают это решение. У нас нет глобального архитектора, который сидит сверху и говорит, кому что использовать. Власть распределена между ребятами, они несут ответственность не только за свой продукт, но и за всё семейство продуктов.
Сергей Батюков. Классическая иерархическая структура фокусируется на процессах, а не на людях. То есть процессы навязываются сверху, и их смысл зачастую остаётся непонятным для команд. Допустим, бэкенд-команда должна выполнить задачи, следуя чётким приоритетам: раз, два, три. Но это не всегда разумный порядок, который приводит к максимально быстрому результату. Здесь у нас есть право голоса. Сервисная команда может сказать: мы лучше сделаем это в оптимальном порядке, чтобы избежать проблем в будущем.
Денежная мотивация не работает. А что работает?
Как целенаправленный переход на SAFe изменил работу сервисных команд?
Сергей Батюков. Мы провели качественное планирование, и теперь краткосрочные планы нам более понятны.
Раньше всё было анархично: люди из продуктовых команд приходили и просили сделать что-то побыстрее, хотя бэкенд-команда в это время занята другими задачами. SAFe-планирование позволяет нам понять, чем будет заниматься команда в ближайшие 1-2 недели. Это не отлитый в бронзе план, но некий ориентир для всех продуктовых команд и для бэкенда: на чём сфокусироваться, чтобы идти нога в ногу.
Сергей Щегрикович. В SAFe особо выделяется роль архитектора. В обычном понимании представляется, что архитектор — это такой мужик, который сидит перед тысячей экранов и всем управляет. В agile архитектор не должен знать ответы на все вопросы, он должен соединять людей из разных команд. И в нашей компании разработчики знают, к кому подойти, если хотят внести предложение.
Люди, которые занимаются продуктом, могут оценить свой результат с помощью маркетинга, для разработчика бэкенда критерии успешной работы другие: написано ли это хорошо или плохо, сколько запросов в секунду выдерживает сервис. Если на бэкенде всегда оставлять технический долг, то есть делать что-то плохо в угоду скорости выпуска продукта, то теряется удовлетворённость от работы, и у людей быстро накапливается разочарование.
Люди должны быть самомотивированы. Денежная мотивация работает 2-3 недели. А что дальше? Красивый офис, плюшки? Лучшая мотивация для разработчика — свобода самостоятельно решать, как сделать лучше, и гордость за выполненную работу. В случае с бэкендом это понимание того, что ты участвовал в задачах, которые принесли пользу конкретным продуктам.
А может, дело не в структуре, а в размере? Вот вас 100 человек, и вы справляетесь. А если вас будет 300?
Сергей Батюков. Я думаю, всё получится. С ростом корпорации растёт и число людей, которые её обслуживают. В больших компаниях есть вертикаль, а есть команда, которая выполняет задачи. Меняется один менеджер, и команда ещё 3-4 месяца работает над вещами, при этом не понимая их смысл. Так происходит потому, что в энтерпрайз-командах есть инерция принятия решений и нет персональной ответственности за то, что происходит. В корпорации людей умышленно делают частью процесса, винтиками: так ими проще управлять.
Одно дело, когда своей идеей сотрудник делится с человеком из вертикали, и запускается бюрократический процесс. И совсем другое, когда когда человек предлагает сделать коллегам что-то новое, и это сразу же внедряется в жизнь.
Ребята, приходя к нам из аутсорса, начинают мыслить продуктово. Да, это занимает время, но бенефиты (когда тебе не надо каждый день говорить команде, что делать), того стоят.
Как стиль управления в стране влияет на бизнес-отношения
Конфликты в командах происходят?
Сергей Щегрикович. Конечно. Как и везде. Иногда из-за расписания, иногда из-за зон ответственности. Конструктивные конфликты должны быть.
Александр Минец. Я не помню серьёзных конфликтов.
Сергей Батюков. Атмосфера в Gismart сама по себе очень «фановая». Люди с удовольствием берутся за задачи, которые им интересны. Этот фан — везде, и он сглаживает углы. У ребят есть общая цель, она прозрачна, мы доверяем друг другу. И если человек задаёт какие-то вопросы, ты знаешь, это потому, что он хочет сделать лучше, а не потому, что он хочет поставить под сомнение твою позицию.
Легко поддерживать «фан», когда вас 5-10 человек.
А у нас фан при 120-и.
Не бывает, чтобы все 120 человек «фанили». Кто-то приходит просто деньги зарабатывать.
Фан сохраняется за счёт того, что каждая команда — это мини-компания внутри большой. Вот они там себе и веселятся.
Сергей Щегрикович. Главное препятствие созданию такой структуры, которая сама принимает решения, это наша культура. Есть даже исследование на тему того, как стиль управления в стране влияет на бизнес-отношения, располагает ли он к силовым методам или нет.
Почему шведская компания Spotify смогла построить плоскую структуру, основанную на доверии? Потому что в Швеции — распределённая структура управления в обществе. Наша же страна тяготеет к силовому методу. Должен ли босс иметь ответы на все вопросы? В России и у нас 75% опрошенных отвечают «да» на этот вопрос, а в Швеции — только 7%.
Поэтому главная проблема — мы сами, мы сражаемся сами с собой. И нам нужен этот фан, чтобы учиться доверять друг другу.
Какие недостатки вы видите в выбранной модели?
Мы в начале пути. Поэтому пока сложно сказать, какие будут препятствия и насколько это взлетит.
А вам удалось получить желаемый коэффициент, восстановить пропорцию «количество людей — количество фичей»?
Александр Минец: у нас сейчас 11 продуктов, а было 4.
Сергей Батюков. Мы верим в то, что люди стали работать лучше. Да, всегда есть какие-то накладки. Но чем текущая ситуация отличается от прежней? Тем, что у нас добавилось много внутренних сервисов, которые не видны, но тем не менее они оптимизируют работу компании. Если всё это измерить, то в совокупности получится неплохой коэффициент.
Фото: Андрей Давыдчик
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.