Сообщество как ячейка

Между человеком и государством — несколько уровней устройства. Семья. Дом. Двор. Кооператив. Школа. Клуб. Объединение по интересам. Профессиональный цех. У каждого уровня свой масштаб, свои правила, свой способ принимать решения. Корпорация и государство — две крайние точки на этой шкале, и оба формата хорошо описаны. Между ними — всё остальное. И именно остальное хуже всего обеспечено инструментами.

Назовём эту срединную форму сообществом. Сообщество — это группа людей, у которой есть три обязательных свойства: ясные границы (известно, кто внутри и кто снаружи), собственные правила (известно, как принимаются решения), и история (известно, что было раньше). Без любого из трёх группа перестаёт быть сообществом и становится либо толпой, либо аудиторией, либо филиалом чего-то большего.

Почему корпоративные инструменты не подходят

Корпоративные продукты — CRM, BPM, taskboard, ERP — построены вокруг одного допущения: есть иерархия и есть подчинение. Менеджер ставит задачу, исполнитель её выполняет, система фиксирует. Эта модель прекрасно работает в компании, где иерархия и есть основной способ координации. В сообществе иерархии либо нет, либо она частичная и не позволяет навязывать решения принудительно. Председатель кооператива не приказывает членам — он созывает собрание.

Поэтому корпоративные системы в сообществе работают плохо. Не потому, что они «плохо сделаны», а потому, что они отвечают на другие вопросы. На вопрос «кто кому подчиняется» в кооперативе нет ответа — его и не должно быть. Зато есть вопросы, на которые корпоративные системы не отвечают: как организовать голосование, в котором вес голоса определяется долей в общем имуществе, как пересчитать паевой вклад при выходе участника, как сохранить репутацию ученика, который через три года становится преподавателем.

Почему государственные инструменты тем более не подходят

Государственные системы устроены ещё специфичнее. Они обслуживают отчётность перед регулятором, а не управление внутри группы. ГИС ЖКХ и установленные законом процедуры нужны для юридически значимой фиксации и проведения общего собрания собственников в случаях, когда это требуется. Но саму подготовку собрания — переговоры, голосование за повестку, обсуждение бюджета, выбор подрядчика — они не покрывают и не должны.

То же относится к налоговой отчётности, регистрации некоммерческих организаций, формам обязательного учёта. Это интерфейс к государству, не интерфейс к участникам. Сообщество, которое полагается только на госсистемы, оказывается без собственного управления: оно регистрирует факт, но не управляет процессом, который к нему привёл.

Почему чаты и таблицы не масштабируются

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

Дальше начинаются проблемы, и они одинаковые везде. Решение, принятое в чате, теряется через месяц — никто не помнит, кто за что голосовал. Таблица с задачами расходится с реальностью, потому что некому её обновлять. Бюджет известен только казначею, остальные доверяют ему на слово, а когда вопросы возникают, доказательств нет. Новый участник, пришедший через год, не понимает контекста — некому его ввести, потому что история разбросана по нескольким чатам и потеряна.

Это не недостаток инструментов. Это родовая особенность чатов и таблиц: они оптимизированы под текущий обмен, а не под длинную историю. Архитектурно для сообщества нужна другая форма — где история накапливается естественно, не требуя отдельного усилия её сохранения.

Чего не хватает

Существующий ландшафт инструментов оставляет дыру: между «всё в чате» и «корпоративная ERP за миллион» — почти нет ничего, что отвечает на специфические запросы сообществ. Те решения, которые есть, — либо дорогие коммерческие продукты для конкретной ниши (управление многоквартирным домом, образовательная платформа, продажа курсов), либо самописные системы единичных кооперативов, не масштабируемые на другие.

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

Что должна уметь платформа сообщества

Из обсуждения выше следуют требования. Платформа сообщества должна:

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

Все остальные функции — выводимы из этих пяти. Голосование — это способ принять решение в соответствии с правилами. Репутация — это срез истории. Делегирование — это перенос границ. Документ — это закреплённое решение с подписями.

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