Три занятия консультанта и план релиза PraxOS 2.3
1. Три занятия консультанта
Когда-то давным-давно (последний раз я писал об этом в 2005г. -- http://ailev.livejournal.com/366097.html) я вывел правило успешной работы:
а) треть времени заниматься чем-то полезным другим людям -- перформанс, приложение сил, демонстрация мастерства. Это и есть видимая часть айсберга консультационной работы. Не это является делом консультанта, это приложение дела.
б) треть времени заниматься своим инструментарием той области, в которой приносишь пользу. Это и есть основное дело. Музыкант всю жизнь репетирует, спортсмен всю жизнь тренируется, консультант всю жизнь учится методам -- это и есть их работа.
в) треть времени заниматься инструментарием того, чем делаешь приносящие пользу инструменты. Музыканту нужно разобраться с его музыкой, спортсмену с физикой движений и психологией, консультанту нужно разобраться в методах. Или тебе свезло, и у тебя есть Великий Гуру, который обеспечивает тебя надлежащим инструментарием для твоего основного дела -- продюсер у музыканта, тренер у спортсмена, и методолог у консультанта, или не свезло -- и тогда нужно заниматься этим делом самостоятельно.
Дисбаланс работы на этих трех уровнях приводит либо к ползанию в какой-то унылой и неразгребаемой непродуктивной текучке с итоговым падением квалификации, либо к полному отрыву от почвы и с ростом как самооценки, так и фактической бесполезности.
А) приложение дела
Я занимаюсь нанесением непоправимой пользы в ходе консультирования -- работы с ситуациями моих клиентов (http://ailev.livejournal.com/759616.html). "Ситуация" -- это когда непонятно, что делать. "Ситуация" -- это когда неизвестен метод. Передавать людям нужный метод -- это вытаскивать их из ситуации. Это и есть та работа, видная публично и оправдывающая то основное дело, которым я занимаюсь. Основные разговоры проходят наполовину в языке клиента, наполовину в перетолковывании этих же высказываний в языке предлагаемого метода, а затем нахождение решения уже во вновь появившемся языке. Как только ты начинаешь говорить "инженерия требований", то при этом подтаскивает тащится довольно большой кусок новой онтологии, в терминах которой можно описать довольно много новых практик, и клиент, работавший раньше в терминах "технических заданий" вдруг осознает, как ему улучшить свою ситуацию, казавшуюся при работе в терминах "технических заданий" неразрешимой. Из практик конструируется новый процесс, жизнь налаживается и можно переходить к освоению следующего метода (рассмотрев точку приложения сил своих и клиента при помощи методов теории ограничений).
Б) основное дело -- работа с лучшими методами
Но для создания подходящего к ситуации метода нужно уже иметь метаметод -- либо "библиотечный" ("из интернета"), либо честно разработанный самостоятельно.
Ситуационная инженерия методов говорит, что иметь готовый метод для конкретной ситуации нельзя. Но его можно "собрать", если у вас для этого есть конструктор методов, методическое Лего с подходящей формы фрагментами, из которого для клиента получается именно то, что ему нужно. Нужны метаметоды, "конструкторы для взрослых", из которых вы должны породить подходящие для ситуации конкретные методы.
Основное дело консультанта -- это как раз напитываться метаметодами, делать свое собственное консалтерское Lego, или Magnastix, или Geomag, или Smogi или Mega Blocks или Механический конструктор №1. Важно, чтобы в твоих метаметодах, как в конструкторе нашлись все нужные детальки-фрагменты методов, из которых ты быстро соберешь подходящий для ситуации клиента метод решения его проблем. В крайнем случае ты должен быть хотя бы "стихийным методологом", чтобы этот новый метаметод создать по потребности, но лучше бы этого не делать -- лучше не изобретать собственный велосипед, а учиться на чужих ошибках.
Плюс у консультанта должен быть набор специфические для его собственной работы метаметодов: для конструирования соответствующего каждой конкретной консультационной ситуации метода помощи клиенту в освоении им передаваемого целевого содержательного метода.
Основное дело -- это "репетиции", "тренировки", "самообразование", то есть а) накачка себя наиболее употребительным набором "содержательных" метаметодов (ISO 15926, MFESA, TOC и т.д.) и "процессных" метаметодов (с какой стороны подойти с содержательным методом к сотрудника клиента, чтобы они этот метод начали осваивать -- change management, НЛП и много чего другого).
Набор этих лучших и самых общих метаметодов мы и назвали PraxOS. Как это работает? Мы выбрали системный подход как онтологию и системную инженерию как использующий ее метаметод самого высокого уровня, далее разбираемся с основными дисциплинами/метаметодами системной инженерии (инженерия требований, инженерия системной архитектуры, управление проектами и т.д.), конкретизируя их до инженерии системной архитектуры по MFESA, управления проектами по Теории ограничений и т.д. -- поддерживая при этом общность онтологии и максимальный уровень обобщений.
Главное в PraxOS -- это разбирательство с предметным и процессным содержанием работы. Так, "метод персонажа", примененный к ситуации "идеального акционера" (подробнее -- http://ailev.livejournal.com/511947.html) может быть еще более обобщен, если понимаешь, что речь идет о метаметоде инженерии требований -- а инженерия требований в общем случае это работа с ролями. "Персонаж" -- это про метод перевода роли заинтересованной стороны в позицию (http://ailev.livejournal.com/760041.html). Как только вы поняли, что речь идет о какой-то заинтересованной стороне и ее требованиях, которая вам непосредственно недоступна -- вы смело можете применять этот метод, даже если речь не идет о разработке коробочного софта или юзабилити.
Как только вы сообразили, что организация -- это система, а акционер -- это заинтересованная сторона, у которой всегда есть требования, то далее не нужно быть восьми пядей во лбу, чтобы на этом уровне общности вспомнить про метод персонажа. Случайные "озарения" становятся рутиной. Главное в методах -- это их масштабируемость, применение одних и тех же мыслительных паттернов на самых разных уровнях детализации в самых разных делах.
Создатели ISO 15288 (как рассказывал нам его архитектор Гарольд Лоусон) чрезвычайно были озабочены именно этой стороной вопроса: масштабируемостью и универсальностью описываемого в нем метаметода системной инженерии. Сохранение этой масштабируемости и есть главная фишка.
Близкий родственник PraxOS в этом плане opfro.org (http://ailev.livejournal.com/674073.html -- где я делаю возмутительную ошибку, спутав ISO 24744 и ISO 24774, что месяцев на пять задержало неминуемую разборку с ситуационной инженерией методов). В OPFRO.org cобрано порядка 1100 фрагментов методов в единой онтологии (и там тоже отражен метаметод инженерии системной архитектуры MFESA). Отличается PraxOS двумя вещами:
а) другим набором "избранных методов" (так, у нас есть Голдратт, а в opfro.org его нет. У нас есть ICM, а в opfro.org его нет. У нас сделан вывод о минимальных четырех описаниях жизненного цикла, а в opfro не сделан. У нас есть методы онтологической интеграции данных, а в opfro.org их нет).
б) использованием немного другого инструментария работы с методами. С одной стороны, oprfo.org тоже движется в русле системной инженерии методов, и даже имеет собственную метамодель. Но наш PraxOS уже сейчас ориентируется на:
-- поддержку полной онтологии ISO 15926 и честную работу с моделью продукта (поддержка продуктной, ценностной группы описаний -- http://ailev.livejournal.com/764492.html).
-- на сегодняшний день работу не в "ручном" режиме, а сразу в SPEM 2.0 (и использование EPFC для этой работы). А в будущем -- выход на собственную метамодель и регистрацию этого стандарта в RDL ISO 15926 (да, я знаю, что там сначала фиксируются определения из оксфордского словаря, затем определения из стандартов ISO, затем только определения из стандартов промышленных ассоциаций, и только в последнюю очередь ориссы. Википедия, она и есть википедия, даже если ее обозвать RDL и дать статус международного стандарта).
Но мало создать такую библиотечку. Нужно еще и уметь применять в ней написанное -- это означает, что мало найти опубликовать в RDL онтологию рабочих продуктов онтологию рабочих продуктов инженерии системной архитектуры (http://ailev.livejournal.com/766364.html). Нужно еще опубликовать эту онтологию у себя в мозгу так, чтобы мозг сумел ей воспользоваться (а потом еще и помог освоить эту онтологию сотрудникам клиента).
Создание этой библиотеки методов и погружение ее в себя любимого затратно. Музыканту платят за выступления, спортсмен получает деньги за соревнования, консультант -- за решения задач клиентов. За репетиции, тренировки, самообразование и прочую подготовительную работу не платят. Но это основное, на что уходит время.
В) инструментарий для дела -- методология
Для основной деятельности консультанта (разбирательства с лучшими практиками работы) требуется хорошо освоить инструментарий работы с методами, как объектами. Ибо метод представляет из себя довольно сложный объект -- метод состоит из его предмета (онтологии, лексики, нотаций -- http://ailev.livejournal.com/761744.html), плюс практик/содержания методов, плюс процессов/жизненных циклов. Метод сам выражается при помощи метамодели, онтологии, лексики, нотаций выбранной версии метаметода системной инженерии методов. Границы метода как системы чрезвычайно расплывчаты. Заинтересованных в методе сторон довольно много (разработчик метода, применяющий метод, кодировщик описания метода, проверяющий выполнение метода, учитель метода и т.д.), все они предъявляют разные требования и к методу, и к инструментарию с ним работы.
Основным методом системной инженерии является построение моделей методов. То есть нашим инструментом в работе с методами является моделирование методов, их анализ и синтез, препарирование и оживление. Для этих целей нужно иметь набор правильных описаний методов, "вынуть методы из головы" и положить их в компьютер -- даже не для того, чтобы эти методы компьютер мог исполнить сам (хотя сингулярность уже близка, и кто знает, что будет через полтора десятка лет?). Это нужно просто для того, чтобы как самому иметь возможность размышлять о метаметодах, методах и т.д. ("внутри головы думать нельзя" -- http://community.livejournal.com/openmeta/190239.html). Но в неменьшей степени это нужно для того, чтобы обеспечивать совместную работу над этими метаметодами, повышать их качество.
Вся эта возня с инструментарием выражения онтологий, лексик, нотаций ситуативной инженерии методов для меня тут инструмент для инструмента -- инструмент методологического размышления над метаметодами, методами, процессами, жизненными циклами, группами описаний и т.д. Этот инструментальный уровень уже совсем непродажный, это чистые затраты. Если бы кто-то за меня тут думал и делал, принял бы его работу с благодарностью. Проблема в том, что адекватных инструментов для моей собственной работы никто не делает: если выходишь на уровень мастера в своем деле, то и инструмент из ближайшего ларька тебе не подходит. Приходится делать методологический инструментарий самостоятельно.
Чтобы работать с предметными методами, нужно уметь как-то представить онтологию, лексику, нотацию. Нужно выбрать или создать метамодели, лексику и нотации для онтологии, лексики, нотации методов. Нужно создать или выбрать софт, который это все поддерживает.
2. Что делать: план релиза PraxOS 2.3
Нужно выпустить релиз PraxOS 2.3 (предыдущий план релиза 2.1 был в октябре 2008г. -- http://ailev.livejournal.com/627019.html, затем в декабре 2008г. был план исследований релиза 2.2 -- http://ailev.livejournal.com/640851.html). В релизе 2.3 признается, что общая цель версии 2 -- разбирательство с "процессными фреймворками" -- остается (это мы так год назад нащупывали идею ситуативной инженерии методов), но также фиксируется зацикленность предыдущей версии на методологических занятиях -- хотя это принесло плоды, ответы на многие поставленные вопросы получены (хотя реализации пока не было).
В этой версии цели мы распишем на три группы, соответствующие трем занятиям консультанта:
а) приложение методов -- консультирование
-- выполнить ряд задач ситуативной инженерии метода для конкретной ситуации клиента (т.е. его целевой системы и его инструментального окружения), чтобы обкатать прихваченные в последнее время лучшие практики. Работа с клиентом дает опыт, без которого всенепременно будут накапливаться и не исправляться ошибки. По понятным причинам, в ЖЖ я не особо обсуждаю этот вопрос -- работа с клиентами не терпит публичности. Граница тут проходит по конкретной целевой системе и инструментарию клиента: его ситуация не должна выноситься на публику без особой на то просьбы. Поэтому раскрываться может только метаметод (PraxOS), но не метод (уточненый для ситуации клиента экземпляр метода).
б) пополнение библиотечки метаметодов и их освоение -- профессиональный рост.
-- исследования и формулирование метаметода иженерии требований второго поколения, т.е. развитие идей http://ailev.livejournal.com/754369.html
-- разбирательство с инженерией системной архитектуры, http://ailev.livejournal.com/758212.html
-- Суровый (крутой, недетский) рефакторинг текущих знаний -- с учетом общая рамки ситуационной инженерии методов, онтологии системного подхода, в том числе онтологии дисциплин системной инженерии -- минимально в части наиболее общих артефактов и именований ее дисциплин. По-хорошему, нужно было бы переписать все постинги, переделать все презентации, перечитать все видео, и заменить тексты на сайте PraxOS. Рефакторинг, он и есть рефакторинг: остановка сегодня, чтобы не затормозиться навсегда завтра.
-- документирование результатов рефакторинга. Вряд ли в версии 2.3 это будет документировано в "универсальном моделере", но на его роль временно назначается EPFC. Возможно, нужно вебсайт http://PraxOS.ru из вики-сайта переделать в продуцируемый этим моделером сайт. Все равно вики-сайты не взлетают, если их пополняют менее пяти человек, а в PraxOS пятерых разработчиков все нет и нет (хотя наблюдают за работой довольно много народу -- обычный эффект торрентовых сетей: аплоадят не более 3%, а пользуются потом все).
в) методология -- инструментарий
-- доформулировать подход PraxOS как интеграцию методов в промышленных масштабах (http://ailev.livejournal.com/640702.html)
-- продолжение планирования "универсального моделера" (http://ailev.livejournal.com/757999.html, http://ailev.livejournal.com/758941.html).
-- -- выбор онтологии, лексики и нотации для (минимально) четырех групп описаний процесса/жизненного цикла http://ailev.livejournal.com/764492.html и реализация их в "универсальном моделере".
-- Онтологию и лексику activity model из предыдущего пункта погрузить в ISO 15926 RDL (или хотя бы в WIP).
-- сделать для универсального моделера мэппинг (с использованием ISO 15926-фасада) для workflow распространенных САПРов (а также для их модулей генерации ППР -- "планов производства работ", встроенных хелпов, чтобы включать в этих хелпы методы клиента и прочая интеграция в конкретные САПР).
-- присматривание к интерактивному программированию в плане изменения метаметодов (т.е. отладки как цикла исследования-создания взаимоувязанных онтологии, лексики, нотации и содержания метаметода) без потери целостности порожденного прошлой версией и доработанного при этом "напильником" метода.
-- агентские архитектуры как решение проблемы SOA и "программирования в большом"
-- Cola как language workbench следующего поколения. Можно ли сделать моделер?
-- соответствие SOA-инфраструктуры для поддержки методов и самих методов (за это, вроде, взялся foxtreme).
Основной задачей текущего момента считаю балансирование всех трех занятий. Треть времени заниматься приложением дисциплины-метаметода и порождением ситуационно-обусловленного метода, треть времени заниматься созданием метаметодов и методов их приложения-освоения, а треть времени продолжать заниматься методологией и методологическими инструментами.
Когда-то давным-давно (последний раз я писал об этом в 2005г. -- http://ailev.livejournal.com/366097.html) я вывел правило успешной работы:
а) треть времени заниматься чем-то полезным другим людям -- перформанс, приложение сил, демонстрация мастерства. Это и есть видимая часть айсберга консультационной работы. Не это является делом консультанта, это приложение дела.
б) треть времени заниматься своим инструментарием той области, в которой приносишь пользу. Это и есть основное дело. Музыкант всю жизнь репетирует, спортсмен всю жизнь тренируется, консультант всю жизнь учится методам -- это и есть их работа.
в) треть времени заниматься инструментарием того, чем делаешь приносящие пользу инструменты. Музыканту нужно разобраться с его музыкой, спортсмену с физикой движений и психологией, консультанту нужно разобраться в методах. Или тебе свезло, и у тебя есть Великий Гуру, который обеспечивает тебя надлежащим инструментарием для твоего основного дела -- продюсер у музыканта, тренер у спортсмена, и методолог у консультанта, или не свезло -- и тогда нужно заниматься этим делом самостоятельно.
Дисбаланс работы на этих трех уровнях приводит либо к ползанию в какой-то унылой и неразгребаемой непродуктивной текучке с итоговым падением квалификации, либо к полному отрыву от почвы и с ростом как самооценки, так и фактической бесполезности.
А) приложение дела
Я занимаюсь нанесением непоправимой пользы в ходе консультирования -- работы с ситуациями моих клиентов (http://ailev.livejournal.com/759616.html). "Ситуация" -- это когда непонятно, что делать. "Ситуация" -- это когда неизвестен метод. Передавать людям нужный метод -- это вытаскивать их из ситуации. Это и есть та работа, видная публично и оправдывающая то основное дело, которым я занимаюсь. Основные разговоры проходят наполовину в языке клиента, наполовину в перетолковывании этих же высказываний в языке предлагаемого метода, а затем нахождение решения уже во вновь появившемся языке. Как только ты начинаешь говорить "инженерия требований", то при этом подтаскивает тащится довольно большой кусок новой онтологии, в терминах которой можно описать довольно много новых практик, и клиент, работавший раньше в терминах "технических заданий" вдруг осознает, как ему улучшить свою ситуацию, казавшуюся при работе в терминах "технических заданий" неразрешимой. Из практик конструируется новый процесс, жизнь налаживается и можно переходить к освоению следующего метода (рассмотрев точку приложения сил своих и клиента при помощи методов теории ограничений).
Б) основное дело -- работа с лучшими методами
Но для создания подходящего к ситуации метода нужно уже иметь метаметод -- либо "библиотечный" ("из интернета"), либо честно разработанный самостоятельно.
Ситуационная инженерия методов говорит, что иметь готовый метод для конкретной ситуации нельзя. Но его можно "собрать", если у вас для этого есть конструктор методов, методическое Лего с подходящей формы фрагментами, из которого для клиента получается именно то, что ему нужно. Нужны метаметоды, "конструкторы для взрослых", из которых вы должны породить подходящие для ситуации конкретные методы.
Основное дело консультанта -- это как раз напитываться метаметодами, делать свое собственное консалтерское Lego, или Magnastix, или Geomag, или Smogi или Mega Blocks или Механический конструктор №1. Важно, чтобы в твоих метаметодах, как в конструкторе нашлись все нужные детальки-фрагменты методов, из которых ты быстро соберешь подходящий для ситуации клиента метод решения его проблем. В крайнем случае ты должен быть хотя бы "стихийным методологом", чтобы этот новый метаметод создать по потребности, но лучше бы этого не делать -- лучше не изобретать собственный велосипед, а учиться на чужих ошибках.
Плюс у консультанта должен быть набор специфические для его собственной работы метаметодов: для конструирования соответствующего каждой конкретной консультационной ситуации метода помощи клиенту в освоении им передаваемого целевого содержательного метода.
Основное дело -- это "репетиции", "тренировки", "самообразование", то есть а) накачка себя наиболее употребительным набором "содержательных" метаметодов (ISO 15926, MFESA, TOC и т.д.) и "процессных" метаметодов (с какой стороны подойти с содержательным методом к сотрудника клиента, чтобы они этот метод начали осваивать -- change management, НЛП и много чего другого).
Набор этих лучших и самых общих метаметодов мы и назвали PraxOS. Как это работает? Мы выбрали системный подход как онтологию и системную инженерию как использующий ее метаметод самого высокого уровня, далее разбираемся с основными дисциплинами/метаметодами системной инженерии (инженерия требований, инженерия системной архитектуры, управление проектами и т.д.), конкретизируя их до инженерии системной архитектуры по MFESA, управления проектами по Теории ограничений и т.д. -- поддерживая при этом общность онтологии и максимальный уровень обобщений.
Главное в PraxOS -- это разбирательство с предметным и процессным содержанием работы. Так, "метод персонажа", примененный к ситуации "идеального акционера" (подробнее -- http://ailev.livejournal.com/511947.html) может быть еще более обобщен, если понимаешь, что речь идет о метаметоде инженерии требований -- а инженерия требований в общем случае это работа с ролями. "Персонаж" -- это про метод перевода роли заинтересованной стороны в позицию (http://ailev.livejournal.com/760041.html). Как только вы поняли, что речь идет о какой-то заинтересованной стороне и ее требованиях, которая вам непосредственно недоступна -- вы смело можете применять этот метод, даже если речь не идет о разработке коробочного софта или юзабилити.
Как только вы сообразили, что организация -- это система, а акционер -- это заинтересованная сторона, у которой всегда есть требования, то далее не нужно быть восьми пядей во лбу, чтобы на этом уровне общности вспомнить про метод персонажа. Случайные "озарения" становятся рутиной. Главное в методах -- это их масштабируемость, применение одних и тех же мыслительных паттернов на самых разных уровнях детализации в самых разных делах.
Создатели ISO 15288 (как рассказывал нам его архитектор Гарольд Лоусон) чрезвычайно были озабочены именно этой стороной вопроса: масштабируемостью и универсальностью описываемого в нем метаметода системной инженерии. Сохранение этой масштабируемости и есть главная фишка.
Близкий родственник PraxOS в этом плане opfro.org (http://ailev.livejournal.com/674073.html -- где я делаю возмутительную ошибку, спутав ISO 24744 и ISO 24774, что месяцев на пять задержало неминуемую разборку с ситуационной инженерией методов). В OPFRO.org cобрано порядка 1100 фрагментов методов в единой онтологии (и там тоже отражен метаметод инженерии системной архитектуры MFESA). Отличается PraxOS двумя вещами:
а) другим набором "избранных методов" (так, у нас есть Голдратт, а в opfro.org его нет. У нас есть ICM, а в opfro.org его нет. У нас сделан вывод о минимальных четырех описаниях жизненного цикла, а в opfro не сделан. У нас есть методы онтологической интеграции данных, а в opfro.org их нет).
б) использованием немного другого инструментария работы с методами. С одной стороны, oprfo.org тоже движется в русле системной инженерии методов, и даже имеет собственную метамодель. Но наш PraxOS уже сейчас ориентируется на:
-- поддержку полной онтологии ISO 15926 и честную работу с моделью продукта (поддержка продуктной, ценностной группы описаний -- http://ailev.livejournal.com/764492.html).
-- на сегодняшний день работу не в "ручном" режиме, а сразу в SPEM 2.0 (и использование EPFC для этой работы). А в будущем -- выход на собственную метамодель и регистрацию этого стандарта в RDL ISO 15926 (да, я знаю, что там сначала фиксируются определения из оксфордского словаря, затем определения из стандартов ISO, затем только определения из стандартов промышленных ассоциаций, и только в последнюю очередь ориссы. Википедия, она и есть википедия, даже если ее обозвать RDL и дать статус международного стандарта).
Но мало создать такую библиотечку. Нужно еще и уметь применять в ней написанное -- это означает, что мало найти опубликовать в RDL онтологию рабочих продуктов онтологию рабочих продуктов инженерии системной архитектуры (http://ailev.livejournal.com/766364.html). Нужно еще опубликовать эту онтологию у себя в мозгу так, чтобы мозг сумел ей воспользоваться (а потом еще и помог освоить эту онтологию сотрудникам клиента).
Создание этой библиотеки методов и погружение ее в себя любимого затратно. Музыканту платят за выступления, спортсмен получает деньги за соревнования, консультант -- за решения задач клиентов. За репетиции, тренировки, самообразование и прочую подготовительную работу не платят. Но это основное, на что уходит время.
В) инструментарий для дела -- методология
Для основной деятельности консультанта (разбирательства с лучшими практиками работы) требуется хорошо освоить инструментарий работы с методами, как объектами. Ибо метод представляет из себя довольно сложный объект -- метод состоит из его предмета (онтологии, лексики, нотаций -- http://ailev.livejournal.com/761744.html), плюс практик/содержания методов, плюс процессов/жизненных циклов. Метод сам выражается при помощи метамодели, онтологии, лексики, нотаций выбранной версии метаметода системной инженерии методов. Границы метода как системы чрезвычайно расплывчаты. Заинтересованных в методе сторон довольно много (разработчик метода, применяющий метод, кодировщик описания метода, проверяющий выполнение метода, учитель метода и т.д.), все они предъявляют разные требования и к методу, и к инструментарию с ним работы.
Основным методом системной инженерии является построение моделей методов. То есть нашим инструментом в работе с методами является моделирование методов, их анализ и синтез, препарирование и оживление. Для этих целей нужно иметь набор правильных описаний методов, "вынуть методы из головы" и положить их в компьютер -- даже не для того, чтобы эти методы компьютер мог исполнить сам (хотя сингулярность уже близка, и кто знает, что будет через полтора десятка лет?). Это нужно просто для того, чтобы как самому иметь возможность размышлять о метаметодах, методах и т.д. ("внутри головы думать нельзя" -- http://community.livejournal.com/openmeta/190239.html). Но в неменьшей степени это нужно для того, чтобы обеспечивать совместную работу над этими метаметодами, повышать их качество.
Вся эта возня с инструментарием выражения онтологий, лексик, нотаций ситуативной инженерии методов для меня тут инструмент для инструмента -- инструмент методологического размышления над метаметодами, методами, процессами, жизненными циклами, группами описаний и т.д. Этот инструментальный уровень уже совсем непродажный, это чистые затраты. Если бы кто-то за меня тут думал и делал, принял бы его работу с благодарностью. Проблема в том, что адекватных инструментов для моей собственной работы никто не делает: если выходишь на уровень мастера в своем деле, то и инструмент из ближайшего ларька тебе не подходит. Приходится делать методологический инструментарий самостоятельно.
Чтобы работать с предметными методами, нужно уметь как-то представить онтологию, лексику, нотацию. Нужно выбрать или создать метамодели, лексику и нотации для онтологии, лексики, нотации методов. Нужно создать или выбрать софт, который это все поддерживает.
2. Что делать: план релиза PraxOS 2.3
Нужно выпустить релиз PraxOS 2.3 (предыдущий план релиза 2.1 был в октябре 2008г. -- http://ailev.livejournal.com/627019.html, затем в декабре 2008г. был план исследований релиза 2.2 -- http://ailev.livejournal.com/640851.html). В релизе 2.3 признается, что общая цель версии 2 -- разбирательство с "процессными фреймворками" -- остается (это мы так год назад нащупывали идею ситуативной инженерии методов), но также фиксируется зацикленность предыдущей версии на методологических занятиях -- хотя это принесло плоды, ответы на многие поставленные вопросы получены (хотя реализации пока не было).
В этой версии цели мы распишем на три группы, соответствующие трем занятиям консультанта:
а) приложение методов -- консультирование
-- выполнить ряд задач ситуативной инженерии метода для конкретной ситуации клиента (т.е. его целевой системы и его инструментального окружения), чтобы обкатать прихваченные в последнее время лучшие практики. Работа с клиентом дает опыт, без которого всенепременно будут накапливаться и не исправляться ошибки. По понятным причинам, в ЖЖ я не особо обсуждаю этот вопрос -- работа с клиентами не терпит публичности. Граница тут проходит по конкретной целевой системе и инструментарию клиента: его ситуация не должна выноситься на публику без особой на то просьбы. Поэтому раскрываться может только метаметод (PraxOS), но не метод (уточненый для ситуации клиента экземпляр метода).
б) пополнение библиотечки метаметодов и их освоение -- профессиональный рост.
-- исследования и формулирование метаметода иженерии требований второго поколения, т.е. развитие идей http://ailev.livejournal.com/754369.html
-- разбирательство с инженерией системной архитектуры, http://ailev.livejournal.com/758212.html
-- Суровый (крутой, недетский) рефакторинг текущих знаний -- с учетом общая рамки ситуационной инженерии методов, онтологии системного подхода, в том числе онтологии дисциплин системной инженерии -- минимально в части наиболее общих артефактов и именований ее дисциплин. По-хорошему, нужно было бы переписать все постинги, переделать все презентации, перечитать все видео, и заменить тексты на сайте PraxOS. Рефакторинг, он и есть рефакторинг: остановка сегодня, чтобы не затормозиться навсегда завтра.
-- документирование результатов рефакторинга. Вряд ли в версии 2.3 это будет документировано в "универсальном моделере", но на его роль временно назначается EPFC. Возможно, нужно вебсайт http://PraxOS.ru из вики-сайта переделать в продуцируемый этим моделером сайт. Все равно вики-сайты не взлетают, если их пополняют менее пяти человек, а в PraxOS пятерых разработчиков все нет и нет (хотя наблюдают за работой довольно много народу -- обычный эффект торрентовых сетей: аплоадят не более 3%, а пользуются потом все).
в) методология -- инструментарий
-- доформулировать подход PraxOS как интеграцию методов в промышленных масштабах (http://ailev.livejournal.com/640702.html)
-- продолжение планирования "универсального моделера" (http://ailev.livejournal.com/757999.html, http://ailev.livejournal.com/758941.html).
-- -- выбор онтологии, лексики и нотации для (минимально) четырех групп описаний процесса/жизненного цикла http://ailev.livejournal.com/764492.html и реализация их в "универсальном моделере".
-- Онтологию и лексику activity model из предыдущего пункта погрузить в ISO 15926 RDL (или хотя бы в WIP).
-- сделать для универсального моделера мэппинг (с использованием ISO 15926-фасада) для workflow распространенных САПРов (а также для их модулей генерации ППР -- "планов производства работ", встроенных хелпов, чтобы включать в этих хелпы методы клиента и прочая интеграция в конкретные САПР).
-- присматривание к интерактивному программированию в плане изменения метаметодов (т.е. отладки как цикла исследования-создания взаимоувязанных онтологии, лексики, нотации и содержания метаметода) без потери целостности порожденного прошлой версией и доработанного при этом "напильником" метода.
-- агентские архитектуры как решение проблемы SOA и "программирования в большом"
-- Cola как language workbench следующего поколения. Можно ли сделать моделер?
-- соответствие SOA-инфраструктуры для поддержки методов и самих методов (за это, вроде, взялся foxtreme).
Основной задачей текущего момента считаю балансирование всех трех занятий. Треть времени заниматься приложением дисциплины-метаметода и порождением ситуационно-обусловленного метода, треть времени заниматься созданием метаметодов и методов их приложения-освоения, а треть времени продолжать заниматься методологией и методологическими инструментами.