Как построить гибкую и адаптивную компанию чтобы она могла достигать результатов быстрее?
Дмитрий КурдюмовАвтор статьи
Привет, хабр. Меня зовут Курдюмов Дмитрий, я основатель консалтингового агентства Smart units.
Более 7 лет я помогаю компаниям трансформировать их процессы и структуру для достижения большей адаптивности. В этой статье хочу поделиться некоторыми подходами к построению компании и структуры команд, которые позволят построить бизнес способный быстро реагировать на изменения рынка
Какую проблему это решает?
Многие компании каждый год тратят уйму времени на то, чтобы построить стратегию и сформировать планы. Но зачастую те планы которые мы построили быстро устаревают, а процессы тормозят рост. Поэтому появляются резонные вопросы:
Как быстро поменять направление если мы узнали новые вводные? Лучше узнали рынок, конкуренты выпустили новый продукт и так далее. Саму стратегию поменять не сложно, а вот как сделать так, чтобы все в компании смогли быстро перестроиться и побежать в другом направлении?
Как правило, вне зависимости от размера бизнеса, существует большая инерция и в целом узкоспециализированность отдельных отделов и команд, которая не позволяет им быстро перестроиться и пойти в другом направлении
Как организовать людей таким образом чтобы избежать
Долгих согласований изменений из за множества слоев в структуре;
Синхронизации большого количества людей;
Размытой ответственности;
Бюрократии;
Отсутствия понимания целей снизу, когда люди попросту исполнители.
Во многом секрет решения этих проблем кроется в структуре организации. Давайте рассмотрим две из них. 1 — классическая функциональная и 2 — продуктовая. Сейчас многие компании меняют свой бизнес и переводят его на продуктовую структуру и управление. Почему они это делают? На своей практике скажу, что в тех компаниях где я проводил продуктовые трансформации, за счет только изменения структуры, получили прирост в скорости (time to market) в несколько раз.
Чтобы понять почему это работает, давайте для начала сравним 2 типа структуры организации.
Функциональная vs Продуктовая структура организации
Функциональная структура организации
Определение:
Функциональная структура организации организует персонал на основе функциональных областей, таких как аналитика, разработка, тестирование, маркетинг, финансы, производство и т.д. Каждая функциональная область предоставляет экспертов, специализирующихся в определенной сфере.
Преимущества:
Экспертиза. Позволяет специалистам сосредотачиваться на своей области компетенции.
Эффективность. Управление и контроль выполнения конкретных задач становятся более прозрачными в пределах каждой функциональной области.
Недостатки:
Изоляция. Отделы могут работать изолированно, затрудняя обмен информацией.
Отсутствие фокуса на результате. При такой структуре люди не отвечают за результат и ответственность размыта. Часто происходит постоянный возврат задач на предыдущие этапы, в итоге теряется очень много времени на координацию.
Медленное принятие решений. Из-за того что система иерархична и поделена на функциональные области, дольше занимает процесс согласований, присутствует бюрократия.
Не гибкость. При такой структуре очень сложно быстро перестраиваться и коммуницировать.
Если подводить итог, то данная структура заточена на стабильность и контроль персонала, но абсолютно не подходит для реализации интеллектуальных задач в среде высокой неопределенности. В такой структуре планы расписаны на месяцы и годы вперед, а система едет медленно, но стабильно. При этом подобная структура не позволит быстро проводить эксперименты, быстро выпускать новые идеи на рынок, отказываться от ненужного. В такой структуре требуется много координации для решения задач требующих совместный труд. В такой структуре люди не замотивированы на результат и отсутствует фокус на клиенте, так как он где-то далеко за пределами иерархии.
Продуктовая структура организации
Определение:
Продуктовая структура организует персонал вокруг конкретных продуктов или услуг. Каждая продуктовая группа ответственна за полный жизненный цикл своего продукта. В каждую продуктовую группу входят все необходимые люди для создания и вывода продукта на рынок. Это могут быть и разработчики, и маркетинг, и юристы. Все в одной лодке и у всех единая цель. Как правило в такой структуре уходят полностью от отделов, а приходят к кроссфункциональными командам и выделенным ролям — функциям или сервисам, которые способны выделено взаимодействовать с командами.
Что называют продуктом?
Продуктом называют то, что несет ценность пользователям и прибыль бизнесу. Соответственно у продукта должны быть следующие характеристики:
У продукта есть бизнес модель (P&L), то есть продукт приносит прибыль.
У продукта есть пользователи.
Все остальное продуктами считать нельзя. Это могут быть части продуктов, какие-то системы помогающие закрывать требования продукта.
Преимущества продуктовой структуры:
Гибкость. Позволяет быстрее реагировать на изменения на рынке. За счет чего? тк продуктовые команды имеют плоскую структуру и отвечают за метрики, а также имеют доступ к клиентам и обратной связи. Все обладают общей целью и фокусом. Как правило работа таких команд построена итеративно. Поэтому менять планы и приоритеты в таких командах проще. Мы можем изменить приоритет по продукту и все команды повернуть в другом направлении.
Скорость. Скорость коммуникаций, фокус на одном, общие цели делают такие команды супер быстрыми и способными быстро реализовать идею и довести ее до клиентов.
Постоянные эксперименты. в такой структуре как правило легче запустить непрерывный тест гипотез, быстрее отказываясь от ненужного.
Интеграция. Обеспечивает интеграцию всех функций вокруг конкретного продукта.
Мотивация людей. в такой структуре приветствуется автономия, креативность, развитие и поэтому это становится хорошим источником мотивации для людей.
Недостатки:
Неравномерная загрузка людей внутри продуктовой группы. Так как все трудятся над целиковой бизнес задачей, но в разные моменты времени загрузка может быть неравномерной. Но в такой структуре приветствуется t-shaping и развитие широкий навыков у специалистов, чтобы в разные моменты времени они могли помогать друг другу. Это в том числе обеспечивает гибкость.
Как организовать команды вокруг продукта?
Команды в продуктовой группе как правило организовываются вокруг целей, которые преследует продукт.
1 способ организации — по CJM клиентов
Если взять пример крупного маркетплейса, над которым трудится более 200 человек, то можно выделить следующие группы вокруг CJM:
Онбординг и Главная страница.
Поиск и рекомендации.
Корзина.
Чекаут из корзины и оплата.
Доставка.
Возвраты.
Плюсы такого подхода:
Вы работаете на всем CJM клиентов и у вас команды отвечают за метрики конкретного куска продукта.
Минусы:
Команды сфокусированы на конкретных шагах в продукте, что делает их узкосфокусированными и локально оптимизирующими конкретный шаг, вместо того чтобы посмотреть на весь CJM и сфокусироваться на тех местах, где это реально нужно. Поэтому следующий подход к организации команд эту проблему решает лучше
2 способ организации команд — по Продуктовым метрикам
Существует всем известная воронка привлечения клиентов — AARRR.
И команды строят вокруг шагов этой воронки.
Например структура построения команд может выглядеть следующим образом:
Продуктовая группа отвечающая за Acquisition, то есть привлечение клиентов.
Продуктовая группа отвечающая за Activation, то есть за активацию клиентов. Что такое активация зависит от конкретного продукта. Как правило в продукте есть целевое действие которое должен сделать пользователь. Например сделать первую покупку.
Продуктовая группа отвечающая за Retention, то есть за удержание клиентов. Чтобы пользователи пользовались продуктом и покупали как можно дольше.
Продуктовая группа отвечающая за Revenue, то есть за максимизацию прибыли совершаемые пользователями.
Плюсы такого подхода:
При такой структуре команды могут изменять весь CJM клиента, вместо фокуса на конкретном шаге, тк отвечают за метрику. Такая структура более гибкая и оптимальная, тк фокусирует команды на росте метрик и неважно какие компоненты, функции и части продуктов мы меняем.
Минусы такого подхода:
Требует усилий на развитие универсальных команд способных изменять весь CJM, пересечения в коде и разработке. Нужна доп синхронизация команд, чтобы не делать одно и тоже.
3 способ организации команд
Создавать универсальные кроссфункциональные команды вокруг продукта, которые в зависимости от приоритета будут делать те или иные задачи. Эта структура еще более гибкая, так как здесь команды могу повернуться в любом направлении в зависимости от потребностей, в том числе начать вместе качать ту или иную метрику.
Но за гибкость приходится платить. Такие команды довольно непросто создать. Если продукт большой и много компонент, то довольно сложно создать команды которые могут доделывать все части продукта.
Плюсы:
Такая структура максимально гибкая, потому как может в любой момент повернуть в другую сторону. Также скорость таких команд тоже высокая тк команды кроссфункциональные и способны все компоненты системы менять самостоятельно
Минусы такого подхода:
Требует усилий на развитие универсальных команд способных изменять весь CJM и компоненты продукта. Требуются доп усилия для развития функциональных областей. Как правило в такой структуре создают сообщества по компетенциям где люди из кроссфункциональных команд регулярно посещают общие встречи на которых синхронизируют и стандартизируют правила.
Как делить команды внутри продуктовых стримов?
Один из подходов — это создавать универсальные кроссфункциональные команды как я описал в способе 3. Однако на этот подход довольно сложно перейти сразу, особенно в сложных системах невозможно чтобы все разработчики знали все компоненты. Это создаст высокую когнитивную нагрузку.
Но есть решение — это топологии команд. Они решают проблему. Топологии или «Team Topologies» были описаны Мэтью Скелтоном и Мэтью Элиасом в виде фреймворка. Основной принцип Team Topologies заключается в создании адаптивных и гибких команд, что способствует более быстрому достижению поставленных целей.
Team Topologies вводит несколько ключевых видов команд, которые могут быть использованы в структуре организации:
Потоковые Команды (Stream-Aligned Teams). Эти группы специализируются в определенных потоках работы, таких как разработка новых функциональных возможностей продукта или обеспечение его непрерывной поставки. Они ориентированы на оперативное выполнение задач в своих областях, что улучшает скорость и предсказуемость разработки.
Команды Сложных Подсистем (Complicated-Subsystem Teams). Эти группы занимаются созданием и поддержкой сложных компонентов или подсистем в продукте или системе. Обладая экспертизой в конкретных областях, они специализируются на технически сложных аспектах продукта, обеспечивая его надежность и эффективность.
Платформенные Команды (Platform Teams). Ответственные за разработку и поддержание общей платформы, используемой другими группами в организации. Эти команды создают инфраструктуру, инструменты и сервисы, упрощающие и ускоряющие процессы разработки для всех остальных команд, способствуя тем самым повышению продуктивности и гибкости всей организации.
Команды Поддержки (Enabling Teams). Они играют важную роль в обеспечении эффективности работы других групп. Предоставляя инструменты, обучение, консультации и другие ресурсы, необходимые для успеха остальных команд, эти группы поддерживают и стимулируют инновации, обеспечивая необходимые знания и ресурсы для других групп в организации.
Такие команды могут быть вместе ориентированы целиком на продукт или его часть или же отвечать за конкретную метрику. При этом в точки зрения построения команд они могут оптимально дополнять друг друга, однако для реализации целиковой бизнес ценности может потребоваться дополнительная координация. Как правило это решается общими каденциями (встречами) по планированию, синхронизации и обзора результатов. Также у таких команд важно синхронизировать спринты разработки чтобы они ехали параллельно.
Итоги
Выбирать структуру организации стоит в первую очередь отталкиваясь от целей компании. Многие продолжают жить в функциональной структуре, хотя хотят быстро создавать востребованные продукты. Им будет очень сложно конкурировать находясь в парадигме, которая была создана для другого.
Подход к организации команд — это также эволюционный процесс. Вы можете начать с нарезки по CJM и организации команд по топологиям, а через время прийти к универсальным командам.
Выбирайте подход с умом и от целей компании. Важно чтобы структура помогала достигать целей, а не препятствовала им.
Практические навыки по адаптации и трансформации процессов вы можете получить в рамках онлайн-курсов от экспертов рынка. А в календаре мероприятий все желающие могут зарегистрироваться на ряд полезных бесплатных вебинаров.
Если вам понравилась статья подписывайтесь на мой телеграм канал. А также если решили провести трансформацию в своей компании записывайтесь на бесплатную консультацию.
