Почему бюрократия убивает горизонтальные коммуникации: анализ иерархических структур и Agile‑подходов
Во многих крупных компаниях цикл принятия решений растягивается на дни, а иногда на недели. В период, когда мир стремительно меняется, такой подход становится не инструментом управления, а помехой для развития и коммуникаций. В противовес бюрократии часто ставят Agile — гибкие коммуникации, которые помогают достигать более высоких результатов. В чём проблема бюрократии? Можно ли её победить? В чём преимущество Agile‑подхода? Как внедрить его в компании без хаоса? С этими вопросами разбираемся в статье.
Почему бюрократия стала врагом коммуникаций?
Современные крупные компании часто напоминают огромные крейсеры, которые вместо гонки за инновациями тонут в болоте согласований. Виной тому бюрократия, которая из инструмента управления превратилась в главного разрушителя коммуникации. Иерархические структуры, созданные для порядка, теперь душат скорость, креативность и прямоту диалога.
Проблема в том, что в погоне за контролем организации обрастают формальностями. Рутинные процессы (бесконечные отчёты, многоуровневые согласования, «эскалации наверх») подменяют настоящее, живое общение, принятое, например, в стартапах. В итоге сотрудники тратят больше времени на соблюдение процедур, чем непосредственно на саму работу.
В результате:
- решения принимаются с опозданием;
- ответственность размывается в цепочке «начальников начальников»;
- креатив и инициатива сотрудников умирают под грузом правил.
Простой пример: представьте чат в Slace, где вопрос от клиента, заданный техподдержке, должен пройти через несколько менеджеров, юриста и финансовый отдел например, прежде чем клиент получит ответ. За это время он успеет уйти к конкурентам. Так бюрократия превратила простую коммуникацию в долгий квест.
Рассылка: как вести бизнес в России
Пять полезных писем пришлем сразу после подписки. В них — бизнес‑идеи, готовые промпты для нейросетей, советы, как выбрать налоговый режим и получать пассивный доход
Анатомия бюрократии: как иерархия душит общение
Обратимся к истокам. Бюрократия по Максу Веберу — это тип социальной организации со строгой иерархией и специализацией государственного чиновничества в административном механизме. Базовые принципы бюрократии по Веберу выглядят следующим образом:
- иерархия приказов, основанная на легальной власти;
- строгое подчинение нижестоящего работника вышестоящему и ответственность не только за свои действия, но и за действия своих подчинённых;
- строгая специализация и разделение труда;
- строгая система отчётности;
- чёткая система процедур, которая обеспечивает единообразие всех внутренних процессов;
- строгая система продвижения по карьерной лестнице, основанная на умениях и опыте, причём всё строго стандартизировано;
- все коммуникации внутри подчинены правилам;
- есть базовый набор целей, к которым стремятся все люди в организации.
Вебер был уверен, что такая рациональная бюрократия — самая эффективная форма управления. Но так ли это? Безусловно, такая структура обеспечивает строгий контроль, высокие стандарты, стабильность и минимизирует риски.
Однако мы живём в эпоху глобальных перемен и тотальной нестабильности во всём. Выживет только тот, кто умеет быстро реагировать на происходящее и подстраиваться под изменяющиеся внешние условия. При тяжеловесной бюрократической системе управления обратная связь существенно замедляется, принятие решений тоже, коммуникации носят формальный, а не деловой характер, инициатива сотрудников подавляется, а информационный «фильтр» между разными уровнями коммуникаций играет роль испорченного телефона.
Горизонтальные коммуникации: почему они умирают в иерархиях
Есть такое страшное слово «субординация». Это система правил поведения и коммуникации внутри организации. Чаще всего именно субординация не позволяет обратиться через голову руководителя к вышестоящему человеку или к сотруднику не своего отдела, не поставив в известность его руководителя. К примеру, отдел маркетинга не может напрямую связаться с отделом IT‑разработки — только через руководителей. В одной такой компании, я знаю, айтишники сидят за запертой на ключ железной дверью и заходить к ним без согласования с CEO или техническим директором нельзя.
Так отделы становятся изолированными друг от друга белыми башнями с жёсткой системой доступов. Это приводит к тому, что сотрудники избегают прямых контактов, снижается уровень ответственности, что часто приводит к бездействию и убивает на корню смелые и перспективные идеи, а также негативно сказывается на уровне вовлечённости персонала в работу. Так, по данным отчёта от Gallup (State of the Global Workplace 2023), только 23% сотрудников во всём мире вовлечены в работу. Это катастрофически мало!
Agile как противопоставление бюрократии
В современном менеджменте бюрократия несёт защитную функцию, но вместе с этим она замедляет скорость принятия решений. Довольно часто Agile противопоставляют бюрократии. На деле всё обстоит не совсем так.
В Agile‑организациях собраны люди с теми специализациями, которые нужны для решения конкретных бизнес‑задач. Самые эффективные из них строят свою внутреннюю структуру вокруг пользовательского пути (Customer Journey Map).
Некоторое время назад было принято управлять «ресурсными башнями». Казалось, что гораздо проще руководить сотрудниками, у которых есть смежные или похожие скилы. Это приводило к решению: проще нанять менеджера, его контролировать и ему давать задачи.
В реально гибкой структуре Agile основой является не персона, а команда (или группа команд) со специализацией на конкретных проблемах пользователя. Да и сама команда собирается вокруг пользовательского пути. Главный фокус здесь в децентрализации принятия решений — оно остаётся у одного конкретного человека. Например, в современных организациях это владелец продукта или продакт‑менеджер. Именно он принимает решения, несёт ответственность за бюджет, следит за тем, чтобы сотрудники зарабатывали в этом бизнес‑направлении. Но между тем, бóльшую часть решений он делегирует: не принимает их все самостоятельно, а только направляет команду. Владелец продукта становится ментором для команды, выращивая в ней экспертизу и умение решать пользовательские проблемы. Такой подход, безусловно, сказывается позитивно на результатах: команда, которая общается напрямую с пользователем, гораздо лучше его понимает. По сути, используется интеллектуальный потенциал не одного руководителя, который принимает решение, а всей команды. Это гораздо эффективнее на длинной дистанции.
Конечно, таких людей учить и нанимать довольно дорого. Им нужны более профессиональные менеджеры и лучшие условия. Но результат такие команды могут показывать в 4–16 раз лучше тех, кто организован по принципу изолированных функций (то есть отдельно маркетологи, отдельно айтишники, отдельно менеджеры по продажам и т.п.).
Agile‑антидот: принципы, ломающие барьеры
Бюрократия не исчезнет сама сама по себе. В некоторых сферах (например, в госуправлении) она будет ещё долго самой эффективной системой управления. Однако всё больше компаний, понимая все минусы бюрократического способа контроля, начинают использовать различные инструменты, в том числе и Agile, чтобы прорубить окно на свежий воздух там, где всё завалено строгими формальностями. Это позволяет им вернуть коммуникациям их главную роль: не контролировать, а созидать.
В основе Agile‑методики лежат принципы самоорганизации, кросс‑функциональных команд и итеративного подхода к работе.
В Agile‑манифесте, который был опубликован в 2001 году, группа разработчиков описала основные ценности этого подхода:
- Люди и их взаимодействия важнее, чем процессы и инструменты. То есть успешные проекты строятся на доверии и общении, которые ускоряют работу в противовес бюрократической субординации.
- Работающий продукт важнее, чем подробная документация. Это не значит, что она не важна, наоборот, но приоритет — работающий продукт и, чем скорее он появится, тем раньше команда получит обратную связь и приступит к улучшению.
- Сотрудничество с клиентом важнее условий договора. Это не значит, что договор не нужно соблюдать, но постоянное взаимодействие с клиентом позволяет разработчикам уточнять требования, быстрее реагировать на изменения и в итоге сделать продукт лучше.
- Готовность к переменам важнее соблюдения первичного плана. В данном случае изменения следует воспринимать как возможность улучшить что‑то, а не как сбой в системе.
Роль «Скрама», ежедневных стендапов и ретроспектив
Scrum («Скрам») — это фреймворк и гибкий метод разработки ПО из семейства Agile, основанный на итеративных и пошагово выстроенных по периодам процессов, обычно длиной в 1–4 недели. Его главная цель — непрерывный прогресс и удовлетворение потребностей бизнеса (или заказчика) через общую ответственность и прозрачный процесс. Проще говоря, он создан для того, чтобы получать быструю обратную связь от рынка: за 1–4 недели можно узнать о своём продукте или сервисе гораздо больше, чем при традиционном подходе.
«Скрам» помогает командам достигать целей через короткие итерации (спринты). В процессе проводятся ежедневные стендапы — 15‑минутные встречи для синхронизации всех участников. Это помогает команде оставаться в контексте. По итогам спринтов проводятся обзоры, где продукт демонстрируется пользователю и собирается обратная связь. Завершают спринт ретроспективы — встречи, на которых анализируются успехи и зоны роста. Все эти практики создают прозрачность, укрепляют коммуникацию и обеспечивают непрерывное улучшение процессов. Они делают работу предсказуемой, а саму команду адаптивной к изменениям, что крайне важно не только в динамичной IT‑среде, но и в целом в существующем мире.
Помимо фокуса команды на самом важном и получения результата за спринт, скрам‑подход позволяет правильным образом собирать обратную связь. В качестве примера приведу один из наших кейсов. В 2017 году руководство крупного банка в Казахстане решило запустить пилотный проект Agile‑команд. В день, когда мы должны были показать первые результаты, на встречу пришли не только руководители, но и реальные пользователи — главные бухгалтеры крупных компаний. В момент, когда одного из них спросили, все ли нравится, он дал самую честную обратную связь и рассказал, что работает, а что нет, что им действительно нужно, а на что лучше не тратить усилия и время, потому что они этим функционалом пользуются от силы раз в год. Таким образом, команда смогла сфокусироваться на самом важном, отбросить 80% ненужной работы, сделать её гораздо позже и тем самым привлечь основных клиентов в рекордно короткие сроки.
Ещё один яркий пример такой работы — это сервис Spotify, который организовал собственный фреймворк на базе Agile, так как «Скрама» им уже не хватало. В Spotify вместо Scrum‑команд появились отряды (squad) с более расширенным ролевым составом, чем просто команда разработчиков. Этот подход привёл компанию к таким результатам:
- были созданы маленькие команды (около 8 человек), которые могли быстрее и гибче развивать свой подход;
- из стартапа в 30 человек Spotify выросла до международной компании в 1600 сотрудников в 30 странах мира;
- была популяризирована концепция кросс‑функциональных команд.
Так в Spotify пришли к тому, что доверие важнее контроля, и пониманию, что отряд работает быстрее, если все решения принимаются внутри, не дожидаясь «ок» от топ‑менеджмента.
Как внедрить Agile без хаоса?
Вектор любых изменений в компании зависит от её лидеров. Если этот вектор неустойчив, или он постоянно меняется, или его просто нет, то компания начинает жить какой‑то своей жизнью. Яркий пример тому — Valve, американская компания‑разработчик и издатель компьютерных игр. Создатели этой «бирюзовой» организации потерпели неудачу, потому что иногда культура внутри компании меняется из‑за того, что в неё проникают люди, которые могут эту культуру поменять. И так как нет стержня в виде лидера, который аккумулирует вокруг себя людей, проекты, идеи и смыслы, начинается внутренняя борьба противоборствующих групп. Команды начинают работать не на цель компании, а против друг друга. В 2018–2022 годах этот подход в Valve вылился в цепочку бизнес‑провалов.
Если вы лидер и хотите изменить культуру компании, то для начала вам это нужно осознать, а потом найти сообщников. Если внутри компании есть люди, разделяющие вашу точку зрения, с ними дело пойдёт быстрее. Ваш главный инструмент — это доверие. Если люди вам доверяют, опять же, дело пойдёт быстрее, если нет — доверие нужно будет завоевать ещё до того, как вы начнёте перестраивать команды и внедрять новые инструменты. И ещё важно понять, что не всем эти изменения придутся по душе и вас в любом случае ждёт некоторая смена кадров.
Запаситесь терпением и начните с малого: выстройте по‑новому процессы вокруг себя и своих соратников, а затем масштабируйте этот опыт на остальные подразделения. С шашкой наголо тут не прокатит. Как вы формировали текущую культуру в своей компании много лет, так её и нужно менять — медленно и планомерно. Культура — очень уязвимая сущность, с ней нужно обращаться бережно. А культура самоорганизации — это настоящее доверие, она не порождает каких‑то внутренних иерархий и позволяет малыми силами достигать невероятных высот.
Пошаговая инструкция для планомерных изменений
Шаг 1. Оцените текущее состояние компании. Сформулируйте цель перехода на новую структуру. Найдите соратников, готовых вместе с вами внедрять новую культуру.
Шаг 2. Проведите тренинги по Agile и стратегии трансформации для топ‑менеджмента и добейтесь их поддержки.
Шаг 3. Создайте из самых заинтересованных сотрудников кросс‑функциональную рабочую группу. Это будет ваш пилотный проект. Не пытайтесь переделать сразу всех. Agile подразумевает итеративный подход, так что самым логичным будет начать с малого. Наймите для команды Agile‑коуча для сопровождения и определите роли внутри неё. Внедрите в эту группу нужные инструменты (Kanban‑доску, аналог Jira или Miro — выбирайте, исходя из ваших потребностей). Они обеспечат вам прозрачный и понятный всем членам группы процесс. Запустите первый спринт с чёткими целями, чтобы в конце этапа оценить результат, и соберите обратную связь от сотрудников.
Шаг 4. Постепенно заменяйте вертикальную отчётность на самоорганизацию команд, внедряйте Agile‑события (стендапы, планирование спринтов, ретроспективы), для отслеживания прогресса используйте визуальные инструменты типа Jira или Kanban‑доски.
Шаг 5. Создавайте автономные команды до 10 человек с набором необходимых компетенций (например, дизайн, разработка, тестирование, аналитика) и доверьте им принятие решений без лишнего микроменеджмента.
Шаг 6. Держите фокус на адаптации персонала, проводите тренинги, если потребуется. Регулярно собирайте фидбэк от сотрудников через ретроспективы и корректируйте процессы.
С таким итеративным подходом один из крупнейших банков Великобритании Barclays в 2016 г. начал переход с классической иерархической модели на Agile в рамках цифровой трансформации. Через два года, оценив результаты, они поняли, что время вывода их продуктов на рынок сократилось на 40%, удовлетворённость клиентов выросла на 25% за счёт внедрения обратной связи, а прибыль в цифровом сегменте выросла на 15%. Ничто не мешает вам сделать то же самое. А если возникают трудности или не знаете, с чего начать, сходите к ментору и обсудите с ним план действий.
Бюрократия не умрёт, но Agile — это эволюция
Есть множество разных мнений, например, что бюрократия никогда не умрёт и что Agile — это рискованный путь в никуда. Есть и другие мнения, что будущее за Agile и его производными. Критиковать можно бесконечно. У Agile, как и у любого способа управления есть свои минусы. Например, эта философия требует высокой степени осознанности и ответственности со стороны всех участников процесса, а таких людей найти непросто. Ясно одно: мы живём в эпоху очень быстрых и кардинальных изменений, за которыми старая бюрократическая система просто не успевает, и этих изменений не избежать.
Сегодня уже успешно работают гибридные модели управления и сильно модернизированные Agile‑проекты. Сейчас самое главное — позволить командам экспериментировать с Agile‑практиками, чтобы найти оптимальный путь для своей компании.
