Чтобы найти способ улучшить процессы и процедуры в компании, полезно смотреть на чужой управленческий опыт: на чём строятся решения, какие паттерны и концепты можно попробовать у себя и уместен ли контекст. Чем шире кругозор, тем из большего числа подходов можно выбрать подходящее решение.
Я Максим Цепков, IT-архитектор, бизнес-аналитик, эксперт по миру Agile, бирюзовых организаций и спиральной динамике. Помимо основной работы, я затаскиваю знания из других отраслей в IT и смотрю, что в них полезного для управления проектами. Потом делюсь опытом на конференциях. Сегодня расскажу о Социократии 3.0 — фреймворке с философскими корнями, который помогает настроить гибкие процессы внутри IT-проекта и команды, повысить производительность и задать фокус правильным ценностям.
Bernhard Bockelbrink, James Priest and Liliana David «Influences and History of Sociocracy 3.0»
Начало социократии: из философии в практику менеджмента
Социократию в середине XIX века придумал французский философ Огюст Конт. Она родилась как пр��ктическое приложение его теории позитивизма. Но оказалась настолько не похожей на другие представления об устройстве общества, что далеко не все сторонники Конта восприняли эти новые идеи, а часть из них даже посчитала, что Конт сошел с ума.
В начале XX века идеи Социократии использовались для управления самостоятельными общинами в распределенной религиозной организации. А в 70 гг. нидерландский предприниматель Герард Энденбург применил этот подход в управлении своей компанией и фактически перенес социократию на менеджмент. Он настроил самоуправление у себя, практика начала тиражироваться по другим компаниям, и в Голландии возникло целое сообщество.
В начале 2010-х социократию дополнили тем, что накопилось в других отраслях — Agile, Lean, холакратия, и так в 2015 появилась «Социократия 3.0».
В списке из 84-х паттернов Социократии примерно половина нам знакомы, например, паттерны бэклога, встреч типа Stand Up, Daily, планирование и т.д. Но есть и другая половина, которая пришла из других источников и здорово дополняет существующие практики управления.
Как устроена Социократия 3.0
Цель Социократии — помочь бизнесу достичь своих целей и сделать это через гибкость, эксперименты и постоянное обучение.
База технологии — концепты, термины и шаблоны
У Социократии свой глоссарий, который помогает описать деятельность и ключевые принципы и шаблоны, чтобы всё реализовать. Это похоже на Agile-манифест, где тоже есть принципы, а потом есть SCRUM и Kanban как их реализация.
Шаблоны — это практики, описанные в виде процедур. Они разбиты на тематические гр��ппы, некоторые из них связаны друг с другом, но можно применять и независимо друг от друга.
Всё это компонуется в целостный фреймворк CommonSence для компании, но шаблоны могут использоваться и отдельно.
Социократия мне нравится тем, что она не предлагает делать революцию: если в компании проблемы, технология предлагает оценить их и посмотреть на шаблоны готовых решений. Дальше можно попробовать, и если не понравится, безболезненно выйти из процесса. Решения из Социократии можно брать независимо и гибко.
Семь основных принципов
Чтобы организовать работу, Социократия предлагает список из принципов:
Результативность: не делать ненужного, делать лишь ценное.
Консент: хочешь сделать — сначала расскажи, чтобы снизить риски и улучшить планы.
Эмпиризм: любое действие — эксперимент с оценкой результатов.
Постоянное развитие: важно регулярно оценивать результаты для поэтапных изменений способа действий.
Равноценность: вовлекайте людей в принятие влияющих решений — это повышает вовлеченность и ответственность, дает коллективный интеллект.
Прозрачность: записывайте всю ценную информацию и делайте её доступной для всех, если нет причин для конфиденциальности. Так каждый сможет лучше ориентироваться и принимать решения по своей работе.
Ответственность: реагируйте, когда возникает потребность, делайте то, на что вы согласились, берите ответственность за направление движения компании.
Что важно, принципы — это один из шаблонов, их можно не принимать. К примеру, если компания работает в таком рыночном или бизнес-контексте, что какие-то принципы не подходят и работают другие — это нормально. Шаблоны нужно адаптировать под себя.
Социократия в процессах IT-разработки
Чтобы лучше понять термины и принципы технологии, пройдемся по основным составляющим Социократии 3.0 и разберем их на примерах.
Цель деятельности — снимать напряжение, а не делать задачи
Напряжение — это источник мотивации для действий. Через него мы меняем процессы, улучшаем продукты, создаем команды и целые компании.
Рассмотрим, как Социократия объясняет стремление к изменениям.
Любая деятельность в организации начинается с напряжения
Представьте, что вы смотрите на какой-то процесс, и вам хочется с ним что-то сделать, потому что раздражает. Как пример можем взять аналитика: ему прилетел запрос о потенциальных проблемах с отчётом. Он лезет в код отчёта, и видит многоэтажную конструкцию запроса (select), которую вдруг не понимает. В других отчётах он запросы «select» читал, быстро находил ошибки, разбирался, объяснял, а тут не получилось. Если таких случаев много, аналитика это раздражает и возникает желание сделать этот select понятным.
При этом, раздражение от напряжения может не нести ценности и быть чисто эстетическим. Например, если мне не нравится, как разработчик форматирует код, потому что я форматирую по-другому, в этом нет ценности. Это просто два подхода, потому что код примерно одинаково понятен.
Возникшее напряжение надо преобразовать в драйвер
Драйвер — это когда мы придумываем, как снять напряжение, чтобы создать возможность для появления ценности или устранить препятствия на её пути.
Сам по себе драйвер не содержит решения, но отражает предположение о том, как изменится поток ценностей.
Когда драйвер найден, запускается экспериментальный цикл: придумать решение, принять это решение, убедиться, что придумка стоит эксперимента, и реализовать.
После реализации смотрим, что получилось сделать, и либо думаем другое решение, либо признаём, что мы ошибались и в драйвере нет ценности.
Соглашение — ответ на драйвер в виде регламента
Соглашение — это договоренность о деятельности в виде политики, протокола или регламента. Роль соглашения не только в достижении ценности через работу, но и в ограничении свободы действий, если они не ведут к ценности.
Есть правила, по которым достигается соглашение:
К решению привлекают всех, кого затрагивает соглашение.
У всех соглашений есть срок пересмотра, когда можно оценить актуальность и пользу драйвера, и если нужно, предложить улучшения.
Пересмотр может произойти в любой момент, если возник драйвер.
Соглашения можно нарушать, если их соблюдение неразумно в конкретной ситуации.
Социократия как фреймворк исходит из того, что если соглашение нельзя нарушить, то его нельзя улучшить. А чтобы улучшить, надо попробовать по-другому. Поэтому нарушение возможно, оно остается на усмотрение того, кто делает. Он же принимает ответственность за:
последствия;
работу с теми, кого это нарушение затронуло;
изменение соглашения, если оно нарушается не один раз, а регулярно.
Если я вижу, что это надо делать регулярно, то соглашение надо менять.
Драйверы и регламенты деятельности
В разработке команды часто применяют различные стайл-гайды, технические политики, регламенты ведения задач и т.д. Все эти правила появились в ответ на какое-то напряжение, но в процессе работы драйвер мог потерять актуальность.
Например, нет пользы в таких нововведениях, как архитектурная политика или архитектурное ревью, если они появились в работе только потому, что нас раздражает «костыльность» архитектуры. Приложения с плохой архитектурой мы всё равно делаем быстро, и они работают. Мы думали, что будет быстрее — быстрее не стало, стало дольше и дороже — а зачем?
Я видел примеры, когда правила постановки инцидентов компании жестко формировались заказчиком. Была компания и процессы в ней работали неформально, команде было удобно. Но появился требовательный заказчик, для него сделали более жёсткие правила, и потом распространили на всех. Даже там, где такая жёсткость не нужна. В итоге правила существуют бессмысленно, и никто не вспоминает, что послужило драйвером.
Оцените ваши регламенты
С точки зрения Социократии интересно оценить стайл-гайды, технические политики, регламенты ведения задач и процессы. Вот примеры вопросов, над которыми можно подумать:
Понятно ли, какие драйверы были у этих регламентов? Почему они появились?
Актуальны ли эти драйверы сейчас?
В чем польза регламента? И как она соотносится с затратами на поддержание?
Как часто пересматривают регламент?
Может ли любой, кто пользуется регламентом, сообщить о напряжении и инициировать пересмотр?
Вовлечены ли все, кого затрагивает регламент, в разработку его содержания?
Драйверы для компании, команды, рабочей группы
Стоит задуматься не только о драйверах для гайдов и политик, но и о драйверах компании, команды, рабочей группы. В чём смысл их работы?
Любую компанию когда-то создали в ответ на напряжение. И этот подход к деятельности тотален. К примеру, если создатель испытывал раздражение от компаний, в которых работал, и захотел сделать у себя по-другому. Так появилась новая компания, с другой ценностью и стратегией работы на драйвер.
Помним, что любое действие — эксперимент, и результат не гарантирован. Фича может оказаться бесполезной, а изменение процесса, придуманное на ретро, не дать эффекта.
Решение — не идеально, оно лишь достаточно хорошо, чтобы уменьшить напряжение
Громадное количество стайл-гайдов, архитектурных гайдов упирается в то, что люди в них закапываются. Образуется всё больше областей, где надо сделать и то, и это, а времени нет. В результате работа теряет смысл.
Фреймворк говорит, что поскольку это эксперимент, то должно быть достаточно хорошо, чтобы появилась ценность и достаточно безопасно, чтобы попробовать. Для большинства рабочих примеров это нормальный, быстрый подход. Он сокращает время, и не нужно искать идеальное решение.
Цель, стратегия и инициатива
В больших задачах решение даёт общую стратегию, направление деятельности. Если есть направление, то дальше оно декомпозируется, и каждый шаг делается отдельным проходом. Поясню про цель, стратегии и инициативы на метафоре путешествия по горам.
Мы где-то в горах. За горами море и устье реки, и мы хотим туда дойти. Стратегия — это когда мы решили, что не пойдём через хребет и выбрали путь в обход. Дальше мы выбираем, какой дорогой идти — попробовали одну, вторую, по пути вскрылись какие-то детали. Инициативы, которые выдвигаются, должны соответствовать стратегии и вести к цели. Когда инициатив много, приходится выбирать.
Вернёмся к примеру про аналитика, который не понимает код в отчёте. Это раздражение можно преобразовать в драйвер: сделать так, что аналитик поймет код. Тогда он быстро выполнит запрос, ответит клиенту и не будет отвлекать разработчика. К этому результату мы можем идти разными путями. Например, посмотреть, в чём он уже хорошо разбирается и обучить тому, что не умеет или научить определять проблему на входе, или какой-то ещё вариант. Надо пробовать: гипотез может быть несколько, и у разных людей могут быть разные предложения.
Принятие решений в группе
Социократия регулирует принятие решений через принципы и шаблоны процедур обсуждения. Принципы говорят:
Хочешь что-то сделать — расскажи, чтобы снизить риски и улучшить.
В ответ на предложение команда выскажет мнения и предложит, что улучшить.
Слушай все мнения, но отвечай лишь на возражения, которые аргументируют вред. Всё остальное можно принять к сведению или не принять.
Квалификация мнения как возражения должна быть подтверждена экспертным мнением.
Эти тезисы разворачиваются в виде шаблонов: как организовать эффективное обсуждение, как работать с возражениями, и почему важно, приняв решение, отпраздновать его, каким бы оно ни было.
Шаблоны принятия решений с помощью консента
Перед началом поиска решения по драйверу, все участники должны согласиться, что результатом станет ценность, а не удовлетворение эстетических ч��вств. Если так, то дальше идёт предложение, уточняющие вопросы, быстрая реакция, мнения, возражения и решение.
Технология конкретизирует по шагам, как это сделать и в какой последовательности. Для каждого шага — свой шаблон: как классифицировать и разрешать возражения, как вовлекать тех, на кого влияет решение, фасилитировать встречи, финализировать решение и др.
Консент — способ принятия решений через инициативу
Консент помогает управлять любыми обсуждениями, холиварами и спорами. Например, когда мы смотрим на решение по дизайну и технологиям — использовать ли новый фреймворк, на основе каких паттернов делать дизайн, использовать ли фабрики, стратегии или сервис-локатор и т.д.
Решение остается за тем, кто будет его исполнять
Тот, кто будет писать код, напишет тот код, который захочет. Конечно, код-ревью может потом заставить всё переписать, но если кода много и всё работает, реализация остается за автором. Важно помнить, что решение не обязано быть совершенным, а лишь достаточно хорошим.
При этом есть два важных полагания:
Если нет возражений по соглашению, я намереваюсь выполнить это соглашение наилучшим образом в пределах моей компетенции.
Я обязуюсь озвучивать возражения, когда они у меня появляются.
Если так действуют все, решение будет выполнено. Но это не значит, что его нельзя изменить. Если исполнитель понял, что решение плохое, и возникает новое напряжение, то можно инициировать процедуру пересмотра решения. Такая нестабильность нормальна.
Важно квалифицировать мнения на возражения и сомнения
Возражение отличается от сомнения опорой на твёрдые факты. Это часто некомфортно для критиков. Кто-то скажет: «А давайте не будем брать Postgres, а останемся на Oracle». А мы попросим аргумент — почему? И тут два варианта возможны. Если тот, кто высказывает, не может обосновать свое возражение, то на них никто не обязан отвечать. А если звучит: «Не хочу учить Postgres», то возникает вопрос, от кого этот тезис исходит. Если со стороны поддержки, и «не хочу» подкрепляется счётом на обучение или на найм новых специалистов, то это может быть аргументированным возражением, имеющим цену. Но с этим можно работать.
Коммуникация, ответственность и совместная работа
Теперь расскажу, как фреймворк помогает распределить ответственность.
Домены и ответственность
Вся деятельность в проекте делится по доменам. Каждый домен — это зона ответственности человека или отдельного круга (команды). У домена свой драйвер, и это то, что придает смысл всей деятельности.
Как делить ответственность
Найти драйвер может любой человек, даже если он вне домена, а реагирует только ответственный. Но нельзя при этом сказать: «Не суйся в мой домен».
Как пример, вы приносите новый техстек в проекте заказчику, а админы говорят, что не умеют это инсталлировать и сопровождать. Но если драйвер полезный и заказчик его принял, то админам остается или научиться новому, сохранив ответственность за все сервера, или делегировать, сказав, что здесь исключение, э��о не наша область, делайте сами. Обычно ответственные за проект согласны делать сами, ведь они не просто так принесли техстек.
В момент выделения домена запускается соглашение, где регулируется ответственность: за что отвечает делегатор и что в ответственности тех, кто управляет доменом. Такой же принцип применяется по отношению к компании или к проекту.
Круги и роли внутри них
Круг — группа людей, которая отвечает за домен. Один человек может участвовать в нескольких кругах, играя разные роли (role keeper).
В гайде фреймворка есть несколько способов организации кругов:
Самоорганизующаяся команда — полуавтономная команда равноценных по статусу людей, которые совместно отвечают за домен.
Команда помощников — люди, которые ещё не готовы принимать ответственность за самоорганизацию, но вполне могут профессионально работать.
Круги связаны друг с другом в сетевую структуру. Эта связь обычно двунаправленная через разных представителей и часто соответствует шаблонам типовой структуры.
Схемы можно комбинировать. Если Kanban говорит: «Организуйте вдоль цепочек создания ценностей», то Социократия предлагает сделать тоже самое, но через организацию кругов, плюс даёт шаблоны, чтобы это быстро реализовать.
Принципы обратной связи
Фреймворк разделяет человека как роль и как личность, поэтому для обратной связи есть шаблоны:
«Обратная связь от равных» описывает действия человека как личности.
«Коллегиальный обзор» помогает дать обратную связь в рамках роли — коллективной или индивидуальной.
Обратную связь организует тот, кому она нужна, но есть предполагаемые сроки, когда можно её запросить. Ещё важно, что это открытая процедура: на неё может попасть любой желающий или заинтересованное лицо как самостоятельно, так и по приглашению.
Целостный фреймворк деятельности
Есть общая схема работы Социократии как фреймворка. Её можно использовать, если создают новую компанию и сразу хотят использовать управление по социократии, а не идти эволюционным путем. А еще он помогает понять структуру технологии и взаимосвязь отдельных шаблонов.
В центре — цель и стратегия. Дальше — принципы работы (не делать не нужного и выявлять препятствия, делать эксперименты, подходы к деятельности) и слой про принципы работы команды (работать автономными командами и создавать окружение для сотрудничества внутри команд). Круг закрывают принципы развития, потому что надо идти вперед, развивать культуру, общие ментальные модели и концепты.
Личные цели и цели организации или команды
У организации, команды и проекта — своя цель. Её поставили основатели или инициаторы и позвали других. Так она стала контрактом для сотрудничества людей, и из цели основателей переросла в цель организации.
С изменениями мира цель меняется, и об этом договариваются в команде.
Интересные шаблоны
Ниже — список из интересных шаблон��в и паттернов решения, которые можно применить или адаптировать у себя.
Просьба о помощи: право на отказ столь же важно, как и право на помощь
Может показаться, что шаблон лишний и чтобы попросить о помощи, не нужна инструкция. На самом деле он помогает сформировать культуру: о помощи может попросить любой, но и тот, кого просят, может отказать.
Искусное участие и Нарушение соглашений
Искусное участие побуждает всё время задавать себе вопрос, действую ли я наилучшим образом для достижения целей сотрудничестве? В том числе, выполняя соглашения, следовать им не всегда разумно в конкретной ситуации. И в этом случае соглашение можно нарушить, для чего есть отдельный шаблон.
Ценности — навигатор при решениях там, где не хватает соглашений
В Социократии нет готовых ценностей, есть принципы. Ценности компания должна выработать сама. Тогда они сработают как навигатор и помогут найти решения там, где не хватает соглашений.
Уточнение и развитие стратегии, домена, роли
Шаблонов такого типа во фреймворке много. В них приведены инструкции для подготовки встреч и разных других процедур. Поэтому, если уже есть готовые описания процессов, эти шаблоны могут пригодиться как дополнение.
Отдельные встречи по управлению
В гайде Социократии выделено несколько типов встреч. У большинства из них есть аналоги — примеру, в SCRUM или Kanban. Но есть и отдельные встречи по управлению, которые в других фреймворках не выделены.
Вытягивающая система для оргизменений и другие шаблоны привнесения Социократии
Чтобы Социократия появилась в организации, её нужно не внедрить, а привнести. Фреймворк опирается на то, что в компании должна быть вытягивающая система, а не пушинг со стороны руководства. Нужно показать, создать условия, увлечь людей.
Встречи: фасилитация, подготовка, сонастройка, рефлексия
В восьмом разделе — информация по встречам: как начать, как проводить и какие ритуалы в конце помогут оценить результат. Как пример — такт сонастройки в начале, который проясняет настроение человека. Или обязательная рефлексия за 5 минут до завершения встречи. Такие практики часто дают большой профит для общей работы.
Прозрачная зарплата
В отдельном шаблоне сформулированы принципы прозрачной зарплаты и критерии справедливой формулы для её расчета. Что учесть, как оценить справедливость и какой подход выбрать, чтобы прозрачность не навредила сотрудникам.
Итоги: Социократия – полезный источник практик
В качестве вывода можно сказать, что характер деятельности в Социократии аналогичен разработке продуктов через эксперименты, и потому многие практики уместны.
Много пользы в шаблонах:
Принципы принятия решений для разных проблем.
Описания процедур, протоколы и канвасы.
Детальное разделение того, что часто слеплено, например, выделить ответственность и выбрать ответственного, или обратная связь человеку и роли.
Социократия — хороший источник организационных решений как библиотеки паттернов и хороший источник решений для дизайна. Используйте!
Ссылки на ресурсы о Социократии 3.0
Основная книга — это гайд по Социократии. Можно изучать в двух версиях — на английском и русском языках. Гайды открыты, информация в документах регулярно обновляется авторами:
Гайд по Социократии на английском sociocracy.org
Гайд по Социократии на русском sociocracy30.ru
Telegram-чат русскоязычного сообщества для тех, кто осваивает Социократию t.me/sociocracy30
Приглашаем на Saint TeamLead Conf - конференцию для тимлидов и руководителей, 26 и 27 сентября 2022 в Санкт-Петербург. Расписание, билеты и подробности на сайте https://clck.ru/sNLxt
