Чтобы найти способ улучшить процессы и процедуры в компании, полезно смотреть на чужой управленческий опыт: на чём строятся решения, какие паттерны и концепты можно попробовать у себя и уместен ли контекст. Чем шире кругозор, тем из большего числа подходов можно выбрать подходящее решение.  Я Максим Цепков, 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, планирование и т.д. Но есть и другая половина, которая пришла из других источников и здорово дополняет существующие практики управления.  Цель Социократии — помочь бизнесу достичь своих целей и сделать это через гибкость, эксперименты и постоянное обучение. У Социократии свой глоссарий, который помогает описать деятельность и ключевые принципы и шаблоны, чтобы всё реализовать. Это похоже на Agile-манифест, где тоже есть принципы, а потом есть SCRUM и Kanban как их реализация.  Шаблоны — это практики, описанные в виде процедур. Они разбиты на тематические группы, некоторые из них связаны друг с другом, но можно применять и независимо друг от друга.   Всё это компонуется в целостный фреймворк CommonSence для компании, но шаблоны могут использоваться и отдельно. Социократия мне нравится тем, что она не предлагает делать революцию: если в компании проблемы, технология предлагает оценить их и посмотреть на шаблоны готовых решений. Дальше можно попробовать, и если не понравится, безболезненно выйти из процесса. Решения из Социократии можно брать независимо и гибко. Чтобы организовать работу, Социократия предлагает список из принципов: Результативность: не делать ненужного, делать лишь ценное. Консент: хочешь сделать — сначала расскажи, чтобы снизить риски и улучшить планы. Эмпиризм: любое действие — эксперимент с оценкой результатов. Постоянное развитие: важно регулярно оценивать результаты для поэтапных изменений способа действий. Равноценность: вовлекайте людей в принятие влияющих решений — это повышает вовлеченность и ответственность, дает коллективный интеллект. Прозрачность: записывайте всю ценную информацию и делайте её доступной для всех, если нет причин для конфиденциальности. Так каждый сможет лучше ориентироваться и принимать решения по своей работе. Ответственность: реагируйте, когда возникает потребность, делайте то, на что вы согласились, берите ответственность за направление движения компании. Что важно, принципы — это один из шаблонов, их можно не принимать. К примеру, если компания работает в таком рыночном или бизнес-контексте, что какие-то принципы не подходят и работают другие — это нормально. Шаблоны нужно адаптировать под себя. Чтобы лучше понять термины и принципы технологии, пройдемся по основным составляющим Социократии 3.0 и разберем их на примерах.  Напряжение — это источник мотивации для действий. Через него мы меняем процессы, улучшаем продукты, создаем команды и целые компании.  Рассмотрим, как Социократия объясняет стремление к изменениям. Представьте, что вы смотрите на какой-то процесс, и вам хочется с ним что-то сделать, потому что раздражает. Как пример можем взять аналитика: ему прилетел запрос о потенциальных проблемах с отчётом. Он лезет в код отчёта, и видит многоэтажную конструкцию запроса (select), которую вдруг не понимает. В других отчётах он запросы «select» читал, быстро находил ошибки, разбирался, объяснял, а тут не получилось. Если таких случаев много, аналитика это раздражает и возникает желание сделать этот select понятным. При этом, раздражение от напряжения может не нести ценности и быть чисто эстетическим. Например, если мне не нравится, как разработчик форматирует код, потому что я форматирую по-другому, в этом нет ценности. Это просто два подхода, потому что код примерно одинаково понятен.  Драйвер — это когда мы придумываем, как снять напряжение, чтобы создать возможность для появления ценности или устранить препятствия на её пути.  Сам по себе драйвер не содержит решения, но отражает предположение о том, как изменится поток ценностей. Когда драйвер найден, запускается экспериментальный цикл: придумать решение, принять это решение, убедиться, что придумка стоит эксперимента, и реализовать.  После реализации смотрим, что получилось сделать, и либо думаем  другое решение, либо признаём, что мы ошибались и в драйвере нет ценности.  Соглашение — это договоренность о деятельности в виде политики, протокола или регламента. Роль соглашения не только в достижении ценности через работу, но и в ограничении свободы действий, если они не ведут к ценности. Есть правила, по которым достигается соглашение: К решению привлекают всех, кого затрагивает соглашение. У всех соглашений есть срок пересмотра, когда можно оценить актуальность и пользу драйвера, и если нужно, предложить улучшения. Пересмотр может произойти в любой момент, если возник драйвер. Соглашения можно нарушать, если их соблюдение неразумно в конкретной ситуации. Социократия как фреймворк исходит из того, что если соглашение нельзя нарушить, то его нельзя улучшить. А чтобы улучшить, надо попробовать по-другому. Поэтому нарушение возможно, оно остается на усмотрение того, кто делает. Он же принимает ответственность за: последствия; работу с теми, кого это нарушение затронуло; изменение соглашения, если оно нарушается не один раз, а регулярно.  Если я вижу, что это надо делать регулярно, то соглашение надо менять. В разработке команды часто применяют различные стайл-гайды, технические политики, регламенты ведения задач и т.д. Все эти правила появились в ответ на какое-то напряжение, но в процессе работы драйвер мог потерять актуальность.  Например, нет пользы в таких нововведениях, как архитектурная политика или архитектурное ревью, если они появились в работе только потому, что нас раздражает «костыльность» архитектуры. Приложения с плохой архитектурой мы всё равно делаем быстро, и они работают. Мы думали, что будет быстрее — быстрее не стало, стало дольше и дороже — а зачем? Я видел примеры, когда правила постановки инцидентов компании жестко формировались заказчиком. Была компания и процессы в ней работали неформально, команде было удобно. Но появился требовательный заказчик, для него сделали более жёсткие правила, и потом распространили на всех. Даже там, где такая жёсткость не нужна. В итоге правила существуют бессмысленно, и никто не вспоминает, что послужило драйвером.  С точки зрения Социократии интересно оценить стайл-гайды, технические политики, регламенты ведения задач и процессы. Вот примеры вопросов, над которыми можно подумать: Понятно ли, какие драйверы были у этих регламентов? Почему они появились? Актуальны ли эти драйверы сейчас? В чем польза регламента? И как она соотносится с затратами на поддержание? Как часто пересматривают регламент? Может ли любой, кто пользуется  регламентом, сообщить о напряжении и инициировать пересмотр? Вовлечены ли все, кого затрагивает регламент, в разработку его содержания? Стоит задуматься не только о драйверах для гайдов и политик, но и о драйверах компании, команды, рабочей группы. В чём смысл их работы?  Любую компанию когда-то создали в ответ на напряжение. И этот подход к деятельности тотален. К примеру, если создатель испытывал раздражение от компаний, в которых работал, и захотел сделать у себя по-другому. Так появилась новая компания, с другой ценностью и стратегией работы на драйвер.  Помним, что любое действие — эксперимент, и результат не гарантирован. Фича может оказаться бесполезной, а изменение процесса, придуманное на ретро, не дать эффекта. Громадное количество стайл-гайдов, архитектурных гайдов упирается в то, что люди в них закапываются. Образуется всё больше областей, где надо сделать и то, и это, а времени нет. В результате работа теряет смысл. Фреймворк говорит, что поскольку это эксперимент, то должно быть достаточно хорошо, чтобы появилась ценность и достаточно безопасно, чтобы попробовать. Для большинства рабочих примеров это нормальный, быстрый подход. Он сокращает время, и не нужно искать идеальное решение.  В больших задачах решение даёт общую стратегию, направление деятельности. Если есть направление, то дальше оно декомпозируется, и каждый шаг делается отдельным проходом. Поясню про цель, стратегии и инициативы на метафоре путешествия по горам. Мы где-то в горах. За горами море и устье реки, и мы хотим туда дойти. Стратегия — это когда мы решили, что не пойдём через хребет и выбрали путь в обход. Дальше мы выбираем, какой дорогой идти — попробовали одну, вторую, по пути вскрылись какие-то детали. Инициативы, которые выдвигаются, должны соответствовать стратегии и вести к цели. Когда инициатив много, приходится  выбирать. Вернёмся  к примеру про аналитика, который не понимает код в отчёте. Это раздражение можно преобразовать в драйвер:  сделать так, что аналитик поймет код. Тогда он быстро выполнит запрос, ответит клиенту и не будет отвлекать разработчика. К этому результату мы можем идти разными путями. Например, посмотреть, в чём он уже хорошо разбирается и обучить тому, что не умеет или научить определять проблему на входе, или какой-то ещё вариант. Надо пробовать: гипотез может быть несколько, и у разных людей могут быть разные предложения. Социократия регулирует принятие решений через принципы и шаблоны процедур обсуждения. Принципы говорят: Хочешь что-то сделать — расскажи, чтобы снизить риски и улучшить. В ответ на предложение команда выскажет мнения и предложит, что улучшить.  Слушай все мнения, но отвечай лишь на возражения, которые аргументируют вред. Всё остальное можно принять к сведению или не принять. Квалификация мнения как возражения должна быть подтверждена экспертным мнением. Эти тезисы  разворачиваются в виде шаблонов: как организовать эффективное обсуждение, как работать с возражениями, и почему важно, приняв решение, отпраздновать его, каким бы оно ни было.  Перед началом поиска решения по драйверу, все участники должны согласиться, что результатом станет ценность, а не удовлетворение эстетических чувств. Если так, то дальше идёт предложение, уточняющие вопросы, быстрая реакция, мнения, возражения и решение.  Технология конкретизирует по шагам, как это сделать и в какой последовательности. Для каждого шага — свой шаблон: как классифицировать и разрешать возражения, как вовлекать тех, на кого влияет решение, фасилитировать встречи, финализировать решение и др. Консент помогает управлять любыми обсуждениями, холиварами и спорами. Например, когда мы смотрим на решение по дизайну и технологиям — использовать ли новый фреймворк, на основе каких паттернов делать дизайн, использовать ли фабрики, стратегии или сервис-локатор и т.д.  Тот, кто будет писать код, напишет тот код, который  захочет. Конечно, код-ревью может потом заставить всё переписать, но если кода много и всё работает, реализация остается за автором. Важно помнить, что решение не обязано быть совершенным, а лишь достаточно хорошим. При этом есть два важных полагания: Если нет возражений по соглашению, я намереваюсь выполнить это соглашение наилучшим образом в пределах моей компетенции. Я обязуюсь озвучивать возражения, когда они у меня появляются.  Если так действуют все, решение будет выполнено. Но это не значит, что его нельзя изменить. Если исполнитель понял, что решение плохое, и возникает новое напряжение, то можно инициировать процедуру пересмотра решения. Такая нестабильность нормальна. Важно квалифицировать мнения на возражения и сомнения Возражение отличается от сомнения опорой на твёрдые факты. Это часто некомфортно для критиков. Кто-то скажет: «А давайте не будем брать Postgres, а останемся на Oracle». А мы попросим аргумент — почему? И тут два варианта возможны. Если тот, кто высказывает, не может обосновать свое возражение, то на них никто не обязан отвечать. А если звучит: «Не хочу учить Postgres», то возникает вопрос, от кого этот тезис исходит. Если со стороны поддержки, и «не хочу» подкрепляется счётом на обучение или на найм новых специалистов, то это может быть аргументированным возражением, имеющим цену. Но с этим можно работать. Теперь расскажу, как фреймворк помогает распределить ответственность.  Вся деятельность в проекте делится по доменам. Каждый домен — это зона ответственности человека или отдельного круга (команды). У домена свой драйвер, и это то, что придает смысл всей деятельности.  Найти драйвер может любой человек, даже если он вне домена, а реагирует только ответственный. Но нельзя при этом сказать: «Не суйся в мой домен».  Как пример, вы приносите новый техстек в проекте заказчику, а админы говорят, что не умеют это инсталлировать и сопровождать. Но если драйвер полезный и заказчик его принял, то админам остается или научиться новому, сохранив ответственность за все сервера, или делегировать, сказав, что здесь исключение, это не наша область, делайте сами. Обычно ответственные за проект согласны делать сами, ведь они не просто так принесли техстек. В момент выделения домена запускается соглашение, где регулируется ответственность: за что отвечает делегатор и что в ответственности тех, кто управляет доменом. Такой же принцип применяется по отношению к компании или к проекту.  Круг — группа людей, которая отвечает за домен. Один человек может участвовать в нескольких кругах, играя разные роли (role keeper).  В гайде фреймворка есть несколько способов организации кругов: Самоорганизующаяся команда — полуавтономная команда равноценных по статусу людей, которые совместно отвечают за домен.  Команда помощников — люди, которые ещё не готовы принимать ответственность за самоорганизацию, но вполне могут профессионально работать. Круги связаны друг с другом в сетевую структуру. Эта связь обычно двунаправленная через разных представителей и часто соответствует шаблонам типовой структуры. Схемы можно комбинировать. Если Kanban говорит: «Организуйте вдоль цепочек создания ценностей», то Социократия предлагает сделать тоже самое, но через организацию кругов, плюс даёт шаблоны, чтобы это быстро реализовать. Фреймворк разделяет человека как роль и как личность, поэтому для обратной связи есть шаблоны: «Обратная связь от равных» описывает действия человека как личности. «Коллегиальный обзор» помогает дать обратную связь в рамках роли — коллективной или индивидуальной. Обратную связь организует тот, кому она нужна, но есть предполагаемые сроки, когда можно её запросить. Ещё важно, что это открытая процедура: на неё может попасть любой желающий или заинтересованное лицо как самостоятельно, так и по приглашению.  Есть общая схема работы Социократии как фреймворка. Её можно использовать, если создают новую компанию и сразу хотят использовать управление по социократии, а не идти эволюционным путем. А еще он помогает понять структуру технологии и взаимосвязь отдельных шаблонов. В центре — цель и стратегия. Дальше — принципы работы (не делать не нужного и выявлять препятствия, делать эксперименты, подходы к деятельности) и слой про принципы работы команды (работать автономными командами и создавать окружение для сотрудничества внутри команд). Круг закрывают принципы развития, потому что надо идти вперед, развивать культуру, общие ментальные модели и концепты. У организации, команды и проекта — своя цель. Её поставили основатели или инициаторы и позвали других. Так она стала контрактом для сотрудничества людей, и из цели основателей переросла в цель организации. С изменениями мира цель меняется, и об этом договариваются в команде.  Ниже — список из интересных шаблонов и паттернов решения, которые можно применить или адаптировать у себя.  Может показаться, что шаблон лишний и чтобы попросить о помощи, не нужна инструкция. На самом деле он помогает сформировать культуру: о помощи может попросить любой, но и тот, кого просят, может отказать.  Искусное участие побуждает всё время задавать себе вопрос, действую ли я наилучшим образом для достижения целей сотрудничестве? В том числе, выполняя соглашения, следовать им не всегда разумно в конкретной ситуации. И в этом случае соглашение можно нарушить, для чего есть отдельный шаблон.  В Социократии нет готовых ценностей, есть принципы. Ценности компания должна выработать сама. Тогда они сработают как навигатор и помогут найти решения там, где не хватает соглашений.  Шаблонов такого типа во фреймворке много. В них приведены инструкции для подготовки встреч и разных других процедур. Поэтому, если уже есть готовые описания процессов, эти шаблоны могут пригодиться как дополнение.  В гайде Социократии выделено несколько типов встреч. У большинства из них есть аналоги — примеру, в SCRUM или Kanban. Но есть и отдельные встречи по управлению, которые в других фреймворках не выделены.  Чтобы Социократия появилась в организации, её нужно не внедрить, а привнести. Фреймворк опирается на то, что в компании должна быть вытягивающая система, а не пушинг со стороны руководства. Нужно показать, создать условия, увлечь людей.  В восьмом разделе — информация по встречам: как начать, как проводить и какие ритуалы в конце помогут оценить результат. Как пример — такт сонастройки в начале, который проясняет настроение человека. Или обязательная рефлексия за 5 минут до завершения встречи. Такие практики часто дают большой профит для общей работы.  В отдельном шаблоне сформулированы принципы прозрачной зарплаты и критерии справедливой формулы для её расчета. Что учесть, как оценить справедливость и какой подход выбрать, чтобы прозрачность не навредила сотрудникам.  В качестве вывода можно сказать, что характер деятельности в Социократии аналогичен разработке продуктов через эксперименты, и потому многие практики уместны.  Много пользы в шаблонах: Принципы принятия решений для разных проблем. Описания процедур, протоколы и канвасы. Детальное разделение того, что часто слеплено, например, выделить ответственность и выбрать ответственного, или обратная связь человеку и роли. Социократия — хороший источник организационных решений как библиотеки паттернов и хороший источник решений для дизайна. Используйте! Основная книга — это гайд по Социократии. Можно изучать в двух версиях — на английском и русском языках. Гайды открыты, информация в документах регулярно обновляется авторами: Гайд по Социократии на английском sociocracy.org  Гайд по Социократии на русском sociocracy30.ru  Telegram-чат русскоязычного сообщества для тех, кто осваивает Социократию  t.me/sociocracy30 Приглашаем на Saint TeamLead Conf - конференцию для тимлидов и руководителей, 26 и 27 сентября 2022 в Санкт-Петербург. Расписание, билеты и подробности на сайте https://clck.ru/sNLxt  Архитектор и бизнес-аналитик