Должен ли босс иметь ответы на все вопросы? Gismart — о том, почему выбрали плоскую структуру компании и что из этого вышло
08.08.2018 09:52
—
Разное
|
Всего три года назад В беседе приняли участие сооснователь и CTO Gismart Александр Минец, руководитель бэкенд-разработки Сергей Батюков и директор инжиниринга Сергей Щегрикович. «Потом нас стало 40, но производительность в 4 раза не увеличилась. Почему?»Откуда взялось предубеждение против классической иерархической структуры? Чем для стартапа она нехороша? Александр Минец. Какое преимущество у маленьких команд? Скорость и подвижность. Так как все близки друг другу, то решения принимаются быстро, продукты на рынок выкатываются тоже быстро. Когда компания растёт, появляются дополнительные расходы на переговоры и согласования. И если не взять контроль в свои руки, то много времени будет тратиться на непонятные переключения и синхронизацию. Но как сохранить дух маленькой команды, когда команда уже немаленькая? Это челлендж. Был период, когда мы росли по чуть-чуть. Пытались не разрушить наш стартапчик, аккуратно вводили в команду по 1-2 человека. Но критическая масса всё равно наросла, и когда мы увидели перспективу на годы вперед (не только симуляторы музыкальных инструментов, но и сегмент мэйнстрим-продуктов в области развлечений), то поняли, что нам необходимо гораздо больше людей. Соответственно надо было продумать, как с такими размерами двигаться вперёд. Сергей Щегрикович. Интуитивно кажется, что при росте компании надо выстраивать какую-то иерархию, ставить людей в подчинённую позицию. В каких-то сферах это, наверное, и правильный подход. Но в ИТ-индустрии, особенно в продуктовых компаниях, это не очень работает, поэтому мы решили пойти другим путём. Мы сохранили структуру относительно независимых продуктовых команд и добавили к ним сервисные команды, которые обслуживают потребности продуктовых. Основная идея такой модели — оставить свободу инициатив и принятий решений именно тем людям, которые работают в продуктовых командах. Вы в какой-то момент почувствовали, что становитесь вертикалью, и нажали на тормоз?
Сергей Щегрикович. Вопрос в том, как при росте команды сохранить скорость изменений и не получить эффект bottleneck (бутылочного горлышка). Если мы ставим менеджера во главе какого-то направления, то он как раз и становится этим узким местом. Менеджеру приходит миллион е-мэйлов, и он волей-неволей затормаживает принятие решений. Круто, когда нет менеджеров, ответственных за какое-то направление, а есть продуктовая команда, вокруг которой всё строится. Именно команда даёт ценность компании, и надо сделать так, чтобы ей было удобно работать и чтобы она быстро давала фичи. Стали смотреть по сторонам и выбирать: есть одна модель, есть другая. В итоге за образцы выбрали модель SAFe (Scaled Agile Framework) — набор правил и предписаний для внедрения agile-принципов в больших организациях и ту, что сформировалась у компании Spotify. Решили взять лучшее из обеих моделей.
«Никто не ходит и не спрашивает, что ему делать»Давайте нарисуем структуру вашей компании. Продуктовые команды — по названиям основных продуктов? Александр Минец. Да. У нас пять продуктовых команд: 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 нам
Сергей Щегрикович. В пример можно привести ещё разработку для Android, там ребята самостоятельно перешли на язык котлин. Если они видят, как выполнять задачу лучше, то сразу принимают это решение. У нас нет глобального архитектора, который сидит сверху и говорит, кому что использовать. Власть распределена между ребятами, они несут ответственность не только за свой продукт, но и за всё семейство продуктов.
Денежная мотивация не работает. А что работает?Как целенаправленный переход на SAFe изменил работу сервисных команд? Сергей Батюков. Мы провели качественное планирование, и теперь краткосрочные планы нам более понятны. Раньше всё было анархично: люди из продуктовых команд приходили и просили сделать что-то побыстрее, хотя бэкенд-команда в это время занята другими задачами. SAFe-планирование позволяет нам понять, чем будет заниматься команда в ближайшие 1-2 недели. Это не отлитый в бронзе план, но некий ориентир для всех продуктовых команд и для бэкенда: на чём сфокусироваться, чтобы идти нога в ногу. Сергей Щегрикович. В SAFe особо выделяется роль архитектора. В обычном понимании представляется, что архитектор — это такой мужик, который сидит перед тысячей экранов и всем управляет. В agile архитектор не должен знать ответы на все вопросы, он должен соединять людей из разных команд. И в нашей компании разработчики знают, к кому подойти, если хотят внести предложение. Люди, которые занимаются продуктом, могут оценить свой результат с помощью маркетинга, для разработчика бэкенда критерии успешной работы другие: написано ли это хорошо или плохо, сколько запросов в секунду выдерживает сервис. Если на бэкенде всегда оставлять технический долг, то есть делать что-то плохо в угоду скорости выпуска продукта, то теряется удовлетворённость от работы, и у людей быстро накапливается разочарование.
А может, дело не в структуре, а в размере? Вот вас 100 человек, и вы справляетесь. А если вас будет 300? Сергей Батюков. Я думаю, всё получится. С ростом корпорации растёт и число людей, которые её обслуживают. В больших компаниях есть вертикаль, а есть команда, которая выполняет задачи. Меняется один менеджер, и команда ещё 3-4 месяца работает над вещами, при этом не понимая их смысл. Так происходит потому, что в энтерпрайз-командах есть инерция принятия решений и нет персональной ответственности за то, что происходит. В корпорации людей умышленно делают частью процесса, винтиками: так ими проще управлять. Одно дело, когда своей идеей сотрудник делится с человеком из вертикали, и запускается бюрократический процесс. И совсем другое, когда когда человек предлагает сделать коллегам что-то новое, и это сразу же внедряется в жизнь. Ребята, приходя к нам из аутсорса, начинают мыслить продуктово. Да, это занимает время, но бенефиты (когда тебе не надо каждый день говорить команде, что делать), того стоят. Как стиль управления в стране влияет на бизнес-отношенияКонфликты в командах происходят? Сергей Щегрикович. Конечно. Как и везде. Иногда из-за расписания, иногда из-за зон ответственности. Конструктивные конфликты должны быть. Александр Минец. Я не помню серьёзных конфликтов.
Легко поддерживать «фан», когда вас 5-10 человек. А у нас фан при 120-и. Не бывает, чтобы все 120 человек «фанили». Кто-то приходит просто деньги зарабатывать. Фан сохраняется за счёт того, что каждая команда — это мини-компания внутри большой. Вот они там себе и веселятся. Сергей Щегрикович. Главное препятствие созданию такой структуры, которая сама принимает решения, это наша культура. Есть даже исследование на тему того, как стиль управления в стране влияет на бизнес-отношения, располагает ли он к силовым методам или нет.
Поэтому главная проблема — мы сами, мы сражаемся сами с собой. И нам нужен этот фан, чтобы учиться доверять друг другу. Какие недостатки вы видите в выбранной модели? Мы в начале пути. Поэтому пока сложно сказать, какие будут препятствия и насколько это взлетит. А вам удалось получить желаемый коэффициент, восстановить пропорцию «количество людей — количество фичей»? Александр Минец: у нас сейчас 11 продуктов, а было 4.
Фото: Андрей Давыдчик Чтобы разместить новость на сайте или в блоге скопируйте код:
На вашем ресурсе это будет выглядеть так
Всего три года назад Gismart была маленькой компанией, сотрудников которой можно было пересчитать по пальцам. За год она увеличилась вдвое, а потом начала расти в...
|
|