Обсуждение

Почитай, плз, сюда http://meatreach.livejournal.com/132010.html и сюда http://meatreach.livejournal.com/132238.html. Там нужно читать и сами посты, и комменты. Issue tracking'а, эккаунтинга и блогов недостаточно. Нужно поддержать сам процесс организации.

А сам процесс построения оргонтологии (оргметаонтология -- это ведь "пустая программа", ненастроенная, несконфигурированная, неуточненная, просто "референсная модель" верхнего уровня. Ее нужно постепенно настроить на конкретную организацию, т.е. создать оргонтологию конкретной организации)? Это же и есть поддержка процесса организации! Это я еще про "архитектуру предприятия" и захмановские модели не заговорил :) Твои посты вполне соответствуют моим. Обрати внимание, я как раз писал про conceptual modelling (conceptual maps) -- и тебе в комментах именно про них упомянули. Я просто предложил использовать как средство построения концептуальных карт смоллток с соответствующим "браузером", построенным на базе интерфейса tweak. Поддержка НЖЯ, ограничения и т.д. -- это будет только в будущих версиях системы. Там еще много чего будет. Пока нужно разобраться с собственно описанием процессов, проектов, программ, операций, процедур, поручений в едином языке. Это пока главное. А там поглядим.

Ага. Просто я иду чуть с другой стороны - от первоочередных земных потребностей, от реального организационного процесса. Нужно куда-то класть возникающие процедуры и должностные инструкции, нужно как-то управлять процессом их появления и разработки. Без этого - ну никак! Беспредел и бардак получается. Поэтому я ввожу не те сущности, которые у тебя появляются - хотя они и совершенно правильные, конечно же - а всего лишь две основных: указивка (вместе с ее жизненным циклом) и зачем она нужна, эта указивка (т.е. НЖЯ или возможность). А все остальное считаю пока вторичным. Хотя, разумеется, понимаю, что думаю в ту же сторону, что и ты (и заимствую очень и очень многое).

Еще раз: 1. Для регуляризации менеджмента необходимо построение организационной модели предприятия. Для этой цели используются специальные программные средства (например, ГосМастер). Для работы с организационным моделлером необходимо в его метаметаонтологии описать организационную метаонтологию (т.е. ты эту онтологию и пытаешься написать). 2. Я как раз и пишу, что может быть таким организационным моделлером. И как бы я заходил на создание организационной метаонтологии. Ибо для тебя слово "процедура" вполне определенное, а для меня оно -- полный туман и непонятки. 3. В классической IDEF0-модели указивка входит в атрибуты операции ("управление", т.е. откуда берется информация о том, как и когда эта операция исполняется). Так что указивки у меня учитываются. А вот "зачем она нужна" -- в следующую версию, когда будет достаточно операций, у них указивок, и нужно будет разбираться с ними. Моя версия -- сама программа будет через некоторое время считаться такой указивкой (т.е. не будет текста приказа, а будет конфигурационный файл для того или иного воркфлоу: вот тебе и указивка. Атрибутом "управление" операции при таком подходе является ее контекст (это соответствует ситуации, когда приказом бы утверждалась IDEF0 схема, и в атрибуте "управление" приводился бы номер как раз того листа этой схемы, на котором изображена соответствующая операция). 4. Кстати, у меня в личном GTD уже некоторое время лежит запись "добавить поля "результат" и "зачем"" :) И никак не соберусь, хотя понимаю, что нужно :)

4. Именно. Основной смысл моего поста - фильтрация указивок. У меня ограниченный организационный ресурс, и мне нужно направить его на те активности, где я получу максимальный эффект. При этом я не заморачиваюсь твоим п.2 - что такое "процедура" - потому что считаю, что это можно вытягивать за счет блогов и вики, комментов и обсуждений, за счет социальной коммуникации. Софт должен быть социальным ("любой сотрудник организации может зарегистрировать НЖЯ", пишу я - это принципиально важно), а это позволяет отказаться от формализации в некоторых местах. ЗЫ. Smalltalk vs. PHP vs. ASP.NET - это, имхо, не принципиально, пока нет первой прикидки функционала. Заход "сама программа будет указивкой" имеет право на существование, но это не должно быть самоцелью, а значит это решение принимается на более позднем этапе работы над проектом.

Кстати, п.1 не так уж и очевиден. Полную оргмодель, может быть, и не надо строить - достаточно описывать те кусочки слона, которые видны в данный момент (учитывая, что я думаю про организацию, которая только начинает себя формализовывать). Это, по идее, должно быть созвучно твоим текстам про контекстное, аспектное и прочее модное программирование.

Полной оргмодели не бывает! Модель всегда частична. Я как раз и хочу использовать все эти аспектные, контекстные, языковые подходы -- чтобы описывать разные части организации. Но эти описания могут стать живыми, если их делать не в специальном моделлере, а исполнимыми (тоже в разных смыслах, кстати ;)

У тебя социальный софт тогда и есть -- моделлер. Ты пишешь заголовок поста "предложение об НЖЯ", или "Указивка номер один", это и есть твое "моделирование". Я хочу понять, к каким объектам в системе нужно уметь писать комменты. Операции в воркфлоу? Поручения в issue tracking? Тут мы опять упираемся в Gjallar: нужно поглядеть, как там это все называется.

That's it, babe!!! Указивка (процедура) в моем тексте - это текст плюс комменты плюс воркфлоу граф, который идет прямиком в issue tracking.

Комменты нужно уметь писать ко всему - просто по определению. При этом, их можно привязывать к объекту, частью которого является комментируемая сущность, а детализацию указывать в тексте коммента - в этом прелесть всей этой системы комментирования. Gjallar не запускается, сцуко. Не могу с ним разобраться. У них 0.4 на подходе (билд для Линуха выложен, но не объявлен на сайте), я жду нормального виндового билда, может с ним справлюсь.

Я придумал название для всего этого безобразия. http://meatreach.livejournal.com/133401.html

О! Давай вот как сформулирую. В твоих текстах я вижу следующую мысль: вот я сейчас напишу issue tracker, и в этом трекере работы будут бегать по workflow графам, которые суть модель организации. Я с этой мыслью, безусловно, согласен. Но. Модель всегда частична, говоришь ты. Она состоит из множества маленьких моделек = процедур = указивок. И узкое место (по Голдратту, в потоке оргработ) для типичной быстроразвивающейся компании - не в том, как строить модель, а в том, какие модели строить, а какие нет. Не в том, как наиболее эффективно и качественно разработать указивку, а в том, какую указивку разрабатывать, а на какую забить. После этого мне наплевать, какие именно бывают указивки, как они устроены и что именно нужно в них комментировать. Мне достаточно RSSа и комментов, или чего угодно еще - главное, чтобы был хоть как-то поддержан жизненный цикл указивки. Но мне важно понимать, какие указивки делать, а какие нет, какая указивка в каком состоянии находится, кто за нее отвечает - создание указивок становится таким же процессом с таким же workflow. И уже тут, конечно, программа начинает сама себя читать. ;)

>абстрактный синтаксис и domain specific languages Вам наверное будет небезыинтересно посмотреть мой постер, где показывается, как "абстрактный синтаксис" воплощен в практическом приложении: http://eclipsezilla.eclipsecon.org/php/attachment.php?bugid=509 недавно я дописал к этой системе и свой предметный язык.

Нет, ты неправильно видишь мою мысль. У меня не классический "процессный подход", это ты мне разные учебники по BPM приписываешь. Воркфлоу-графа может и не быть: выполнение работ может осуществляться путем непосредственного их выполнения (т.е. могут быть либо отдельные поручения на работы, которые складываются в граф по мере выполнения работ -- "программирование по образцу", либо просто будут передаваться сообщения от одного исполнителя другому об окончании этапа работы вплоть до передачи такого сообщения по факту передачи результатов в виде измененний файла/текста/поля в учетной системе). У меня довольно много было ссылок на разные маргинальные примеры программирования в тех условиях, когда программист не пишет классические скрипты (непосредственное манипулирование, а также собственно программирование в отличие от скриптинга. Программирование по образцу. Программирование интерфейсов, кстати, все именно об этом). Жизненный цикл указивки вполне может быть поддержан, для этого нужно понять, что это такое (например, чем указивка-регламент отличается от указивки-поручения). Чем и занимаемся.

Да, я в том числе -- о таком.

Совершенно неважно, чем регламент отличается от поручения! Ты не знаешь, нужен ли этот регламент или поручение, а начинаешь разбираться, что у него внутри, до того, как поймешь, нужно ли вообще его выпускать.

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

Наверное, в последовательности ваших рассуждений где-нибудь через 2-3 поста появиться XML. Или я уже пропустил?

Не появится. XML -- это конкретный синтаксис, не более того. Я же пока предлагаю совсем другое: смоллток вместо XML. Пока меня никто не отговорил от того, что смоллток менее выразителен, чем OWL. Я ведь не semantic web делаю по классическим стандартам W3C. Я хочу использовать протоколы Крокета -- и если там где-то есть XML, то и ладненько, мало ли что там на нижнем уровне есть. А на верхнем уровне я буду описывать мир в объектах и сообщениях, антропоморфно. Это точно не про XML (меня ведь не интересует синтаксис подобного представления, да оно и не слишком деревянное может получиться).