Фундаментальное образование / Левенчук А.

Фундаментальное образование / Левенчук А.

by Евгений Волков -
Number of replies: 2
Пишет Anatoly Levenchuk (ailev
2018-05-10 16:10:00

Цепочка «Фундаментальное образование»

Чтобы стать хорошим инженером по требованиям, мало освоить курс "Практика JTBD" или "Практика Use Case 2.0". Нужно иметь фундаментальное образование: знать концептуальную дисциплину "инженерия требований", для чего как-то уложить в голове "системную инженерию" в целом, а для этого бегло владеть "системным мышлением", что требует какого-то мастерства в "онтологике". Тем самым компетенции в практиках инженерии требований будут не только прикладными, но и глубокими. А совместное владение неформальным и формальным мышлением сделает эти компетенции широкими. То же самое относится к любым другим компетенциям. Так, для хорошего владения практикой "Управление буфером проекта" недостаточно освоить перед этим концептуальную дисциплину "управление проектом/операционный менеджмент", но тоже нужно иметь поставленное системное мышление, для чего опять потребуется обратиться к онтологике. Про "стейкхолдерское мастерство", чтобы хорошо играть свою роль инженера по требованиям или операционного менеджера тут разговор отдельный. Проблема в том, что для разговора о глубоком и широком фундаментальном образовании, которое нужно, чтобы прикладное образование перестало быть поверхностным и мелким, не хватает языка, нет структурного представления о содержании образования. Сегодня разговоры ведутся лишь о форме: интерактивность, проектность, визуальность и т.д.. Но какое содержание должно быть облачено в эту великолепную современную проектную, визуальную, смешанную (blended) и т.д. педагогическую форму?!

В настоящем посте собраны ссылки на цепочку (sequence) моих постов марта-мая 2018 по теме "фундаментальное образование". В эту цепочку добавлены и несколько более ранних текстов, важных для понимания. Это немало, по этим ссылкам вы найдёте в пересчёте на книжный формат более сотни страниц текста, а если смотреть и содержание комментариев и интересоваться материалами по ссылкам, то объём чтения легко потянет на книжку в 200 страниц. 

По сути, эти тексты являют собой "проектную документацию" для создания системы фундаментального образования в Школе системного менеджмента (http://system-school.ru/). Так что это не "попсовые" тексты для случайного читателя. Для уверенного их понимания нужно сначала разобраться с материалом моего курса "Системное мышление" (http://systemsthinkingcourse.ru/), и желательно ещё и курса онтологики (http://system-school.ru/kurs-ontologitcheskiy-fitnes/). 

Рекомендованный порядок чтения:

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

Предыдущая моя цепочка постов по образованию называлась "Подстрочник рассказа о тренажёре клуба одиноких мозгов сержанта Солта" и была посвящена теме развития беглости мышления с опорой на тренажёры — путём выполнения многих мелких заданий, как в физике, математике, информатике, но только набор предметов другой, начиная с системного мышления: https://ailev.livejournal.com/1287293.html.

  • 2 комментария

А можно полюбопытствовать, чем подтверждено «обучение хорошего инженера»? Что такие инженеры после вашего обучения создали? Не с целью подколоть, просто интересно

Для того, чтобы инженеры создали что-то именно после нашего обучения, их нужно обучать отнюдь не столько часов, сколько идут наши курсы — курс системного мышления 36 аудиторных часов, курс системной инженерии 36 аудиторных часов. То есть наши курсы по факту идут впрок уже состоявшимся инженерам и менеджерам. Ну, и они создают самое разное интересное после обучения (и в ходе обучения) — от каких-то прочностных напылений до лазерной 3D печати зубных коронок, от рамановских спектрометров до вычислительных методов для машинного обучения. Опять же, всё это закрытая информация, увы: проекты-то у нас обычно не "учебные", а вполне рабочие, и ими на публике предпочитают не делиться. Ну, и у нас не только инженеры выпускаются, но и техпредприниматели, и менеджеры. И даже методологи (например, довольно много тренеров проектного управления).

Можете поглядеть, например, какие были доклады на наших конференциях: http://system-school.ru/event/nautchno-praktitcheskaya-konferentsiya-20180415/http://system-school.ru/nautchno-praktitcheskaya-konferentsiya-sistemny-menedzhment-16042017/. Как видите, много докладов как раз разбирают вопрос об успешности-неуспешности использования материала курсов на практике.

803 words

In reply to Евгений Волков

Диаграмма фундаментального образования / Левенчук А.

by Евгений Волков -

Пишет Anatoly Levenchuk (ailev
2018-06-11 18:39:00

https://ailev.livejournal.com/1431940.html

Диаграмма фундаментального образования

Вот чуток дополненная (65 практик, 69 связей) диаграмма фундаментального образования (кликабельно):

Это просто чуток доработанный и повёрнутый набок для лучшей читаемости вариант диаграммы из поста "почему не работают трёхдневные курсы", читать про неё в целом там: https://ailev.livejournal.com/1430047.html (а вся цепочка "фундаментальное образование" -- https://ailev.livejournal.com/1427073.html). 

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

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

Эта диаграмма иллюстрирует следующее:

1. Всякие иерархии убоги, разнообразие жизни в УДК не упихнёшь. Сколько школ мысли, столько иерархий тут можно было бы нарисовать крупными мазками. А если мелкими мазками, то мазки одного человека утром и вечером будут существенно не совпадать. Показанные отношения "часть-целое" для дисциплин тут очень, очень условны. В конечном итоге, функциональная грамотность является частью всех дисциплин и тем самым входит во все методологии.

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

2. Всякие картинки убоги при хоть сколько большом размере (у меня экран 4К, 43", так что у меня даже запасец был для рассматривания такой картинки. Остальным сочувствую. А редактор был yEd, https://www.yworks.com/products/yed). Даже если бы я влепил бы сюда по формальному признаку на каждом узле по многоточию для показа многочисленных неупомянутых практик (а их ведь тьмы, и тьмы, и тьмы!), картинка бы распухла до абсолютно нечитаемых размеров. А сейчас она просто теряет читаемость, но не абсолютно.

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

3. В онтологику нужно засунуть было побольше (там и Байесовщина, и моделирование на полном спектре мышления, и прагматизм, и много чего ещё), прямо внутрь её узла. Но я сдержался. Крупными мазками, только крупными, тут не было цели мельчить. В какой-то мере наша "онтологика" это тоже "большая картина мира", "монстрообразная методология" и её тоже нужно было бы давать сереньким, а на этом уровне уныло перечислять все источники и составные части онтологики. Но нет. Я тут намеренно неформален.

4. Все эти soft skills при ближайшем рассмотрении оказываются вполне практиками. Я их тут не отражал. Но да, стейкхолдерское мастерство на этой картинке тоже есть, хотя нужно помучиться, чтобы его туда добавить. Оно будет уровнем повыше системного мышления (так как в нём явно используется понятие практики, стейкхолдера, и прочих системных понятий), но пониже прикладных практик, которые, конечно, все стейкхолдерским мастерством пользуются. Вот за эти сложности выражения мы и не любим такие "простые модульные диаграммы". Нет, жизнь сложней простых модульных диаграмм, не нужно эти диаграммы абсолютизировать.

UPDATE: обсуждения в фейсбуке -- https://www.facebook.com/groups/771940449578453/permalink/1503228213116336/https://www.facebook.com/ailevenchuk/posts/10213118746497344

 

deep_econom

11 июня 2018, 16:16:25 UTC

 [онтологика] --> [научное мышление]

смешно )))

если мне память сильно не врет, то я когда-то критиковал подобные диаграммы Вашего производства. 

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

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

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

deep_econom

11 июня 2018, 19:53:40 UTC Комментарий изменен:  11 июня 2018, 19:55:06 UTC

это был не я, 
может у меня кто выкладывал, типа ники Сантехник или Мудризм, на памяти у них типа таких глобальных диаграмм

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

согласен

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

dn2010

11 июня 2018, 16:42:26 UTC Комментарий изменен:  11 июня 2018, 16:44:56 UTC

 

Сейчас вроде исправилось, но возможно потому, что я залогинился написать ответ под постом.

Есть противоречие между тем, что ты трактуешь эту диаграмму одновременно:

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

Лучше бы упоминания про части убрать и стрелочки изменить.

А вот нет. Есть два варианта трактовки: модуль это что-то в операционном окружении, подключается через интерфоейс. И второй вариант: модуль это что-то, буквально входящее внутрь обращающегося к его сервису другого модуля. В софте бывает реализовано оба варианта: системный вызов трассируется либо во внешнюю среду, либо в run-time библиотеку. Тут многие свойства информационных объектов. То есть я утверждаю, что чтобы заработал кусок мозга с каким-нибудь PMI BoK, нужно будет в его состав включить в том числе кусок мозга с функциональной грамотностью. 

Так что чёрт с ними, со стрелочками. Замена стрелочек никого не спасёт. Ибо нету таких стрелочек, на которые было бы правильно менять!

vvagr

11 июня 2018, 18:31:22 UTC

Проблема-то не со стрелочками, на стрелочки мало кто обратит внимание, кроме тех, у кого и так всё куда надо включилось и на что надо опирается.

Проблема в том, что кусок мозга, ответственный за функциональную грамотность, не может быть одновременно включён и в кусок мозга, с PMI, и к кусок мозга с DSM.

А если уж обратить внимание на то, что в мозгу и прочих коннекционистских моделях никаких таких буквальных "кусков" нет, это пояснение совсем всё запутывает.

Но на вызовы во внешние совместно используемые библиотеки это всё же похоже, так что часть-целое тут совсем не при чём, просто лишнее умное слово.

ailev

11 июня 2018, 19:05:50 UTC

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

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

vvagr

11 июня 2018, 18:33:35 UTC

Кстати да, отсутствие какой-то приемлемой нотации для функциональных диаграмм - большая проблема. Что означает универсальный коннектор на функциональной диаграмме - недавно в ФБ обсуждали. Я настаивал на том, что это в большинстве случаев потоки и потенциалы, как в Моделике. 

Но вот ни в коем случае не часть-целое.

Увы, тут не "знание" течёт и перерабатывается. Тут совсем другое что-то происходит. И вот точно не хотелось бы определять это в какой-то парадигме информатики как "перекодировку" или "оценку" или ещё что-то в духе http://ailev.livejournal.com/1008054.html.

Тут, конечно, отношения более запутанные: в мозгу при процессинге ведь и не теория теорий работает с её наследованием, и не теория прототипов с её модификацией, а что-то совсем другое. Вот даже не хочу обсуждать. И у меня это работа сервисов, а не функций. У меня там модули, я не вдаюсь в то, как именно обрабатывается там информация и для чего. Я просто оговорил в тексте, что стрелочку "часть-целое" можно обсуждать по-всякому, тут это включение более фундаментального мыслительного сервиса в состав размышления по какой-то более прикладной дисциплине..

Прекрасная формулировка: "вычитывать мысли и излагать мысли".

Но я бы добавил: "работать со своими мыслями", т.е. "рефлексировать".
И как высшая степень такой работы, - "создавать новые смыслы".

Рискну вставить алтын в здешний пинг-понг про стрелочки:

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

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

 

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

Вот чуток дополненная (65 практик, 69 связей) диаграмма фундаментального образования (кликабельно): Это просто чуток доработанный и повёрнутый набок для лучшей читае...

AILEV.LIVEJOURNAL.COM

 
Комментарии
Arkadiy Rozhkov

Arkadiy Rozhkov Интересноая схема, вот только что такое ТРИЗ++ Что это за развитие?

 

 · Ответить · 18 ч

Анатолий Левенчук

Анатолий Левенчук ТРИЗ++ это современный вариант ТРИЗ, развивавшийся главным образом за рубежом и к практикам инженерии системной архитектуры добавивший множество практик инженерии требований и отчасти разработки концепции использования (концепции продукта.сервиса, ConOps). В Школе системного менеджмента это называется "системная методология инноваций", но в ядре там всё тот же ТРИЗ, не останавливавшийся в своём развитии с конца 80-х.

 
Arkadiy Rozhkov

Arkadiy Rozhkov А кто авторы развития? Ведь недостаточно сказать, что наука развивается. Нужны осязаемые доказательства этого развития. Новые методологии, публикации, приемы.

 · 
Arkadiy Rozhkov

Arkadiy Rozhkov Я к тому, что читаешь Г.С. Альтшуллера и всё предельно понятно. А читаешь современных авторов и не покидает ощущение словестной эквилибристики.

·  · 

Анатолий Левенчук

Анатолий Левенчук Там множество авторов, и они, как это водится, сходятся-расходятся постоянно, единого свода знаний в единой версии нет. И авторитетного источника, который сказал бы, где там словесная эквилибристика, а где реальное знание -- такого источника тоже нет. Мы разговариваем с людьми отсюда: https://matriz.org/

MATRIZ.ORG

 

1854 words

In reply to Евгений Волков

EduOps: ускоряем жизненный цикл фундаментального образования / Левенчук А.

by Евгений Волков -
Пишет Anatoly Levenchuk (ailev
2018-06-05 19:12:00

EduOps: ускоряем жизненный цикл фундаментального образования

Основная мысль этого поста: нужно двигаться к EduOps, меняя текущее разделение труда в педагогике. Это нужно для того, чтобы результаты исследований оказывались в виде компетенций в головах учеников в разы и разы быстрее, чем в текущей системе образования. Да, я говорю тут о механизмах, которые помогут реализовать Просвещение-2020 (https://ailev.livejournal.com/1430302.html).

Disclaimer: для понимания текста нужно как-то владеть системным мышлением в объёме курса "Системное мышление" http://www.systemsthinkingcourse.ru/, и основ онтологики (http://system-school.ru/ontologics -- не прозевайте, там 4й поток стартует уже 8 июня 2018), а также набором идей из цепочки моих постов "Фундаментальное образование" https://ailev.livejournal.com/1427073.html. Ещё нужно понимать онтики онтологизации из https://ailev.livejournal.com/1427265.html и системных описаний из https://ailev.livejournal.com/1429330.html. Без этого текст просто "многабукофф с непонятными словами". А ведь все эти "непонятные слова" подробно разъясняются в указанных текстах. Увы, разговаривать о новом образовании требует нового образования. Ну, и мне важно написать сейчас не попсовый текст (с этим вполне справятся и другие люди), а просто задокументировать для профессионального обсуждения некоторый набор идей.

Жизненный цикл образования 

Полный (то есть системный, а не проектный) жизненный цикл образования (как результата, 4D индивида, итоговой успешной системы, а не как процесса его получения -- то есть жизненный цикл куска мозга с совокупностью полученных в ходе образования компетенций, вдоль линии рассуждений об actionable знаниях/дисциплинах из раздела "знания/дисциплины вещны" в https://ailev.livejournal.com/1429330.html), удобно рассматривать для разных целей по-разному:
-- для образования человечества в целом (например, населения какой-то страны или населения глобуса -- то есть изготовление каких-то более-менее серийных в части фундаментального образования и малосерийных в части прикладного образования мозгов. Фундаментальное и прикладное образования различаются так, как это описано в тексте "почему не работают трёхдневные тренинги" https://ailev.livejournal.com/1430047.html)
-- образование одного человека, работа с его "образовательной траекторией". Так сказать, образовательный водопад против образовательной спирали.
-- образование в части буквально одной дисциплины.

Помним, что жизненный цикл -- это отсылка к обеспечивающей системе, т.е. всем тем добрым людям и их инструментам, которые занимаются разными практиками изготовления образованного мозга. Для целей настоящего поста общий жизненный цикл образования рассмотрим пока на примере одной дисциплины, но по-системному: с самого начала, с момента появления тех знаний, которые будут нейропрограммировать мозг. "Нейролингвистическое программирование" ведь исходило из очень близких идей -- "мозг всему обучается, и хорошему и плохому, причём задействуются в том числе и бессознательные механизмы", "обучение = программирование мозга какими-то текстами", причём тексты -- это всё что угодно, любые паттерны, см. "информатику" в https://ailev.livejournal.com/1008054.html, и там можно только чуть-чуть поправить в части явного введения понятия о спектре формальности мышления из "онтики онтологизации" https://ailev.livejournal.com/1427265.html. Так что образование по его сутевой практике -- это нейропрограммирование. Но не всё так просто, ибо мы должны (ровно как написано в учебнике системного мышления) проверить, что там происходит в самом начале жизненного цикла и после его окончания. И тут ситуация выглядит так:

-- исследователь и/или разработчик (R&D) добывает знание из природы (прородной или технической -- это неважно) и кладёт его описание на полку. Для меня это именно описание знаний, левая часть V-diagram, system definition. Исследования -- важнейшая часть практик разработки образования, и хотелось бы подчеркнуть, что в наш жизненный цикл исследования входят.

-- культур-трегер вдруг говорит, что это знание нужно народу для дела. Тут знание понимается уже как будущая дисциплина. В этот момент идёт усиленная инженерия требований к дисциплине: определяется интерес (понимаемый как concern из онтики системных описаний и готовятся специфические образовательные требования -- определяются интерфейсы с другими дисциплинами в образовательной системе, ограничения по объёму дисциплины, её границах, уточнения избранной "школы мысли" -- т.е. определение того, что есть "исследовательская секта", а что есть "исследовательский мейнстрим", и т.п.). Это место образовательной политики, и с этого момента "разработки концепции образовательного продукта", и далее "разработки требований" к образовательному курсу все и начинают обычно. Вот нет, у нас ЖЦ образования начинается с творчества -- исследований или разработок по решению каких-то противоречий, с решения проблемы, см. https://ailev.livejournal.com/1425331.html.

-- методист переваривает знание в учебный курс: учебник, задачник, экзамены (concept inventory). Обычно жизненный цикл образования считает вот это окончанием левой части V-диаграммы, а то и всей левой частью. Мы согласны, только начинаем левую часть с исследований и разработок, R&D. Нет исследований и разработок -- нет целостного образования, есть его маленькие фрагменты.

-- педагог заинтересовывает ученика и кладёт знание в голову в виде компетенции. Всё, знание стало actionable -- дисциплина начинает жить как некоторый кусок мозга ученика, плотно перевязанный связями с другими кусками мозга, где живут другие дисциплины и в любой момент готово сработать, оно превратилось в компетенцию. Не будем даже интересоваться, как именно это устроено внутри мозга. Это функциональное описание на системном уровне компетенций, меня не волнует тут нейрофизиология. Меня волнует только то, что для любого знания нужен не только носитель информации этого знания, но и интерпретатор, учитывающий это знание при действиях во внешнем мире. И мозг (или компьютер в датацентре, или компьютер в роботе, у которого ведь тоже могут быть компетенции) как раз такое место, где носитель информации и интерпретатор встречаются, и это позволяет обзывать такую дисциплину системой, привязывать её к 4D. Это и есть transfer, заключительная часть "изготовления дисциплины". Осталось проверить и провести приёмку, то есть выполнить V&V, а дальше принять компетенцию-кусок-мозга в эксплуатацию и эксплуатировать.

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

-- ученик находит проблемы в своих компетенциях. Он осознан, поэтому может эти проблемы отследить и описать. Он тем самым даёт отклик исследователю-разработчику, R&D продолжает добывать результаты с учётом этих "пользовательских запросов", всё образование по дисциплине проходит очередной цикл, мозги ученика получают patch (обновление, новую версию, "новую прошивку"). 

Вот этот последний пункт жизненного цикла важен, он расширяет жизненный цикл. Управление конфигурацией, управление изменениями, откат неудачных версий, вот это всё с компетенциями должно происходить как обновления в Windows (в принципе, обновление корпоративного софта или софта крупных вебсайтов происходит примерно так же, только процедуры чуть менее известны). Ну, или как обновления приложений в телефонах.

Тем самым поставка образования из разовой превращается в сервис, "последняя версия Windows 10, дальше она будет вечно обновляться", и точно так же "Последний аттестат вашего образования вы только что получили, далее мы будем непрерывно его обновлять. Никаких гарантий необновившим". Плохо обновляют? Меняем провайдера образования на того, кто это делает лучше!). Мозги в этом плане мало отличаются от телефона, который только и делает, что меняет ОС и приложения -- чтобы быть современным!

Тут всё уже хорошо для обсуждения, чётко видно антикварное разделение труда и чудовищный time to market, особенно в фундаментальных дисциплинах с надеждой на массовый выпуск мозгов со state-of-the-art мировоззрением. 

В прикладных дисциплинах при мелкосерийном выпуске обученных мозгов время от окончания исследований до получения результата вполне можно делать небольшим. Всякие разработчики прикладных методик типа Kanban for developing или Requirements discovery разъезжают по миру с концертами, сеют разумное-доброе-вечное в разных городах и весях. Они себя и позиционируют-то как консультанты-тренеры-учителя, а не как разработчиков! И пишут по результатам своих исследований книжки, которые справедливо воспринимаются как учебники. Эти учебники они поддерживают своими очными курсами, а иногда и онлайн-курсами -- беда только в том, что масштабирования тут особого в их жизненных циклах нет, но иногда оно вполне происходит. 

Переходим к EduOps

Для чего нам вдруг потребовалось такое рассуждение? Для того, чтобы предложить концепцию EduOps ровно так же, как ранее были предложены концепции DevOps, DataOps и далее NoOps. Команды (не отдельные люди!) разработчиков содержания образования, то есть те люди, которые проводят R&D в каких-то предметных областях (в том числе фундаментальных предметных областях -- онтологике, системном мышлении и т.д.), берут на себя ответственность не просто за исследования, но и за эксплуатацию результатов исследований -- то есть за то, чтобы результаты их исследований превращались в компетенции.

Идея DevOps решала проблему невидимой высокой, но вполне кирпичной стены между левой и правой частями V-диаграммы в информационных проектах. Исходные коды перекидываются разработчиками (Developers) эксплуатационщикам (Operations) с воплем "от нас ушло!" и немедленным требованием денег. Самые сознательные разработчики с тяжёлым вздохом вдруг признали ответственность за то, что происходит с исходными кодами после того, как "от них ушло" и назвались DevOps. Результаты? Выпуск пары-тройки релизов в день на "боевые сервера", вместо одного релиза раз в полгода или раз в год. Скорость разработки не изменилась, но вот скорость получения результатов разработки пользователями изменилась в разы и разы.

Потом это же произошло с работниками, занимающимися данными -- появились DataOps. В 2011 году появился термин NoOps -- ибо была поставлена задача автоматизации происходящего в system realization, и сопутствующая дискуссия, что никакого NoOps не выйдет, потому как какие-то люди должны таки заниматься этой автоматизацией. Эта история DevOps-DataOps-NoOps с большим числом ссылок написана вот тут: https://ailev.livejournal.com/1367897.html.

Моя идея в том, чтобы включить R&D в жизненный цикл образования (это, кстати, не новая идея -- в "Педагогика и логика" Георгий Петрович Щедровицкий высказывал именно её, отцы-основатели МФТИ в своей "образовательной системе МФТИ" явно проговаривали именно её, и несть примеров именно этого). Отличие моего предложения в том, что я предлагаю явно следовать идеям DevOps: нужно чуть подхакать и Dev часть и автоматизировать по максимуму Ops части, чтобы иметь возможность выкатывать по множеству обновлений версий в день, а не обновляться раз в двадцать пять лет (срок физического вымирания поколения учителей), как это происходит с фундаментальным образованием сейчас.

Примером тут может служить Andrew Ng и другие исследователи Deep Learning/Machine Learning/AI, которые ведут исследования, а результаты оформляют зачастую не только как статьи, но и как лекции во всевозможных школах, делают видеокурсы, тьюториалы. А ещё их исследования легко воспроизводимы (публикуются данные), поддержаны инструментами (они публикуются тоже, благо это софтверные инструменты), см. подробности в "как организован прогресс в AI и почему там всё быстро", https://ailev.livejournal.com/1360574.html

Есть мощный выход от "упражнений для учёбы" в "проекты для дела" -- Kaggle (https://www.kaggle.com/) используется и учениками для тренировок, и промышленниками для того, чтобы задать какое-то новое направление в исследованиях и разработках. И этой же цели служат разнообразные другие соревнования и хакатоны (начиная с DARPA Grand Challenge, в котором приняли участие студенческие команды в том числе -- это тоже было частью образования, равно как частью исследований, https://ru.wikipedia.org/wiki/DARPA_Grand_Challenge).

Идея benchmarks и учебных datasets с упражнениями тут стоят очень недалеко. Исследования и образования, экзамены для исследователей с их идеями и учеников с их освоением материала -- всё потихоньку смешивается. Всё уже происходит, нужно только структурировать лучшие практики происходящего, и для этого хорошо подходит риторика EduOps.

Параллельное фундаментальное образование

Ещё образовательная инженерия (если уж заговорили на языке EduOps) перемешивается с исследованиями в традициях параллельной инженерии (concurrent engineering, https://ailev.livejournal.com/943532.html): все ведущие практики разных стадий жизненного цикла по факту идут вперемешку. Пусть это будет параллельное образование, concurrent education. То есть будущее образования я вижу не столько в изменении поздних стадий жизненного цикла (например, очередной хайп по поводу edutainment и очередной загиб всех этих попсовых "игрофикаций"), в особом внимании к общей организации жизненного цикла -- по образу и подобию DevOps.

А само изготовление нужного мозга, вестимо, будет автоматизироваться, равно как огромное внимание будет уделяться управлению конфигурацией не столько на уровне проекта/design ("в порядке ли все учебники на полке? Правильные ли у них версии? Совместимы ли между собой?"), но на уровне воплощения системы ("В порядке ли все компетенции? Правильные ли у них версии? Совместимы ли между собой?").

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

EduOps -- это про организацию жизненного цикла образования в Просвещении-2020, то есть всё это должно заработать не только в прикладном образовании, но и в фундаментальном, где мы должны столетний жизненный цикл массового перевода результатов исследований в массовые мыслительные компетенции сократить до пятилетнего.

Это мы и делаем в Школе системного менеджмента, http://system-school.ru/. Скажем, я не только исследования по системному мышлению и методологии системной инженерии и системного менеджмента веду, но и учебник написал, и задачами озаботился, и даже MOOC сделал. Это далеко не EduOps, как это должно бы быть, но ещё не вечер -- мы медленно-медленно ползём в правильном направлении. Этот пост про осознанность этой ползьбы: мы должны чётко понимать то, что делаем, иметь какую-то приличную онтику для обсуждения происходящего, и желательно не изобретать свою, а "встать на плечи гигантов". Мы и встаём на плечи гигантов, в данном случае на плечи исследователей и разработчиков из DevOps, DataOps, NoOps.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/groups/771940449578453/permalink/1497615923677565/

По ваш мнению:
1) без нейромашинных интерфейсов перспективы есть? Хорошие?
2) толковые вещества пригодятся/понадобятся?
3) что делать с "неоткатываемостью" реальных мозговых прошивок (особенность устройства живого мозга), …
… из-за которой каждый следующий нейропрограммный шаг должен учитывать существование и влияние всех предыдущих, уникальные для каждого индивида?

redmassacre

6 июня 2018, 12:38:30 UTC Комментарий изменен:  6 июня 2018, 12:38:48 UTC

там на днях какие-то британские ученые вроде нашли где память лежит (не знаю, как дополнение к вопросу 3, или сбоку-припёку)

Видов и механизмов памяти гораздо больше одного.
Умозрительно — с дюжину (базовых и производных).

Вот то что [скорее всего] работает в верхней части иерархии когнитивных систем, там где нужны абстрактность+адаптивность+динамика репрезентативной системы.

Оно же подробнее

спасибо, будем посмотреть

1, 2 -- я как раз в группе нейронета только что написал: https://www.facebook.com/groups/nevronet/permalink/1061187754047545/ (Кофейный нейронет -- https://lenta.ru/news/2018/06/06/cofee/

употребление кофе до выполнения задачи улучшало оценки работоспособности коллектива в 1,4 раза по сравнению с контрольной группой. Другой эксперимент, в котором участвовали 62 студента, употреблявшие в ходе исследования кофе с кофеином и без, показал аналогичный результат. Кроме того, добровольцы в опытной группе сообщали о повышении внимательности. По словам ученых, они чаще замечали, что другие испытуемые активно участвовали в обсуждении, а также сами старались внести свой вклад.

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

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

Что-то подобное уже сейчас делает knewton: он учитывает успешность-неуспешность маленьких учебных шагов и посылает тебя по короткому или длинному учебному маршруту в зависимости от ответов. Это ещё называют адаптивным обучением (не путать с программируемым обучением).

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

cantechnik

6 июня 2018, 14:16:49 UTC Комментарий изменен:  6 июня 2018, 14:17:04 UTC

/// в ходе исследования кофе с кофеином и без ///

Есть ещё элеутерокок и родиола, добровольцев надо найти;

/// Так и тут: непрерывные замеры перед шагами обучения/программирования/деплоймента курсов ///

Сложность замеряемого смущает.
Особенно в смысле эвристик/обоснований причинности "успешность/неуспешность :-: "предыдущие шаги"

cantechnik

6 июня 2018, 14:28:16 UTC Комментарий изменен:  6 июня 2018, 14:28:57 UTC

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

Т.е. кофеин растормозил коммуникативные компоненты и переразметил акценты в контексте "соц-панциря".
С [индивидуальным] интеллектом как таковым это связано опосредованно (и скорее всего статистически "неплоско").
Добавили бы амитал натрия, было бы ещё эффективнее.
Или каннабиоидов каких-нибудь лёгонких))

Эксперимент поставлен ненаучно.

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

В программерстве именно _убирают_ неудачный/мешающий код. Насовсем.
С мОзгами это технически невозможно (скорее всего).

--- ---
Насчёт веществ … я подразумевал не столько общую стимуляцию, сколько прямое (в известной мере адресное) воздействие на соотв [биохимические] механизмы памяти — через ингибирование/инициацию экспрессии генов etc., — в контексте _истинного_ исправления предыдущего нейрокода, … вкл методические/методологические когнитивные механизмы/подсистемы (интересующий нас функциональный уровень когнитома).

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

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

Во всяких там эзотерических помойках такое обычно тегируют как "наращивание осознанности".

Ну и в "1984" данная тема центральная, хоть и с другой стороны.

В целом - все правильно и очень созвучно моим представлениям. Но если говорить о том, что "встать на плечи гигантов", то надо DevOps дополнить еще двумя составляющими, которые в IT ему предшествовали, и на которые DevOps в значительной мере опирается: это Agile, сделавший переход от поставки законченного проекта к итеративной поставке малыми порциями, и UX, как раз дотянувший левую ветвь V-диаграммы до конечного пользователя и рынка (когда стейкхолдер формулирует задачу как "занять 20% рынка таких-то пользователей"). В каждом из них - свои гиганты и их надо тоже привлечь.

Потому что без этого мы будем иметь задачу перевода в DevOps legacy-продуктов, подготовленных старой школой и университетом. В IT devops на legacy обламывается...

Дык я, вроде, ясно обозначил: исследователи берут ответственность за скорейшее донесение своих результатов прямо до мозгов курсантов (не пишу "студентов", потому как неявно идёт отсылка на возраст, а тут универсально всё). Я не пишу, что исследователями доносится legacy. В этом же фишка: не что системные администраторы приходят в гости к разработчикам забрать их продукты, а разработчики свои продукты сопровождают вплоть до момента эксплуатации их. Так что никаких legacy, и можно бессмысленно ещё пообсуждать: делаются ли исследования по тщательно разработанному плану, или там варианты agile )))

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

Да, хорошо сказано: в курсе системной инженерии вышли на системное мышление, а затем и на патч мышления вообще. Ибо иначе не получается. И да, патч мышления вообще весьма и весьма объёмен. Но ничего не попишешь.

В принципе, нейронная сетка, которая обучается не с нуля, а с хотя бы ошибочного "черновичка", много быстрее обучается. Так что это всё быстрее будет, чем с нуля мировоззрение делать: хоть что-то старое из настроек сетки, да останется )))

3282 words