Знаниевые формы и их системная инженерия
В сегодняшний (или таки вчерашний?) день знаний хорошо бы понять, кто кого где когда зачем почему чему (каким знаниям) учит -- в том числе учит и якобы уже давно отучившихся взрослых.
По определению, знания -- это справочные факты, т.е. факты, которые можно использовать во множестве ситуаций (во множестве проектов, во множестве деятельностей). Выучил арифметику один раз в начальной школе -- жмёшь потом кнопки калькулятора и в модном магазине, и в конструкторском бюро. Выучил управление проектами и/или управление жизненным циклом в ВУЗе -- и используешь это потом всю жизнь. Часть знаний -- это "нетленка", а часть скоропортящаяся. Арифметика меняется за десяток лет не слишком сильно (но и то после школы приходится с десятичной запятой переходить на десятичную точку -- в школе-то до сих пор запятой учат!), а вот "управление жизненным циклом" существенно меняет своё содержание каждые пять лет, и эти знания постоянно требуют освежения. Про всякие новоявленные deep learning (которым, вполне возможно, в ближайшем будущем будут учить инженеров так же, как мат.статистике и интегральному исчислению) я вообще молчу: практический старт этой дисциплине был дан в 2006г., всего семь лет назад (http://ailev.livejournal.com/1044735.html, http://ailev.livejournal.com/1045081.html).
Классификаций для знаний можно представить огромное количество: в зависимости от того, что хочется с этими знаниями делать, такие категории знаний и вводить. Например:
-- научная нетленка против научной тленки (арифметика и ньютоновская механика против управления жизненным циклом и deep learning).
-- научные (как тленка, так и нетленка) против корпоративных (управление жизненным циклом "как бывает вообще" против управления жизненным циклом в рамках конкретной компании -- с задействованием конкретных рабочих продуктов. См. http://ailev.livejournal.com/1082662.html).
-- за которые платишь сам (интегральное исчисление, системная инженерия -- такому обычно учат только в ВУЗах, за три дня не научишься) и за которые тебе заплатит производство (однодневный курс по программному пакету поддержки интегрального исчисления, трёхдневное знакомство с парочкой диаграмм из двухлетнего курса системной инженерии).
Чтобы обсуждать все эти различения для знаний для целей обучения, т.е. сравнивать вчерашние и сегодняшние варианты дисциплин, оценивать объемы, нужно их как-то паковать в сравнимой форме. А раз знания упакованы, то в этой же форме их можно и принимать, как лекарства -- все эти знаниевые пилюли, микстуры, порошки. От формы зависит и лёгкость усвоения, и легкость приготовления, и лёгкость понимания теми, кто выписывает и оплачивает рецепт.
Оценку объема знания для какой-то новой специализации я приводил в http://ailev.livejournal.com/871079.html -- это примерно 30Мзнаков, то есть 30 томов по 1Мзнаку (400 страниц) каждый, изучаемые 10 месяцев со скоростью примерно три томика в месяц. Для справки: body of knowledge по системной инженерии (http://www.sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledge_%28SEBoK%29) это примерно 800 страниц текста, но этот текст не столько сам о чём-то рассказывает, сколько даёт ссылки на литературу -- это такое 800-страничное оглавление к литературе, детально описывающей предметную область.
Знания для повышения квалификации без отрыва от производства пакуются на сегодняшний день (в порядке роста строгости формы):
-- непрерывно накрапывающий дождик из самых разных статей, монографий, докладов на конференциях, постов в блогах по отдельным темам, и лучшие специалисты потребляют их в таком "диком" виде. Всё свежее, необъятное, живое, малопонятное для новичков (непонятно, с чего начать, чем закончить).
-- TechPack (редакторская выборка отдельных капелек из дождичка: что-то типа "хрестоматии", но без прилагающегося "учебника" или иного варианта сборки знания во что-то общее). Пример -- это http://techpack.acm.org/
-- онлайн учебные курсы и тьтюториалы с лекциями по отдельным темам. Пример: http://ocw.mit.edu/courses/engineering-systems-division/esd-33-systems-engineering-summer-2010/index.htm;
-- учебники (книжки с картинками, систематически излагающие какой-то материал, ранее доступный в виде "дождика". К книжке иногда прилагается задачник с упражнениями -- "рабочая тетрадь");
-- body of knowledge (обзорный текст, в котором показывается связь разных кусочков знаний между собой, а литература -- это есть кусочки знания из TechPack). Пример -- http://www.sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledge_%28SEBoK%29. В принципе, это не сильно отличается от учебника, разве учебник пишет "автор", а Body of Knowlede готовится коллективом авторов и утверждается по процедуре, похожей на процедуру стандартизации (версии, сбор замечаний, переделки, формальные утверждения и т.д.);
-- библиотеки практик: те же Body of Knowledge, но развёрнутые в сторону реального применения в проектах и перепакованные по более-менее одинаковому образцу (ибо эти Body of Knowledge внутри себя все устроены уникально, нет двух одинаковых -- а на библиотеки практик существуют стандарты оформления, их немало: те же OPF, SPEM 2.0, ISO 24744, OMG Essence). Как самая сложная форма, предполагающая к тому же выход от "знаний" к "умениям", эта форма на сегодняшний день гипотетическая -- практики-то как-то описаны, но вот учиться по этим описаниям нельзя. В качестве примера можно привести http://opfro.org в стандарте OPF, http://www.sysmod.de/ в SPEM 2.0. Это, скорее, не учебные материалы, а оглавления для требуемого 30-томника. Обратим особое внимание, что библиотеки практик по сути отличаются от "методологий" (процессных фреймворков, ailev.livejournal.com/560707.html -- всех этих RUP, CMMI и прочих ISO 15288) тем, что методология требует использования в каждом проекте одного и того же способа работы (метода), а библиотека практик набирает из разных практик для разных проектов разные методы (то есть в одном проекте поменьше предполагается использование user stories, в другом user cases -- http://ailev.livejournal.com/1082573.html).
Требуемые 30 томов по какой-то профессиональной специализации:
-- находятся в разной форме (что-то доступно учебниками, что-то видеолекциями, а что-то только на уровне базового оглавления)
-- абсолютно не связаны не только терминологически, но даже по базовым идеям (например, курс проектного управления может настаивать на строгой "водопадной модели", а курс архитектуры ориентироваться на какие-то виды agile).
-- непонятна последовательность освоения (даже если все тридцать томов лежат перед тобой готовенькие -- с чего начать?!)
-- упражнения или хотя бы вопросы для контроля знаний можно найти только вместе с классическими учебниками, или в онлайн курсах лекций. Изредка можно встретить вопросы контроля знаний, если организована профессиональная сертификация на базе Handbook и/или Body of Knowledge.
Оставим за рамками обсуждения то, чем дистантное образование (т.е. освоение материала 30 томов) отличается от очного -- дистантное образование хорошо передает знания, но вот различные социальные аспекты (ценности и убеждения, принадлежность к школе и профессии, навыки обсуждения проблем с коллегами и коллективной работы, и т.д. и т.п.) для дистантного образования труднодостижимы. "Полный опыт", как это делается в лучшем очном образовании, от учителей к ученикам в дистантном образовании не переносится, только знаниевые его аспекты. Но сегодня же вчерашний день знаний, да? Так что помолчим о том, как учить, поговорим побольше о том, как упаковать то, чему учить.
Как структурировать знаниевый эквивалент 30 томиков -- особенно с учётом того, что ежегодно часть нужно переписывать, чтобы поддерживать актуальность общего курса, и сама структура этого знания наверняка будет меняться год от года? Как описать эти знания о той или иной деятельности?
Следуя 4D подходу, нам нужно начать с того, что соответствует этим знаниям в реальном мире -- какая система? В реальном мире знаниям соответствует система деятельности: совокупность всех участвующих в той или иной деятельности индивидов (т.е. объектов, имеющих протяженность в пространстве и времени). То есть нужно определить систему деятельности -- получить достаточный для наших целей набор описаний!
Помним, что мы обобщаем догадки архитектурного подхода, закреплённые в ISO 42010 и прояснённые в книжках типа http://libgen.org/get?nametype=orig&md5=abb4676b7b1ddfa74e33b7799ebbb61a с альфы архитектуры до альфы определения системы. Диаграммку см. на слайде 14 тут: http://www.slideshare.net/abayda/essence-syseng-omg20jun13v41
Далее действуем по норме:
1. Поскольку есть система, то у неё есть определение системы (альфа) и описание системы (набор рабочих продуктов). Неважно, что наша система деятельности не проектируется, а просто описывается: мы просто восстанавливаем определение системы (требования, архитектура, design), и отражаем его в описании системы (body of knowledge и библиотека практик).
2. Как у любой системы, у системы деятельности есть стейкхолдеры, у которых есть разные цели и соответствующие этим целям разные интересы по отношению к этой системе. То, что система деятельности -- это система систем (в неё входят вполне автономные поддеятельности, контролируемые разными community of practice) мы будем игнорировать. Нас вполне устроит, если наше описание сработает только для тех проектов (endeavours), в которых будет происходить деятельность пользующихся нашими описаниями людей, т.е. мы считаем, что так определённая система деятельности нам инженерно подконтрольна (в отличие от системы деятельности, соответствующей всей профессиональной деятельности на планете, которая была есть и будет по той или иной специализации).
3. Разные интересы требуют разных тематических групп описаний (view), которые получаются в соответствии с разными методами описаний (viewpoint) и удобны для удовлетворения интересов разных "действующих лиц" соответствующей предметной области (в системной инженерии -- занимающихся маркетингом, инженеров разных специализаций, операционных менеджеров, технологов и т.д.). Вот отсюда (из системного подхода) и следует, что описание любой системы деятельности условными тридцатью томами с разными видами её описаний вполне нормально -- в протиповоставление описанию системы одним супертомом с "единым описанием" из редукционистского подхода. Напомню, что системный подход противопоставляется именно редукционистскому подходу с его единственным "научно выверенным единым описанием".
Скорее всего, нужно будет удовлетвориться не написанием 30 томов исчерпывающего описания деятельности, а какой-то федерирующей компоненты для этих тридцати томов (мэппинг основных сущностей).
4. Но и само определение деятельности имеет своих стейкхолдеров по образовательной тематике: организаторов образования, авторов учебников, курсантов, методистов, специалистов HR служб и т.д. Это означает, что в этих 30 томиках есть не только описания самой деятельности, но и те описания, которые связаны именно с обучением/образованием. Федерирующая компонента из пункта 2 как раз будет их включать. Грубо говоря, описания деятельности - это описание run time, но часть описаний относится к compile time (и относится, безусловно, к описаниям альфы "технологии").
Какие это могут быть описания? Отвечаем на этот вопрос точно так же, как для любой другой системы (в какой то мере идём по книжке http://libgen.org/get?nametype=orig&md5=abb4676b7b1ddfa74e33b7799ebbb61a -- не изобретаем велосипед, а пытаемся использовать уже имеющиеся в культуре знания по стилям описаний):
1. Описания модульных стилей, отвечающие на вопросы:
-- из каких частей (подсистем) состоит курс (и из каких частей состоит описание деятельности -- наш "учебник-библиотека практик"), структура декомпозиции на учебные модули -- "практики"? "главы-параграфы"?
-- какие зависимости между модулями (если какую-то часть неправильно освоить, какую часть нельзя будет дальше учить надлежащим образом?): модульные слои, "физику нельзя учить, пока нет навыка в работе с вещественными числами".
-- ...
По этим описаниям авторам можно понять, что в курсе нужно создать, а курсантам можно понять, что они будут осваивать.
2. Стили описания компонентов и соединений:
-- как конкретно ссылаются модули друг на друга (гипертекст? примечания? отсутствие ссылок, просто подразумевается использование. Последовательный текст -- flow как в scrievener, или проход по основному тексту в дополнительные материалы с возвратами -- call and return)?
-- как происходит сборка итогового метода из осваиваемых практик (все эти "образовательные пути" на графе модулей)?
-- когда возможен контроль знаний?
Именно по этим описаниям можно понять, насколько курс получается:
-- адаптируем (например, можно ли из него выделить кусочки для маленьких тьюториалов на один-два томика, или это гиблое дело -- нужно одним длинным куском проходить вперемешку все 30 томов)
-- сколько времени его учить, учитывая что части курса влияют друг на друга (path dependance)
-- насколько разные части курса смогут быть склеены в голове курсанта в одно целое
-- насколько обучение можно разделить на осмысленные стадии
-- насколько одну деятельность можно поделить на несколько человек
Особо отметим, что учебные модули (учебника-библиотеки практик) и компоненты учебного курса (учебного процесса) трассируются друг ко другу, но необязательно 1:1 (то есть учебный модуль "в учебнике" вполне соответствует компоненте какого-то учебного курса 1:1, если, как в школе, параграфы учебника проходятся последовательно, один за одним. В таком обучении каждую учебную тему "проходят" один раз -- чтобы больше к ней уже не возвращаться, а реальная интеграция пройденного будет в производственной жизни. Но некоторые учителя предпочитают проходить материал "по спирали", непрерывно возвращаясь к уже пройденным темам в попытках комбинирования их материала со всевозрастающим количеством пройденного материала других тем. У таких учителей даже учебники не подразумевают чёткого предметного деления в своих главах: их невозможно использовать как справочники (знания!) по предмету, они именно "учебники". И в любой момент времени невозможно ответить на вопрос: "пройдена" ли такая-то тема (то есть тестирование должно это учитывать: в какой момент тестировать усвоение темы "управление жизненным циклом", если её прохождение окажется размазанным по всему курсу системной инженерии? Что делать, если все тридцать томов курса "начаты", но ни один далеко не кончен -- ждать тридцати экзаменов в конце года, или как-то надеяться на промежуточные тестирования?).
Так что не путаем компоненты (динамика, run time -- computational models, обсуждается процесс) и модули (статика, compile time -- декомпозиционные модели с точки зрения "изготовителя" и автономности в проектировании и использовании), но и не забываем об их неразрывной связи.
Компоненты -- это про сюжет, нарратив. Если сделать текст с нарративом (с плохой модульностью), то будет "бестселлер", по нему будет хорошо учиться. Если сделать текст-справочник, то будет лонгселлер, он будет нужен в том числе и после окончания обучения -- но... энциклопедии не принято читать, все эти "body of knowledge" абсолютно нечитабельны, недаром рядом с ними пытаются делать какие-то Guides.
3. Стили размещения ответят на вопросы:
-- кто сможет это преподавать (объяснять и обсуждать)? Отметим, что "кто создаёт" -- это больше вопрос к модульным стилям.
-- кто и как сможет организовать контроль знаний (тесты? собеседования? решения задач? эссе?)
-- каковы форматы хранения учебника-библиотеки практик на серверах? Какие сервера потребуются (справочный-тьюторный? курса? тестирования?).
* * *
Почему я это тут так загадочно пишу? Ведь все эти вопросы (хотя и в другой терминологии) обсуждаются в instructional design? Ну, я вроде бы провозглашал цель компактификации мышления: системный инженер должен самые разные инженерные проекты (в том числе instructional design -- это ведь инженерия!) уметь единообразно представлять, ему должно хватать для этого средств. Люди в instructional design комьюнити хороши насчёт instructional, но не факт, что они круче в design, чем systems engineers (или software engineers). А уж если стоит необычная задача (как у меня сейчас -- создание библиотеки практик по системной и организационной инженерии и инженерному менеджменту), которая в какой-то момент потребует коллективной работы самых разных стейкхолдеров -- то лучше бы постановку этой задачи сразу делать в языке системной инженерии, а не в языке какого-то одного из стейкхолдеров.
Заодно предотвращаются многие ошибки типа попытки отделаться одной группой описаний или сборки всего содержания в какую-то одну иерархию.
В этом тексте нужно обратить внимание на то, что даёт пример самой начальной стадии применения системного подхода к какому-то проекту (выделили систему, определили стейкхолдеров и их интересы, затем наметили потребные стили описаний из числа самых распространённых).
Но не нужно обольщаться: я не дал почти никаких примеров, плюс оборвал изложение на том моменте, когда для каждого стиля описаний нужно будет выбрать метод описаний (желательно библиотечный, чтобы не изобретать велосипед), а затем (САМОЕ ГЛАВНОЕ!!!) -- придумать (а не только документировать придуманные кем-то -- это не работа аналитика-"писаря-под-диктовку в заданных формальных языках"!) сами эти описания. Моё основное время сейчас уходит именно на это "главное" -- под scrivener затащено уже триста страниц материала и я пытаюсь вытащить из них все эти разные стили описаний и сделать так, чтобы их было легко менять и дополнять в ходе актуализации учебного материала. А потом под появляющуюся постепенно структуру и все 800 страниц затащу...
С Днём Знаний!
По определению, знания -- это справочные факты, т.е. факты, которые можно использовать во множестве ситуаций (во множестве проектов, во множестве деятельностей). Выучил арифметику один раз в начальной школе -- жмёшь потом кнопки калькулятора и в модном магазине, и в конструкторском бюро. Выучил управление проектами и/или управление жизненным циклом в ВУЗе -- и используешь это потом всю жизнь. Часть знаний -- это "нетленка", а часть скоропортящаяся. Арифметика меняется за десяток лет не слишком сильно (но и то после школы приходится с десятичной запятой переходить на десятичную точку -- в школе-то до сих пор запятой учат!), а вот "управление жизненным циклом" существенно меняет своё содержание каждые пять лет, и эти знания постоянно требуют освежения. Про всякие новоявленные deep learning (которым, вполне возможно, в ближайшем будущем будут учить инженеров так же, как мат.статистике и интегральному исчислению) я вообще молчу: практический старт этой дисциплине был дан в 2006г., всего семь лет назад (http://ailev.livejournal.com/1044735.html, http://ailev.livejournal.com/1045081.html).
Классификаций для знаний можно представить огромное количество: в зависимости от того, что хочется с этими знаниями делать, такие категории знаний и вводить. Например:
-- научная нетленка против научной тленки (арифметика и ньютоновская механика против управления жизненным циклом и deep learning).
-- научные (как тленка, так и нетленка) против корпоративных (управление жизненным циклом "как бывает вообще" против управления жизненным циклом в рамках конкретной компании -- с задействованием конкретных рабочих продуктов. См. http://ailev.livejournal.com/1082662.html).
-- за которые платишь сам (интегральное исчисление, системная инженерия -- такому обычно учат только в ВУЗах, за три дня не научишься) и за которые тебе заплатит производство (однодневный курс по программному пакету поддержки интегрального исчисления, трёхдневное знакомство с парочкой диаграмм из двухлетнего курса системной инженерии).
Чтобы обсуждать все эти различения для знаний для целей обучения, т.е. сравнивать вчерашние и сегодняшние варианты дисциплин, оценивать объемы, нужно их как-то паковать в сравнимой форме. А раз знания упакованы, то в этой же форме их можно и принимать, как лекарства -- все эти знаниевые пилюли, микстуры, порошки. От формы зависит и лёгкость усвоения, и легкость приготовления, и лёгкость понимания теми, кто выписывает и оплачивает рецепт.
Оценку объема знания для какой-то новой специализации я приводил в http://ailev.livejournal.com/871079.html -- это примерно 30Мзнаков, то есть 30 томов по 1Мзнаку (400 страниц) каждый, изучаемые 10 месяцев со скоростью примерно три томика в месяц. Для справки: body of knowledge по системной инженерии (http://www.sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledge_%28SEBoK%29) это примерно 800 страниц текста, но этот текст не столько сам о чём-то рассказывает, сколько даёт ссылки на литературу -- это такое 800-страничное оглавление к литературе, детально описывающей предметную область.
Знания для повышения квалификации без отрыва от производства пакуются на сегодняшний день (в порядке роста строгости формы):
-- непрерывно накрапывающий дождик из самых разных статей, монографий, докладов на конференциях, постов в блогах по отдельным темам, и лучшие специалисты потребляют их в таком "диком" виде. Всё свежее, необъятное, живое, малопонятное для новичков (непонятно, с чего начать, чем закончить).
-- TechPack (редакторская выборка отдельных капелек из дождичка: что-то типа "хрестоматии", но без прилагающегося "учебника" или иного варианта сборки знания во что-то общее). Пример -- это http://techpack.acm.org/
-- онлайн учебные курсы и тьтюториалы с лекциями по отдельным темам. Пример: http://ocw.mit.edu/courses/engineering-systems-division/esd-33-systems-engineering-summer-2010/index.htm;
-- учебники (книжки с картинками, систематически излагающие какой-то материал, ранее доступный в виде "дождика". К книжке иногда прилагается задачник с упражнениями -- "рабочая тетрадь");
-- body of knowledge (обзорный текст, в котором показывается связь разных кусочков знаний между собой, а литература -- это есть кусочки знания из TechPack). Пример -- http://www.sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledge_%28SEBoK%29. В принципе, это не сильно отличается от учебника, разве учебник пишет "автор", а Body of Knowlede готовится коллективом авторов и утверждается по процедуре, похожей на процедуру стандартизации (версии, сбор замечаний, переделки, формальные утверждения и т.д.);
-- библиотеки практик: те же Body of Knowledge, но развёрнутые в сторону реального применения в проектах и перепакованные по более-менее одинаковому образцу (ибо эти Body of Knowledge внутри себя все устроены уникально, нет двух одинаковых -- а на библиотеки практик существуют стандарты оформления, их немало: те же OPF, SPEM 2.0, ISO 24744, OMG Essence). Как самая сложная форма, предполагающая к тому же выход от "знаний" к "умениям", эта форма на сегодняшний день гипотетическая -- практики-то как-то описаны, но вот учиться по этим описаниям нельзя. В качестве примера можно привести http://opfro.org в стандарте OPF, http://www.sysmod.de/ в SPEM 2.0. Это, скорее, не учебные материалы, а оглавления для требуемого 30-томника. Обратим особое внимание, что библиотеки практик по сути отличаются от "методологий" (процессных фреймворков, ailev.livejournal.com/560707.html -- всех этих RUP, CMMI и прочих ISO 15288) тем, что методология требует использования в каждом проекте одного и того же способа работы (метода), а библиотека практик набирает из разных практик для разных проектов разные методы (то есть в одном проекте поменьше предполагается использование user stories, в другом user cases -- http://ailev.livejournal.com/1082573.html).
Требуемые 30 томов по какой-то профессиональной специализации:
-- находятся в разной форме (что-то доступно учебниками, что-то видеолекциями, а что-то только на уровне базового оглавления)
-- абсолютно не связаны не только терминологически, но даже по базовым идеям (например, курс проектного управления может настаивать на строгой "водопадной модели", а курс архитектуры ориентироваться на какие-то виды agile).
-- непонятна последовательность освоения (даже если все тридцать томов лежат перед тобой готовенькие -- с чего начать?!)
-- упражнения или хотя бы вопросы для контроля знаний можно найти только вместе с классическими учебниками, или в онлайн курсах лекций. Изредка можно встретить вопросы контроля знаний, если организована профессиональная сертификация на базе Handbook и/или Body of Knowledge.
Оставим за рамками обсуждения то, чем дистантное образование (т.е. освоение материала 30 томов) отличается от очного -- дистантное образование хорошо передает знания, но вот различные социальные аспекты (ценности и убеждения, принадлежность к школе и профессии, навыки обсуждения проблем с коллегами и коллективной работы, и т.д. и т.п.) для дистантного образования труднодостижимы. "Полный опыт", как это делается в лучшем очном образовании, от учителей к ученикам в дистантном образовании не переносится, только знаниевые его аспекты. Но сегодня же вчерашний день знаний, да? Так что помолчим о том, как учить, поговорим побольше о том, как упаковать то, чему учить.
Как структурировать знаниевый эквивалент 30 томиков -- особенно с учётом того, что ежегодно часть нужно переписывать, чтобы поддерживать актуальность общего курса, и сама структура этого знания наверняка будет меняться год от года? Как описать эти знания о той или иной деятельности?
Следуя 4D подходу, нам нужно начать с того, что соответствует этим знаниям в реальном мире -- какая система? В реальном мире знаниям соответствует система деятельности: совокупность всех участвующих в той или иной деятельности индивидов (т.е. объектов, имеющих протяженность в пространстве и времени). То есть нужно определить систему деятельности -- получить достаточный для наших целей набор описаний!
Помним, что мы обобщаем догадки архитектурного подхода, закреплённые в ISO 42010 и прояснённые в книжках типа http://libgen.org/get?nametype=orig&md5=abb4676b7b1ddfa74e33b7799ebbb61a с альфы архитектуры до альфы определения системы. Диаграммку см. на слайде 14 тут: http://www.slideshare.net/abayda/essence-syseng-omg20jun13v41
Далее действуем по норме:
1. Поскольку есть система, то у неё есть определение системы (альфа) и описание системы (набор рабочих продуктов). Неважно, что наша система деятельности не проектируется, а просто описывается: мы просто восстанавливаем определение системы (требования, архитектура, design), и отражаем его в описании системы (body of knowledge и библиотека практик).
2. Как у любой системы, у системы деятельности есть стейкхолдеры, у которых есть разные цели и соответствующие этим целям разные интересы по отношению к этой системе. То, что система деятельности -- это система систем (в неё входят вполне автономные поддеятельности, контролируемые разными community of practice) мы будем игнорировать. Нас вполне устроит, если наше описание сработает только для тех проектов (endeavours), в которых будет происходить деятельность пользующихся нашими описаниями людей, т.е. мы считаем, что так определённая система деятельности нам инженерно подконтрольна (в отличие от системы деятельности, соответствующей всей профессиональной деятельности на планете, которая была есть и будет по той или иной специализации).
3. Разные интересы требуют разных тематических групп описаний (view), которые получаются в соответствии с разными методами описаний (viewpoint) и удобны для удовлетворения интересов разных "действующих лиц" соответствующей предметной области (в системной инженерии -- занимающихся маркетингом, инженеров разных специализаций, операционных менеджеров, технологов и т.д.). Вот отсюда (из системного подхода) и следует, что описание любой системы деятельности условными тридцатью томами с разными видами её описаний вполне нормально -- в протиповоставление описанию системы одним супертомом с "единым описанием" из редукционистского подхода. Напомню, что системный подход противопоставляется именно редукционистскому подходу с его единственным "научно выверенным единым описанием".
Скорее всего, нужно будет удовлетвориться не написанием 30 томов исчерпывающего описания деятельности, а какой-то федерирующей компоненты для этих тридцати томов (мэппинг основных сущностей).
4. Но и само определение деятельности имеет своих стейкхолдеров по образовательной тематике: организаторов образования, авторов учебников, курсантов, методистов, специалистов HR служб и т.д. Это означает, что в этих 30 томиках есть не только описания самой деятельности, но и те описания, которые связаны именно с обучением/образованием. Федерирующая компонента из пункта 2 как раз будет их включать. Грубо говоря, описания деятельности - это описание run time, но часть описаний относится к compile time (и относится, безусловно, к описаниям альфы "технологии").
Какие это могут быть описания? Отвечаем на этот вопрос точно так же, как для любой другой системы (в какой то мере идём по книжке http://libgen.org/get?nametype=orig&md5=abb4676b7b1ddfa74e33b7799ebbb61a -- не изобретаем велосипед, а пытаемся использовать уже имеющиеся в культуре знания по стилям описаний):
1. Описания модульных стилей, отвечающие на вопросы:
-- из каких частей (подсистем) состоит курс (и из каких частей состоит описание деятельности -- наш "учебник-библиотека практик"), структура декомпозиции на учебные модули -- "практики"? "главы-параграфы"?
-- какие зависимости между модулями (если какую-то часть неправильно освоить, какую часть нельзя будет дальше учить надлежащим образом?): модульные слои, "физику нельзя учить, пока нет навыка в работе с вещественными числами".
-- ...
По этим описаниям авторам можно понять, что в курсе нужно создать, а курсантам можно понять, что они будут осваивать.
2. Стили описания компонентов и соединений:
-- как конкретно ссылаются модули друг на друга (гипертекст? примечания? отсутствие ссылок, просто подразумевается использование. Последовательный текст -- flow как в scrievener, или проход по основному тексту в дополнительные материалы с возвратами -- call and return)?
-- как происходит сборка итогового метода из осваиваемых практик (все эти "образовательные пути" на графе модулей)?
-- когда возможен контроль знаний?
Именно по этим описаниям можно понять, насколько курс получается:
-- адаптируем (например, можно ли из него выделить кусочки для маленьких тьюториалов на один-два томика, или это гиблое дело -- нужно одним длинным куском проходить вперемешку все 30 томов)
-- сколько времени его учить, учитывая что части курса влияют друг на друга (path dependance)
-- насколько разные части курса смогут быть склеены в голове курсанта в одно целое
-- насколько обучение можно разделить на осмысленные стадии
-- насколько одну деятельность можно поделить на несколько человек
Особо отметим, что учебные модули (учебника-библиотеки практик) и компоненты учебного курса (учебного процесса) трассируются друг ко другу, но необязательно 1:1 (то есть учебный модуль "в учебнике" вполне соответствует компоненте какого-то учебного курса 1:1, если, как в школе, параграфы учебника проходятся последовательно, один за одним. В таком обучении каждую учебную тему "проходят" один раз -- чтобы больше к ней уже не возвращаться, а реальная интеграция пройденного будет в производственной жизни. Но некоторые учителя предпочитают проходить материал "по спирали", непрерывно возвращаясь к уже пройденным темам в попытках комбинирования их материала со всевозрастающим количеством пройденного материала других тем. У таких учителей даже учебники не подразумевают чёткого предметного деления в своих главах: их невозможно использовать как справочники (знания!) по предмету, они именно "учебники". И в любой момент времени невозможно ответить на вопрос: "пройдена" ли такая-то тема (то есть тестирование должно это учитывать: в какой момент тестировать усвоение темы "управление жизненным циклом", если её прохождение окажется размазанным по всему курсу системной инженерии? Что делать, если все тридцать томов курса "начаты", но ни один далеко не кончен -- ждать тридцати экзаменов в конце года, или как-то надеяться на промежуточные тестирования?).
Так что не путаем компоненты (динамика, run time -- computational models, обсуждается процесс) и модули (статика, compile time -- декомпозиционные модели с точки зрения "изготовителя" и автономности в проектировании и использовании), но и не забываем об их неразрывной связи.
Компоненты -- это про сюжет, нарратив. Если сделать текст с нарративом (с плохой модульностью), то будет "бестселлер", по нему будет хорошо учиться. Если сделать текст-справочник, то будет лонгселлер, он будет нужен в том числе и после окончания обучения -- но... энциклопедии не принято читать, все эти "body of knowledge" абсолютно нечитабельны, недаром рядом с ними пытаются делать какие-то Guides.
3. Стили размещения ответят на вопросы:
-- кто сможет это преподавать (объяснять и обсуждать)? Отметим, что "кто создаёт" -- это больше вопрос к модульным стилям.
-- кто и как сможет организовать контроль знаний (тесты? собеседования? решения задач? эссе?)
-- каковы форматы хранения учебника-библиотеки практик на серверах? Какие сервера потребуются (справочный-тьюторный? курса? тестирования?).
* * *
Почему я это тут так загадочно пишу? Ведь все эти вопросы (хотя и в другой терминологии) обсуждаются в instructional design? Ну, я вроде бы провозглашал цель компактификации мышления: системный инженер должен самые разные инженерные проекты (в том числе instructional design -- это ведь инженерия!) уметь единообразно представлять, ему должно хватать для этого средств. Люди в instructional design комьюнити хороши насчёт instructional, но не факт, что они круче в design, чем systems engineers (или software engineers). А уж если стоит необычная задача (как у меня сейчас -- создание библиотеки практик по системной и организационной инженерии и инженерному менеджменту), которая в какой-то момент потребует коллективной работы самых разных стейкхолдеров -- то лучше бы постановку этой задачи сразу делать в языке системной инженерии, а не в языке какого-то одного из стейкхолдеров.
Заодно предотвращаются многие ошибки типа попытки отделаться одной группой описаний или сборки всего содержания в какую-то одну иерархию.
В этом тексте нужно обратить внимание на то, что даёт пример самой начальной стадии применения системного подхода к какому-то проекту (выделили систему, определили стейкхолдеров и их интересы, затем наметили потребные стили описаний из числа самых распространённых).
Но не нужно обольщаться: я не дал почти никаких примеров, плюс оборвал изложение на том моменте, когда для каждого стиля описаний нужно будет выбрать метод описаний (желательно библиотечный, чтобы не изобретать велосипед), а затем (САМОЕ ГЛАВНОЕ!!!) -- придумать (а не только документировать придуманные кем-то -- это не работа аналитика-"писаря-под-диктовку в заданных формальных языках"!) сами эти описания. Моё основное время сейчас уходит именно на это "главное" -- под scrivener затащено уже триста страниц материала и я пытаюсь вытащить из них все эти разные стили описаний и сделать так, чтобы их было легко менять и дополнять в ходе актуализации учебного материала. А потом под появляющуюся постепенно структуру и все 800 страниц затащу...
С Днём Знаний!