Консультирование и преподавание. Образование.
Я уже много раз тут писал, что считаю себя консультантом -- и тем самым имеющим прямое отношение к образованию (но не преподаванию). Попробую пояснить тут это с использованием аппарата ситуативной инженерии методов.
Все образование крутится вокруг дисциплин -- самых разных методов (практик и шаблонов их применения), которые цветут и пахнут вокруг какой-то онтологии.
Эти дисциплины можно условно разбить на общеметодический уровень и ситуационный уровень (http://ailev.livejournal.com/755969.html):
-- общеметодический уровень описывает онтологию и методы, еще не касаясь особенностей системы, стадии ее жизненного цикла и используемого инструментария.
-- ситуационный уровень требует конкретизации онтологии и методов для конкретной системы (или типа систем), ее стадии жизненного цикла (или набора стадий) и используемого инструментария.
Я утверждаю, что задача преподавателя -- это научить студента общеметодическому уровню той или иной дисциплины в степени, достаточной для того, чтобы студент не растерялся и на ситуационном уровне смог выполнить адаптацию метода. Научить этому можно, например, используя имитационные системы. Преподаватель дает студенту задачи на придуманных им системах, их стадиях жизненного цикла и выбранном им инструментарии, студент их решает, применяя метод, которому его учат.
Задача консультанта -- разобраться сначала с ситуацией клиента (определение: ситуация -- это когда непонятно, что делать, т.е. непонятен метод). То есть нужно понять, какова система, какова ее стадия жизненного цикла, каковы обеспечивающие системы -- в том числе инструментальное окружение. Понять, какой метод может клиенту помочь в его ситуации и найти этот метод в эээ... интернете, если метод консультанту неизвестен. Если метод не находится, то создать его самостоятельно: заняться методологией как деятельностью, для чего провести всякие исследования и затем заняться инженерией метода. Клиент дает консультанту задачу в виде своей системы, ее стадии жизненного цикла и инструментов -- и консультант готовится к ее решению путем нахождения правильного метода. И вот тут самое интересное: в этой ситуации консультант должен выполнить образовательную практику -- передать знание о методе клиенту, чтобы он сам решил свою задачу, применил метод, но не к учебной системе, а к своей системе.
Идеальный случай был бы такой: консультант становится на некоторое время преподавателем, дает клиенту задания на "системах из задачника", а затем обученный клиент идет к своим системам и быстро-быстро применяет полученные знания на практике.
Такого идеального случая не бывает, ибо консультанту никто не даст стать преподавателем: метод нужно создавать вместе с клиентом (потому как клиент обычно хорошо знает свою систему, стадию жизненного цикла и инструменты), попутно меняя границы системы и даже саму систему, стадии жизненного цикла и инструментальное окружение, каким-то чудесным образом (ибо домашние задания клиенту давать невозможно -- это ведь он дает консультанту задания!) передавая ему онтологию нужной дисциплины и мотивируя на применение метода на практике. То же самое образование, что и у преподавателя, но в гамаке и на лыжах в максимально неприспособленных для преподавания условиях.
Теперь на примере системной инженерии.
Если я преподаватель системной инженерии, то я читаю курсы системной инженерии примерно на том уровне общности, на каком дан стандарт ISO 15288 (т.е. "для систем любой природы, любого уровня в структуре подсистем, любого масштаба и любых стадий жизненного цикла"), или руководство по конкретной дисциплине системной инженерии (например MFESA -- описание инженерии системной архитектуре опять же "для любой системы... и т.д."). Задачки из задачника, разборы ситуаций, кейсы и так далее.
Если я консультант, и понимаю, что клиенту можно помочь методами системной инженерии (некоторым -- именно что применением всей системной инженерии, некоторым -- особым вниманием к какой-то практике), то у меня не будет возможность читать им курс лекций и проводить семинарские занятия. Я должен буду уговорить обратиться к стандартам -- и сотрудники клиентов со скрипом прочтут стандарт (учебник не прочтут!). Трудные места я буду разъяснить не за флипчартом и не на учебной системе, а за третьей чашкой чая в каком-нибудь кабинете -- и вместо флипчарта будет размахивание руками, а вместо учебной системы первая попавшаяся под руку система, на которой сосредоточено внимание клиента (ничего, после третьего или четвертого объяснения на третьей или четвертой системе его бессознательное генерализует и интериоризует это трудное место, далее он и сам справится).
Итого: если преподаватель, то обсуждаются системы преподавателя, а ситуационный метод остается неизвестен (передаются только общеметодические знания). Если консультант -- обсуждаются системы клиента, и по ходу дела создается ситуативный (адаптированный к ситуации) метод.
Но в качестве исходного сырья и у преподавателей и у консультантов должен быть запас хороших методов, чтобы не приходилось разыскивать эээ... в интернете (а то и создавать, уж какие получатся) абсолютно все методы ввиду полной методологической безграмотности.
У нас такой запас методов называется PraxOS (другой такой запас методов у других консультантов -- www.opfro.ogr). Совершенно понятно, если PraxOS будет использован преподавателями для образования. Но мы будем использовать его для консалтинга: проделывая ситуационную инженерию метода для каждого клиента.
Преподавание же у нас довольно редкая и эпизодическая деятельность, скорее уж побочный продукт.
Так что все эти "программы курсов" у меня в блоге нужно рассматривать не столько как планы нашей возможной преподавательской работы, сколько альтернативным способом представления методического знания ("библиотека методов"). Признаюсь честно, не так давно я узнал про ситуационную инженерию методов и начал описывать свою деятельность в этих терминах -- поэтому все время и напирал на образовательную составляющую.
В любом случае, эти программы курсов/библиотеки методов служат великолепным сырьем для преподавательской работы (только к ним нужно добавить а) учебные задачки с указанием системы и стадии ее жизненного цикла и б) учебные инструменты -- используемый софт, бланки и т.д.).
А теперь резко поднимем планку для преподавания, и будем обсуждать не "тренинг", а образование (слово тут тоже поменяется с "преподаватель" на "учитель").
Тут же выяснится, что у каждого ребенка есть ситуация которую преподаватель обычно игнорирует, а принимает во внимание и временами переходит в роль консультанта -- дает нужные для текущей ситуации методы (иногда даже прихватывая их не только из своего личного опыта, но и из эээ... интернета), и тогда по факту ребенок ставит задачки учителю-как-консультанту. Но дальше учитель отличается: его главная задача (в отличие от главной задачи консультанта) -- это заменить задачки ученика на те задачки, которые учитель считает правильными (вопрос о содержании образования). И вместо "давай я научу тебя хвастаться картинкой не только друзьям, а всему миру -- покажу как выложить картинку на Flickr до того, как тебя этому научит первый встречный" скорректирует изучаемую дисциплину на нужную ученику в его будущих ситуациях, а не в его текущей ситуации и одновременно заменяя реальную систему, ее стадию жизненного цикла и инструментарий из текущей ситуации ученика на учебную систему, стадию жизненного цикла и инструментарий (ибо реальных у ученика сейчас нет -- учим-то будущим ситуациям!) -- "ну что, ты еще не ловишь кайф от решения дифференциальных уравнений? Мы ведь их решаем с тобой уже пару месяцев!".
Теперь можно пообсуждать, может ли переходить консультант в позицию учителя (и менять задачки, которые хочет с ним решать клиент, и тем самым менять набор методов, которым он научит в итоге клиента) -- пусть сценирование такой ситуации будет предлагаемым читателю этого постинга мыслительным упражнением.
Это все, конечно, очень зыбкие материи. Мне очень радостно, что язык ситуативной инженерии методов вводит нужные различения и помогает разобраться в ситуации с преподаванием, консультированием и образованием. Мы на верном пути.
Все образование крутится вокруг дисциплин -- самых разных методов (практик и шаблонов их применения), которые цветут и пахнут вокруг какой-то онтологии.
Эти дисциплины можно условно разбить на общеметодический уровень и ситуационный уровень (http://ailev.livejournal.com/755969.html):
-- общеметодический уровень описывает онтологию и методы, еще не касаясь особенностей системы, стадии ее жизненного цикла и используемого инструментария.
-- ситуационный уровень требует конкретизации онтологии и методов для конкретной системы (или типа систем), ее стадии жизненного цикла (или набора стадий) и используемого инструментария.
Я утверждаю, что задача преподавателя -- это научить студента общеметодическому уровню той или иной дисциплины в степени, достаточной для того, чтобы студент не растерялся и на ситуационном уровне смог выполнить адаптацию метода. Научить этому можно, например, используя имитационные системы. Преподаватель дает студенту задачи на придуманных им системах, их стадиях жизненного цикла и выбранном им инструментарии, студент их решает, применяя метод, которому его учат.
Задача консультанта -- разобраться сначала с ситуацией клиента (определение: ситуация -- это когда непонятно, что делать, т.е. непонятен метод). То есть нужно понять, какова система, какова ее стадия жизненного цикла, каковы обеспечивающие системы -- в том числе инструментальное окружение. Понять, какой метод может клиенту помочь в его ситуации и найти этот метод в эээ... интернете, если метод консультанту неизвестен. Если метод не находится, то создать его самостоятельно: заняться методологией как деятельностью, для чего провести всякие исследования и затем заняться инженерией метода. Клиент дает консультанту задачу в виде своей системы, ее стадии жизненного цикла и инструментов -- и консультант готовится к ее решению путем нахождения правильного метода. И вот тут самое интересное: в этой ситуации консультант должен выполнить образовательную практику -- передать знание о методе клиенту, чтобы он сам решил свою задачу, применил метод, но не к учебной системе, а к своей системе.
Идеальный случай был бы такой: консультант становится на некоторое время преподавателем, дает клиенту задания на "системах из задачника", а затем обученный клиент идет к своим системам и быстро-быстро применяет полученные знания на практике.
Такого идеального случая не бывает, ибо консультанту никто не даст стать преподавателем: метод нужно создавать вместе с клиентом (потому как клиент обычно хорошо знает свою систему, стадию жизненного цикла и инструменты), попутно меняя границы системы и даже саму систему, стадии жизненного цикла и инструментальное окружение, каким-то чудесным образом (ибо домашние задания клиенту давать невозможно -- это ведь он дает консультанту задания!) передавая ему онтологию нужной дисциплины и мотивируя на применение метода на практике. То же самое образование, что и у преподавателя, но в гамаке и на лыжах в максимально неприспособленных для преподавания условиях.
Теперь на примере системной инженерии.
Если я преподаватель системной инженерии, то я читаю курсы системной инженерии примерно на том уровне общности, на каком дан стандарт ISO 15288 (т.е. "для систем любой природы, любого уровня в структуре подсистем, любого масштаба и любых стадий жизненного цикла"), или руководство по конкретной дисциплине системной инженерии (например MFESA -- описание инженерии системной архитектуре опять же "для любой системы... и т.д."). Задачки из задачника, разборы ситуаций, кейсы и так далее.
Если я консультант, и понимаю, что клиенту можно помочь методами системной инженерии (некоторым -- именно что применением всей системной инженерии, некоторым -- особым вниманием к какой-то практике), то у меня не будет возможность читать им курс лекций и проводить семинарские занятия. Я должен буду уговорить обратиться к стандартам -- и сотрудники клиентов со скрипом прочтут стандарт (учебник не прочтут!). Трудные места я буду разъяснить не за флипчартом и не на учебной системе, а за третьей чашкой чая в каком-нибудь кабинете -- и вместо флипчарта будет размахивание руками, а вместо учебной системы первая попавшаяся под руку система, на которой сосредоточено внимание клиента (ничего, после третьего или четвертого объяснения на третьей или четвертой системе его бессознательное генерализует и интериоризует это трудное место, далее он и сам справится).
Итого: если преподаватель, то обсуждаются системы преподавателя, а ситуационный метод остается неизвестен (передаются только общеметодические знания). Если консультант -- обсуждаются системы клиента, и по ходу дела создается ситуативный (адаптированный к ситуации) метод.
Но в качестве исходного сырья и у преподавателей и у консультантов должен быть запас хороших методов, чтобы не приходилось разыскивать эээ... в интернете (а то и создавать, уж какие получатся) абсолютно все методы ввиду полной методологической безграмотности.
У нас такой запас методов называется PraxOS (другой такой запас методов у других консультантов -- www.opfro.ogr). Совершенно понятно, если PraxOS будет использован преподавателями для образования. Но мы будем использовать его для консалтинга: проделывая ситуационную инженерию метода для каждого клиента.
Преподавание же у нас довольно редкая и эпизодическая деятельность, скорее уж побочный продукт.
Так что все эти "программы курсов" у меня в блоге нужно рассматривать не столько как планы нашей возможной преподавательской работы, сколько альтернативным способом представления методического знания ("библиотека методов"). Признаюсь честно, не так давно я узнал про ситуационную инженерию методов и начал описывать свою деятельность в этих терминах -- поэтому все время и напирал на образовательную составляющую.
В любом случае, эти программы курсов/библиотеки методов служат великолепным сырьем для преподавательской работы (только к ним нужно добавить а) учебные задачки с указанием системы и стадии ее жизненного цикла и б) учебные инструменты -- используемый софт, бланки и т.д.).
А теперь резко поднимем планку для преподавания, и будем обсуждать не "тренинг", а образование (слово тут тоже поменяется с "преподаватель" на "учитель").
Тут же выяснится, что у каждого ребенка есть ситуация которую преподаватель обычно игнорирует, а принимает во внимание и временами переходит в роль консультанта -- дает нужные для текущей ситуации методы (иногда даже прихватывая их не только из своего личного опыта, но и из эээ... интернета), и тогда по факту ребенок ставит задачки учителю-как-консультанту. Но дальше учитель отличается: его главная задача (в отличие от главной задачи консультанта) -- это заменить задачки ученика на те задачки, которые учитель считает правильными (вопрос о содержании образования). И вместо "давай я научу тебя хвастаться картинкой не только друзьям, а всему миру -- покажу как выложить картинку на Flickr до того, как тебя этому научит первый встречный" скорректирует изучаемую дисциплину на нужную ученику в его будущих ситуациях, а не в его текущей ситуации и одновременно заменяя реальную систему, ее стадию жизненного цикла и инструментарий из текущей ситуации ученика на учебную систему, стадию жизненного цикла и инструментарий (ибо реальных у ученика сейчас нет -- учим-то будущим ситуациям!) -- "ну что, ты еще не ловишь кайф от решения дифференциальных уравнений? Мы ведь их решаем с тобой уже пару месяцев!".
Теперь можно пообсуждать, может ли переходить консультант в позицию учителя (и менять задачки, которые хочет с ним решать клиент, и тем самым менять набор методов, которым он научит в итоге клиента) -- пусть сценирование такой ситуации будет предлагаемым читателю этого постинга мыслительным упражнением.
Это все, конечно, очень зыбкие материи. Мне очень радостно, что язык ситуативной инженерии методов вводит нужные различения и помогает разобраться в ситуации с преподаванием, консультированием и образованием. Мы на верном пути.