Anatoly Levenchuk (ailev) wrote in aeg_dev,
Anatoly Levenchuk
ailev
aeg_dev

Административные аналитики

Административный аналитик в госсекторе -- это то же самое, что бизнес-аналитик в частном секторе. Административный аналитик дизайнит государство, бизнес-аналитик дизайнит бизнес. Один проектирует административные структуры и процессы, другой -- бизнес-структуры и бизнес-процессы.

Люди, которые имеют склонность к подобной работе, приходят из программистов, физиков, юристов -- это совершенно неважно. Обычно такие люди появляются там и тогда, когда образуется какая-то новая инфраструктура. Они часто называют себя "инфраструктурщиками". Так, в 1990 году не было никаких административных аналитиков на рынке ценных бумаг. А к 1997 году их был даже избыток (я по 120 человек в зале собирал, которые активно творили в этой области, правда, в разных масштабах). Там было две "главных партии": сторонники регистраторов и сторонники депозитариев. Чисто по юридической конструкции регистраторы оказались коррупционными, а депозитарии -- нет. И было несколько поколений нормативных актов, регулирующих эту деятельность. И десяток инфраструктурщиков, которые всю эту нормотворческую активность развивали, и развивали инфраструктурные институты на рынке ценных бумаг. А потом (еще в 1997 году, за год до кризиса) наступила стагнация на рынке ценных бумаг, и инфраструктурщики потянулись в разные другие отрасли.

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

Можно спорить, нужно ли было создавать регулирование на рынках ценных бумаг и электроэнергии, а также сложнейшие системы юридической обвязки тамошних программных систем учета и торговли, но таких споров не может быть по поводу электронного государства: регулирование государственного учета и обеспечиваемых государством транзакций необходимо. Фактическое появление электронного государства требует быстрого апдейта этого регулирования -- сами ИКТ-технологии нейтральны по отношению к государственному управлению, но потенциально их можно использовать и во вред, и во благо (http://v-novikov.livejournal.com/241835.html). Поэтому кто-то (я считаю -- административные аналитики) должны создать такое регулирование и такие информационно-коммуникационные системы, которые улучшат государственное управление.

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

Административный аналитик должен иметь несколько свойств, отличающих его от "обычных людей":
1. Владеть юридическим мышлением, чтобы беседовать с юристами (самому ему быть юристом необязательно).
2. Владеть алгоритмическим мышлением, чтобы беседовать с программистами (самому быть программистом необязательно).
3. Обладать развитой рефлексией, чтобы не путать юридическую и программистскую действительности (то есть быть умным и немножко подкованным философски/методологически).
4. Понимать в устройстве государственного управления, в том числе понимать критерии его качества (причем понимать не только "из опыта", но и "из принципов", ибо тут замешано много этики, типа "будем ли улучшать госуправление и ставить компьютеры в целях удобства нашего дорогого Дракона". Для этого неплохо бы разбираться в азах политэкономии, правовой философии, политологии).
5. Понимать в современных технологиях организации (оргдизайне), ибо в конечном итоге его работа -- организовывать целенаправленную коллективную деятельность людей. Желательно при этом разбираться не только в management sciences, но и в operation research.

Административную реформу-3 должны делать административные аналитики. Они должны быть независимы от ведомств, организационную начинку которых они дизайнят, и ИКТ-системы которых они проектируют. Они должны быть умны и честны, но прежде всего -- они должны быть. Взять сейчас их неоткуда, поэтому их нужно выращивать. Выращиваться они будут в пилотных проектах (мини-реформах: небольших проектах, в которых создание нормативных актов и информационных систем слиты в единое целое -- чтобы юристы не игнорировали использование компьютеров, а программисты не продолжали автоматизировать хаос).
* * *
Спасибо mp_1812, который обратил мое внимание на существенность явного описания различия между юридическим и программистским (алгоритмическим) мышлением в случае переходного периода от полного отсутствия административных аналитиков к периоду, когда их некоторое количество уже появится, и они договорятся о том, как строить и оформлять свою работу. Я дальше буду писать не столько точные формулировки (не цепляйтесь за слова), сколько общие смыслы.

1. Юристы мыслят декларативно, а не процедурно. ЕСЛИ ... ТО ... ИНАЧЕ ... (гипотеза-диспозиция-санкция) у юристов -- это вовсе не ЕСЛИ ... ТО ... ИНАЧЕ ... (условный оператор) у программистов. Скорее, это предикат из декларативного программирования -- но кто из программистов долго и много занимался декларативным программированием?! Все клаузы закона (более того -- все клаузы всех законов!) действуют одновременно, законы не начинают выполняться с первой статьи и продолжают статья за статьей, пока закон не закончится. Любой хороший программист мечтает писать на декларативных языках, но любой средний программист обычно с трудом поворачивает мозги в этом направлении -- ибо не нужно писать, что делать, нужно просто описывать мир одновременно верными утверждениями (а в системах представления знаний эти утверждения еще и могут быть противоречивыми!).

2. Юристам проще: при наличии коллизии они всегда подразумевают выход в реальный мир (обычно это обращение в суд). Поэтому они не слишком заморачиваются над непротиворечивостью огромных массивов своих требований, а главное -- не слишком заморачиваются их детальностью. Программист приучен, что любые требования должны быть максимально детальными. Более того, юристов приучают в законы писать минимум, чтобы не смущать буйство жизни излишними формализмами (приучают, но не слишком успешно, как каждый из нас чувствует на своей шкуре). Законы должны быть прямого действия, безо всяких там "уточнений подзаконными актами" -- это для юристов ценность. Программист понимает, что никакая спецификация не будет работать без ее уточнения до уровня кода. У юриста нет понятия "уровня кода". То есть юрист стремится (так его учили) к минимальной регламентации, программист -- к максимальной. Между этими двумя стремлениями существует огромный ценностный разрыв, приводящий к постоянным спорам и конфликтам при встречах. Программист говорит: "а что я должен делать в таких-то и таких-то случаях?". Юрист ему отвечает: "все равно, пока вы остаетесь в рамках исходных требований", что либо приводит программиста в бешенство, либо позволяет ему удивлять юриста реализацией, направленной именно на обход духа исходных требований тщательным использованием неконкретности буквы.

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

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

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 40 comments