Gismart — о том, почему выбрали плоскую структуру компании и что из этого вышло

Всего три года назад 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.

Сергей Батюков. Мы верим в то, что люди стали работать лучше. Да, всегда есть какие-то накладки. Но чем текущая ситуация отличается от прежней? Тем, что у нас добавилось много внутренних сервисов, которые не видны, но тем не менее они оптимизируют работу компании. Если всё это измерить, то в совокупности получится неплохой коэффициент.

 

Фото: Андрей Давыдчик
 

Источник: dev.by
Теги: Gismart, команды
Нашли в тексте ошибку — выделите её и нажмите Ctrl+Enter.

Обсуждение

Missing-female
+1

>> У нас нет глобального архитектора, который сидит сверху и говорит, кому что использовать. Власть распределена между ребятами, они несут ответственность не только за свой продукт, но и за всё семейство продуктов.

Интересно, а кому-то когда-то реально приходилось "нести ответственность"? Звучит-то это всё хорошо, но, как мне кажется, такое очень легко и незаметно скатывается в полный армагедец, разгребать который потом приходит "архитектор, который сидит сверху"

Missing
+3

Думаю, их главной проблемой в нынешнем виде будет невозможность находить сотрудников, который так же прёт, как пришедших ранее. А там уже да, и до архитектора недалеко :)

Missing-male
+1

Что происходит, если кто-то налажал?

Кто-то встает и говорит "я" ?

Missing-male
+1

Тянут спички. Чувак с короткой больше не фанит.

9d873028274d465dfa5aa366850decc3?1534206070
Alexey Zelenovsky
– Team Lead в Luxoft

Есть же ПМы и продукт оунеры

Missing-male

Имхо, в таких конфигурациях д.б. неформальные лидеры с полномочиями недостающих формальных.

9d873028274d465dfa5aa366850decc3?1534206070
Alexey Zelenovsky
– Team Lead в Luxoft

>>> В пример можно привести ещё разработку для Android, там ребята самостоятельно перешли на язык котлин. Если они видят, как выполнять задачу лучше, то сразу принимают это решение

Ну, так себе пример. На Котлин сейчас все андроидщики переходят. Это как похвалиться переходом с jQuery на react. Вот если бы вы на бекенде c джавы на котлин...

Missing-male

А вот и не все. Я не перешел :)

Считаю это таким же хайпом, как руби на рельсах в свое время. Страсти поулеглись и все заняли свои места.

Missing-female

О, интересно. А вы пробовали разобраться с тем, какие преимущества даёт Котлин разработчику, или так, "Рабинович напел"?

Missing-male

Никаких. Киллер-фич не обнаружено.

Единственный смысл в новом "языке" - иметь хоть какой-то аргумент в тёрках с Ораклом по java. Но это такое себе.

А учитывая, что грядет некий новый Андроид, то...

Missing
+1

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

Missing-male
+1

>> А может, дело не в структуре, а в размере? Вот вас 100 человек, и вы справляетесь. А если вас будет 300?

>> Сергей Батюков. Я думаю, всё получится.

хочется разделить оптимизм, но чудес не бывает, увы... элементарные законы природы... и ни фан, ни agile не спасет...

без прихода к иерархическим моделям с ростом числа сотрудников никак...

Максимум, превращение в некий инвестиционный фонд для стартапов с выступлением обслуги, бэкенда, всей наработанной экспертизы - в виде акселератора. Тут ещё можно представить себе условное "бесконечное" множенье команд и продуктов...


Авторизуйтесь, чтобы оставлять комментарии

Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
datahata — хостинг в Беларуси