Менеджмент менеджмента: как во «Фланте» внедрили принятие решений эфемерными рабочими группами

С момента, когда в 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» заставили нас иначе взглянуть на организационную структуру. Внутри компании выделились три бизнес-юнита:

В рамках новой структуры значение гильдии менеджеров проектов потеряло свою актуальность. В DaaS на смену ей пришёл подход к управлению, который перенял и адаптировал практики использования эфемерных рабочих групп уже в своих процессах.

Первым успешным применением практики стала рабочая группа по адаптации ценностей гильдии для всего подразделения DaaS. Используя прежнюю механику работы эфемерных групп, нам удалось в течение пары недель скорректировать ценности для бизнес-юнита в целом и согласовать их со всем менеджментом, а ещё через неделю — со всеми членами всех команд.

Примерно через год после внедрения эфемерных рабочих групп в гильдии я наткнулся на доклад Сергея Кривого «Метод принятия решений динамической группой». Ребята из SEMrush на несколько лет раньше нас прошли практически тем же путем, хотя и с другой мотивацией. Крайне рекомендую доклад к просмотру.