Всем привет! С момента, когда в 2012 году сотрудники Valve слили явили миру документацию о том, как устроена плоская организационная модель, менеджмент перестал быть прежним. Одни восприняли плоскую систему управления как антиутопию и менеджерский кошмар, другие — как панацею в управлении технологическими компаниями. Споры не утихают до сих пор. Тем не менее среди технологических компаний идея минимизации управленческой структуры, идея «плоскости» если не всеобщая, то крайне популярная.
Повсеместное применение Agile-методов если не требует, то по крайней мере подразумевает использование плоских оргмоделей. Мы во «Фланте» тоже используем довольно плоскую управленческую модель с большим количеством свободы: DevOps as a Service-подразделение компании структурно состоит из команд, менеджеры которых совместно принимают решения относительно общего курса развития. На уровне команд, совместно с их сотрудниками, принимаются решения по внутрикомандным вопросам.
Плоские проблемы, с которыми столкнулись мы
Антиутопическая Флэтландия из документации Valve даже в нашем ограниченном применении начала сталкиваться с рядом проблем роста. Когда компания выросла до 150 человек и примерно 15 команд, эффективно и быстро принимать решения стало сложно. Основная проблема была в том, как найти консенсус, ведь только руководителей команд оказалось около 30 человек. Договориться о чём-то, а тем более единогласно, было невозможно.
Одновременно с этим всё острее вставала проблема синхронизации методов работы в каждой отдельно взятой команде. Из-за сложности принятия общих решений различия в процессах накапливались несколько лет, и со временем мы осознали, что процессы в разных командах стали несовместимы. При этом нам требовалось внести существенные изменения в продуктовую и процессную модель наших услуг, причём речь шла об изменениях в 11 сервисных командах одновременно.
В наследство от плоской организационной модели в небольшом стартапе мы получили процесс, когда менеджеры команд принимали непосредственное участие в управлении компанией и её развитии. Одновременно с этим во главе команд у нас собрались высококвалифицированные руководители из ИТ и телекома, которым, помимо финансовой мотивации, требовались и интересные, масштабные задачи. Таким образом, третьей если не проблемой, то задачей была необходимость удовлетворить амбиции менеджмента в создании вклада в общее дело, в деятельном участии в развитии компании.
Эти три вопроса нам и предстояло совместно решить.
Как появились рабочие группы
Впервые на практике со сложностью согласованного принятия решений мы столкнулись в 2022 году. Фактически тогда началась коллективная работа менеджеров проектов «Фланта»: мы стали собираться еженедельно на встрече с говорящим названием «PMBook».
Ещё из Scrum Guide мы знали о рекомендации не создавать команды размером больше 10 человек. Причиной как раз является сложность принятия консенсусного решения, а нас — менеджеров проектов — на тот момент уже было 11. Задачу по синхронизации процессов в командах мы пытались начать решать внедрением нового флоу планирования и инструментария к этому флоу сразу во всех 11 командах.
Необходимо пояснить, что команды во «Фланте» — это независимые организационные единицы со своим бюджетом и правом на автономное принятие решений об организации процесса работы.
С весны 2022 года мы провели множество попыток договориться разной степени холиварности. Результат был плачевным: все команды продолжали работать по-старому. В конце концов уже казалось, что остаётся только определить, кто будет главой, и поручить этому человеку принятие решений. Мы даже назначили встречу для выбора лидера.
Во время подготовки к встрече меня не покидало чувство культурного неприятия «самодержавия», которое было необходимо ввести. «Флант» всегда отличался демократичным подходом, способностью слышать мнение каждого и принимать это мнение во внимание. Кроме того, необходимо не только синхронизировать процессы в командах, но и развивать процессы взаимодействия с клиентами, межкомандные коммуникации, продажи, управление бюджетом. Контролировать все эти области одновременно, да ещё и с неподдельным интересом, не смог бы ни один человек.
И тут мне на ум пришла идея использовать метод принятия решений небольшими рабочими группами, по 3–5 человек в каждой. Такой группе легко разработать прототип любого решения в зоне своей ответственности, а добровольный лидер узкого направления будет максимально мотивирован.
На встрече я изложил идею коллегам, и ребята её подхватили. Результатом стало создание гильдии ПМов. Мы посмотрели бэклог актуальных на тот момент менеджерских задач и определили, что нужны следующие рабочие группы:
-
Взаимодействие с клиентом (довольный клиент).
-
Процессы в команде.
-
Продажи.
-
Управление бюджетом.
-
Взаимодействие внутри компании и управление знаниями.
Рабочие группы в практике гильдии
Структура новой гильдии оказалась довольно жизнеспособной. Рабочие группы быстро создавали прототипы решений и процессов, опробовали их в своих командах и рассказывали о них на общем собрании гильдии. Чаще всего после небольшого обсуждения прототипы забирали для дальнейшего внедрения в инженерные команды.
Но не прошло и пары месяцев, как мы вдруг осознали, что рабочая группа «Взаимодействие внутри компании и управление знаниями» решила все свои острые задачи. При этом рабочей группы для задач по систематизации найма менеджеров у нас не было. Сложилась довольно странная ситуация, когда фокус групп был направлен не туда, где обосновались наиболее актуальные проблемы и для гильдии, и для компании в целом.
Изначально у нас не было строгой установки, что группы будут вечными, но мы и не ожидали, что изменения в структуре гильдии потребуются так быстро. В этот момент мы пересмотрели саму концепцию гильдии: приняли совместное решение о создании эфемерных рабочих групп для решения конкретной задачи вместо жёстко установленных рабочих групп по направлениям.
Эффективность нового процесса была высокой. Например, рабочая группа по продажам всего за пару месяцев систематизировала весь процесс продаж: этапы воронки, их длительность, процессы внутри каждого этапа, ролевую модель. Эта же группа переработала шаблоны документов: бриф, рабочие презентации, коммерческое предложение и так далее. Результатами её работы мы пользуемся по сей день.
Механика работы эфемерных рабочих групп
Как же это работает?
В этой статье мы оставляем за скобками вопрос лидерства в гильдии и в плоской организации вообще. Без лидера функционирование таких организационных структур невозможно себе представить. Тем не менее, чтобы не оставлять вопрос открытым, рекомендую прочесть книгу «Лидер и племя» Логана, Кинга и Фишер-Райта. Книга базируется на парадигме спиральной динамики и даёт фундаментальные знания о лидерстве в разных типах коллективов.
Для начала участниками гильдии формируется список запросов на изменение или попросту — нерешённых вопросов. Инициаторами запросов являются или клиенты, или команды, или продиктованная рынком необходимость.
Раз в неделю на общем собрании гильдии бэклог запросов приоритизируется. Часть вопросов отдаётся в существующие рабочие группы, часть решается на месте и, если требуется, создаётся новая эфемерная рабочая группа.
Рабочая группа состоит из 3–5 человек. Из их числа выбирается руководитель. Определённого механизма выбора руководителя нет, чаще всего это происходит на добровольной основе. Если добровольцев не нашлось, группа определяет руководителя сообща. Избранный руководитель берёт на себя обязанности по организации и ведению церемоний группы и по представлению результатов работы.
Рабочая группа — новая или уже существующая — прорабатывает прототип решения, который представляет всей гильдии на одном из будущих собраний.
Как правило, после представления возникает ряд вопросов, после которых решение окончательно дорабатывается и внедряется в командах.
Эфемерные рабочие группы не панацея
Эфемерные рабочие группы имеют довольно узкоспециализированное применение, как и любой управленческий механизм.
Во-первых, они действительно хорошо работают только в плоских управленческих структурах. Если у вас в компании вертикальная или матричная организационная модель, ограниченное применение эфемерных рабочих групп иногда возможно на уровне менеджмента. В строго вертикальных структурах, например в государственных организациях, применение эфемерных рабочих групп возможно исключительно в творческих, инженерных и научных коллективах, где и так традиционно применяется групповое принятие решений.
Во-вторых, критически важной для работы механизма эфемерных рабочих групп становится культура лидерства в компании. Как мы уже говорили ранее, без лидера рабочая группа обречена на неудачу.
Вот и получается, что метод легко применим в среде руководителей в плоских организациях и частично — для организации рабочих коллективов «белых воротничков» (куда ИТ тоже попадают).
Рабочие группы на следующей ступени роста компании
Активное развитие экосистемы продуктов Deckhouse, выросшей из инструментов автоматизации сервисного подразделения в востребованный на рынке продукт, и объединение с компанией «Экспресс 42» заставили нас иначе взглянуть на организационную структуру. Внутри компании выделились три бизнес-юнита:
-
продуктовая разработка Deckhouse;
-
cервисный бизнес-юнит DaaS (DevOps as a Service);
-
сервисно-консалтинговый бизнес-юнит «Экспресс 42».
В рамках новой структуры значение гильдии менеджеров проектов потеряло свою актуальность. В DaaS на смену ей пришёл подход к управлению, который перенял и адаптировал практики использования эфемерных рабочих групп уже в своих процессах.
Первым успешным применением практики стала рабочая группа по адаптации ценностей гильдии для всего подразделения DaaS. Используя прежнюю механику работы эфемерных групп, нам удалось в течение пары недель скорректировать ценности для бизнес-юнита в целом и согласовать их со всем менеджментом, а ещё через неделю — со всеми членами всех команд.
Применив эфемерные рабочие группы, мы научились быстро вырабатывать и принимать решения. Научившись договариваться, мы смогли если не синхронизировать процессы в командах, то пойти семимильными шагами в сторону их унификации. Ну и в качестве бонуса амбициозные менеджеры получили возможность проявить себя и показать свой профессионализм в рабочих группах.
P. S.
Примерно через год после внедрения эфемерных рабочих групп в гильдии я наткнулся на доклад Сергея Кривого «Метод принятия решений динамической группой». Ребята из SEMrush на несколько лет раньше нас прошли практически тем же путем, хотя и с другой мотивацией. Крайне рекомендую доклад к просмотру.
Читайте и другие статьи менеджеров DaaS-команд в нашем блоге:
Автор: gserge
