Требования к ИТ-инфраструктуре ПАГИТ

Jun 06, 2012 13:27


Продолжая обсуждение концепции ПАГИТ, хотел бы углубиться в функциональные и архитектурные требования, которые могут быть предьявлены к ИТ- инфраструктуре, для того, чтобы сделать привлекательным и удобным для граждан участие в совместном проектировании и программировании будущего.

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

Базовая гипотеза: гражданское сообщество тогда и только тогда способно к долгосрочным согласованным действиям, когда каждое мероприятие этой программы является частью конкретных личных долосрочных программ значительного количества граждан. 
Разумеется, тут постулируется, что личная долгосрочная программа гражданина нацелена на некоторое конкретное ценное для него благо, потому как составлять такую программу безцельно вряд ли кто будет.
Обосновываем необходимость базовой гипотезы. Как я уже писал, сообщество отличается от толпы тем, что сообщество состоит из граждан, у которых в головах - сложная картинка мира, состоящая из популярных и не очень мемов, некоторые из которых (я называю их тараканами) уникальны. Как следствие, на краткосрочном горизонте, под влиянием одной эмоции (даже возможно сложной структуры), граждане могут объединиться. И тут будут работать общие мемы.

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

Тут очевидно, если подливать масла в огонь, как, например, делает сегодня власть на выступления оппозиции своими криворукими решениями, то эмоция может долго тлеть и подогревать котел протестов. Но даже в таком случае усталость накопится, и протесты выродятся в что-то довольно маргинальное скорее всего с низкой численностью и противоправными действиями, за которые можно сажать.

Почему? Потому что критерий устойчивости участия в общественных процессах - соотношение между общими мемами и собственными тараканами, мало своего и хорошая пропаганда дают длительное участие, но риторический вопрос - а у кого такое соотношение наблюдается?

Обосновываем достаточность базовой гипотезы. Допустим, такая программа сформирована. Тогда возможность сообщества к долгосрочным действиям может быть реализована путем объединения усилий заинтересованных граждан по реализации мероприятий собственных программ. Вопрос лишь в том, как им друг друга найти, и как объединить усилия и ресурсы.

Пока оставляем за скобками вопросы достаточности ресурсного обеспечения каждого мероприятия - тут, очевидно, есть некоторый баланс между количеством граждан и инструментальными способностями объединяться с одной стороны, и требующимися для выполнения поставленной задачи ресурсами с другой стороны.

Сосредоточимся на возможности формирования собственных программ, а также поиска и поддержки переговорного процесса между их авторами. Как это можно сделать технически?
Скорее всего, это сеть порталов на общей шине, с зеркалами и обменом данными по запросам, каждый из которых предоставляет данные сервисы определенным группам пользователей. Ключевое различие - в квалификации тех, кто планирует собственные программы.
Большинству, чтобы что-то долгосрочное (хотя бы лет на десять) спланировать, никакой квалификации не хватит. Но таковых можно научить формулировать свои личные цели (конкретные и ценные лично для себя), которые уже могут служить ориентирами для программаторов. Понимание ценностного ландшафта общества - в действительности имеет самостоятельное политическое значения. Чего хочет конкретно активная часть населения - важнейший и для власти, и для опрозиции вопрос. Эту задачу должна решать первая, самая раскрученная часть ПАГИТ.

Вторая группа порталов, которую и делать и наполнять сложнее, должна давать возможность импортировать из первой группы целевые множества, и покрывать их концепциями устройства общества. Основная задача таких порталов - проверка концепций на противоречия. Значит, этот функионал должен быть реализован, вполне возможно, с помощью деревьев дискуссии с примением формальных правил, с репутацией рецензентов (которая формируется путем оценки действий в системе самими участниками), и правом закрыть ветку дискуссии в том случае, если вариант противоречия будет доведен до логического положительного или отрицательного вывода.

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

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

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

Первые две группы порталов выполняют относительно стандартные операции и потому могут быть разобщены. Желательно соединение мостами, чтобы не терять время на вытаптывание дорожек, когда они уже проложены до тебя. Т.е. вопрос решается шиной - в самом простом варианте - протоколом взаимодействия, например, на основе rdf.

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

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

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

Это сделать намного сложнее, чем предыдущие системы-порталы. Слишком высок уровень абстракции, на котором надо писать софт, при этом слишком конкретны должны быть действия пользователя, чтобы он мог совершать осознанные ходы, не обладая особенной компетенцией. Тут думаю, требуются iRing-подобные системы, смотрим опыт Avalon\Camelot. Зато возможен краудсорсинг решения, и придумать стратегию прохождения какого-либо уровня может подросток, который гамал после школы.

Можно пожертвовать общностью и интерфейсом, можно даже отказаться от модели-проверки качества стратегии. На начальном этапе может быть затычка в виде конструктора иерархических структур работ (WBS) - стандартной софтины по управлению проектами. Тогда и программу делать сложнее, и проверять ее сложнее. Тут уже верю \ не верю.

Но! WBS легко пересекаются друг с другом для определения сходства. Т.е. если наследовать каждую работу от прародителя, специфицируя ее ограниченным набором приемов и устанавливая связи, то при достаточно массовом использовании системы - тысячи пользователей - будет сравнительно легко найти тех, у кого есть такие же куски. Значит, если поддержать такой поиск сходства, то сравнительно легко будет найти тех, кто собирается делать такой же блок, как и ты.

Теперь поддерживаем функционал поиска модели совместной работы, включая упрощенные схемы подтверждения согласия на ее использование (с репутационным штрафом в случае последующего отказа) с выделением и администрированием ресурсов - временных или финансовых - и тебе adaptive case management, со всеми его прелестями, вроде контекстно-ориентированного банка лучших практик, использования лучшей компетенции, совместный поиск ресурсов, открытая верификация целей \ результатов исполнения каждого блока мероприятий и прочие фичи.

И самое главное. WBS удобна для администрирования исполнения проекта \ куска проекта. Останется добавить вероятностную модель реализации (значима тут схема управления возможностями и рисками) - и мы имеем продвинутую систему управления глобальными проектами, позволяющими тем успешнее продвигаться, чем у большего количества граждан более совпадают промежуточные цели.

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

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

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

Для качественного планирования описанной системы необходимо еще будет определиться с системой ключевых показателей эффективности, под которую необходимо оптимизировать архитектуру. В моем представлении, это проект на 2-3 года и стоимостью 30-50 млн рублей (разумеется, при разумном использовании условно бесплатных компетенций активистов, в т.ч. моей).

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

Для целей создания рапределенной системы лучше открыть протоколы и модельную архитектуру каждого вида портала (возможно даже сделать модельные тз и выложить открытый код некоторых модулей), безопасность и проверку передаваемого контента, а также кого включать в оборот, а кого - нет, пусть выбирают сами интересанты. Тогда мы полностью освобождаем систему от вводной догматики власти и оппозиции - и пусть мастерство разработчиков и реальные потребности граждан дальше определяют, к какому будущему нам идти.

P.S. Как обычно, желающим точнее и глубже в теорию, читать Левенчука, ближе всего к теме - http://ailev.livejournal.com/1001918.html, http://ailev.livejournal.com/994835.html, http://praxos.livejournal.com/14905.html.

опытным путем, Политика

Previous post Next post
Up