Руководство по проектированию системы управления онлайн-сообществом (Community Governance System далее CGS).
Данный материал является выжимкой одноимённой статьи Austin Robey. На данный момент мы находимся на стадии активного экспериментирования с Web 3.0 организациями, по этой причине в индустрии пока не был найден «безусловный стандарт» системы управления. Как правило, большинство из них используют для принятия решений систему «один токен=один голос» (что похоже на традиционное корпоративное управление), либо «один участник=один голос». В данной статье мы рассмотрим «матрицу принятия решений» как первичный элемент разработки CGS.
Матрица решений.Первое что нужно сделать, приступая к проектированию CGS – это создание матрицы принятия решений. Основная её задача – обеспечение ясности и прозрачности процесса принятия решений.
В свою очередь, создание матрицы принятие решений состоит из следующих шагов:
-Каталогизация всех решений, которые уже принимаются.-Идентификация стейкхолдеров. Определение групп стейкхолдеров которые потенциально могут участвовать в процессе принятия решений и которых затрагивают эти решения.
-Квалификация стейкхолдеров. Определение групп стейкхолдеров которые непосредственно будут участвовать в принятии решений и их градация.
Пример: Что бы стать членом сообщества человек должен иметь активную учётную запись в течение 6-ти месяцев. Что бы стать активным контрибьютором, человек должен посвятить работе в проекте не менее 40 часов за предыдущие 6 месяцев. Что бы войти в core team человек должен работать над проектом в режиме фуллтфйм.
-Эмпатия и ответственность по отношению к стейкхолдерам. Некоторые решения влияют на определенные группы стейкхолдеров больше, чем на другие. Некоторые группы стейкходлеров могут не хотеть нести ответственность за определенные решения. При разработке элегантных структур принятия решений важно с помощью координирования определить, в принятии каких решений должны участвовать те или иные группы стейкхолдеров.
Пример: Музыкантам в ДАО посвящённом стримингу музыки, возможно, не нужно отвечать за принятие ежедневных операционных решений, но им однозначно стоит участвовать в принятии стратегических решений таких как фандрайзинг, распределение прибыли и проч.
Как принимаются решения.Далее нужно определить способ которым будут приниматься решения.
К примеру, это может быть:
Консенсус: Все согласны.
Демократия: Голосование с определённым порогом участников для легитимности.
Большинство: Простое большинство голосов.
Супербольшинство: Предложение не принимается, если одна из групп стейкхолдеров накладывает вето простым большинством голосов.
Квадратичное голосование: Х количество токенов даёт квадратный корень из Х количества голосов».
Согласие: Предложение принято если отсутствуют серьёзные возражения.
Совещание: Решение принято с учётом поправок на мнение других участников.
Делегация: Один человек уполномочен принимать решения в конкретной области.
Финальные штрихи.Далее все вышеперечисленные элементы объединяются для создания документа, который представляет собой полную картину того, как принимаются решения. Этот документ должен быть составлен совместно и рассматриваться как живой документ, реагирующий на меняющиеся потребности организации. Затем документ публично обнародуется, чтобы все заинтересованные стороны знали, как принимаются решения.
Пример матрицы принятия решений вы найдете, а оригинальной статье.Кроме того, сообщество или DAO может разработать и принять иные документ, такие как:
- Манифест.
- Чёткие руководящие принципы.
- Политику разрешения конфликтов и спорных ситуаций.
- Любые другие документы, способствующие организации и координации сообщества.
На практике, многие DAO имеют целый перечень «руководящих документов», в которых описаны как концептуальные вещи (цели, задачи, основные принципы), так и более прикладные, «операционные» процессы (организация работы конкретных «отделов»).
Стройте сообщества, развивайте Web 3.0 и помните что любые правила игры, лучше чем полное их отсутствие😉
Оригинал
