Привет, Хабр!

Частенько тимлидов беспокоит одна ситуация: команда из кросс‑функциональных специалистов собирается решить важный вопрос, а процесс превращается в бесконечный спор. Каждый тянет одеяло на себя, вето любого участника способно затормозить прогресс, и в итоге решение либо принимается слишком долго, либо вообще откладывается. В поисках способа ускорить принятие решений и при этом учитывать мнение каждого, естьподход под названием Sociocracy 3.0 (S3). Сегодня я расскажу, что это за методика, как она помогает командам принимать решения на основе согласия без бесконечных обсуждений и вето, и как её можно пилотно опробовать в проекте.

Кратко об истоках

Начну с небольшого экскурса. Термин «социократия» придумал ещё в XIX веке философ Огюст Конт, но в управлении организаций эти идеи по‑настоящему воплотил в 1970-х голландский инженер Герард Энденбург. Ему хотелось управлять своей компанией по‑человечески, без жёсткой иерархии, но без потери эффективности. Энденбург разработал метод управления на основе кругов и согласия — так родилась современная социократия, или динамическое управление. С годами метод прижился в различных организациях, а в 2015 году консультанты Бернхард Бокельбринк и Джеймс Прист на основе этих идей и опыта Agile/Lean‑среды представили открытую методику Социократия 3.0. Это уже не жёсткая система, а гибкий фреймворк с десятками паттернов, которыми команда может воспользоваться по своему усмотрению. S3 впитала в себя лучшие принципы Agile, Lean, холакратии и других подходов, сохранив философию социократии: самоорганизация, вовлечение людей и коллективный разум вместо директивного менеджмента.

Звучит здорово, но давайте разбираться по порядку.

Принятие решений по согласию вместо консенсуса

Центральная идея Социократии 3.0 — принятие решений по принципу согласия (consent). В традиционных подходах часто стремятся к консенсусу, когда решение принимается только если все с ним активно согласны. Казалось бы, здорово — полное единодушие! — но на практике достичь консенсуса сложно и долго: стоит одному человеку возразить, и решение стопорится до бесконечности. К сожалению, в жизни команд это выливается либо в компромиссы по минимальному общему знаменателю, либо в скрытое недовольство тех, чьё мнение проигнорировали ради мнимого согласия.

Consent‑подход снимает эту проблему. Решение считается принятым, когда никто из участников не выдвинул существенного возражения. Не нужно, чтобы все обожали план — важно, чтобы не было серьёзных причин против. Если возражения нет, команда движется дальше. Если возражение появляется, его не воспринимают как провокацию или право вето, а рассматривают как ценную информацию: повод доработать предложение так, чтобы устранить риск или проблему, которая беспокоит участника. В социократии говорят: «Достаточно хорошо, чтобы попробовать, и безопасно в достаточной степени, чтобы не навредить». То есть решение не обязано быть идеальным и вечным — достаточно, чтобы оно работало сейчас и не несло явной угрозы целям команды. Его всегда можно пересмотреть, когда появятся новые данные или изменятся условия.

Допустим, команда обсуждает, внедрять ли новый фреймворк в проекте. По консенсусу им пришлось бы убеждать каждого скептика, тратить часы на споры, пока последний участник не скажет заветное «ну ладно, пусть будет». В формате согласия процесс другой: один из разработчиков делает предложение: «Давайте в следующем сервисе используем Framework X». Далее раунд вопросов для прояснения — коллеги уточняют детали, оценивают влияние. Затем раунд реакций — коротко делятся мнениями, но решение ещё не принимается. После этого фасилитатор встречи спрашивает: «Есть ли возражения?». Если никто не возражает — решение принимается за несколько минут! Если же, скажем, тимлид возражает: «Я против, потому что у нас не хватает опыта, есть риск сорвать сроки», — группа не голосует «за» или «против», а совместно обсуждает это возражение. Возможно, дорабатывают предложение: например, провести обучение или сначала сделать небольшой прототип на новом фреймворке. Потом снова спрашивают про возражения. Процесс идёт по кругу, пока возражения не исчезнут, и тогда обновлённое решение принимается. Конечно же возражение должно быть аргументированным, указывающим на риск или несоответствие целям. Просто сказать «мне не нравится» недостаточно. Такой подход экономит время — не нужно стремиться к идеалу или всеобщей любви, достаточно убрать критичные проблемы и можно действовать. В итоге решения принимаются быстрее, а команда чувствует себя в безопасности: никто не продавил решение силой, все могли высказать опасения и быть услышанными.

Круги и домены

Помимо принципа согласия, S3 предлагает пересмотреть структуру команды или организации. Вместо классической пирамиды с начальниками и подчинёнными используется система кругов. Круг — это группа людей, которая отвечает за определённый домен. Домен — по сути, область ответственности, где этот круг имеет полномочия принимать решения и реализовывать их. Например, в компании может быть круг разработки продукта, круг маркетинга, круг поддержки пользователей — каждый со своим чётким фокусом. В контексте одной кросс‑функциональной команды можно представить круг, ответственный за качество и процессы, или круг технического развития продукта, и т. д. Главное, чтобы у круга была общая цель и зона ответственности, понятная всем участникам.

Как же связаны разные круги между собой, чтобы не получилась разрозненная анархия? Здесь работает принцип двойной связи. Если круги выстроены по уровню (например, команда → отдел → весь отдел → компания), то связь между «верхним» и «нижним» уровнями осуществляется в обоих направлениях. Обычно это выглядит так: руководитель круга (скажем, руководитель отдела) входит в состав вышестоящего круга как лидер, донося видение и цели сверху. А кто‑то из членов круга (делегат) представляет интересы своего круга на уровне выше, донося обратную связь, проблемы и предложения снизу вверх. Двойная связь дает циркуляцию информации и влияние решений в обе стороны: верх получает правдивую картину снизу, а нижний круг — стратегическую информацию и поддержку сверху. Причём делегат выбран самими членами круга (обычно как раз через обсуждение по согласия, без выдвижения кандидатур формально) и имеет равные права в дискуссиях на верхнем уровне. Так исключается искажение информации и одностороннее диктование — обратная связь пронизывает всю систему.

В маленькой команде, конечно, всё проще: может быть один круг, который сам себе и начальник, он же и исполнитель. Но даже там идея кружной структуры полезна: распределение ролей внутри команды можно рассматривать как микро‑круги. Например, роль тимлида, роль ответственного за качество, за деплой и т. д. — каждая роль имеет свой «домен». Sociocracy 3.0 рекомендует чётко оговорить обязанности и области полномочий каждой роли, чтобы все понимали, кто чем владеет. Это устраняет дублирование и серые зоны ответственности.

Кстати, выбор людей на роли — отдельный интересный паттерн S3. Вместо назначения «сверху» или стандартного волеизъявления «кто хочет быть скрам‑мастером?» проводится выбор без кандидатов. Все члены круга открыто обсуждают, кто из коллег лучше всего подходит на роль, и формируют решение по согласованию. Никто заранее не выдвигает свою кандидатуру, поэтому и проигравших нет — решение коллективное, обоснованное и, как правило, охотно принимается назначенным человеком (ведь группа доверила ему эту ответственность, аргументированно объяснив почему).

Паттерны S3

Социократия 3.0 интересна тем, что не навязывает строгий процесс. Вместо этого она предлагает набор из десятков паттернов — проверенных практик и правил, которые помогают решать типичные проблемы самоорганизации. Фактически, это библиотека рецептов на разные случаи: как проводить встречи, как распределять задачи, как улучшать взаимодействие в команде и пр. На сегодняшний день паттернов уже порядка 70–80, и они открыто опубликованы (есть даже подробный гайд в открытом доступе — для желающих углубиться). Приведу несколько примеров, которые показались мне полезными:

• Обсуждение предложений (Proposal Forming): структура для группового обсуждения проблемы и совместной выработки решения. Например, перед тем как принять решение по consent‑процессу, команда может сначала соборно накидать варианты решения, улучшить их, объединить лучшие части — чтобы итоговое предложение учитывало максимум точек зрения.

• Ведение реестра напряжений: в S3 используется понятие «напряжение» — это разрыв между тем, как есть, и как могло бы быть лучше. Грубо говоря, любая проблема, неудобство или возможность улучшения — это напряжение. Паттерн предлагает фиксировать такие напряжения (например, отдельный бэклог улучшений) и регулярно их рассматривать на встречах круга

• Чёткие договорённости (Agreement): любое принятое по согласию решение фиксируется как соглашение — будь то правило, процесс, структура ролей. S3 рекомендует явно записывать кто, за что отвечает, какие правила действуют, и самое главное — пересматривать эти договорённости по мере необходимости.

• Регулярные обзоры и ретроспективы: в социократии ценится эмпирический подход, поэтому есть паттерны, напоминающие Scrum: проводить ретроспективы, проверять, достигли ли решения желаемого эффекта. Например, когда команда принимает решение, сразу можно назначить дату или условие ревью, чтобы вернуться и оценить: работает ли решение, или нужны корректировки.

• Роли и бэклоги: часть паттернов вам покажется знакомой. То же понятие бэклога, итеративного планирования, Daily Scrum — всё это уже давно применяется в Agile и органично вписывается в Sociocracy 3.0. S3 вообще не стремится всё выдумать с нуля — половина практик позаимствована или вдохновлена существующими методологиями. Зато другая половина дополняет наш набор инструментов управления проектами. Например, паттерны на определение домена круга, на согласование ожиданий с внешними стейкхолдерами, на масштабирование количества кругов в организации и т. д.

Паттерны S3 — модульные и гибкие. Их не нужно внедрять разом или полностью. Выберите ту практику, которая решит вашу текущую проблему. Допустим, у вас слишком долгие планёрки — можно начать с паттерна регламента встречи (таймбоксы, четкая повестка, роли фасилитатора и протоколиста). Или, например, в команде неясно, кто за что отвечает — попробуйте паттерн определения доменов и ролей, пропишите зоны ответственности. Каждое нововведение — это тоже эксперимент. Если не приживётся, можно откатить безболезненно.

Когда пригодится Социократия 3.0 и как стартовать пилотно

Вы, возможно, думаете: «Звучит неплохо, но подходит ли это для моей команды или компании?». Элементы S3 полезны, когда:

• Команда кросс‑функциональная, много стейкхолдеров. Когда за столом собираются разработчики, тестировщики, аналитики, дизайнеры, представитель бизнеса — велика опасность, что решение утонет в разношёрстных мнениях. Метод согласия позволяет учесть разные перспективы без бесконечного холивара.

• Нужно больше автономности и скорости. В классических иерархиях каждый чих нужно согласовывать через три уровня начальства, что убивает инициативу.

• Есть проблемы с вовлечённостью команды. Если сотрудники пассивны, молчат на собрании, боятся брать ответственность — социократия может оживить культуру.

• Компания выросла и старые процессы не тянут. Бывает, стартап вырастает, а хаотичный стиль управления начинает буксовать. S3 предоставляет каркас, чтобы встроить самоорганизацию и не скатиться в бюрократию.

Хорошо, вы решились попробовать. С чего начать? Рекомендую не бросаться сразу перестраивать всю организацию, а провести пилот в одном домене. Пусть это будет небольшой рабочий круг с понятной зоной ответственности. Например, выберите проблемную область, где нужны улучшения: качество выпуска релизов, взаимодействие с другими отделами или, скажем, процесс найма разработчиков. Сформируйте круг из заинтересованных людей (это могут быть представители разных ролей, кого касается этот вопрос). Объясните им принципы S3 — хотя бы базово: про согласие, про роли, про фиксацию решений. Затем в течение нескольких спринтов (2-3 месяца) позвольте этому кругу работать по‑новому: проводить встречи в формате согласия, экспериментировать с паттернами.

Во время пилота много внимания уделяйте обратной связи и обучению. Возможно, понадобится фасилитатор, знакомый с социократией, который мягко направит команду, чтобы та не скатилась обратно в старые привычки (например, молчаливое несогласие вместо явных возражений). Запланируйте регулярные ретроспективы: что получается, что буксует? Например, через каждый спринт собирайте участников круга и спрашивайте: «Мы приняли 5 решений по consent‑принципу. Как они сработали? Все ли понимали процесс? Возникали ли скрытые возражения, которые не озвучили?» Такой мета‑анализ поможет вовремя скорректировать применение методики.

По завершении пилотного периода оцените результаты. Улучшилось ли качество и скорость решений в выбранном домене? Стали ли участники активнее предлагать идеи, брать ответственность? Как отнеслись внешние стейкхолдеры к решениям круга? Если есть ощутимая польза, у вас будет кейс, с которым легче масштабировать практики S3 на другие команды или всю компанию. Если же эффекта нет — по крайней мере, вы попробовали с малой кровью и поняли ограничения.

Проблемы

Как и любой подход, Sociocracy 3.0 — не серебряная пуля. В завершение отмечу несколько важных моментов, чтобы вы шли в это осознанно:

• Нужны знания и тренировка. Методологии не работают сами по себе, их должны применять люди. Придётся потратить время на обучение команды принципам согласия, ролям, новым терминам. Поначалу процессы (особенно собрания по новым правилам) могут идти медленнее, пока все не притрутся. Это нормально — закладывайте время на обучающий период.

• Без поддержки сверху не взлетит. Если верхушка компании не готова доверять командам и делегировать решения, социократия столкнётся с сопротивлением. Представьте: ваш круг договорился по согласованию запустить новый подход, а директор сказал «Нет, будет по‑моему». Вся мотивация тут же рухнет. Поэтому важно, чтобы хотя бы в рамках пилота руководство дало «зеленый свет» и не вмешивалось без крайней нужды. Лучше, если топ‑менеджеры сами заинтересованы в успехе такого эксперимента.

• Не для экстремальных ситуаций. Социократическое принятие решений отлично работает в проектных и управленческих вопросах, когда ценна проработка разных мнений. Но в кризисных случаях (инцидент в продакшене, пожар на сервере) — не время собирать круг и обсуждать возражения, тут нужен быстрый единоначальный экшен. Впрочем, это скорее вопрос здравого смысла: S3 не требует применять согласие абсолютно везде и всегда. Определите границы: где мы работаем по‑новому, а где действуем по старой схеме.

• Культура открытости — обязательна. Принцип прозрачности гласит: все важные договорённости и информация должны быть доступны. Если в компании привыкли многое решать кулуарно, не документировать решения, скрывать проблемы — придётся менять культуру. Начните с себя и своего круга: публикуйте протоколы встреч, фиксируйте принятые правила, держите видимым список задач и напряжений. Постепенно люди оценят, что открытость экономит время и строит доверие.

• Постоянное улучшение. S3 основана на идее эмпирического подхода: пробуем — учимся — улучшаем. Даже сами принципы и паттерны можно адаптировать. Если чувствуете, что какой‑то инструмент не заходит, обсудите командой, в чём причина. Может, стоит его модифицировать под ваш контекст. Социократия 3.0 не догма, а конструктор для развития вашей собственной системы управления.

Лично меня S3 привлекла своей здоровой прагматичностью. Просто логичные принципы, призванные ускорить решения и вовлечь людей, плюс большая подборка практик, многие из которых знакомы любому знакомому Agile. Да, название «социократия» звучит непривычно и даже слегка пугающе, но суть довольно приземлённая: сделать так, чтобы каждый в команде мог влиять на решения, и при этом никто не тормозил общий прогресс по пустякам. Возможно, именно этого не хватало вашей команде для нового витка продуктивности и взаимопонимания. Удачи!

Если в спринтах стабильно всплывают «узкие места» — по коду, DevOps-процессам, аналитике или управлению — их проще закрывать точечно. В OTUS есть корпоративные треки под опытные команды: живые вечерние занятия и практические задачи по вашим кейсам, контроль прогресса в кабинете тимлида и гибкая сборка программы — от открытых групп до кастомного курса под домен. Встраивается в рабочий ритм без лишней бюрократии — чтобы команда быстрее решала боевые задачи.

А чтобы оставаться в курсе актуальных трендов управления в IT и первыми узнавать новости о бесплатных мероприятиях, подписывайтесь на Telegram‑канал OTUS4Business.